Vincular a recursão do DNS lenta

Acabamos de configurar um servidor DNS recursivo usando a versão estável mais recente do Bind 9.10

Estamos descobrindo que as pesquisas DNS recursivas são bastante lentas. Em qualquer lugar de 1 a 3 segundos. Depois que a pesquisa está no cache, o DNS é resolvido em questão de milissegundos, conforme o esperado.

Estamos utilizando dicas ROOT para as pesquisas recursivas e parece que é de onde vem a lentidão. Se configurarmos um encaminhador, a resolução do DNS diminuirá para um tempo de recursão sensato de 100 - 300ms.

Para o serviço que estamos configurando, não quero contar com encaminhadores, prefiro usar dicas de raiz.

Aqui está a principal configuração do nosso arquivo named.conf . Qualquer ponteiro para ajudar a melhorar o desempenho seria ótimo.

options{
allow-recursion  { any; };
allow-query-cache  { any; };
allow-query  { any; };

listen-on  port 53  { any; };
listen-on-v6  port 53  { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

zone-statistics yes;
max-cache-ttl 3600;
max-ncache-ttl 3600;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";

directory  "/var/named";
dump-file  "/var/named/data/cache_dump.db";
statistics-file  "/var/named/stats/named_stats.txt";
memstatistics-file  "/var/named/stats/named_mem_stats.txt";

rate-limit {
    responses-per-second 10;
    log-only yes;
};

prefetch 5;};

zone "." {
type hint;
file "named.ca";};

include "/var/named/conf/logging.conf";

Encontramos o problema. Foi um problema de transferência de hardware da NIC.

A execução tcpdump -vvv -s 0 -l -n port 53encontrou vários [bad udp cksum 6279!]erros para cada consulta DNS.

Uma pequena navegação no Google me apontou na direção certa. Como se vê, devido ao nosso sistema CentOS sendo executado como VM no XenServer (problemas semelhantes relatados com o VMWare etc.), o descarregamento de hardware da NIC é ativado por padrão.

A corrida ethtool -k eth0 | grep onmostrou o seguinte

x-checksumming: on
tx-checksum-ipv4: on
scatter-gather: on
tx-scatter-gather: on
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
tx-gso-robust: on [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]

Executando o ethtool -K eth0 tx off rx offTCP TCP descarregado desativado. Reiniciei o serviço de rede por uma boa medida

service network restart

e testado BIND. Agora estamos obtendo tempos de resposta muito rápidos do BIND

dig centos.org

; <<>> DiG 9.10.2-P4-RedHat-9.10.2-P4.el6 <<>> centos.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61933
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;centos.org.INA

;; ANSWER SECTION:
centos.org.60INA85.12.30.227

;; Query time: 268 msec
;; SERVER: 192.168.10.25#53(192.168.10.25)
;; WHEN: Thu Sep 17 08:25:39 AEST 2015
;; MSG SIZE  rcvd: 55

Eu tive esse mesmo problema com consultas recursivas muito lentas em um servidor físico do CentOS 7 BIND e encontrei essa resposta (TX Offloading) e muitas correções orientadas ao IPv6 em torno de vários threads, nenhum dos quais funcionou para mim.

Acontece que o local do servidor em questão tinha um firewall Cisco ASA mais antigo, que limitava o tamanho dos pacotes de resposta UDP a 512 bytes; Atualmente, parece que as respostas UDP para consultas DNS geralmente são muito maiores, até cerca de 2000 bytes. Há uma página sobre isso aqui:

Por que o DNS através do UDP tem um limite de 512 bytes?

Eu configurei o ASA para permitir pacotes de resposta UDP maiores (há um comando de correção específico para isso) que resolveu o problema:

https://supportforums.cisco.com/t5/getting-started-with-lans/dns-dropped-because-packets-to-big-for-configured-512/td-p/861718