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

[Mark Andrews]

Allowing a registration without NS records would fix this and other
problems like defensive registrations.  There is no real reasons
registrations must have NS records.  Some registries allow defensive
registrations.

Mark

In message <20140513215133.GJ2455 at mx1.yitter.info>, Andrew Sullivan writes:
> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org