BIND9 : corriger les logs EDNS UDP packet size 512

Voici un autre message croisé dans les logs de BIND9, généralement dans /var/log/daemon.log, /var/log/syslog ou via journalctl :

named: success resolving DOMAIN after reducing the advertised EDNS UDP packet size to 512 octets
named: success resolving DOMAIN after disabling EDNSCode language: HTTP (http)

Ce message signifie que BIND a réussi à résoudre le domaine, mais seulement après avoir réduit la taille UDP EDNS annoncée, ou après avoir désactivé EDNS pour cette requête.

Autrement dit : la résolution finit par fonctionner, mais le chemin réseau ou le serveur DNS distant ne gère pas correctement les requêtes EDNS avec une taille UDP plus grande.

À l’époque, je m’étais contenté de masquer la catégorie de logs correspondante. Aujourd’hui, je préfère commencer par comprendre le problème, puis réduire le bruit seulement si le comportement est connu et sans impact.

Comprendre EDNS et la limite historique de 512 octets

Le DNS historique sur UDP utilisait une taille de message limitée à 512 octets. EDNS, pour Extension Mechanisms for DNS, permet notamment d’annoncer une taille UDP plus grande et d’ajouter des options modernes au protocole DNS.

BIND peut donc envoyer des requêtes avec EDNS même si DNSSEC n’est pas activé. EDNS ne sert pas uniquement à DNSSEC, même si DNSSEC en dépend fortement pour transporter des réponses plus volumineuses.

Le problème apparaît lorsqu’un serveur autoritaire, un firewall, un routeur, une middlebox ou un lien réseau gère mal ces paquets UDP plus grands. BIND essaie alors une taille plus petite, parfois jusqu’à 512 octets, ou finit par désactiver EDNS pour obtenir une réponse.

L’ISC indiquait déjà que les versions supportées de BIND envoient des requêtes avec EDNS activé par défaut, et que certains équipements ou serveurs cassés peuvent provoquer ces messages de repli. Lire ISC Knowledge Base : BIND log messages about disabling EDNS.

Pourquoi la valeur 1232 est devenue importante

Pendant longtemps, beaucoup de résolveurs annonçaient une taille EDNS de 4096 octets. En pratique, cela pouvait provoquer de la fragmentation UDP et des échecs sur certains chemins réseau.

DNS Flag Day 2020 a recommandé de réduire les tailles de buffers EDNS afin d’éviter les problèmes de fragmentation. La page DNS Flag Day 2020 donne par exemple cette configuration pour BIND :

options {
    edns-udp-size 1232;
    max-udp-size 1232;
};

Cette valeur de 1232 octets vise à limiter le risque de fragmentation sur les réseaux IPv6 et IPv4 encapsulés. DNS Flag Day 2020

Les versions modernes de BIND ont aussi évolué dans ce sens. L’ISC indique que, pour dig, la taille EDNS par défaut est passée de 4096 à 1232 octets à partir de BIND 9.18, conformément aux recommandations de DNS Flag Day 2020. ISC Knowledge Base : dig and EDNS buffer size

Première étape : vérifier votre version de BIND

Avant de modifier la configuration, vérifiez la version installée :

named -v

Ou :

dig -v

Sur Debian/Ubuntu :

dpkg -l | grep bind9

Les versions modernes de BIND ont déjà des valeurs plus raisonnables que les anciennes. La documentation BIND 9.20 indique par exemple que edns-udp-size contrôle la taille EDNS UDP annoncée et que sa valeur par défaut est 1232. BIND 9 documentation : configuration reference

Vérifier où le message apparaît

Selon la distribution et la configuration logging, vous pouvez trouver le message dans plusieurs endroits :

sudo grep -R "reducing the advertised EDNS UDP packet size" /var/log 2>/dev/null
sudo grep -R "disabling EDNS" /var/log 2>/dev/nullCode language: JavaScript (javascript)

Avec systemd :

sudo journalctl -u bind9 -g "EDNS" --no-pagerCode language: JavaScript (javascript)

Ou en temps réel :

sudo journalctl -u bind9 -f

Si le message apparaît rarement et uniquement pour quelques domaines externes, ce n’est pas forcément grave. Si les logs sont saturés, ou si des domaines importants échouent régulièrement, il faut diagnostiquer davantage.

Tester un domaine avec dig

Pour tester un domaine qui déclenche le message, utilisez dig.

dig example.comCode language: CSS (css)

Pour afficher la requête envoyée et voir la taille EDNS annoncée :

dig example.com +qrCode language: CSS (css)

La ligne EDNS indique notamment la taille UDP annoncée.

Vous pouvez tester une taille précise :

dig example.com +bufsize=1232

Ou simuler une taille plus grande :

dig example.com +bufsize=4096

Et tester sans EDNS :

dig example.com +noednsCode language: CSS (css)

Ces tests permettent de savoir si le domaine répond correctement avec EDNS, avec une taille réduite, ou seulement sans EDNS.

Solution moderne : limiter la taille EDNS UDP

Si votre serveur utilise une ancienne configuration ou si vous constatez des problèmes liés à la fragmentation, vous pouvez définir explicitement une taille EDNS raisonnable.

Éditez le fichier :

sudo nano /etc/bind/named.conf.options

Dans le bloc options, ajoutez ou adaptez :

options {
    edns-udp-size 1232;
    max-udp-size 1232;

    // autres options...
};Code language: JavaScript (javascript)

La directive edns-udp-size fixe la taille EDNS UDP annoncée pour contrôler la taille des paquets reçus depuis les serveurs autoritaires lors des requêtes récursives. La documentation BIND indique que les valeurs valides vont de 512 à 4096, et que la valeur par défaut moderne est 1232. BIND 9 documentation : edns-udp-size

Cette configuration ne “supprime” pas seulement le message. Elle réduit aussi le risque que BIND doive retomber à 512 octets ou désactiver EDNS à cause de paquets fragmentés ou bloqués.

Tester puis recharger BIND

Avant de redémarrer BIND, vérifiez la syntaxe :

sudo named-checkconf

Si la commande ne retourne rien, la configuration est syntaxiquement valide.

Rechargez ensuite BIND :

sudo systemctl reload bind9

Ou, si nécessaire :

sudo systemctl restart bind9

Sur les anciens systèmes :

sudo service bind9 reload

Je préfère reload lorsque c’est possible, car cela évite un arrêt complet du service. Le bon vieux /etc/init.d/bind9 restart appartient plutôt à l’album de famille.

Solution historique : masquer la catégorie edns-disabled

Si vous avez identifié que ces messages ne sont que du bruit et que vous voulez simplement les retirer des logs, vous pouvez modifier la configuration de logging.

Dans /etc/bind/named.conf.options, ou mieux dans un fichier dédié inclus par votre configuration, ajoutez :

logging {
    category lame-servers { null; };
    category edns-disabled { null; };
};Code language: JavaScript (javascript)

Puis vérifiez et rechargez :

sudo named-checkconf
sudo systemctl reload bind9

Cette méthode supprime les messages de log, mais ne corrige pas la cause. Elle peut rester acceptable si vous savez que le serveur résout correctement les domaines concernés et que vous ne voulez pas polluer vos logs avec des serveurs distants mal configurés.

Mais je ne commencerais plus par là. Masquer une catégorie, c’est utile quand le bruit est compris. Sinon, c’est juste mettre un casque antibruit devant un voyant moteur.

Ne pas désactiver EDNS globalement

On pourrait être tenté de désactiver EDNS plus largement. Mauvaise idée dans la plupart des cas.

EDNS est nécessaire à de nombreux comportements DNS modernes, notamment DNSSEC. Le désactiver globalement peut provoquer plus de problèmes qu’il n’en résout.

La bonne approche consiste plutôt à :

• utiliser une taille EDNS UDP raisonnable ;
• vérifier les firewalls et middleboxes ;
• diagnostiquer les domaines qui posent problème ;
• laisser TCP/53 disponible pour les réponses volumineuses ;
• masquer les logs uniquement si le comportement est compris.

Vérifier que TCP/53 n’est pas bloqué

Quand une réponse DNS est trop grande pour UDP, le DNS peut basculer vers TCP. Si TCP/53 est bloqué, vous pouvez obtenir des résolutions lentes ou instables.

Pour tester une résolution en TCP :

dig example.com +tcpCode language: CSS (css)

Pour tester directement un serveur DNS spécifique :

dig @8.8.8.8 example.com +tcp
dig @1.1.1.1 example.com +tcpCode language: CSS (css)

Si votre résolveur local doit faire de la récursion, assurez-vous que les sorties UDP/53 et TCP/53 sont autorisées. Certains problèmes EDNS ne sont pas vraiment des problèmes BIND, mais des firewalls qui ont décidé d’être créatifs.

Cas DNSSEC

DNSSEC augmente souvent la taille des réponses DNS, car les réponses incluent des signatures et des enregistrements supplémentaires.

Si DNSSEC est activé sur votre résolveur, une mauvaise gestion d’EDNS, de la fragmentation UDP ou de TCP/53 peut provoquer des problèmes de validation ou de résolution.

Vérifiez votre configuration DNSSEC :

grep -R "dnssec-validation" /etc/bindCode language: JavaScript (javascript)

Et testez un domaine signé :

dig dnssec-failed.org
dig sigok.verteiltesysteme.netCode language: CSS (css)

Selon votre configuration, un domaine volontairement cassé comme dnssec-failed.org doit échouer si la validation DNSSEC fonctionne. C’est attendu.

Configuration moderne recommandée

Voici une base propre pour un résolveur BIND moderne :

options {
    directory "/var/cache/bind";

    recursion yes;
    dnssec-validation auto;

    edns-udp-size 1232;
    max-udp-size 1232;

    auth-nxdomain no;
    listen-on-v6 { any; };
};Code language: JavaScript (javascript)

Et si vous voulez réduire le bruit des logs après diagnostic :

logging {
    category lame-servers { null; };
    category edns-disabled { null; };
};Code language: JavaScript (javascript)

Je séparerais idéalement les deux intentions : d’abord une configuration DNS saine, ensuite une politique de logging moins bavarde.

Diagnostic rapide

Voici la séquence que j’utiliserais aujourd’hui :

# Version de BIND.
named -v
dig -v

# Voir les messages EDNS.
sudo journalctl -u bind9 -g "EDNS" --no-pager

# Tester le domaine avec la taille moderne.
dig example.com +bufsize=1232

# Tester avec une taille plus grande.
dig example.com +bufsize=4096

# Tester sans EDNS.
dig example.com +noedns

# Tester en TCP.
dig example.com +tcp

# Vérifier la configuration.
sudo named-checkconf

# Recharger BIND.
sudo systemctl reload bind9Code language: PHP (php)

Mémo rapide

# Fichier de configuration.
sudo nano /etc/bind/named.conf.options

# Réglage EDNS recommandé.
options {
    edns-udp-size 1232;
    max-udp-size 1232;
};

# Masquer les messages après diagnostic.
logging {
    category lame-servers { null; };
    category edns-disabled { null; };
};

# Vérifier la configuration.
sudo named-checkconf

# Recharger BIND.
sudo systemctl reload bind9

# Suivre les logs.
sudo journalctl -u bind9 -f

# Tester EDNS.
dig example.com +bufsize=1232
dig example.com +bufsize=4096
dig example.com +noedns
dig example.com +tcpCode language: PHP (php)

Conclusion

Le message success resolving after reducing the advertised EDNS UDP packet size to 512 octets indique que BIND a réussi à résoudre un domaine après avoir réduit la taille UDP EDNS annoncée. Il peut aussi indiquer un repli après désactivation d’EDNS.

Si le message est rare, il s’agit souvent d’un serveur distant ou d’un équipement réseau qui gère mal EDNS. Si le message est fréquent, il faut vérifier la taille EDNS, le passage TCP/53, DNSSEC, les firewalls et la version de BIND.

La correction moderne consiste souvent à utiliser une taille EDNS plus raisonnable :

edns-udp-size 1232;
max-udp-size 1232;

Si vous voulez seulement réduire le bruit dans les logs, vous pouvez toujours masquer la catégorie :

logging {
    category edns-disabled { null; };
};Code language: JavaScript (javascript)

Mais je traiterais cela comme une finition, pas comme le premier réflexe. Les logs sont bavards, certes, mais parfois ils essaient poliment de vous dire qu’un routeur quelque part massacre vos paquets DNS.

Report a typo