4 ms·

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 lev

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.
      - oefrha 6y ago
        > Having safe guards against people misconfiguring things are always helpful No, the problem is people can have their domains snatched even without misconfiguring things. You keep saying it's the users' fault, when the same could happen when users follow whatever you consider best practices.
        vegardx 6y ago
        No, they can't. The user has either failed to complete setting things up, or forgot to change the name servers to something else after removing it. It's a configuration issue created by the user. Some TLDs check for this, they won't transfer a domain to new name servers unless they already respond as authoritative name servers for that domain. The argument is that someone else could set up a zone before you. But there can't be duplicate zones, and the user should create this zone before changing the name servers. There are mitigation strategies that have already been discussed, but other than being a Nice Thing (tm) and likely lowering the volume of support tickets I don't see how this is the providers fault. You set the name servers before checking that you had control over said name servers, or forgot to change them when moving away.

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.
    - oefrha 6y ago
      > Having safe guards against people misconfiguring things are always helpful No, the problem is people can have their domains snatched even without misconfiguring things. You keep saying it's the users' fault, when the same could happen when users follow whatever you consider best practices.
      - vegardx 6y ago
        No, they can't. The user has either failed to complete setting things up, or forgot to change the name servers to something else after removing it. It's a configuration issue created by the user. Some TLDs check for this, they won't transfer a domain to new name servers unless they already respond as authoritative name servers for that domain. The argument is that someone else could set up a zone before you. But there can't be duplicate zones, and the user should create this zone before changing the name servers. There are mitigation strategies that have already been discussed, but other than being a Nice Thing (tm) and likely lowering the volume of support tickets I don't see how this is the providers fault. You set the name servers before checking that you had control over said name servers, or forgot to change them when moving away.