[sclug] Sticky DNS Glue.

Roland Turner raz.fpyht.bet.hx at raz.cx
Sat Oct 25 09:05:42 UTC 2003


On Thu, Jun 05, 2003 at 01:11:14AM +0100, James Fidell wrote:

> Quoting Roland Turner (raz.fpyht.bet.hx at raz.cx):
> 
> > For the vast majority of
> > situations, the glue is not neccessary, but other than for
> > delegations managed by particularly clueless registrars
> > (easily.co.uk springs to mind), it is ordinarily included to
> > provide performance and reliability improvements.
> 
> I think you'll find the general case is actually the opposite.

Argument by anecdote won't get us too far, but I take your point,
I was stating an opinion as though it were a fact; my apologies.

> Listing specific glue records for a domain where the nameservers
> are outside of the domain (and particularly where the domains
> containing the nameservers aren't managed by you) is a major
> pain and things will generally work a lot better if you *don't*
> list glue records where nameserver addresses are outside your
> control.
> 
> Consider, for example, you being a registrar listing my nameservers
> for a domain.  How do you deal with me changing the IP addresses of
> my nameserver?  You have to rebuild your zone files, checking the
> addresses for my nameservers each time.  How often do you do that?

As registrar, I would not attempt to deal with this at all. Presumably
the service you'd be offering your customers would include interaction
with the registrar(s) for any domains that you were managing. In
the event that you were changing the IP addresses of one or more
of your nameservers (I assume that you meant "nameservers" above,
not "nameserver"), that would of neccessity include notifying the
registrar(s), at the very least for any domains containing their
own delegated nameservers, even if you avoided providing glue records
for domains which did not. It is my experience that, for this
reason, most commercial providers of DNS service go out of their
way to avoid changing the IP addressess of their nameservers.

> I can wind down the TTL on my zone files running up to any IP address
> change for my nameservers, helping people pick up the new records as
> soon as possible.  After the change, you'll be giving out invalid data
> until such time as you rebuild the zone files, so this actually makes
> DNS less reliable.

As above, only if you were to make a habit of changing the IP addresses
of delegated nameservers without notifying the registrars of
affected domains; at the very least for those domains which
contain their own delegated nameservers. Notifying registrars is
simply part of the process of DNS management, in my experience
anyway.

If you are not in this habit, then this means that resolution for
a domain with glue records depends upon less domains being
available than resolution without them.

(N.B. You may be tempted to argue that redundant DNS servers are
rarely down, so this can be disregarded. I am making an assertion
about reliability, and therefore about which of two improbable events
is less likely to occur; outage of enough redundant servers to cause
a request to fail is less likely to occur when glue records are in use
than when they are not; my assertion is about the relative
likelihood of these two events occurring and is not altered by
the fact that both events are improbable.)

> Performance-wise, most people will have cached the NS data after the
> first query anyway, so whilst there's a small performance gain from
> having glue records, it's not that significant.

This argument doesn't fly; the same resolvers that cache the NS
record will cache whatever other information they obtain during
the same resolution from the same server(s), and do so for the
same period of time (oddball TTL configurations in the domains
notwithstanding). If the NS record is in cache, then it's pretty
likely that whatever was being looked up in the domain is also in
cache. Across the total number of non-cached DNS resolutions that
are performed, the vast majority request just one item from a
given domain ("what are your MX's?", or "what is the address of
www?", etc.). N.B. This is not the same as the total number of
DNS resoltuions Internet-wide; it is the number of non-cached
reolutions which determines performance.

Consequently, the absence of glue records will typically double
(at least) the amount of DNS traffic required to resolve lookups
in the delegated domain.

> You gave the example of easily.co.uk as a clueless registrar who doesn't
> list glue records.  I'm not necessarily going to disagree with the
> clueless bit, but let's check out a few others.  Your own domain,
> for instance.  The .cx registry doesn't hold glue records for its
> nameservers.

This is true, but as a customer of the .cx registry, I am not
impressed with their ability to cope sensibly with delegation,
much less with glue. There appears to be some creeping entropy in
their zone files; every now and then I re-enter my delegation,
and every now and then, bits of it appear to fall off and/or
change. (In fact, w.r.t Nard' original question, they also appear
to be confused about glue and reverse DNS.)

> How about someone bigger?  Say, Nominet?  They do hold
> glue records for all my .uk domains, but only because my nameservers
> appear inside a .uk domain anyway and therefore the glue records are
> required to exist.  They don't carry glue records where the nameservers
> are, say, in .com or .net.

Arguments of the form "those big[1] guys think X is true,
therefore X must be true" hold about as much sway with me as
arguments of the form "most people think X is true, therefore X
must be true"; which is to say "none at all".

- Raz

1: / rich / powerful / reputable / church-sanctioned /
government-sanctioned / voter-sanctioend / attractive / cool /
clever / funny / famous / ...



More information about the Sclug mailing list