Recursion DNS lenta

9

Acabamos de configurar un servidor DNS recursivo utilizando la última versión estable de Bind 9.10

Estamos descubriendo que las búsquedas recursivas de DNS son bastante lentas. En cualquier lugar de 1 a 3 segundos. Una vez que la búsqueda está en caché, el DNS se resuelve en cuestión de milisegundos como se esperaba.

Estamos utilizando sugerencias ROOT para las búsquedas recursivas y parece que de aquí proviene la lentitud. Si configuramos un reenviador, la resolución de DNS se reduce a un tiempo de recursión razonable de 100 - 300 ms.

Para el servicio que estamos configurando, no quiero confiar en los reenviadores, preferiría usar sugerencias de raíz.

Aquí está la configuración principal de nuestro archivo named.conf . Cualquier sugerencia para ayudar a mejorar el rendimiento sería genial.

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";
ausip
fuente
55
Usaría tcpdump y vería qué sucede realmente durante las solicitudes lentas.
yoonix
¿Algo en los registros?
Håkan Lindqvist

Respuestas:

6

Encontramos el problema. Fue un problema de descarga de hardware de la NIC.

La ejecución tcpdump -vvv -s 0 -l -n port 53encontró un puñado de [bad udp cksum 6279!]errores para cada consulta DNS.

Un pequeño vistazo en Google me señaló en la dirección correcta. Como resultado, debido a que nuestro sistema CentOS se ejecuta como VM en XenServer (problemas similares informados con VMWare, etc.), la descarga de hardware NIC está habilitada de forma predeterminada.

Correr ethtool -k eth0 | grep onmostró lo siguiente

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]

Ejecución de la ethtool -K eth0 tx off rx offdescarga TCP TX deshabilitada. Reinicié el servicio de red por si acaso

service network restart

y probado BIND. Ahora estamos obteniendo tiempos de respuesta muy rápidos de 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
ausip
fuente
2

Tuve el mismo problema con las consultas recursivas muy lentas en un servidor físico CentOS 7 BIND y encontré esta respuesta (TX Offloading) y muchas correcciones orientadas a IPv6 en varios subprocesos, ninguno de los cuales funcionó para mí.

Resulta que la ubicación del servidor en cuestión tenía un firewall Cisco ASA más antiguo que estaba limitando el tamaño de los paquetes de respuesta UDP a 512 bytes; Parece que en estos días las respuestas UDP para las consultas DNS a menudo son mucho más grandes, hasta alrededor de 2000 bytes. Hay una página al respecto aquí:

¿Por qué DNS a través de UDP tiene un límite de 512 bytes?

Configuré el ASA para permitir paquetes de respuesta UDP más grandes (hay un comando de reparación específico para esto) que resolvió el problema:

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

Eric Hensley
fuente