Bind DNS Recursion Slow

Nous venons de configurer un serveur DNS récursif en utilisant la dernière version stable de Bind 9.10

Nous constatons que les recherches DNS récursives sont assez lentes. De 1 à 3 secondes. Une fois la recherche dans le cache, DNS se résout en quelques millisecondes comme prévu.

Nous utilisons des astuces ROOT pour les recherches récursives et cela semble être l'origine de la lenteur. Si nous configurons un redirecteur, la résolution DNS se résume à un temps de récursivité sensible de 100 à 300 ms.

Pour le service que nous mettons en place, je ne veux pas compter sur des transitaires, je préférerais utiliser des indices racine.

Voici la configuration principale de notre fichier named.conf . Tous les conseils pour améliorer les performances seraient formidables.

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

Nous avons trouvé le problème. Il s'agissait d'un problème de déchargement du matériel de la carte réseau.

L'exécution a tcpdump -vvv -s 0 -l -n port 53trouvé une poignée d' [bad udp cksum 6279!]erreurs pour chaque requête DNS.

Un petit survol sur Google m'a fait pointer dans la bonne direction. Il s'avère que, en raison de notre système CentOS fonctionnant en tant que VM sur XenServer (problèmes similaires signalés avec VMWare, etc.), le déchargement du matériel NIC est activé par défaut.

La course a ethtool -k eth0 | grep onmontré ce qui suit

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]

Exécution du ethtool -K eth0 tx off rx offdéchargement TCP TX désactivé. J'ai redémarré le service de mise en réseau pour faire bonne mesure

service network restart

et testé BIND. Nous obtenons maintenant des temps de réponse très rapides 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

J'ai eu ce même problème avec des requêtes récursives très lentes sur un serveur physique CentOS 7 BIND et j'ai trouvé cette réponse (déchargement TX) et de nombreux correctifs orientés IPv6 autour de divers threads, dont aucun ne fonctionnait pour moi.

Il s'avère que l'emplacement du serveur en question avait un pare-feu Cisco ASA plus ancien qui limitait la taille des paquets de réponse UDP à 512 octets; il semble que de nos jours, les réponses UDP pour les requêtes DNS sont souvent beaucoup plus importantes, jusqu'à environ 2000 octets. Il y a une page à ce sujet ici:

Pourquoi DNS via UDP a une limite de 512 octets?

J'ai configuré l'ASA pour autoriser des paquets de réponse UDP plus volumineux (il existe une commande de correction spécifique pour cela), ce qui a résolu le problème:

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