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

[Andrew Sullivan]

On Thu, May 15, 2014 at 06:52:16AM +0200, Patrik Fältström wrote:

> One have to remember that if example.com have an ns in
> ns.example.net and example.net is not renewed, there are already
> problems between example.com and example.net that can not really be
> resolved by adding technical/engineering algorithms on it.

Yes, and I've tried to say that more than once.  Nothing in Registry1
can do anything at all about something in the completely other
Registry2.  There's no link.  I once suggested (I think it might have
been in a hallway, even) that maybe DNSOP could express an opinion
that for the simplest cases, in-zone glue was more likely to be kept
up to date than anything else; an entire flock of ducks immediately
appeared and nibbled me to death, so I decided that idea wasn't worth
pursuing either.  
 
> I think in the example you list Andrew, where you have example.com
> with NS ns.example.com and then example2.com with NS ns.example.com,
> first of all ns.example.com is not needed as an object for
> example2.com as the name is not in the delegated zone. I.e. we
> should use same rules as for glue. 

The problem is _not on the child side_, it's on the parent side.  On
the parent side, you absolutely do need glue for ns.example.com.  It's
an "internal" host object -- DNS geeks pronounce this "in-baliwick
glue in the .com zone" -- and at any given moment, even if that glue
is not needed right then, it might be needed in the next (consider the
case where example.com is changing its name servers.  The glue should
be created just before the change.  Therefore, the registry should
publish the glue in the zone, even if example.com is not at that
instant using ns.example.com).

> glue be needed, and in that case I think ns.example.com should be
> removed when example.com is removed. Reason for this is that I do
> see larger problems if ns.example.com exists and someone else is
> then registering example.com and "inherits" the ns.example.com
> object.

The protocol won't permit you to remove example.com when
ns.example.com exists.  That's how the OP's problem arose.  Registrars
rename the subordinate object (rename ns.example.com in our case) so
that it's no longer subordinate to example.com.  That makes the
protocol problem go away.  Maybe Joe's other explanation in this
thread makes it clearer, since I'm obviously not making this
apparent.  (Therefore, I'll shut up on the topic now :-) )

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com