RHEL5 - Bind não retorna registros IPv6

Question

Eu tenho dois resolvedores de 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

A configuração é exatamente a mesma, os dois servidores DNS não estão configurados com endereços IPv6 e o BIND não escuta consultas de clientes no IPv6.

Eu me pergunto por que apenas RHEL6 retorna registros IPv6, existe alguma opção de configuração relacionada a isso:

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

    

Answer 1

Quando você consulta um servidor DNS de armazenamento em cache ( ra sinalizador definido na sua resposta), o que você recebe na seção ADDITIONAL deve ser considerado "melhor esforço" fora do que os RFCs exigem explicitamente que um servidor faça. Alguns servidores desabilitam a seção ADDITIONAL inteiramente , exceto quando exigido pelo RFC, ou seja, a opção minimal-responses do BIND.

Nesse cenário, a seção ADDITIONAL conterá registros dos quais o servidor está passivamente ciente, mas você não pode considerar essas informações exaustivas. Não vai sair do seu caminho para obter os dados extras para você, porque seria um trabalho desnecessário e tem coisas melhores para fazer com seu tempo. AAAA IPs de servidor de nomes não são solicitados com frequência e é comum que eles estejam ausentes.

Veja o seguinte exemplo:

$ 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

O que eu fiz aqui é demonstrar meu cache retornando uma seção ADDITIONAL que não possui os registros AAAA . Em seguida, dou ao cache uma ajuda útil sobre a existência de um registro AAAA , e minha nova tentativa puxa para baixo uma seção adicional que contém a resposta AAAA para esse registro, mas não para o outro.

Um servidor de nomes autoritativo ou um servidor de nomes de referência não estaria preenchendo passivamente a seção ADDITIONAL .