BIND 9.9.3 atualizações de escravo: recebimento de notificação para zona 'domínio': não autorizado

Question

Estou com problemas para obter uma zona carregada corretamente em um servidor DNS escravo. Ambos os servidores estão executando o BIND 9.9.3-P2.

Eu já estou veiculando ~ 150 zonas e elas estão funcionando corretamente. No entanto, quando estou adicionando outro domínio, o servidor escravo está se recusando a reconhecê-lo.

Aqui está a especificação da zona no mestre:

zone "test.no" { type master; file "/var/lib/named/zones/test.zone"; };

Aqui está a especificação da zona no escravo:

zone "test.no" { type slave; masters { master.ip; }; file "/var/lib/named/zones/test.zone"; };

E quando eu faço um rndc reload no mestre, o escravo recebe a notificação, transfere a zona do mestre e não reclama. Isto é dos logs no escravo:

27-Mar-2014 10:30:15.146 zone test.no/IN: no master file
27-Mar-2014 10:30:15.146 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.157 dns_zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.158 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 queue_soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: serial: new 2014031901, old not loaded
27-Mar-2014 10:30:15.170 queue_xfrin: zone test.no/IN: enter
27-Mar-2014 10:30:15.171 zone test.no/IN: Transfer started.
27-Mar-2014 10:30:15.171 zone test.no/IN: no database exists yet, requesting AXFR of initial version from x.x.x.x#53
27-Mar-2014 10:30:15.171 transfer of 'test.no/IN' from x.x.x.x#53: connected using x.x.x.y#59644
27-Mar-2014 10:30:15.179 zone test.no/IN: zone transfer finished: success
27-Mar-2014 10:30:15.179 zone test.no/IN: transferred serial 2014031901
27-Mar-2014 10:30:15.179 zone_needdump: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 transfer of 'test.no/IN' from x.x.x.x#53: Transfer completed: 1 messages, 6 records, 197 bytes, 0.007 secs (28142 bytes/sec)
27-Mar-2014 10:30:15.180 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone test.no/IN: sending notifies (serial 2014031901)
27-Mar-2014 10:30:15.186 zone_dump: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_gotwritehandle: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 decrement_reference: delete from rbt: 0x9a725d8 test.no
27-Mar-2014 10:30:15.187 dump_done: zone test.no/IN: enter

E /var/lib/named/zones/test.zone é criado e preenchido no escravo:

-rw-r--r-- 1 named named 250 Mar 27 10:30 test.zone

Tudo bem e bom! No entanto, depois de aumentar a série no master e fazer outro recarregamento, recebo o mesmo erro:

27-Mar-2014 10:30:51.405 client x.x.x.x#42033: received notify for zone 'test.no': not authoritative

A zona test.no é a segunda zona que estou tentando com o mesmo erro e a configuração tem a mesma sintaxe que o resto das zonas de trabalho.

O arquivo de zona real como aparece no mestre:

$TTL 1h0m6s
@       IN      SOA     ns1.domain.no. postmaster.domain.no. (
                        2014031902      ; serial, todays date + todays serial #
                        1H              ; refresh, seconds
                        2H              ; retry, seconds
                        2D              ; expire, seconds
                        1H )            ; minimum, seconds

                NS      ns1.domain.no.
                NS      ns2.domain.no.
                TXT     "test.no"


test        A     10.0.0.1

    

Answer 1

Resolvido:

Houve duas instâncias de ligação em execução no servidor! Um aparentemente órfão que continuou servindo pedidos (e, assim, recusando a zona que não conhecia). E um que obedientemente respondeu aos comandos rndc e registrando todas as coisas certas no mesmo arquivo de log da outra instância.

Eu escolhi isto quando mudei a diretiva de escuta para somente localhost, a fim de filtrar todo o barulho vindo dos clientes no arquivo de log. No entanto, as consultas continuavam explodindo os arquivos de log e, em seguida, eu verifiquei novamente quais portas e IPs estavam ouvindo e, de fato, havia várias entradas não consistentes.

Estou um pouco desapontado porque o rndc reload me deixou continuar conversando com um processo isolado na prática, mesmo sem um aviso de que o processo nomeado não estava vinculado à sua porta do udp devido a conflitos; -)

    

Answer 2

Para o benefício de qualquer outra pessoa que tenha este problema e acabe aqui no Google, para mim, o problema foi causado pelo uso das exibições do BIND.

Eu tinha configurado várias visualizações, presumindo que o BIND combinaria todas as visualizações correspondentes em uma, mas na verdade seleciona a primeira exibição correspondente e usa apenas essa, ignorando todas as outras. Consequentemente, o cliente só estava vendo uma pequena seção de minhas zonas e, portanto, as que estavam faltando na visualização estavam surgindo como não autoritativas.

Meu problema foi corrigido colocando tudo em arquivos de inclusão e os usando para garantir que cada visualização estivesse totalmente completa por conta própria.