A pesquisa reversa de DNS leva 5 segundos para desistir

1

Eu tenho um sistema Debian 2.6.26-2-xen-amd64 que leva 5 segundos entre a segunda e a terceira pesquisa reversa de DNS. Todos (a maioria?) Outros sistemas semelhantes aqui fazem as três pesquisas com pouca espera entre eles.

Eu tentei descobrir o que poderia estar causando a diferença, mas, até agora, não consegui. O que poderia ser?

EDITAR

Embora eu tenha observado o problema ao registrar na máquina com o sshd, sabendo que a lentidão geralmente tem um problema com o dns reverso, testei-o usando host . Isso está sendo fornecido pelo pacote host , versão 20000331-9 .

Aqui está a saída do tcpdump do teste em duas máquinas.

Anfitrião com atraso:

11:47:58.883885 IP 192.168.20.127.48797 > 172.16.1.1.53: 13275+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:47:58.884258 IP 172.16.1.1.53 > 192.168.20.127.48797: 13275 ServFail 0/0/0 (42)
11:47:58.884326 IP 192.168.20.127.34876 > 172.16.1.1.53: 13275+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:47:58.884804 IP 172.16.1.1.53 > 192.168.20.127.34876: 13275 ServFail 0/0/0 (42)
11:48:03.892639 IP 192.168.20.127.43032 > 172.16.1.1.53: 21337+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:48:03.893282 IP 172.16.1.1.53 > 192.168.20.127.43032: 21337 ServFail 0/0/0 (42)

Anfitrião sem demora:

11:15:58.222147 IP 192.168.21.26.50046 > 172.16.1.1.53: 2040+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.222611 IP 172.16.1.1.53 > 192.168.21.26.50046: 2040 ServFail 0/0/0 (42)
11:15:58.222718 IP 192.168.21.26.51288 > 172.16.1.1.53: 2040+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.223102 IP 172.16.1.1.53 > 192.168.21.26.51288: 2040 ServFail 0/0/0 (42)
11:15:58.223197 IP 192.168.21.26.36545 > 172.16.1.1.53: 20425+ PTR? 30.4.16.172.in-addr.arpa. (42)
11:15:58.223550 IP 172.16.1.1.53 > 192.168.21.26.36545: 20425 ServFail 0/0/0 (42)
    
por Daniel C. Sobral 27.10.2010 / 15:27

2 respostas

1

Ok, o problema foi o pacote libnss-mdns , que foi instalado como um pacote recomendado com Java.

    
por 28.10.2010 / 13:55
0

ServFail é uma situação anormal. Talvez versões posteriores do BIND ou da biblioteca de resolvedores implementem uma estratégia de prevenção de congestionamento mais agressiva para o ServFail? Os dois servidores estão executando versões diferentes do BIND ou da biblioteca de resolvedores?

Como o ServFail é incomum, indicando que alguns servidores DNS não estão respondendo, um atraso no envio da terceira tentativa normalmente não deve causar problemas adicionais. Na minha experiência, a perda do serviço DNS geralmente resulta em atrasos em vários segundos.

Suspeito que, se você recebesse, digamos, respostas NXDOMAIN, provavelmente não veria atrasos de muitos segundos.

Se os servidores DNS para o domínio reverso do endereço em questão fossem contatáveis e responsivos, isso não seria um problema?

    
por 27.10.2010 / 15:46