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.