Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My understanding is that if I have the nameservers for both and set to and, looking up will:

  • look up to find its nameservers, yielding no glue records (.com registry won't provide glue for .us domains)
  • look up and (necessarily both?), each of which will:
    • query, yielding glue records for and
    • apparently query and/or to get the address(es) for and/or (is this correct? this seemed to be my experience)
  • query and/or to get the address for

If instead, we have the nameservers for both and set to and, looking up will:

  • look up to find its nameservers, yielding glue records for and
  • query and/or to get the address for

Am I correct that in this case, there are only these two steps in the lookup? Specifically, I seem to be experiencing a volume of lookups in that suggests that lookups for are not always using the glue records, resulting in an extra step where and/or are looked up by querying and/or

(edited to highlight my minor questions buried in the first example and to try to clarify my primary question at the end.)

Maybe some diagrams will help, since I think I'm explaining this badly. Here's my understanding of what should happen when looking up if's nameservers are and


The third lookup step seems to be happening nearly universally, but doesn't entirely make sense to me. Should that third step really be there?

Here's my understanding of what should happen when looking up if's nameservers are and


Is my understanding of this case correct?

Here's what I think might be happening with around 1/3 of the lookups for with nameservers and (based on the number and timing of queries to the nameservers for various domains):


Is this actually possible and/or does it represent a badly-behaved client?

share|improve this question
up vote 2 down vote accepted

To add to Mit's answer. The best practice is to only use Glue Records to resolve those circular dependencies. See section 2.3 of RFC1912:

To quote:

Some people get in the bad habit of putting in a glue record whenever
they add an NS record "just to make sure". Having duplicate glue
records in your zone files just makes it harder when a nameserver moves to a new IP address, or is removed. You'll spend hours trying to figure out why random people still see the old IP address for some host, because someone forgot to change or remove a glue record in some other file. Newer BIND versions will ignore these extra glue records in local zone files.

Note that last bit if you're using BIND. Also, I think most DNS clients will ignore extra-domain glue records, which would explain what you're seeing.

Edit to follow up on comment.

With TLD glue records, you'd typically provide them to your registrar, but otherwise the same rules apply. I run domains in and .com. I also have name servers in both of those TLDs that are authoritative for all of my domains.

If I run dig ns and dig ns com, I can see the big heap of servers that are authoritative for those TLDs. If I pick one of those listed .com servers and dig @<server> ns <mydomain>.com it'll return all four name servers for my domain, but only the glue records of the name servers in the same TLD (supplied as ADDITIONALs), which is what you're describing.

If I run dig @< server> <myotherdomain>, I'll again get all four name servers, but this time accompanied by the glue records for the 3 of them in the TLD.

This is all as it should be. If all of your name servers are in the .us TLD, then clients looking for your .com domains will be told the domain names of your name servers by the .com servers; then the clients will perform another query on the .us servers to find their IPs. That extra round trip might sound inefficient, but it only has to happen once per TTL period per client. (typically 48 hours for TLD records.)

(Apologies if you already know all of the above). To answer the original question. Glue records are not intended to save DNS lookups. They're necessary to prevent infinite loops.

Edit 2

Sorry for waffling around the issue. I see what you mean, now (Good diagrams, by the way).

My understanding of how clients should behave is that if one has the opportunity to get authoritative RRs, then it should; but in this case, the client is asking the name server for its own A records, which is pointless, since the Glue is those A records.

I'm reaching the limits of my knowledge here, but I can't think of any situation why a client would need to do this. I'm guessing here, but perhaps the client implementation needs to check that the server is definitely authoritative for, even when that means what looks like a pointless, extra round-trip.

Try a dig +trace to see if it does the same thing. I'd be curious to see if it does the same lookup if the original query was for a name, too.

share|improve this answer
I'm not talking about glue records that I'm providing in any way. I'm talking about glue records provided by the TLD. I'm pretty sure that if at the .com registry the nameservers for are registered hosts in, the .com registry provides the glue records along with the nameserver host names when is looked up at the .com level. It can't do this if the nameservers are in because the .com registry does not know about .us hosts. – Isaac Dec 8 '10 at 17:19
I see what you mean, but I think it works the same way, in principal. I'll update by post with a bit more. – SmallClanger Dec 8 '10 at 18:12
You're a lot closer to my issue now. What I'm seeing in particular seems to be that (1) something on the order of 1/3 of the lookups for records in (whose nameservers are in seem to be causing lookups in, as if the server doing the lookup in is ignoring the glue records returned by the .com server for the nameservers; ... – Isaac Dec 8 '10 at 19:42
and (2) that if the nameservers for are in, the server doing the lookup in nearly always looks up ns* after its been given that IP as a glue record by .us when trying to look up ns* – Isaac Dec 8 '10 at 19:43
Perhaps my edits to the question adding diagrams of the three specific scenarios/questions that I have will make it clearer what I'm trying to ask. – Isaac Dec 8 '10 at 23:24

Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. If the name given in the delegation is a subdomain of the domain for which the delegation is being provided, there is a circular dependency. In this case the nameserver providing the delegation must also provide one or more IP addresses for the authoritative nameserver mentioned in the delegation. This information is called glue. The delegating name server provides this glue in the form of records in the additional section of the DNS response, and provides the delegation in the answer section of the response.

For example, if the authoritative name server for is, a computer trying to resolve first resolves Since ns1 is contained in, this requires resolving first, which presents a circular dependency. To break the dependency, the nameserver for the org top level domain includes glue along with the delegation for The glue records are address records that provide IP addresses for The resolver uses one or more of these IP addresses to query one of domain's authoritative servers, which allows it to complete the DNS query. This might fix the issue.

share|improve this answer
I think my original question was not sufficiently clear. Can you answer the bolded questions that follow each of the diagrams in my edited question? – Isaac Dec 8 '10 at 23:21

Glue is intended to bootstrap queries which would otherwise be unresolvable. Imagine no glue:

  1. query root for, get referral to com namesevers.
  2. query com nameserver for, get referral to, the nameserver for
  3. Oops, we don't have the IP for query com nameserver for
  4. goto 3.

The com nameserver needs to return an A record for or you never get there.

You can still run into problems with out of bailiwick delegations since authoritative nameservers don't often return glue records for those. For example:

  1. query com nameserver for, get answer of
  2. query us nameserver for, get answer of
  3. goto 1

Whoops -- neither the com nameserver nor the us nameserver will return glue for out of bailiwick referrals. DJB has some examples in more detail.

Anyway, glue is not intended as a shortcut, but as a mechanism to avoid loops. Caching provides your mechanism to save lookups.

share|improve this answer
I think my original question was not sufficiently clear. Can you answer the bolded questions that follow each of the diagrams in my edited question? – Isaac Dec 8 '10 at 23:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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