[dns-operations] Weirdness with glue for old (gone) DNS servers

[Andrew Sullivan]

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
ajs at anvilwalrusden.com