bind / named não está funcionando no UDP de external

1

Este é estranho.

Eu configurei isso há muito tempo, em um centos5. Pelo que me lembro, costumava funcionar. Por algum tempo agora, não é. Acabei de ser informado, então não faço ideia do que mudou quando isso fez com que não funcionasse.

Até agora: Está funcionando bem localmente (udp e tcp) (dig @localhost) Está funcionando bem externamente, via tcp (dig @YYYY + tcp) Mas não está respondendo do externo via udp (dig @YYYY)

Para este domínio, o dig foi tentado de uma fonte externa de Linux e de uma ferramenta online. A ferramenta online foi verificada para funcionar com outro domínio e 8.8.8.8 como servidor. Além disso, para descartar a queda do UDP do ISP, eu testei a escavação em outro domínio com @ 8.8.8.8 e funcionou.

Não acho que o firewall seja um problema porque o tcpdump diz:

[root@localhost etc]# tcpdump -n udp "dst port 53 or src port 53"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:26:43.871668 IP X.46044 > 192.168.0.101.domain:  42303+ A? <<MY_DOMAIN>>. (32)
02:26:43.874388 IP 192.168.0.101.domain > XXXX.46044:  42303*- 1/1/1 A YYYY (83)
02:26:48.874140 IP X.46044 > 192.168.0.101.domain:  42303+ A? <<MY_DOMAIN>>. (32)
02:26:48.876168 IP 192.168.0.101.domain > XXXX.46044:  42303*- 1/1/1 A YYYY (83)
02:26:53.876772 IP X.46044 > 192.168.0.101.domain:  42303+ A? <<MY_DOMAIN>>. (32)
02:26:53.878231 IP 192.168.0.101.domain > XXXX.46044:  42303*- 1/1/1 A YYYY (83)


3 packets captured
3 packets received by filter
0 packets dropped by kernel

e, permitindo que o rndc querylog mostre nas mensagens:

Feb  5 02:14:48 localhost named[15570]: starting BIND 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 -u named -t /var/named/chroot
Feb  5 02:14:48 localhost named[15570]: adjusted limit on open files from 1024 to 1048576
Feb  5 02:14:48 localhost named[15570]: found 1 CPU, using 1 worker thread
Feb  5 02:14:48 localhost named[15570]: using up to 4096 sockets
Feb  5 02:14:48 localhost named[15570]: loading configuration from '/etc/named.conf'
Feb  5 02:14:48 localhost named[15570]: using default UDP/IPv4 port range: [1024, 65535]
Feb  5 02:14:48 localhost named[15570]: using default UDP/IPv6 port range: [1024, 65535]
Feb  5 02:14:48 localhost named[15570]: no IPv6 interfaces found
Feb  5 02:14:48 localhost named[15570]: listening on IPv4 interface lo, 127.0.0.1#53
Feb  5 02:14:48 localhost named[15570]: listening on IPv4 interface eth0, 192.168.0.101#53
Feb  5 02:14:48 localhost named[15570]: command channel listening on 127.0.0.1#953
Feb  5 02:14:48 localhost named[15570]: zone <<MY_DOMAIN>>/IN: loaded serial 107
Feb  5 02:14:48 localhost named[15570]: running
Feb  5 02:15:06 localhost named[15570]: isc_log_open 'named.run' failed: permission denied
Feb  5 02:15:06 localhost named[15570]: query logging is now on
Feb  5 02:15:16 localhost named[15570]: client XXXX#43793: query: <<MY_DOMAIN>> IN A +

Então, fica a consulta. Parece estar respondendo também, mas até onde eu posso dizer, nenhum pacote está sendo descartado. O iptables é configurado com OUTPUT ACCEPT e não há regras para a cadeia de saída. Eu também tentei com o firewall desativado e não fiz diferença, então novamente duvido que seja do iptables.

Então por que o hack não está passando pelo udp?

todas as indicações são bem-vindas. Estou sem ideias.

configuração física é: INET < - > router < - > servidor

o roteador é um Trendnet TW100-94w1CA caso seja importante.

    
por ciuly 04.02.2014 / 22:52

1 resposta

2

Esta não é a primeira vez que um ISP decidiu que não gostava de usuários executando um servidor DNS. Tem certeza de que também não está configurado como um open-resolver? Isso é motivo para bloqueá-lo.

Desde que você sugeriu que ele parou de funcionar sem alterações do seu lado, eu suspeitaria que uma nova regra de firewall foi lançada na sua face do lado do provedor (fora do seu controle) para bloquear DNS / respostas de saída /. Firewalls hoje em dia podem fazer isso através de inspeção profunda de pacotes e deixar suas saídas / consultas / funcionando bem.

A única forma de verificar se é possível ver os pacotes de resposta do DNS faz com que ele passe pelo seu roteador de upstream (ADSL?).

Claro, pode haver várias outras causas, mas parece improvável neste momento.

    
por 09.02.2014 / 23:28