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

Mark Andrews marka at isc.org
Tue May 13 23:20:33 UTC 2014

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


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

More information about the dns-operations mailing list