DNS records: a sticky subject

Overview

This article is intended above all for people who choose their own domain name servers. This is no doubt a minority, since most holders delegate this choice to their Registrar or to the DNS operator of their choice. But if you’re responsible for choosing authoritative servers for a domain, this article may be of interest to you.

In order to understand glue, we first need to understand how the DNS works. (Have you seen our diagrammatic illustration below?)

A DNS resolver seeking information on a domain name, let’s say www.saintdenis.re, will first query the authoritative name servers for the root, then those for .re (managed by Afnic) and lastly those of the DNS hoster Oléane, which currently manages the saintdenis.re domain. So there are two successive delegations, from the root to the .re TLD and from Afnic to Oléane. Delegation works by the parent DNS zone indicating the authoritative name servers for the sub-zone or “child” zone located under it. It should be stressed that delegation is by way of names, not IP addresses.

With the “dig” command, we can see the reply from Afnic’s server when the resolver queries the IP address of www.saintdenis.re¹:

% dig @d.nic.fr www.saintdenis.re A
…
;; AUTHORITY SECTION:
saintdenis.re.		3600 IN	NS ns6.oleane.net.
saintdenis.re.		3600 IN	NS ns7.oleane.net.

So in essence the d.nic.fr server’s reply to its client, the resolver, is: “I don’ t know, but ask ns6.oleane.net or ns7.oleane.net.” This is delegation.

So far so good, but if the resolver is to continue its quest, it’s going to have to query these two Oléane servers, and to do that it needs their IP addresses. No problem – it queues the main query, i.e. that for www.saintdenis.re, and makes a new one, for ns6.oleane.net. This will go to the root² and then to Verisign (which manages .net). Once the resolver has the IP addresses of these servers, it will be able to query the information on www.saintdenis.re.

But in this case the servers³ of www.saintdenis.re were outside the domain (and indeed outside the TLD). Imagine we want to send an email to someone @inra.fr. The resolver has to ask for the names of the email servers of this domain, and to do so it has to go through the DNS resolution process. When it asks Afnic, the registry for .fr:

% dig @d.nic.fr inra.fr MX
…
;; AUTHORITY SECTION:
inra.fr.		3600 IN	NS ns3.inra.fr.
inra.fr.		3600 IN	NS ns2.inra.fr.
inra.fr.		3600 IN	NS ns1.inra.fr.

There will be a circular dependency; to obtain the addresses of servers such as ns1.inra.fr, the authoritative name servers for inra.fr will have to be queried, but to do this, we need their IP addresses, which can only be obtained by asking them… Glue is the solution allowing this vicious cycle to be resolved. Glue records are supplementary records returned by the “parent” domain server. The complete response was in fact:

% dig @d.nic.fr inra.fr MX
…
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4
…
;; AUTHORITY SECTION:
inra.fr.		3600 IN	NS ns3.inra.fr.
inra.fr.		3600 IN	NS ns2.inra.fr.
inra.fr.		3600 IN	NS ns1.inra.fr.

;; ADDITIONAL SECTION:
ns3.inra.fr.		3600 IN	A 147.99.111.234
ns2.inra.fr.		3600 IN	A 147.100.222.2
ns1.inra.fr.		3600 IN	A 138.102.119.26
…

The DNS client, the resolver, now has all the information it needs for the DNS resolution. These last three type A records (IP address in the old format), in the Additional section of the response, are the glue records. In the case of the response to the query on www.saintdenis.re, since the name servers were not in the zone served, no glue records were necessary.

The fact that the DNS has undergone so many changes since its creation makes it difficult to keep track of all the relevant technical standards. I recommend the standard known as BCP 219, which rigorously specifies the DNS terminology. (Section 7 defines glue records).

Managing the glue

Right, but for the authoritative servers for .fr to send the glue records to the DNS client, they need to know where to find them, which means they have to be in the .fr registry database. This database is fed by the registrars via the EPP (Extensible Provisioning Protocol). So the registrar needs to have sent this information on the glue records. And this is why, if you choose your DNS hoster yourself rather than accepting the default choice proposed by your registrar, and if the DNS servers that you indicate are in the domain that they are going to serve, you will have to indicate their IP addresses.

If you enjoy the nitty-gritty of the protocol, these glue records are transmitted by EPP in accordance with the RFC 5732 standard, which maps and defines host names of objects handled by EPP.

So we should point out that these glue records constitute additional work for domain name holders wishing to use the authoritative servers of their choice. And that’s not the end of the story by any means – glue records have to be kept up to date. The IP addresses of the authoritative servers may change. And then the glue records have to be changed, not just in the local database but also with the registry, through the intermediary of the registrar. Experience shows that this step is often forgotten. What are the consequences? If the known glue records of the “parent” domain are invalid (out of date), the domain loses at least one and probably several name servers since they can no longer be contacted⁴. Worse still, if the old IP address has been allocated to someone else, part of the traffic may be diverted to this other party. So it’s important to manage glue records rigorously.

In the domain or not in the domain?

As we have seen, glue records are not obligatory⁵ if the authoritative name server is not in the domain that it serves (the example of saintdenis.re above). In view of the additional work and responsibilities associated with glue records, should we place these name servers in the domains that they serve? There’s no easy answer to this, each method having its pros and cons. Having servers outside the domain means there’s no need to indicate and maintain glue records. Having servers in the domain avoids reliance on external domains over which there may be no control. This is why ANSSI recommends “giving priority to glue delegations when the use of glueless delegations introduces new third-party dependencies.” But in this case, be careful to keep the glue records exact when an authoritative server changes IP address.

Note that to see the dependencies of a domain, you can use NS Tree.

Finally, don’t forget that there may be more difficult cases, such as that of a domain A all the name servers of which are in domain B, all of whose name servers are in turn in domain A, thus creating a circularity from which there is no way out. When choosing name servers, take the time to consider the issue carefully.

Perhaps one day…

As we’ve seen, glue records allow the IP address of a name server to be provided such that the domain name can be resolved in cases where the latter uses name servers hosted in the same domain.

The IETF (Internet Engineering Task Force) project DELEG marks a radical change to DNS delegation (see my article “DNS delegation and its possible evolution with DELEG”). If it comes to fruition (it’s a complicated, long-term project), the notion of glue will be profoundly changed, making this article obsolete.