RHEL5 - Bind не возвращает записи IPv6

У меня есть два преобразователя DNS:

  • RHEL5 - BIND 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2
  • RHEL6 - 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
Источник

1 ответ

Решение

Когда вы запрашиваете кеширующий DNS-сервер (ra флаг установлен в вашем ответе), что вы получаете в ADDITIONAL раздел следует рассматривать как "наилучшее усилие" вне того, что RFC явно требует от сервера. Некоторые серверы отключают ADDITIONAL раздел полностью, за исключением случаев, когда это требуется RFC, то есть BIND minimal-responses вариант.

В этом сценарии ADDITIONAL раздел будет содержать записи, о которых сервер знает пассивно, но вы не можете считать эту информацию исчерпывающей. Это не изо всех сил, чтобы получить дополнительные данные для вас, потому что это было бы ненужной работой, и у нее есть более важные дела со своим временем. AAAA IP-адреса серверов имен не часто запрашиваются, и они обычно отсутствуют.

Возьмите следующий пример:

$ rpm -q bind97
bind97-9.7.0-17.P2.el5_9.1
$ dig @localhost +noall +additional faultserver.ru
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 faultserver.ru
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 раздел.

Источник
Другие вопросы по тегам