3 ms·

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. H

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
        > But there can't be duplicate zones, and the user should create this zone before changing the name servers. One of two things happen: 1. Both are allowed to initiate the claim before verification comes through (Cloudflare allows this, not sure about DO); result: domain snatched by attacker; 2. Only one initiation is allowed, in which case the attacker denied you your setup until a support ticket, and even then, how do you prove you’re not the attacker in the support ticket? Either case, disruption can be caused by an attacker. You keep saying mitigation is just a nice thing and providers are not responsible. What a weird hill to die on. Are you a provider?
        vegardx 6y ago
        The owner of the domain is responsible to make sure they are in control of the zone where they've decided to point the name servers. Failure to do so means that anyone able to create zones on these name servers can do so. On Amazon you can request a delegation set, which means a combination of four name servers. Do that enough times and I'm sure you'll have all the possible variations that could exist. For every Amazon account you can request 100 delegation sets, but it's easy to scale this out over multiple accounts. I'm also willing to bet you can easily get that limit raised to thousands of delegation sets by just telling support you're going to use the account for hosting tons of zones. I don't know the specifics of how CloudFlare does it, but I assume you're more than welcome to do the same, programatically. There's no hill to die on. I don't work for a provider, and how is that even relevant? Seems like a weird straw man argument or something. The potential risks of this is blown way out of proportions. You're still in control over the domain, just not the zone. Do stupid things, win stupid prices? In this case, letting someone else control your zone because you failed to understand how DNS works.
belorn 6y ago
For the vast majority of registrars you would find it hard to find one that do not offer DNS. For defunct registrars it does get more tricky but you can have better security than what is provided here. Have the customer first create an account and link the domain to the account and then change NS rather than the other way around. This solves the issue of people discovering domains that point to DO but has no linked account. Defunct registrars is a interesting problem. If they don't have functional name servers then it is also very likely that they don't have a functional portal and customer support in order to change the NS records. Defunct registrars are thus a pretty manual problem, so sacrificing security for easier process seems like a bad deal. A best practice should make the common case easy but secure, and the uncommon case secure and possible.

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
      > But there can't be duplicate zones, and the user should create this zone before changing the name servers. One of two things happen: 1. Both are allowed to initiate the claim before verification comes through (Cloudflare allows this, not sure about DO); result: domain snatched by attacker; 2. Only one initiation is allowed, in which case the attacker denied you your setup until a support ticket, and even then, how do you prove you’re not the attacker in the support ticket? Either case, disruption can be caused by an attacker. You keep saying mitigation is just a nice thing and providers are not responsible. What a weird hill to die on. Are you a provider?
      - vegardx 6y ago
        The owner of the domain is responsible to make sure they are in control of the zone where they've decided to point the name servers. Failure to do so means that anyone able to create zones on these name servers can do so. On Amazon you can request a delegation set, which means a combination of four name servers. Do that enough times and I'm sure you'll have all the possible variations that could exist. For every Amazon account you can request 100 delegation sets, but it's easy to scale this out over multiple accounts. I'm also willing to bet you can easily get that limit raised to thousands of delegation sets by just telling support you're going to use the account for hosting tons of zones. I don't know the specifics of how CloudFlare does it, but I assume you're more than welcome to do the same, programatically. There's no hill to die on. I don't work for a provider, and how is that even relevant? Seems like a weird straw man argument or something. The potential risks of this is blown way out of proportions. You're still in control over the domain, just not the zone. Do stupid things, win stupid prices? In this case, letting someone else control your zone because you failed to understand how DNS works.

belorn 6y ago

For the vast majority of registrars you would find it hard to find one that do not offer DNS. For defunct registrars it does get more tricky but you can have better security than what is provided here. Have the customer first create an account and link the domain to the account and then change NS rather than the other way around. This solves the issue of people discovering domains that point to DO but has no linked account. Defunct registrars is a interesting problem. If they don't have functional name servers then it is also very likely that they don't have a functional portal and customer support in order to change the NS records. Defunct registrars are thus a pretty manual problem, so sacrificing security for easier process seems like a bad deal. A best practice should make the common case easy but secure, and the uncommon case secure and possible.