Eu tenho um número de servidores DNS, todos executando o bind9 (9.5.1, para ser específico) sob o fedora. 4 deles são escravos, alimentados por um mestre comum para o nosso DNS público. Todos estes estão localizados nos portais públicos dos nossos vários escritórios.
Um deles tem toneladas de mensagens em seus arquivos de log semelhantes a estes:
Jul 21 17:26:18 gateway named[3487]: client 10.171.3.8#52500: view internal: error sending response: host unreachable
Eu me pergunto de onde isso vem. O firewall está aberto na porta 53 entre as duas máquinas (10.171.3.8 é um servidor DNS interno localizado em um controlador de domínio do Windows). Os domínios internos NÃO listam o gateway como um servidor de nomes (portanto, não deve haver nenhuma tentativa de replicar os domínios) e o gateway não manipula nenhum DNS interno. Os clientes nessas mensagens variam entre os dois controladores de domínio na rede interna e um terceiro servidor de nomes interno (executando o bind9 no debian em um segmento diferente da rede).
Quaisquer ponteiros são muito bem-vindos.
Em resposta à primeira resposta:
O problema com isso é que o tcpdump não apresenta problemas. Aqui está um extrato de "tcpdump -i qualquer porta 53"
09:13:38.283308 IP valine.aminocom.com.61815 > ns-pri.ripe.net.domain: 14075 PTR? 166.225.58.95.in-addr.arpa. (44)
09:13:42.007410 IP gateway-eng.aminocom.com.37047 > alanine.aminocom.com.domain: 35410+ PTR? 12.3.172.10.in-addr.arpa. (42)
Ao mesmo tempo, o registro de DNS mostra:
Jul 22 09:13:38 gateway named[3487]: client 10.171.3.6#61300: view internal: error sending response: host unreachable
Jul 22 09:13:40 gateway named[3487]: client 10.172.3.12#56230: view internal: error sending response: host unreachable
Jul 22 09:13:40 gateway named[3487]: client 10.171.3.8#55221: view internal: error sending response: host unreachable
Jul 22 09:13:49 gateway named[3487]: client 10.171.3.8#51342: view internal: error sending response: host unreachable
Então, claramente às 09:13:40 houve duas tentativas mal-sucedidas de se conectar a máquinas internas (10.172.3.12 e 10.171.3.8, ambas são servidores DNS), mas nada na saída do tcpdump.