Bind DNS Recursion Slow


9

Abbiamo appena installato un server DNS ricorsivo utilizzando l'ultima versione stabile di Bind 9.10

Stiamo scoprendo che le ricerche DNS ricorsive sono piuttosto lente. Ovunque da 1 a 3 secondi. Una volta che la ricerca è nella cache, DNS si risolve in pochi millisecondi come previsto.

Stiamo utilizzando i suggerimenti ROOT per le ricerche ricorsive e questo sembra essere il punto da cui proviene la lentezza. Se configuriamo un server d'inoltro, la risoluzione DNS si riduce a un ragionevole tempo di ricorsione di 100 - 300 ms.

Per il servizio che stiamo configurando, non voglio fare affidamento su server di inoltro, preferirei utilizzare i suggerimenti di root.

Ecco la configurazione principale dal nostro file named.conf . Qualsiasi suggerimento per aiutare a migliorare le prestazioni sarebbe fantastico.

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

5
Vorrei usare tcpdump e vedere cosa sta realmente accadendo durante le richieste lente.
yoonix,

Qualcosa nei registri?
Håkan Lindqvist,

Risposte:


6

Abbiamo riscontrato il problema. Era un problema di scaricamento dell'hardware della NIC.

L'esecuzione ha tcpdump -vvv -s 0 -l -n port 53rilevato una manciata di [bad udp cksum 6279!]errori per ogni query DNS.

Una piccola navigazione su Google mi ha indicato la giusta direzione. A quanto pare, a causa del nostro sistema CentOS in esecuzione come VM su XenServer (problemi simili segnalati con VMWare ecc.), L'offload dell'hardware NIC è abilitato per impostazione predefinita.

La corsa ha ethtool -k eth0 | grep onmostrato quanto segue

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]

Esecuzione di ethtool -K eth0 tx off rx offoffload TCP TX disabilitato. Ho riavviato il servizio di rete per buona misura

service network restart

e testato BIND. Ora stiamo ottenendo tempi di risposta molto rapidi da 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

2

Ho avuto lo stesso problema con query ricorsive molto lente su un server BIND CentOS 7 fisico e ho trovato questa risposta (Offload TX) e molte correzioni orientate a IPv6 attorno a vari thread, nessuna delle quali ha funzionato per me.

Si scopre che la posizione del server in questione aveva un vecchio firewall Cisco ASA che limitava la dimensione dei pacchetti di risposta UDP a 512 byte; al giorno d'oggi sembra che le risposte UDP per le query DNS siano spesso molto più grandi, fino a circa 2000 byte. C'è una pagina a riguardo qui:

Perché DNS tramite UDP ha un limite di 512 byte?

Ho configurato l'ASA per consentire pacchetti di risposta UDP più grandi (esiste un comando di correzione specifico per questo) che ha risolto il problema:

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.