См. RFC 1035 , который касается DNS и, в частности, раздел 4.1 «Формат сообщения».
Вы прочтете там:
раздел дополнительных записей содержит RR
которые относятся к запросу, но не являются строго ответами на
вопрос.
А также различные форматы в разделе 3.3, в которых объясняется, какая запись вызовет определенную «дополнительную» обработку.
Вы также можете найти в RFC 1034 разделы 6.2 и 6.3 некоторые примеры запросов и ответов, где вы увидите, как заполняется дополнительный раздел.
Теперь, чтобы вернуться к вашему примеру, проблема в том, что вы не указываете явно, какой сервер имен вы запрашиваете, что означает, что вы получаете ответ от рекурсивного по умолчанию.
В этом случае вы видите:
- в поле «Ответить» - точная запись для вашего запроса (по умолчанию dig делает
A, если вы ничего не указали)
- в «Власти» вы видите, что рекурсив узнал о том, какие серверы имен являются авторитетными для вашей записи
- в поле «Дополнительно» вы получаете IP-адреса серверов имен в предыдущем разделе, особенно здесь, поскольку вы находитесь в случае «in-bailiwick» (часто называемом «клеем»), так что вы (как рекурсивный сервер имен) могли бы иметь нет способа подключить авторитетные сервера имен.
Давайте повторим запрос напрямую, используя авторитетный сервер имен, а затем сравним его с другим случаем:
$ 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
Итак, мы просим одного авторитетного сервера имен зоны .COM дать нам серверы имен google.com. Результат аналогичен ранее.
Давайте запросим тот же сервер имен, но для другого домена:
$ 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
Обратите особое внимание на список namservers в разделе «Authority» и список с A / AAAA в разделе «Additional». Вы поймете, что только те, которые заканчиваются на .com или .net (потому что это особый случай, когда оба этих TLD обрабатываются одним и тем же реестром) имеют здесь IP-адреса, потому что авторитетные серверы имен для .COM / .NET ничего не знают об именах и IP-адресах в других доменах верхнего уровня.
Это может показаться еще более на следующем примере:
$ 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
Нет "Дополнительного" раздела вообще, потому что все серверы имен находятся вне зоны!