Bind: “final inesperado de entrada” devido a NS

Question

Eu tropecei em um erro estranho em uma configuração master-slave (s) de Bind.

A zona funciona bem no mestre, mas nos escravos estou recebendo esses tipos de erros:

21-May-2014 19:06:07.573 general: info: zone example.com/IN: refresh: failure trying master 1.2.3.4#53 (source 0.0.0.0#0): unexpected end of input

É assim que meu arquivo de bind se parece:

@   IN SOA  ns1.example.com.    admin.example.com. (
    2014052116    ; Serial
    28800         ; Refresh
    180           ; Retry
    604800        ; Expire
    21600       ) ; Minimum

                86400   IN A        1.2.3.4
                86400   IN MX       10 mail.example.com.
                86400   IN MX       20 mail2.example.com.
                86400   IN NS       ns1.example.com.
                86400   IN NS       ns2.example.com.
                86400   IN NS       ns3.example.com.
                86400   IN NS       ns1.example.net.
                86400   IN NS       ns2.example.net.
                86400   IN NS       ns3.example.net.
                86400   IN NS       ns1.example.org.

; until here it works -- if I uncomment the below here, I'll get "end of input" failures.
;               86400   IN NS       ns2.example.org.
;               86400   IN NS       ns3.example.org.


*               86400   IN A        1.2.3.4
[...]

Se eu descomentar as duas linhas NS comentadas - recebo os erros "End of Input". Se eu os mantiver comentado, tudo funciona bem.

Existe uma quantidade máxima de NS ou tamanho de arquivo que causa falha?

Obrigado.

Editar:

named-checkzone:

master # named-checkzone example.com example.com. 
zone example.com/IN: example.com/MX 'mail.example.com' is a CNAME (illegal)
zone example.com/IN: example.com/MX 'mail2.example.com' is a CNAME (illegal)
zone example.com/IN: loaded serial 2014052105
OK

opções globais:

options {
    directory "/var/cache/bind";
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
    listen-on { any; };
    dnssec-enable yes;
    recursion no;
    statistics-file "/var/log/named.stats";
    try-tcp-refresh yes;
};

Versão

(mesmo nos três servidores):

# named -v
BIND 9.8.4-rpz2+rl005.12-P1

    

Answer 1

Acho que você está correndo contra o tamanho máximo permitido do pacote DNS UDP de 512 bytes. Antes de fazer a solicitação AXFR esperada (que é executada no modo TCP; sem restrição de tamanho), um servidor escravo também fará uma consulta SOA para confirmar se o mestre se considera autoritativo para a zona.

O problema que você encontra aqui é que a resposta SOA conterá mais do que apenas as seções PERGUNTA e RESPOSTA:

• A seção AUTHORITY conterá todos os seus servidores de nomes configurados.
• A seção ADICIONAL conterá todos os registros A e AAAA conhecidos para esses servidores de nomes.

É por isso que ajustar seus registros NS ou seus registros A / AAAA associados está causando impacto no sucesso de toda a transferência de zona, mas a adição de outros tipos de registros não tem influência. Seus dados de autoridade combinada são muito grandes para o que pode ser transmitido pelo UDP.

Infelizmente, não conheço nenhuma solução alternativa para isso. O Manual de Referência do Administrador do BIND faz referência a uma opção try-tcp-refresh , mas o padrão é sim e não está desabilitado em suas opções. Não tenho certeza se a transferência de zona é o fim de seus problemas. Mesmo se fosse para ter sucesso, isso causaria problemas para qualquer cliente que, por sua vez, fizesse qualquer solicitação que incluísse suas seções de AUTORIDADE e ADICIONAIS. EDNS0 é projetado para resolver problemas como este, mas eu acho AUTORITY inchar é muito funcionalmente baixo nível para que seja capaz de chutar dentro

Espero que minha análise esteja errada até certo ponto. Eu acho que você tem um problema muito interessante e eu gostaria de ver alguém fornecer uma resposta melhor para isso, porque eu também aprendi com isso.