{"id":20052,"date":"2023-03-02T17:21:28","date_gmt":"2023-03-02T17:21:28","guid":{"rendered":"https:\/\/news.lacnic.net\/?p=20052"},"modified":"2023-03-03T15:51:49","modified_gmt":"2023-03-03T15:51:49","slug":"dns-ns-glue-and-ns-glue-and-authoritative-ns-records","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/en\/dns-ns-glue-and-ns-glue-and-authoritative-ns-records\/","title":{"rendered":"DNS – NS Glue and NS glue and Authoritative NS Records"},"content":{"rendered":"\n

By Carlos Mart\u00ednez<\/a>, LACNIC CTO<\/p>\n\n\n\n

<\/a><\/a>Context of the Problem<\/strong><\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

To illustrate the problem, as an example, we will use the DNS zone corresponding to the IPv6 documentation prefix, i.e., 2001:db8::\/32<\/strong>.<\/p>\n\n\n\n

Using the convention typically used for reverse resolution, the corresponding DNS zone is \u201c8.b.d.0.1.0.0.2.ip6.arpa<\/strong>\u201d.<\/p>\n\n\n\n

Zone Delegation<\/strong><\/strong><\/p>\n\n\n\n

Zone delegation is the process whereby a \u201cparent\u201d zone transfers responsibility for resolving a portion of the namespace it covers to a \u201cchild\u201d server.<\/p>\n\n\n\n

The way to do this is to create a set of records in the parent zone which are known as \u201cdelegation records\u201d and which serve as indicators that the delegation is happening. These delegation records must contain at least one NS<\/em> (nameserver) record and may additionally include A<\/em> or AAAA<\/em> records in case the name specified in the NS record cannot be resolved through other zones.<\/p>\n\n\n\n

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 \u201csearches\u201d for the delegations until it either obtains an authoritative<\/em> response or encounters an error status.<\/p>\n\n\n\n

This search for delegations occurs by first querying the NS records to the \u201cparent\u201d zones, then to the child zones. The NS records in the parent zones, those that correspond to \u201cdelegation records,\u201d are not authoritative<\/strong> and are only used as a \u201cclue\u201d to find the actual NS’s, i.e., the authoritative<\/strong> records.<\/p>\n\n\n\n

\"\"
Fig. 1 \u2014 Example of a correct delegation. Non-authoritative \u201cglue\u201d NS records and authoritative NS records match and the servers respond correctly.<\/figcaption><\/figure>\n\n\n\n

Problem Diagnosis<\/strong><\/strong><\/p>\n\n\n\n

My preferred way to identify the causes of this type of problems is to use tools such as dig<\/strong> or drill<\/strong> from a terminal, trying to manually follow the steps that a recursive server follows when attempting to obtain a response.<\/p>\n\n\n\n

Let’s suppose that 1.0.0.2.ip6.arpa<\/a> is the \u201cparent\u201d zone where issues have been detected, and that ns1.rir.la<\/a> and ns2.rir.la<\/a> are the authoritative servers for this zone.<\/p>\n\n\n\n

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:<\/p>\n\n\n\n

 $ dig @ns1.rir.la NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10148\n;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5\n;; ANSWER SECTION:\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tNS1.emp1.com.\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tNS2.emp1.com.\n\n<\/code><\/pre>\n\n\n\n
We can see that there are no records in the \u201cAUTHORITY\u201d 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 \u201cANSWER\u201d section.<\/p>\n\n\n\n
The next step is to use this information to query the same NS records but<\/strong> to the servers which we assume should be authoritative<\/strong> for this zone.<\/p>\n\n\n\n
 $ dig @ns1.emp1.com. NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; AUTHORITY SECTION:\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tservA.emp1.com.\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tservB.emp1.com.\n\n<\/code><\/pre>\n\n\n\n
This is where the problems begin. The records in the parent zone do not match the records in the child zone.<\/p>\n\n\n\n
But the problem doesn\u2019t end here:<\/p>\n\n\n\n
$ dig @servA.emp1.com NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23423\n;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1\n;; WARNING: recursion requested but not available\n<\/code><\/pre>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\n
This is why any name under the \u201c8.b.d.0.1.0.0.2.ip6.arpa<\/strong>\u201d zone can never be successfully resolved, despite the fact that the servers listed in the delegation records do know the zone in question.<\/p>\n\n\n\n
Figure 2 illustrates this situation.<\/p>\n\n\n\n
\"\"
Fig. 2: This figure shows the \u201cbroken\u201d delegation: in the first query, the resolver obtains authoritative NS records that point to a server that does not answer queries for names in the zone being delegated.<\/figcaption><\/figure>\n\n\n\n
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\u2019s 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.<\/p>\n\n\n\n
<\/a>Possible Solutions<\/strong><\/strong><\/p>\n\n\n\n
With no additional information about what configuration change the user wanted to achieve, it is difficult to specify what the ideal solution would be.<\/p>\n\n\n\n
However, some things should be underlined:<\/p>\n\n\n\n