Forçar solicitações DNS do encaminhador para o modo TCP

Eu configurei um servidor DNS no SLES10 (atualmente vincular 9.6) em um servidor com hospedagem múltipla. Este servidor pode ser consultado em todas as redes internas e fornece respostas para todas as redes internas. Temos duas zonas "principais" DNS separadas. Cada uma dessas zonas está sendo atendida por vários servidores DNS do Windows com autoridade.

Agora meu servidor linux é um servidor DNS secundário para uma dessas zonas (zona interna privada) e atua como encaminhador para a outra zona (zona interna pública).

Até recentemente, essa configuração funcionava sem problemas. Agora eu recebo - ao consultar a zona interna pública (por exemplo, pelo hostcomando em um cliente linux) a mensagem de erro

;; Truncado, tentando novamente no modo TCP

um wireshark-dump revelou a causa disso: a primeira consulta sai no modo UDP, a resposta não se encaixa no UDP (devido à longa lista de NS autoritativos), depois é repetida no modo TCP, fornecendo a resposta correta.

Agora a pergunta: Posso configurar minha ligação para consultar os encaminhadores no modo TCP sem tentar o UDP primeiro?

Atualização: Tentando minha mão na arte ASCII ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

— Nils
fonte

um pequeno diagrama disso seria útil - estou lutando para descobrir qual servidor é qual da sua descrição.

— Alnitak

um pouco melhor, embora ainda não esteja claro entre exatamente quais hosts você está executando este hostcomando e qual consulta está sendo enviada.

— Alnitak

Os clientes solicitam via SLES10 as entradas da zona pública interna. A zona privada interna não sofre - pois existem apenas 2 entradas NS.

— Nils

e os clientes são simplesmente resolvedores de stub simples?

— Alnitak

sugiro que você adicione minimal-responses: yesà configuração do BIND no SLES 10 - isso pode reduzir os tamanhos de resposta. De qualquer forma, a maioria das consultas normais não excederá o limite de 512 bytes.

— Alnitak

Respostas:

Primeiro, eu não chamaria isso de erro, apenas uma mensagem informativa.

Segundo, os servidores DNS sempre respondem a consultas UDP (pelo menos BIND, não consigo encontrar opções para desativar o UDP) e os clientes sempre tentam (?) Enviar uma consulta UDP primeiro (por exemplo, não há opções no resolv.conf para alterar isso nem na JVM) - se eles se encaixam em um pacote UDP (geralmente, as solicitações)

Se você tiver um caso de uso específico, poderá especificar o uso de TCP, por exemplo, no shell script, use 'dig + tcp' ou 'host -T' para resolução e use as chamadas de sistema 'sethostent / gethostbyname / endhostent' (consulte man página) para forçar o TCP em outros casos.

Se você realmente deseja tentar bloquear o UDP, a única opção que posso ver é com uma regra iptable, mas não tenho certeza de que essa configuração funcione. Espero que a resolução do DNS simplesmente falhe.

— Dan Andreatta
fonte

nominalmente, há um benefício de desempenho ao saber a priori que a consulta UDP falhará e testando primeiro o TCP. Veja a RFC 5966 para uma discussão sobre isso.

— Alnitak

@Alnitak e eu gostaria de obter esse benefício.

— Nils

@Nils por isso precisamos descobrir por que EDNS, aparentemente, não está funcionando ...

— Alnitak

Não tenho nenhum caso de uso especial - os clientes usarão sua biblioteca de resolvedores -, mas cada solicitação e cada resposta passarão pela rede duas vezes - não gosto disso.

— Nils

@ Nils, o problema é que o cliente decide UDP / TCP, mas o servidor sabia o tamanho da resposta.

— Dan Andreatta

Seu servidor BIND deve estar usando EDNS (consulte RFC 2671) para permitir pacotes UDP com mais de 512 bytes.

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

Isso deve permitir que seu conjunto NS grande seja recuperado pelo UDP, sem exigir a sobrecarga de uma conexão TCP para outras consultas menores.

Observe, no entanto, que esses são realmente os valores padrão. Se o EDNS não estiver sendo usado, algo está bloqueando ou os servidores que recebem as opções do EDNS não o suportam.

Além disso, observe que hostnão suporta EDNS. É perfeitamente possível que suas consultas de encaminhador -> servidor já estejam usando EDNS, e você simplesmente não pode vê-lo quando tenta com seu cliente local.

Tente em dig +bufsize=4096 @server hostname Avez de usar host.

— Alnitak
fonte

Quem deveria estar usando isso? Provavelmente meu servidor e meus encaminhadores da zona "público interno"?

— Nils

Qual é o sentido de enviar a lista completa de NS na resposta de qualquer maneira?

— Nils

@Nils o protocolo DNS exige que o conjunto completo de entradas correspondentes a mesma (QNAME, QTYPE e QCLASS) tuple são indivisíveis (aka um "RRset")

— Alnitak

você pode me indicar a RFC sobre este RRset?

— Nils

O host Actaully usa a biblioteca de resolvedores padrão e, na minha estação de trabalho, ele suporta EDNS0. Para testar se os pedidos especificam EDNS0, execute 'tcpdump -x port 53' e o dump hexadecimal deve conter (no final, na seção adicional) a sequência 0029 1000 0000 8000 0000, que é a representação binária do OPT RR.

— Dan Andreatta