See RFC 1035 that deals with DNS and specifically section 4.1 "Message Format".
You will read there:
the additional records section contains RRs
which relate to the query, but are not strictly answers for the
question.
And also the various formats under 3.3 that explains which record will trigger specific "additional" treatment.
You can also find in RFC 1034 sections 6.2 and 6.3 some examples of queries and replies where you will see how the Additional section is filled out.
Now to go back to your example, the problem is that you are not specificying explicitely which nameserver you query which means you get answer from the default recursive one.
In which case you see:
- in "Answer" the exact record for your query (dig does an
A by default if you do not specify anything)
- in "Authority" you see what the recursive has learnt about which nameservers are authoritative for your record
- in "Additional" you get the IP addresses of the nameservers in previous section, especially here since you are in a "in-bailiwick" case (often known as "glues") so you (as a recursive nameserver) would have no way to connect the authoritative nameservers.
Let us redo the query directly using an authoritative nameserver, and then compare with another case:
$ dig google.com NS @a.gtld-servers.net
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> google.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12149
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN NS
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 68 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:23:20 EST 2018
;; MSG SIZE rcvd: 287
So here we are asking one authoritative nameserver of the .COM zone to give us the nameservers of google.com. The result is similar to previously.
Let us query the same nameserver but for another domain:
$ dig ultradns.com NS @a.gtld-servers.net
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> ultradns.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54105
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ultradns.com. IN NS
;; AUTHORITY SECTION:
ultradns.com. 172800 IN NS pdns196.ultradns.com.
ultradns.com. 172800 IN NS pdns196.ultradns.net.
ultradns.com. 172800 IN NS pdns196.ultradns.org.
ultradns.com. 172800 IN NS pdns196.ultradns.info.
ultradns.com. 172800 IN NS pdns196.ultradns.biz.
ultradns.com. 172800 IN NS pdns196.ultradns.co.uk.
ultradns.com. 172800 IN NS ari.alpha.aridns.net.au.
ultradns.com. 172800 IN NS ari.beta.aridns.net.au.
ultradns.com. 172800 IN NS ari.gamma.aridns.net.au.
ultradns.com. 172800 IN NS ari.delta.aridns.net.au.
;; ADDITIONAL SECTION:
pdns196.ultradns.com. 172800 IN A 156.154.64.196
pdns196.ultradns.com. 172800 IN AAAA 2001:502:f3ff::e8
pdns196.ultradns.net. 172800 IN A 156.154.65.196
pdns196.ultradns.net. 172800 IN AAAA 2610:a1:1014::e8
;; Query time: 72 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:25:24 EST 2018
;; MSG SIZE rcvd: 432
Pay close attention to the list of namservers in the "Authority" section and the ones having an A/AAAA record in the "Additional" section. You will realise that only those ending in .com or .net (because this is a special case where both of these TLDs are handled by the same registry) have IP addresses here because the authoritative nameservers for .COM/.NET know nothing about names and IP addresses in other TLDs.
This can be seem even more with this example:
$ dig aridns.com NS @a.gtld-servers.net
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> aridns.com NS @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2552
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aridns.com. IN NS
;; AUTHORITY SECTION:
aridns.com. 172800 IN NS dns1.ausregistry.net.au.
aridns.com. 172800 IN NS dns1-1.ausregistry.net.au.
aridns.com. 172800 IN NS dns1-2.ausregistry.net.au.
aridns.com. 172800 IN NS dns2-1.ausregistry.net.au.
;; Query time: 68 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Sep 03 19:28:07 EST 2018
;; MSG SIZE rcvd: 139
No "Additional" section at all, because all nameservers are out of zone!
