Ligar a recursão de DNS lenta

Question

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

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

Estamos utilizando dicas de ROOT para as pesquisas recursivas e isso parece ser o local de origem da lentidão. Se configurarmos um encaminhador, a resolução do DNS será reduzida para um tempo sensitivo de recursão de 100 a 300 ms.

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

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

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";

    

Answer 1

Encontramos o problema. Foi um problema de descarregamento de hardware da NIC.

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

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

A execução de ethtool -k eth0 | grep on mostrou 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]

A execução de ethtool -K eth0 tx off rx off desativou o descarregamento do TCP TX. Eu reiniciei o serviço de rede para uma boa medida

service network restart

e testado BIND. Estamos agora recebendo 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

    

Answer 2

Eu tive esse mesmo problema com consultas recursivas muito lentas em um servidor físico do BOSD do CentOS 7 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 a localização do servidor em questão tinha um firewall Cisco ASA mais antigo que limitava o tamanho dos pacotes de resposta UDP a 512 bytes; Parece que hoje em dia as respostas UDP para consultas DNS são geralmente 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?

Configurei o ASA para permitir pacotes maiores de resposta UDP (existe um comando de ajuste específico para isso) que resolveu o problema:

link