Servidor DNS atrás do NAT

Question

Eu tenho um servidor DNS Bind 9 sentado atrás de um firewall NAT, supondo que o IP com a Internet voltada para IP seja 1.2.3.4

Não há restrições quanto ao tráfego de saída e a porta 53 (TCP / UDP) é encaminhada de 1.2.3.4 para o servidor DNS interno (10.0.0.1). Não há regras de tabelas de IP no VPS ou no servidor Bind 9 interno.

De um VPS Linux remoto localizado em outro lugar na internet, o nslookup funciona bem

# nslookup foo.example.com 1.2.3.4
Server:    1.2.3.4
Address:   1.2.3.4#53

Name:      foo.example.com
Addresss:  9.9.9.9

No entanto, ao usar o comando host no VPS remoto, recebo a seguinte saída:

# host foo.example.com 1.2.3.4
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; connection timed out; no servers could be reached.

A partir do VPS, posso estabelecer uma conexão (usando telnet) para 1.2.3.4:53

No servidor DNS interno (10.0.0.1), o comando do host parece estar bem:

# host foo.example.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

foo.example.com has address 9.9.9.9

Alguma sugestão de por que o comando host no meu VPS está reclamando da resposta que vem de outra porta, e o que posso fazer para corrigir isso?

Mais informações:

De um host do Windows externo à rede

>nslookup foo.example.com 1.2.3.4
DNS request timeout
    timeout was 2 seconds
Server: UnKnown
Address: 1.2.3.4

DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
*** Request to UnKnown timed-out

Esta é uma instalação padrão do bind do Ubuntu 12.04 LTS, com cerca de 11 zonas configuradas.

$ named -v
BIND 9.8.1-P1

TCP Dump (filtrado) do servidor DNS interno

20:36:29.175701 IP pc.external.com.57226 > dns.example.com.domain: 1+ PTR? 4.3.2.1.in-addr.arpa. (45)
20:36:29.175948 IP dns.example.com.domain > pc.external.com.57226: 1 Refused- 0/0/0 (45)
20:36:31.179786 IP pc.external.com.57227 > dns.example.com.domain: 2+[|domain]
20:36:31.179960 IP dns.example.com.domain > pc.external.com.57227: 2 Refused-[|domain]
20:36:33.180653 IP pc.external.com.57228 > dns.example.com.domain: 3+[|domain]
20:36:33.180906 IP dns.example.com.domain > pc.external.com.57228: 3 Refused-[|domain]
20:36:35.185182 IP pc.external.com.57229 > dns.example.com.domain: 4+ A? foo.example.com. (45)
20:36:35.185362 IP dns.example.com.domain > pc.external.com.57229: 4*- 1/1/1 (95)
20:36:37.182844 IP pc.external.com.57230 > dns.example.com.domain: 5+ AAAA? foo.example.com. (45)
20:36:37.182991 IP dns.example.com.domain > pc.external.com.57230: 5*- 0/1/0 (119)

TCP Dump do cliente durante a consulta

21:24:52.054374 IP pc.external.com.43845 > dns.example.com.53: 6142+ A? foo.example.com. (45)
21:24:52.104694 IP dns.example.com.29242 > pc.external.com.43845: UDP, length 95

    

Answer 1

Para resumir o que foi escrito anteriormente em comentários com mais alguma explicação:

Parece um pouco que suas regras de NAT para o UDP foram quebradas. Uma indicação é a mensagem de erro reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53 e seu rastreio retirado do cliente em que a resposta se parece com dns.example.com.29242 > pc.external.com.43845: UDP, length 95 . A porta de origem para o pacote de resposta deve ser 53, está correta no seu despejo obtido do servidor DNS (onde resolve para domain para fins de exibição).

Embora alguns resolvedores (especialmente históricos) possam aceitar respostas de DNS de diferentes portas / IPs, a maioria não aceitaria - principalmente devido a razões de segurança para impedir DNS spoofing e ataques de envenenamento de cache .

De qualquer forma, para tráfego UDP NAT sem conexão, seu roteador deve preservar dados de estado do pacote de consulta UDP DNS previamente recebido e mapear novamente a tupla IP: port para o pacote de resposta de volta para 1.2 .3: 53 - o que aparentemente não acontece. Pode ser um erro de configuração ou um bug na maneira como o roteador está manipulando a tabela de estado UDP para casos de encaminhamento de porta - então sua melhor aposta seria abrir um caso com o suporte ao cliente do fabricante (tendo atualizado o código para o mais recente / maior de antemão - é provável que tal problema tenha sido percebido por outros usuários anteriormente e, portanto, provavelmente já esteja corrigido).