DNS resolve o tempo limite no RHEL 6.3 por trás do firewall

Question

Eu tenho um servidor rodando o Red Hat 6.3 Enterprise dentro de uma máquina virtual VMWare. Há um firewall Juniper SSG 5 entre o servidor e a Internet. Estou tentando diagnosticar o que parece ser o tempo limite de pesquisa de DNS, mas receio não ter o conhecimento necessário para fazê-lo.

Aqui está a saída do tcpdump quando eu faço um $ wget www.google.com.br :

$ tcpdump -i eth0 -n -vvv not port ssh

14:15:15.361010 IP (tos 0x0, ttl 64, id 8975, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.12.54835 > 200.196.66.30.domain: [bad udp cksum f4e1!] 47797+ A? www.google.com.br. (35)
14:15:15.361195 IP (tos 0x0, ttl 64, id 8976, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.12.54835 > 200.196.66.30.domain: [bad udp cksum 4e62!] 8028+ AAAA? www.google.com.br. (35)
14:15:15.362122 IP (tos 0x0, ttl 61, id 25375, offset 0, flags [none], proto UDP (17), length 283)
    200.196.66.30.domain > 192.168.1.12.54835: [udp sum ok] 47797 q: A? www.google.com.br. 4/4/4 www.google.com.br. [1m] CNAME www-cctld.l.google.com., www-cctld.l.google.com. [4m47s] A 74.125.234.184, www-cctld.l.google.com. [4m47s] A 74.125.234.191, www-cctld.l.google.com. [4m47s] A 74.125.234.183 ns: google.com. [20h11m12s] NS ns1.google.com., google.com. [20h11m12s] NS ns2.google.com., google.com. [20h11m12s] NS ns3.google.com., google.com. [20h11m12s] NS ns4.google.com. ar: ns1.google.com. [3d1h39m] A 216.239.32.10, ns2.google.com. [3d23h47m54s] A 216.239.34.10, ns3.google.com. [3d21h48m53s] A 216.239.36.10, ns4.google.com. [3d14h11m28s] A 216.239.38.10 (255)
14:15:20.365434 IP (tos 0x0, ttl 64, id 8977, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.12.54835 > 200.196.66.30.domain: [bad udp cksum f4e1!] 47797+ A? www.google.com.br. (35)
14:15:20.366657 IP (tos 0x0, ttl 61, id 25377, offset 0, flags [none], proto UDP (17), length 283)
    200.196.66.30.domain > 192.168.1.12.54835: [udp sum ok] 47797 q: A? www.google.com.br. 4/4/4 www.google.com.br. [55s] CNAME www-cctld.l.google.com., www-cctld.l.google.com. [4m42s] A 74.125.234.191, www-cctld.l.google.com. [4m42s] A 74.125.234.183, www-cctld.l.google.com. [4m42s] A 74.125.234.184 ns: google.com. [20h11m7s] NS ns4.google.com., google.com. [20h11m7s] NS ns2.google.com., google.com. [20h11m7s] NS ns3.google.com., google.com. [20h11m7s] NS ns1.google.com. ar: ns1.google.com. [3d1h38m55s] A 216.239.32.10, ns2.google.com. [3d23h47m49s] A 216.239.34.10, ns3.google.com. [3d21h48m48s] A 216.239.36.10, ns4.google.com. [3d14h11m23s] A 216.239.38.10 (255)
14:15:20.366760 IP (tos 0x0, ttl 64, id 8978, offset 0, flags [DF], proto UDP (17), length 63)
    192.168.1.12.54835 > 200.196.66.30.domain: [bad udp cksum 4e62!] 8028+ AAAA? www.google.com.br. (35)
14:15:20.368486 IP (tos 0x0, ttl 61, id 25378, offset 0, flags [none], proto UDP (17), length 263)
    200.196.66.30.domain > 192.168.1.12.54835: [udp sum ok] 8028 q: AAAA? www.google.com.br. 2/4/4 www.google.com.br. [55s] CNAME www-cctld.l.google.com., www-cctld.l.google.com. [3m7s] AAAA 2800:3f0:4001:805::1017 ns: google.com. [20h11m7s] NS ns3.google.com., google.com. [20h11m7s] NS ns2.google.com., google.com. [20h11m7s] NS ns4.google.com., google.com. [20h11m7s] NS ns1.google.com. ar: ns1.google.com. [3d1h38m55s] A 216.239.32.10, ns2.google.com. [3d23h47m49s] A 216.239.34.10, ns3.google.com. [3d21h48m48s] A 216.239.36.10, ns4.google.com. [3d14h11m23s] A 216.239.38.10 (235)
14:15:20.368936 IP (tos 0x0, ttl 64, id 36272, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.12.58407 > 74.125.234.191.http: Flags [S], cksum 0xa695 (correct), seq 2103294767, win 14600, options [mss 1460,sackOK,TS val 499988127 ecr 0,nop,wscale 7], length 0
14:15:20.370424 IP (tos 0x0, ttl 58, id 12210, offset 0, flags [none], proto TCP (6), length 60)
    74.125.234.191.http > 192.168.1.12.58407: Flags [S.], cksum 0x2a65 (correct), seq 1378505609, ack 2103294768, win 14180, options [mss 1430,sackOK,TS val 4016826562 ecr 499988127,nop,wscale 6], length 0
[...]

O atraso de 5 segundos entre a terceira e a quarta linhas acontece de forma consistente.

Eu não posso reproduzir o atraso usando nslookup , dig ou dig +dnssec , então estou sem ideias.

Alguém tem alguma pista sobre qual poderia ser o problema?

    

Answer 1

Isso acontece em ambientes IPv4 / IPv6 de pilha dupla onde a máquina que faz uma pesquisa de DNS envia solicitações para registros AAAA e A no mesmo soquete, esperando receber duas respostas de volta. Este é o comportamento padrão para versões relativamente recentes da glibc. O firewall da Juniper, no entanto, descarta a conexão após a primeira resposta.

A base de conhecimento da Juniper tem um artigo descrevendo como configurar o firewall para funcionar em torno desta questão .

Como observou o @BMDan, você também pode adicionar a linha a /etc/resolv.conf :

options single-request-reopen

Isso funciona em torno do comportamento do firewall quebrado abrindo duas conexões para procurar os registros AAAA e A.