BIND9 : supprimer le message "success resolving after reducing the advertised EDNS UDP packet size to 512 octets" des logs photo

BIND9 : corriger les logs EDNS UDP packet size 512

Publié le 11 mai 2026 by Matt Biscay · Lecture: 6 minutes

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.

NginX : corriger “upstream sent too big header”

Publié le 10 mai 2026 by Matt Biscay · Lecture: 8 minutes

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas. Côté navigateur, j’obtenais une erreur 502 Bad Gateway. Côté logs Nginx, le message était beaucoup plus explicite :

upstream sent too big header while reading response header from upstreamCode language: JavaScript (javascript)

Ce message signifie que Nginx a bien reçu une réponse de l’upstream, par exemple PHP-FPM, mais que les en-têtes HTTP envoyés par cet upstream sont trop gros pour les buffers configurés.

En clair : le backend répond, mais Nginx n’arrive pas à lire tous les headers de réponse dans l’espace mémoire prévu. Il coupe donc court et renvoie souvent une erreur 502.

Comprendre l’erreur “upstream sent too big header”

Dans une configuration PHP classique, Nginx reçoit les réponses depuis PHP-FPM via FastCGI. La réponse contient deux parties :

les en-têtes HTTP, par exemple Set-Cookie, Location, Cache-Control ;
le corps de la réponse, c’est-à-dire le HTML, JSON, XML, etc.

L’erreur apparaît lorsque la partie “headers” dépasse la taille que Nginx peut lire avec la configuration actuelle.

La documentation Nginx indique que fastcgi_buffer_size définit la taille du buffer utilisé pour lire la première partie de la réponse FastCGI, qui contient généralement une petite réponse avec les headers. Elle indique aussi que fastcgi_buffers définit le nombre et la taille des buffers utilisés pour lire la réponse complète de l’upstream FastCGI.

Dans le cas d’un reverse proxy classique, le même problème peut exister, mais avec les directives proxy_buffer_size et proxy_buffers, pas avec fastcgi_buffer_size.

Serveur dédié : résoudre l’erreur “Can’t connect to local MySQL server through socket”

Publié le 09 mai 2026 by Matt Biscay · Lecture: 7 minutes

Après une mise à jour du serveur SQL, ou après un redémarrage physique du serveur, il est possible d’obtenir l’erreur suivante :

error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Missing /var/run/mysqld/mysqld.sockCode language: PHP (php)

On peut aussi la rencontrer sous cette forme :

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)Code language: JavaScript (javascript)

Cette erreur signifie que le client MySQL essaie de se connecter à un socket Unix local, mais que le fichier mysqld.sock n’existe pas à l’emplacement attendu.

Le problème peut avoir plusieurs causes : MySQL n’est pas démarré, le serveur écoute sur un autre socket, le répertoire /run/mysqld n’existe pas, ses permissions sont incorrectes, ou le service n’arrive pas à créer son socket au boot.

Comprendre le rôle de mysqld.sock

Sur Linux, une connexion locale à MySQL ou MariaDB peut passer par un socket Unix plutôt que par TCP/IP.

Au lieu de se connecter à :

127.0.0.1:3306Code language: CSS (css)

le client utilise un fichier spécial, souvent situé ici :

/var/run/mysqld/mysqld.sockCode language: JavaScript (javascript)

ou, plus précisément sur les systèmes modernes :

/run/mysqld/mysqld.sock

Sur beaucoup de distributions, /var/run est un lien symbolique vers /run. Le répertoire /run est temporaire : son contenu est recréé à chaque démarrage. C’est précisément pour cela qu’un problème de création du dossier /run/mysqld peut réapparaître après un reboot.

MySQL explique que le chemin du socket peut être défini avec l’option socket dans les fichiers de configuration, aussi bien dans une section serveur comme [mysqld] que dans une section client comme [client].