3 ms·

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 confi

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.

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.