181

This is a Canonical Question about DNS glue records.

What exactly (but briefly) is a DNS glue record? Why are they needed and how do they work?

Falcon Momot
  • 24,795
  • 12
  • 60
  • 89
LanceBaynes
  • 2,847
  • 9
  • 27
  • 31

4 Answers4

153

A glue record is a term for a record that's served by a DNS server that's not authoritative for the zone, to avoid a condition of impossible dependencies for a DNS zone.

Say I own a DNS zone for example.com. I want to have DNS servers that're hosting the authoritative zone for this domain so that I can actually use it - adding records for the root of the domain, www, mail, etc. So, I put the name servers in the registration to delegate to them - those are always names, so we'll put in ns1.example.com and ns2.example.com.

There's the trick. The TLD's servers will delegate to the DNS servers in the whois record - but they're within example.com. They try to find ns1.example.com, ask the .com servers, and get referred back to... ns1.example.com.

What glue records do is to allow the TLD's servers to send extra information in their response to the query for the example.com zone - to send the IP address that's configured for the name servers, too. It's not authoritative, but it's a pointer to the authoritative servers, allowing for the loop to be resolved.

Shane Madden
  • 112,014
  • 12
  • 174
  • 247
  • citation for "those are always names" – Pacerier Jul 23 '20 at 21:53
  • 1
    @Pacerier RFC 1034 (https://www.ietf.org/rfc/rfc1034.txt) and RFC 1035 state explicitly that NS records' RDATA contain a hostname or, as 1035 put it: "A which specifies a host which should be authoritative for the specified class and domain." – gaige Aug 14 '20 at 10:09
68

I requested that this answer be merged in from a duplicate question, as the existing answers did not explain the role of the ADDITIONAL section.

To see how it works, type this: dig +trace +additional google.com SOA

This will trace the nameserver authority starting from the root servers (+trace). Adding +additional will also show you the ADDITIONAL section of each DNS server response. Normally most people think of DNS in terms of the QUESTION and the ANSWER sections, but ADDITIONAL also plays an important role: if the nameserver knows the answers to any queries that are related to the answer, it can pre-emptively supply those answers in the ADDITIONAL section without requiring additional queries from your client.

Note that the authoritative nameservers for google.com are rooted under the domain they're authoritative for. (ns1.google.com, ns2.google.com, etc.)

When you ask a nameserver to supply the list of nameservers for a domain, they will often supply a list of A-type records (IP addresses) in the ADDITIONAL section, not just the NS-type answers: these are called glue records, used to prevent circular dependencies. In this case, those A records are served from the TLD (.com, .org, etc.) nameservers based on the IP addresses that someone supplied the DNS registrar responsible for the domain. They can usually be changed by logging into the admin web interface they supply you.

(disclaimer: AAAA records containing IPV6 addresses can also be supplied as part of the glue, but I left this out for simplicity's sake.)

Andrew B
  • 31,278
  • 11
  • 89
  • 126
  • Thank you for the detailed explanation. I've learned a lot. – Egemenk Feb 03 '13 at 14:34
  • Very good explanation. Wish I'd stumbled upon this detail of circular dependency resolution before my last job interview. I'm pretty sure my cluelessness on the subject cost me dearly. – converter42 Feb 18 '15 at 15:43
  • @converter42 To be fair, I don't think most sysadmins actually expect you to get that question right. I'm a DNS lead and I certainly don't. It *does* tell me when an interviewee knows DNS better than 80% of other admins though. :) – Andrew B Feb 18 '15 at 16:00
  • `+additional` just triggers displaying (on by default) or not (with `+noadditional`) of the additional section in the reply. It does not change what is sent on the wire to the nameserver nor what it sents back. – Patrick Mevzek Mar 26 '19 at 17:50
  • 1
    @Patrick The additional section is *not* on by default when executing `+trace`. That's why it's there. – Andrew B Mar 27 '19 at 16:13
  • 1
    @AndrewB noted, but it seems at least to depend on dig version or something else, in my `dig +trace` tests, adding `+additional` does not change the output at all) – Patrick Mevzek Mar 27 '19 at 16:17
  • @Patrick Must be fairly recent. It still doesn't in `DiG 9.9.5-9+deb8u17-Debian`, which suggests the behavior changed sometime after they started showing DS and RRSIG records in trace by default. – Andrew B Mar 27 '19 at 16:40
  • @AndrewB "DiG 9.12.0" – Patrick Mevzek Mar 27 '19 at 16:41
41

After searching forever and reading a lot about glue records and still not understanding what they were or how you can make them I finally found an answer and it's a very simple one.

As I understand there is no magic extra information sent from somewhere, this is how it works.

Lets say your domain is example.com and you want to use your own name servers ns1.example.com and ns2.example.com, you need at least two DNS servers.

  • ns1.example.com has IP 192.0.2.10
  • ns2.example.com has IP 192.0.2.20

In order for this to work now you need the top domain owner to put following records into their DNS.

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

Those two A records are the glue records and they need to be at the top domain, in this case .com, and not all registrars can get this done for you.

If this is wrong please correct me. I just thought I try explain in a simple way for others who can't find correct answer.

user9517
  • 113,143
  • 20
  • 201
  • 283
hasse
  • 529
  • 4
  • 2
  • 8
    The only caveat to your answer is that glue records are not limited to appearing in the top level domains. You can also have a `sub.example.com` that is delegated to `ns1.sub.example.com` and `ns2.sub.example.com` in the `example.com` zone. The nameservers for `com` have delegated `example.com` away from themselves and cannot provide glue for any of its children. – Andrew B Jun 23 '17 at 20:35
  • 5
    The key point seems to be that without a glue record, if the requested subdomain and name server are underneath the same domain, you will be stuck in an infinite loop: `sub.example.com` --> `example.com` --> `ns1.example.com` --> `example.com` --> `ns1.example.com`... and so on – Daniel Waltrip Feb 08 '18 at 20:38
  • 2
    I'm having a brain fart and each time I read an explanation of glue I don't quite get enough information - due I'm sure to my lack of knowledge of the meaning of the terms... in this answer when you @hasse when you say "These two A records are the glue records and they need to be at the top domain"... what do you mean exactly by "the top domain"? – Claud Nov 13 '18 at 20:57
  • 2
    @Claud a top domain (I think he means top level domain or TLD) are domains like com, net, org, (and the list goes on) found at the top of the domain hierarchy.. every domain name is a subdomain of another except these top level domains. – frezq May 25 '19 at 12:45
  • I don't see how domain registries fit into these answers about glue records. My domain registry has a DNS that can point to its own nameserver or my custom nameserver. But I can't change the TTL so I can migrate websites quickly. Does this have to do with glue records somethow? – David Spector Sep 13 '19 at 14:42
  • @DavidSpector TTLs are sometimes ignored by other DNS servers anyway if they dictate their own caching policies. Use `dig +trace` to have dig do a noncached lookup of your domain using the latest available data, it will recurse all the way to the TLD (.com, .net etc) servers then work back following the breadcrumb trail. (More info: https://serverfault.com/a/778830/32054) I just migrated nameservers for a domain - despite setting 60 second TTLs for the SOA and the most important A records, some servers are still caching old details 24 hours later... :-) – Chris Woods Feb 06 '20 at 12:50
  • I have never heard of "dig". I tried "dig +trace" in a command prompt, and the error message was "'dig' is not recognized as an internal or external command, operable program or batch file." More information on "dig" is needed if others are to use it. Concerning the poor support for TTL, why not change how it works? Why not keep DNS entries for a very long time (a month?), simply marking them as referenced or not? Then a "push" mechanism could distribute changes efficiently and quickly throughout the world. No room here for details. Polling is inefficient and should be abolished. – David Spector Feb 07 '20 at 13:28
  • @DavidSpector According to the error message you got, you seem to be using ms's "cmd.exe" shell. You need to gain access to a Unix box to be able to play with the cool toys. – Johan Boulé May 13 '20 at 00:28
  • @DavidSpector, there's no "push" mechanism, because a source server doesn't know who's subscribed and wants to be notified. The current model that involves "other" servers requesting the "source" for updates has proven to be more feasible. – Sam Sirry May 19 '20 at 12:19
  • Sam, Well, of course there is no push mechanism. The solution is very simple: keep the basic mechanism of propagation the same, but add the following functionality: add an optional flag to a DNS lookup to require an authoritative response. Then an end user who needs the latest update can (usiing a system commnand) force a chain of lookups (and data updates) starting at the local DNS and ending at the authoritative zone DNS. This instantly updates all the DNS caches in that chain, allowing an end user to use a zone DNS change instantly. Solves many problems. – David Spector May 20 '20 at 10:54
38

There is a precise (and concise) explanation on wikipedia.
To quote:

Circular dependencies and glue records

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.

. . .

For example, if the authoritative name server for example.org is ns1.example.org, a computer trying to resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in example.org, this requires resolving example.org 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 example.org. The glue records are address records that provide IP addresses for ns1.example.org. 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.

voretaq7
  • 78,916
  • 17
  • 127
  • 213