5 ms·

Maybe I'm missing something here, but isn't this only a problem if you migrate your domain DNS away from DO and forget to also change the nameserver with your r

Maybe I'm missing something here, but isn't this only a problem if you migrate your domain DNS away from DO and forget to also change the nameserver with your registrar? So of course, if you tell the world "These guys over there are responsible for resolving my domains" you shouldn't be surprised if they actually do this.

oefrha 6y ago
1. The guys over there responsible for resolving my domains should probably verify that they're actually my domains. You want to offer an authoritative nameserver service you better take it serious. 2. Someone can register your domain first and you won't even be able to migrate in (at least without customer support).
- vegardx 6y ago
  I'm not sure how you imagine that you could prove that you owned the domain, on a technical level. You're updating the NS-records for your domain at the top level domain, being able to do that should provide enough proof that you in fact own this domain.
  - oefrha 6y ago
    Of course there are ways to prove you own a domain, e.g. one way Google verifies domain ownership is through a TXT record, the content of which is only known to you until you set it. (Well, that doesn't work if the registrar doesn't offer any DNS service other than submitting NS records to a zone file.) The NS records updated to generic, known values shows that someone who owns that domain intends to use your nameserver, but that someone doesn't have to be the one claiming the domain. If two accounts try to claim a domain at the same time, and the NS records have been set, which account do you award the domain to? Also, strict proof may not be necessary, there's the Cloudflare/Route53 way with a pool of nameservers used for verification. Cloudflare has a blog post explaining that: https://blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers/ https://blog.cloudflare.com/whats-the-story-behind-the-names... (Disclaimer: I'm not sure if account-specific combos are attacker-proof. Definitely better than generic ones though.)
    - vegardx 6y ago
      When you're changing NS-records you're actually updating the TLD, so at that point any other records should be considered moot, like the suggested TXT record. How do you imagine people migrate if the current name servers aren't responding any more? Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time". The way Amazon does it sure helps mitigate it. I'm just not sold on the idea that it's their responsibility to solve this. And I suspect they do this for other reasons as well, like spreading out across multiple TLDs.
      - oefrha 6y ago
        > any other records should be considered moot, like the suggested TXT record Yes, apparently I didn't think this through. That leaves the nameserver combo method. > Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time". That only solves the someone trying to snatch your domain after they find out your nameservers have changed. They can still initiate the claim before you do for any other reason. > I'm just not sold on the idea that it's their responsibility to solve this. That's an opinion (flawed if you ask me), and has nothing to do with whether proof of ownership is technically possible. And if the pool of combos is large enough and uniquely assigned to each account it's certainly a technical solution to the problem.
        vegardx 6y ago
        They can claim the domain before you, but like you mentioned used in combination with a matrix of name servers this should quite easily be mitigated. Another solution is to time box new zones. And don't get me wrong, I think the solution that Amazon and CloudFlare use are better than nothing. Having safe guards against people misconfiguring things are always helpful, and I'm sure it would result in fewer support cases.
deleted 6y ago
[deleted]

oefrha 6y ago

1. The guys over there responsible for resolving my domains should probably verify that they're actually my domains. You want to offer an authoritative nameserver service you better take it serious. 2. Someone can register your domain first and you won't even be able to migrate in (at least without customer support).

vegardx 6y ago
I'm not sure how you imagine that you could prove that you owned the domain, on a technical level. You're updating the NS-records for your domain at the top level domain, being able to do that should provide enough proof that you in fact own this domain.
- oefrha 6y ago
  Of course there are ways to prove you own a domain, e.g. one way Google verifies domain ownership is through a TXT record, the content of which is only known to you until you set it. (Well, that doesn't work if the registrar doesn't offer any DNS service other than submitting NS records to a zone file.) The NS records updated to generic, known values shows that someone who owns that domain intends to use your nameserver, but that someone doesn't have to be the one claiming the domain. If two accounts try to claim a domain at the same time, and the NS records have been set, which account do you award the domain to? Also, strict proof may not be necessary, there's the Cloudflare/Route53 way with a pool of nameservers used for verification. Cloudflare has a blog post explaining that: https://blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers/ https://blog.cloudflare.com/whats-the-story-behind-the-names... (Disclaimer: I'm not sure if account-specific combos are attacker-proof. Definitely better than generic ones though.)
  - vegardx 6y ago
    When you're changing NS-records you're actually updating the TLD, so at that point any other records should be considered moot, like the suggested TXT record. How do you imagine people migrate if the current name servers aren't responding any more? Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time". The way Amazon does it sure helps mitigate it. I'm just not sold on the idea that it's their responsibility to solve this. And I suspect they do this for other reasons as well, like spreading out across multiple TLDs.
    - oefrha 6y ago
      > any other records should be considered moot, like the suggested TXT record Yes, apparently I didn't think this through. That leaves the nameserver combo method. > Given the decentralized nature of DNS it's very simple to set things up before you change the nameservers, and this is widely considered to be the best practice. This also solves the "two accounts trying to claim a domain at the same time". That only solves the someone trying to snatch your domain after they find out your nameservers have changed. They can still initiate the claim before you do for any other reason. > I'm just not sold on the idea that it's their responsibility to solve this. That's an opinion (flawed if you ask me), and has nothing to do with whether proof of ownership is technically possible. And if the pool of combos is large enough and uniquely assigned to each account it's certainly a technical solution to the problem.
      - vegardx 6y ago
        They can claim the domain before you, but like you mentioned used in combination with a matrix of name servers this should quite easily be mitigated. Another solution is to time box new zones. And don't get me wrong, I think the solution that Amazon and CloudFlare use are better than nothing. Having safe guards against people misconfiguring things are always helpful, and I'm sure it would result in fewer support cases.

deleted 6y ago

[deleted]