Como você configura o BIND para encaminhar consultas DNS reversas para outro servidor DNS?

Question

Eu tenho dois domínios no meu ambiente. Um deles é um domínio de diretório ativo para "myproductionlab.local" em 10.60.0.0/16
Então eu tenho uma caixa debian executando bind9 para um domínio, 'mytestlab.local'
Eu adicionei uma entrada no meu named.conf.local:

zone "60.10.in-addr.arpa" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};
zone "myproductionlab.local" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};

a caixa debian está configurada para ter 127.0.0.1 para resolução DNS e não há forwarders configurados globalmente.

resolução de nomes resolve muito bem:

nslookup mymachine.myproductionlab.local  
Server:     127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
Name:   mymachine.myproductionlab.local
Address: 10.60.10.200

e no log de consulta:

client 127.0.0.1#36076 (mymachine.myproductinlab.local): query: mymachine.myproductionlab.local IN A + (127.0.0.1)

mas o DNS reverso não é encaminhado:

nslookup 10.60.10.200
Server:     127.0.0.1
Address:    127.0.0.1#53
** server can't find 200.10.60.10.in-addr.arpa: NXDOMAIN

e do log de consulta:

client 127.0.0.1#40295 (200.10.60.10.in-addr.arpa): query: 200.10.60.10.in-addr.arpa IN PTR + (127.0.0.1)

Eu tentei várias variações de zona:

zone "60.10.in-addr.arpa" {
zone "10.60.10.in-addr.arpa" {
zone "200.10.60.10.in-addr.arpa" {

Eu também tentei tcpdump e 0 pacotes foram capturados para o nslookup 10.60.10.200, mas os pacotes foram capturados para o nome.

quando especifico manualmente o servidor DNS no nslookup ele também funciona bem:

nslookup 10.60.10.200 10.60.10.5
Server:     10.60.10.5
Address:    10.60.10.5#53
200.10.60.10.in-addr.arpa   name = mymachine.myproductionlab.local.

    

Answer 1

nslookup não é muito útil, qual é a saída de dig -x 10.60 10.200

que mostrou que os seus intervalos privados predefinidos foram ativados e a captura dos seus pedidos como autoridade.

remova ou edite-os para serem mais específicos.

    

Answer 2

A saída do DIG levou-me a descobrir o problema

dig -x 10.60.10.200

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 10.60.10.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26824
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;200.10.60.10.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.    86400   IN  SOA localhost. root.localhost. 1 604800     86400 2419200 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 13:46:50 CST 2017
;; MSG SIZE  rcvd: 104

10.in-addr.arpa. foi definido em zones.rfc1918 que aponta para db.empty
Nas versões anteriores do bind zones.rfc1918 não foi incluído por padrão e mesmo assim eu verifiquei todas as configurações e nada está dizendo bind para ler esse arquivo, então ele deve ser lido por padrão agora nesta versão ou está configurado em outro lugar.

dpkg -l | grep bind
ii  bind9                                1:9.9.5.dfsg-9+deb8u6            amd64        Internet Domain Name Server
ii  bind9-host                           1:9.9.5.dfsg-9+deb8u6        amd64        Version of 'host' bundled with BIND 9.X
ii  bind9utils                           1:9.9.5.dfsg-9+deb8u6        amd64        Utilities for BIND
ii  libbind9-90                          1:9.9.5.dfsg-9+deb8u6        amd64        BIND9 Shared Library used by BIND

    

Answer 3

Apenas no caso de alguém acertar isso ... Para versões recentes do Bind9 (pelo menos no Debian) não é suficiente para desabilitar o

include "/etc/bind/zones.rfc1918";

declaração

porque o Bind9 então os cria automaticamente. Em vez disso,

empty-zones-enable no;

é obrigatório na sua seção de opções ( named.conf.options ).

Consulte o link .