[sclug] Sticky DNS Glue.

[Roland Turner]

Nard wrote:

> The DNS names must have a "GLUE" record,

This is true in one particular case, yes.

> which means it has to have reverse lookup.

Glue records have nothing to do with in-addr.arpa (aka reverse
lookup). They are additional A records alongside the NS records
required for a delegation.

Consider how foo.com is actually delegated:

- The .com zone file contains (at least) two NS records for foo.com

- Typically these will point to something like ns1.isp.com and ns2.isp.com

foo.com       IN    NS    ns1.isp.com.
              IN    NS    ns2.isp.com.

Conceptually (but not actually, there's lots of caching and
short-cutting in real DNS), a machine trying to resolve
www.foo.com into an IP address will look in its root hints file
to find a root domain server, then ask it who to ask about .com,
then ask that server who to ask about foo.com, then ask that
server for an A record for www.foo.com. NS records always refer
to a hostname, not an IP address, so the resolver must run the
whole process on ns1.isp.com to find the address of the
nameserver to ask about www.foo.com. Perhaps you are thinking
that this is a little inefficient? Worse, what if the NS records
for isp.com point back to foo.com?

Both of these problems are solved with the addition of "glue"
records, like this:

foo.com.      IN    NS    ns1.isp.com.
              IN    NS    ns2.isp.com.
ns1.isp.com.  IN    A     1.2.3.4
ns2.isp.com.  IN    A     5.6.7.8

In this way, the delegating domain's authoritative nameservers
can provide a clue (a glue clue?) to client resolvers in order to
avoid needless traipsing around the DNS. 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 mentioned above that there is one case in which glue records
are required; it is the case where the delegated nameservers have
their names inside the delegated domain. Here is a particularly
relevant example that I sorted out this week:

  $ dig @A.GTLD-SERVERS.NET. countersnipe.com

  ; <<>> DiG 9.2.2 <<>> @A.GTLD-SERVERS.NET. countersnipe.com
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60655
  ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

  ;; QUESTION SECTION:
  ;countersnipe.com.              IN      A

  ;; AUTHORITY SECTION:
  countersnipe.com.       172800  IN      NS snow.countersnipe.com.
  countersnipe.com.       172800  IN      NS ice.countersnipe.com.

  ;; ADDITIONAL SECTION:
  snow.countersnipe.com.  172800  IN      A       217.155.62.174
  ice.countersnipe.com.   172800  IN      A       212.13.199.83

  ;; Query time: 107 msec
  ;; SERVER: 192.5.6.30#53(A.GTLD-SERVERS.NET.)
  ;; WHEN: Wed Jun  4 23:07:02 2003
  ;; MSG SIZE  rcvd: 103

Notice that the answer from A.GTLD-SERVERS.NET (which just
happens to be the ultimate authority for .com; working out how I
know this is left as an exercise for the reader with dig and a
copy of the DNS root zone hints file from a bind installation)
contains _both_ the names of the nameservers and the addresses
for those names. If the addresses were not included, it would
simply not be possible for someone looking up countersnipe.com
to find the delegated nameservers and therefore to ask any
further questions. The address records appear in a.gtld...'s
response because the .com zone contains them as glue records
to accompany the delegation.

I suspect that this is the situation that you've encountered; if
your registrar can't cope with this, find another.

- Raz