O que poderia ser essa latência extra de 50 ms em meu servidor de resolução de DNS não acoplado (Fedora)?

Question

Eu tenho uma discrepância na latência da consulta. Não é um problema, é estranho o suficiente para me preocupar.

• A máquina cliente (Fedora 18) é executada de forma não vinculada - 1.4.19-1.fc18.x86_64.
• Máquina do servidor (teste Debian 7) executa o unbound 1.4.17-2.

Ambos estão conectados ao mesmo roteador doméstico. No entanto, o servidor pode resolver consultas não armazenadas em cache quase duas vezes mais rápido. Isso não era o que eu esperava! O servidor é um ARM de 1Ghz (sheevaplug), e a máquina cliente é um Intel Core Duo de 2.1Ghz.

Ambas as instâncias validam o DNSSEC. Eles retornam o SERVFAIL para www.dnssec-failed.org. Ambos estão configurados para usar os mesmos caches de DNS upstream do meu ISP.

Tudo o que posso pensar até agora é algum problema com o NAT. O roteador é configurado com o servidor como "padrão DMZ", ou seja, ele recebe todos os pacotes que ninguém mais está reivindicando, que é como eu executo serviços públicos como SSH e bittorrent :). Ou ... talvez a versão menor-19 esteja validando mais estritamente que a versão menor-17, de alguma forma?

Metodologia de teste: resolução de 10 subdomínios inexistentes de .de. (Deve causar falta de cache do ISP). O .de. O TLD é pré-carregado consultando o yahoo.

Do lado do cliente

$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig twitter$i.de.) | grep Query; done

Result - mean 120ms, stddev 60ms

Do lado do servidor

$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig aldi$i.de. ) | grep Query; done

Result - mean 70ms, stddev 50ms

Eu sei, o teste não parece ótimo, e minhas estatísticas podem não ser uma evidência esmagadora. Mas eu tentei mais algumas vezes, e não parece diferente.

    

Answer 1

Ah! Eu apenas deparei o unbound.conf entre os dois computadores. Parece que o Fedora liga a opção abaixo. Desligá-lo elimina a latência adicional na máquina do Fedora.

    # Harden the referral path by performing additional queries for
    # infrastructure data.  Validates the replies (if possible).
    # Default off, because the lookups burden the server.  Experimental
    # implementation of draft-wijngaards-dnsext-resolver-side-mitigation.
    harden-referral-path: yes

Vou ter que procurar e decidir se quero usá-lo:).

Link: link