DNS – NS Glue and NS glue and Authoritative NS Records
02/03/2023
A client reports that, after a change in their DNS configurations, one of their reverse zones can no longer be resolved by DNS clients on the Internet.
To illustrate the problem, as an example, we will use the DNS zone corresponding to the IPv6 documentation prefix, i.e., 2001:db8::/32.
Using the convention typically used for reverse resolution, the corresponding DNS zone is “8.b.d.0.1.0.0.2.ip6.arpa”.
Zone Delegation
Zone delegation is the process whereby a “parent” zone transfers responsibility for resolving a portion of the namespace it covers to a “child” server.
The way to do this is to create a set of records in the parent zone which are known as “delegation records” and which serve as indicators that the delegation is happening. These delegation records must contain at least one NS (nameserver) record and may additionally include A or AAAA records in case the name specified in the NS record cannot be resolved through other zones.
When a recursive server receives a request to resolve a name, it begins a query process where it initially queries the DNS root and somehow “searches” for the delegations until it either obtains an authoritative response or encounters an error status.
This search for delegations occurs by first querying the NS records to the “parent” zones, then to the child zones. The NS records in the parent zones, those that correspond to “delegation records,” are not authoritative and are only used as a “clue” to find the actual NS’s, i.e., the authoritative records.
Problem Diagnosis
My preferred way to identify the causes of this type of problems is to use tools such as dig or drill from a terminal, trying to manually follow the steps that a recursive server follows when attempting to obtain a response.
Let’s suppose that 1.0.0.2.ip6.arpa is the “parent” zone where issues have been detected, and that ns1.rir.la and ns2.rir.la are the authoritative servers for this zone.
To query the delegation records of the zone where problems are suspected, we query the parent zone for the NS records of the corresponding child zone:
$ dig @ns1.rir.la NS 8.b.d.0.1.0.0.2.ip6.arpa
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10148
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; ANSWER SECTION:
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS NS1.emp1.com.
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS NS2.emp1.com.
We can see that there are no records in the “AUTHORITY” section of the response, which is the expected behavior, as the NS records of the parent zone are not authoritative. However, we do obtain a response in the “ANSWER” section.
The next step is to use this information to query the same NS records but to the servers which we assume should be authoritative for this zone.
$ dig @ns1.emp1.com. NS 8.b.d.0.1.0.0.2.ip6.arpa
;; AUTHORITY SECTION:
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS servA.emp1.com.
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS servB.emp1.com.
This is where the problems begin. The records in the parent zone do not match the records in the child zone.
But the problem doesn’t end here:
$ dig @servA.emp1.com NS 8.b.d.0.1.0.0.2.ip6.arpa
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23423
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
In addition to the fact that the NS servers listed as authoritative in the zone are different from those listed in the parent zone, the supposedly authoritative server is not configured to resolve the zone for which it is supposed to be authoritative.
This is why any name under the “8.b.d.0.1.0.0.2.ip6.arpa” zone can never be successfully resolved, despite the fact that the servers listed in the delegation records do know the zone in question.
Figure 2 illustrates this situation.
This problem can be insidious and difficult to diagnose, because if a dig query is performed without taking any special precautions, querying for the zone’s SOA (one of the records most commonly used for testing, as it is always present), it is possible that dig will return a response, but any subsequent query will fail.
With no additional information about what configuration change the user wanted to achieve, it is difficult to specify what the ideal solution would be.
However, some things should be underlined:
- The NS records listed in the parent zone and in the child zone must match.
- We must then either configure the zone where problems are suspected in servers “servA” and “servB” or the authoritative NS listed in the zone itself must become ns1 and ns2.emp1.com.
Final Comments
It is important to fully understand the mechanism by which a name server traverses a zone delegation point. We must keep in mind the process by which the NS records in the parent zone are checked against the child zone.
The configuration error found in these reverse zones is not limited to the reverse DNS tree, nor is it limited to reverse IPv6 records. This same mistake can be made in direct zones with the “company.com.tld” format.
It is also essential to know how to make the most of tools such as dig or drill. Certain graphical tools such as DnsViz and ZoneMaster can also be useful.