On Tue, May 13, 2014 at 01:53:36PM -0500, Chris Adams wrote: > However, I found (after re-adding the domain to our servers), the domain > works. "dig +trace" didn't work because while the not-in-service bit > doesn't resolve, the .COM servers include glue that still points to the > correct IPs. This IMHO is broken and confusing - does anybody know if > it is intentional? We are preparing to change our NS IPs, and I would > have no way of updating this stale glue.
Right. This is a hangover problem. But no, there's no general way to check this except for the child to check the parent for the glue for every name. The explanation of why this is follows, but it's long; if you just want to know what to do, "Check every name using your nameservers at the parent side for glue before renumbering". The problem comes because in the shared registration systems, different actors can depend on the same object. So, even of RegistrarA is the sponsor of (in EPP, "domain") example.com and (again, in EPP, "host") ns.example.com, RegistrarB might sponsor some name with host ns.example.com in the nameserver set. I suspect this arises usually because of domain name transfers, but it needn't. I suspect that most of the latter-day registries have this problem now to some extent, but since Verisign's shared registry system (with registrars and so on) has been around so long and is so large, one runs into it more there (I first encountered it at Afilias after we started operating .org). It's particularly a problem when there is glue associated to the host object, because that will often show up in the DNS. (For what it's worth, I encountered it at Afilias not because of a deletion, but because the UltraDNS servers, which is all we used in those days, would suppress any glue record that wasn't strictly required for in-baliwick resolution. The Verisign servers of the period didn't seem to have quite the same rule. Instantly, we took a bunch of people off the air. It was a fun day.) When RegistrarA wants to delete example.com (because nobody's paying for it), they can't do so unless they delete all subordinate-named objects. So, the existence of ns.example.com prevents the deletion of example.com. But you can't delete the host object when anything is linked to it. The answer is to rename ns.example.com to ns.example.com.invalid.com (IIRC, there's usually something in the registry to prevent actually naming it ns.example.com.invalid, which would solve much of this trouble because the glue would be suppressed). This leaves the host active as the NS for something, but it no longer has the offending subordinate name, so that domain can be removed. This solves the registrars' problem of paying for something they can't sell. It causes you problems. I encourage you to read the entry on "externality" in Wikipedia. Some many years ago when I still worked for a registry and cared about these things, I had an idea for a mechanism (using the poll queue in EPP) that permitted notifications to flow between registrars about these sorts of things, and that would have imposed costs on people who weren't playing nice. Everyone else told me I was stupid because the registrars would never permit it and it would have to go through the GNSO and don't piss off your customers you stupid not-salesperson. So I gave up. I still think it'd be a good idea, though. A -- Andrew Sullivan [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
