У меня есть два преобразователя DNS:
RHEL5 - BIND 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2RHEL6 - BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4Конфигурация точно такая же, оба DNS-сервера не настроены с адресами IPv6, и BIND не прослушивает клиентские запросы по IPv6.
Интересно, почему только RHEL6 возвращает записи IPv6, есть ли какой-либо параметр конфигурации, связанный с этим:
RHEL5
# dig @RHEL5 example.com NS
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @RHEL5 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59564
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 84843 IN NS ns01.example.com.
example.com. 84843 IN NS ns02.example.com.
;; ADDITIONAL SECTION:
ns01.example.com. 2233 IN A 192.168.10.10
ns02.example.com. 2233 IN A 192.168.20.20
;; Query time: 1 msec
;; SERVER: 10.10.1.10#53(10.10.1.10)
;; WHEN: Wed May 7 15:08:33 2014
;; MSG SIZE rcvd: 464
RHEL6
# dig @RHEL6 example.com NS
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @RHEL6 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59564
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 84843 IN NS ns01.example.com.
example.com. 84843 IN NS ns02.example.com.
;; ADDITIONAL SECTION:
ns01.example.com. 2233 IN A 192.168.10.10
ns01.example.com. 171236 IN AAAA 2001:502:f4gg::1
ns02.example.com. 2233 IN A 192.168.20.20
ns02.example.com. 171236 IN AAAA 2410:a1:1024::1
;; Query time: 1 msec
;; SERVER: 10.10.2.10#53(10.10.2.10)
;; WHEN: Wed May 7 15:08:53 2014
;; MSG SIZE rcvd: 464
Когда вы запрашиваете кэширующий DNS-сервер (ra установленный в вашем ответе), что вы получите в ADDITIONAL раздел следует рассматривать как «максимальную эффективность» за пределами того, что RFC явно требует от сервера делать. Некоторые серверы отключают ADDITIONAL раздел полностью кроме случаев, предусмотренных RFC, т.е. BIND's minimal-responses вариант.
В этом сценарии ADDITIONAL Раздел будет содержать записи, о которых сервер пассивно осведомлен, но вы не можете считать эту информацию исчерпывающей. Он не собирается изо всех сил собирать для вас дополнительные данные, потому что это будет ненужная работа, и у него есть лучшие дела для своего времени. AAAA IP-адреса серверов имен не часто запрашиваются, и они часто отсутствуют.
Возьмем следующий пример:
$ rpm -q bind97
bind97-9.7.0-17.P2.el5_9.1
$ dig @localhost +noall +additional serverfault.com
brad.ns.cloudflare.com. 82084 IN A 173.245.59.105
roxy.ns.cloudflare.com. 6209 IN A 173.245.58.142
$ dig @localhost +short brad.ns.cloudflare.com AAAA
2400:cb00:2049:1::adf5:3b69
$ dig @localhost +noall +additional serverfault.com
brad.ns.cloudflare.com. 82056 IN A 173.245.59.105
brad.ns.cloudflare.com. 86397 IN AAAA 2400:cb00:2049:1::adf5:3b69
roxy.ns.cloudflare.com. 6181 IN A 173.245.58.142
Я продемонстрировал, что мой кеш возвращает ADDITIONAL раздел, в котором отсутствует AAAA записи. Затем я извещаю кеш-память о существовании одного AAAA запись, и моя последующая повторная попытка откроет дополнительный раздел, содержащий AAAA ответ для этой записи, но не для другой.
Авторитетный сервер имен или ссылающийся сервер имен не будет пассивно заполнять ADDITIONAL раздел.