Resolving a domain's NS when it points at the same domain

Question

Reading this question got me thinking:

I want to host a DNS server for my home website from my home (which has a static IP) what do I need to do?

I'm comfortable with DNS and how it works, but this question lead me down a path I've not considered before.

Suppose I host a DNS server for my own domain (example.com) at 1.2.3.4, and this DNS server advertises the following (simplified) zone:

@   NS ns.domain.com.
@   A  1.2.3.4
ns  A  1.2.3.4

I then subsequently register ns.example.com as example.com's name server with my registrar.

We can't resolve the address of ns.example.com without first knowing who is responsible for example.com.

Once we know that ns.example.com is the name server for example.com won't we get stuck? Surely there is no way to contact ns.example.com because the A record identifying their IP address is held by that same server...?

Presumably there is a step that I'm missing in the lookup...

---

Having read this, my understanding is confirmed but I'm still left puzzled...

It looks like this is possible, as google.com appears to be configured this way (as outlined in the linked article).

Isn't there a step missing between 5 and 6?

Step 5: [...] The .com gTLD server responds with a list of all of google.com’s NS records. In this case Google has four name servers, “ns1.google.com” to “ns4.google.com.”

Step 6: Finally, the DNS resolver queries one of Google’s name server for the IP of “www.google.com.”

... yes, but we need to know the IP of one of these nameservers to query them, effectively swapping a www.google.com query out for an interim ns1.google.com query.

---

What am I missing here?

Answer 1

In this situation, the parent zone has a copy of the relevant A/AAAA records – called glue records – so in 'Step 5' the server automatically includes them in the response and no further nested queries are needed.

Any response that includes NS records (whether it was a direct query for NS records, or whether it was an ordinary query that generates a referral) will always include the corresponding glue records under the "ADDITIONAL" section:

$ dig google.com. A @c.gtld-servers.net.

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

;; AUTHORITY SECTION:
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns2.google.com.
...

;; ADDITIONAL SECTION:
ns1.google.com.     172800  IN  AAAA    2001:4860:4802:32::a
ns1.google.com.     172800  IN  A   216.239.32.10
ns2.google.com.     172800  IN  AAAA    2001:4860:4802:34::a
ns2.google.com.     172800  IN  A   216.239.34.10
...

(This copy is managed manually – when the domain's owner configures nameservers in the parent zone, they may also specify the IP addresses along with the names.)

As an example of how the records are actually stored, you can take a look at the root zone which has many such delegations with glue records – they're simply placed inline in the parent zone:

lt.             172800  IN  NS      a.tld.lt.
lt.             172800  IN  NS      b.tld.lt.
a.tld.lt.       172800  IN  A       195.8.218.131
b.tld.lt.       172800  IN  A       194.0.20.1
b.tld.lt.       172800  IN  AAAA    2001:678:19:0:0:0:0:1

As a final note, glue records only become mandatory for same-domain nameservers, but they are not required when a loop wouldn't occur – it is very common for domain A to use nameservers from under domain B, in which case the parent zone often won't have glue records and the client will indeed have to do additional queries on its own.

Answer 2

Step 5 on that article says:

[...] The .com gTLD server does not have the IP addresses for google.com, but it knows the location of google.com’s name servers. The .com gTLD server responds with a list of all of google.com’s NS records.

If I'm not wrong, although the .com gTLD server does not have records for the IP addresses for google.com, knowing the location of google.com's name server it can query the IP addresses and respond with them.

Perhaps doing some experimentation with dig using +trace and +norecurse in several steps can clarify what's going on.