I am currently doing some benchmarking on the DNS service at my place of work. One of the bigger anomalies this is throwing up is a significant number of domains where, in some cases the lookup is returning a NXDOMAIN response while in others I am getting a valid response to an MX lookup.

(The domains in question are external)

While its possible that this may be due to a difference in config between a pair of authoritative servers, I realized I don't know which response to expect when I try to resolve a domain with no glue records. (links to authoritative sources would be appreciated).


Strictly speaking, glue is only necessary in one scenario: nameservers falling within a zone cut defined by the same zone. RFC 1034 §4.2.1 makes this explicit, emphasis mine:

One of the goals of the zone structure is that any zone have all the data required to set up communications with the name servers for any subzones. That is, parent zones have all the information needed to access servers for their children zones. The NS RRs that name the servers for subzones are often not enough for this task since they name the servers, but do not give their addresses. In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response.

The idea that glue is "required" at the registry/registrar level is a widespread fallacy, mostly emerging from the the days when there were a scant few gGTLDs to choose from. As the number of TLDs to choose from has steadily increased over the years, it's becoming increasingly more common to encounter glueless TLD referrals. Take goo.gl for example:

$ dig @d.nic.gl +noall +authority +additional goo.gl
goo.gl.                 86400   IN      NS      ns4.google.com.
goo.gl.                 86400   IN      NS      ns3.google.com.
goo.gl.                 86400   IN      NS      ns1.google.com.
goo.gl.                 86400   IN      NS      ns2.google.com.

Note the conspicuous lack of ADDITIONAL data here. gl does not not need to provide glue for anything inside of com. When this scenario is encountered, it becomes necessary to recurse through the com TLD in order to obtain the IP address of one of those nameservers. Any glue encountered along the way will be followed as normal. I won't quote RFC 1034 §4.3.2 here as it's somewhat silly to restate basic operation fundamentals.

In short, glue is only mandatory where both the standards or the policy of specific registrars (or registries) require it. The latter requiring it is not necessarily an indication of the former. In cases where a glueless delegation from the TLDs is encountered, it's simply business as usual.

If glue were to be missing in a scenario where it is required (your actual question I suspect), and no other nameservers were available to provide the authoritative response, that would be a clear case of SERVFAIL. NXDOMAIN would imply that an authoritative server could be reached, which is not the case here. The server which defines the zone cut is not authoritative for data beneath the cut (RFC 2181 §6.1), and an inability to reach the authoritative servers means that you've arrived at a dead end.

  • All of this said, missing glue (where it is required) would be indicative of a pretty crappy registrar. Some name and shame is probably warranted here. – Andrew B Jun 21 '16 at 12:36
  • Thanks, but I already knew what glue records are - I was hoping to find out what response I would get if the glue was missing and was required – symcbean Jun 21 '16 at 12:36
  • See last paragraph. – Andrew B Jun 21 '16 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.