DNS : les problèmes de MTU peuvent casser le DNS — comment le prouver et le corriger

Ce qui se passe réellement : pourquoi la MTU casse le DNS

Le DNS est petit jusqu’à ce qu’il ne le soit plus. Les requêtes A pour des zones modestes tiennent généralement confortablement dans un seul paquet UDP. Mais dès que les réponses grossissent — signatures DNSSEC, plusieurs enregistrements, longues chaînes TXT (bonjour SPF/DMARC), enregistrements SVCB/HTTPS, ou simplement un résolveur bavard — vous pouvez obtenir une réponse qui dépasse la MTU du chemin entre le client et le serveur.

Quand cela arrive, deux choses doivent être vraies pour que le DNS sur UDP fonctionne :

• La réponse doit être fragmentée et tous les fragments doivent arriver, dans l’ordre, au client.
• Ou le client et le serveur doivent négocier une charge utile plus petite (typiquement via EDNS(0)) pour éviter toute fragmentation.

Dans les réseaux réels, la fragmentation est fragile. Les pare-feu laissent tomber les fragments. Les dispositifs NAT « aident » en expirant les fragments. Certains équilibreurs de charge ne hachent que sur le premier fragment (qui ne contient pas les ports UDP pour les fragments suivants), et alors vos fragments empruntent des chemins différents comme dans un travail de groupe.

Donc la requête DNS sort, le résolveur envoie une réponse UDP trop grande, cette réponse est fragmentée, un fragment disparaît, et le client reste là à attendre. Finalement il réessaie, peut-être en TCP, peut-être vers un autre résolveur, peut-être pas. De l’extérieur vous voyez : « instabilité DNS ». De l’intérieur vous voyez : « un problème réseau couche 2–3 déguisé en problème couche 7 ».

La découverte de la MTU du chemin (PMTUD) est censée prévenir ce bazar en faisant envoyer par les routeurs des ICMP « Fragmentation Needed » (IPv4) ou « Packet Too Big » (IPv6) pour que les points de terminaison apprennent la taille maximale. Mais PMTUD nécessite que l’ICMP passe. De nombreux environnements traitent ICMP comme un invité indésirable et s’étonnent ensuite que la plomberie fuit.

Une réalité opérationnelle : le DNS est souvent le premier protocole à révéler la douleur de la MTU parce qu’il est omniprésent, utilise UDP par défaut et intervient dans presque toutes les autres cascades de panne. Quand le DNS casse, tout semble cassé. Votre travail consiste à prouver que c’est la MTU, puis à réparer le chemin pour ne pas passer la semaine suivante à blâmer le résolveur.

Blague #1 : Si vous bloquez l’ICMP parce que c’est « peu sûr », vous avez réinventé l’équivalent réseau d’enlever le témoin d’huile parce qu’il était gênant.

Le mécanisme clé : EDNS(0) et « quelle taille est trop grande ? »

Le DNS classique limitait les réponses UDP à 512 octets. EDNS(0) (RFC 2671, puis RFC 6891) a étendu le DNS pour que les clients puissent annoncer un tampon UDP plus grand (souvent 1232 octets est une valeur moderne sûre). C’est bien : cela réduit les retours en TCP et améliore les performances. C’est aussi mauvais : cela augmente la probabilité de dépasser la MTU d’un chemin défaillant et d’avoir des pertes silencieuses.

Donc le schéma « la MTU casse le DNS » ressemble souvent à ceci :

1. Le client envoie une requête DNS avec EDNS(0) annonçant 4096 octets.
2. Le résolveur renvoie une réponse UDP de 1600–3000 octets.
3. Un saut ne peut pas la transporter (par ex. tunnel VPN, lien PPPoE, réseau d’overlay, MTU mal réglée sur une vNIC).
4. La fragmentation se produit ou la PMTUD devrait se déclencher, mais les fragments/ICMP sont bloqués.
5. Le client expire, réessaie, ou bascule sur TCP — si c’est autorisé.

Pourquoi c’est souvent « seulement certains domaines »

Les problèmes de MTU ne cassent pas le DNS tant qu’ils ne cassent pas les grosses réponses DNS. C’est pourquoi vous pouvez résoudre example.com toute la journée tandis que some-dnssec-heavy-domain.tld plante. Tout domaine avec DNSSEC, de grands enregistrements TXT, beaucoup d’enregistrements dans un RRset, ou des chaînes CNAME est un candidat.

Le plus effrayant est que vous pouvez « réparer » cela accidentellement en changeant de résolveur, en mettant plus en cache ou en attendant. Aucun de ces changements ne répare le chemin. Ils déplacent simplement le symptôme jusqu’à ce qu’il fasse mal à un nom plus important à 2 h du matin.

Faits & historique importants en production

• Fait 1 : La limite originale des réponses UDP DNS était de 512 octets ; EDNS(0) a relevé cette limite en permettant aux clients d’annoncer un tampon UDP plus grand.
• Fait 2 : L’adoption de DNSSEC a rendu les réponses volumineuses courantes, car les signatures et le matériel de clés ajoutent du poids — en particulier pour les réponses négatives (preuves NSEC/NSEC3).
• Fait 3 : Une taille UDP EDNS « sûre » couramment utilisée aujourd’hui tourne autour de 1232 octets pour éviter les problèmes de fragmentation IPv6 sur les parcours typiques.
• Fait 4 : PPPoE réduit la MTU Ethernet de 1500 à 1492, et les tunnels peuvent vous amener encore plus bas. Vous pouvez perdre ~60–80 octets rapidement.
• Fait 5 : Les routeurs IPv4 peuvent fragmenter les paquets, mais les routeurs IPv6 ne fragmentent pas ; la fragmentation est effectuée uniquement par les points de terminaison, ce qui rend PMTUD et la livraison d’ICMPv6 beaucoup plus importants.
• Fait 6 : De nombreux middleboxes traitent les fragments IP comme suspects et les laissent tomber, parfois intentionnellement, parfois comme effet secondaire d’un « durcissement ».
• Fait 7 : Certains dispositifs NAT et pare-feu suivent mal les flux UDP pour les fragments, parce que les fragments ultérieurs n’incluent pas les informations de port UDP.
• Fait 8 : Le basculement DNS vers TCP fait partie de la conception du protocole, mais dans les réseaux d’entreprise TCP/53 est souvent bloqué « parce que DNS, c’est UDP ». C’est comme transformer un petit problème de MTU en panne totale.
• Fait 9 : Les réseaux d’overlay cloud et l’encapsulation (VXLAN, Geneve, IPsec, GRE) réduisent couramment la MTU effective. Quand vous empilez des tunnels, vous empilez de l’overhead, pas du bonheur.

Une citation à garder en mémoire dans la culture ops, car elle s’applique sans détour aux mystères de la MTU :

« une idée paraphrasée » — Richard Feynman : la réalité doit primer sur les relations publiques ; la nature ne se laisse pas tromper.

Playbook de diagnostic rapide (faire ceci en priorité)

Si le DNS est instable et que vous suspectez la MTU, ne commencez pas par réinstaller systemd-resolved ou par argumenter sur quel résolveur public est le meilleur. Faites ceci :

1) Confirmer qu’il s’agit de « réponses DNS volumineuses »

• Choisissez un domaine qui échoue et un domaine qui réussit.
• Testez avec EDNS activé et désactivé.
• Testez explicitement UDP vs TCP.

2) Mesurer la MTU du chemin dans la direction défaillante

• Depuis le client vers l’IP du résolveur (pas « Internet » en général).
• Utilisez des ping avec le bit DF (IPv4) ou des ping IPv6 avec taille.
• S’attendre à trouver un nombre inférieur à 1500 sur les VPN, PPPoE, overlays et certains parcours cloud.

3) Chercher des trous ICMP et des pertes de fragments

• Capture de paquets sur le client ou près du résolveur.
• Vérifier les règles de pare-feu pour les ICMP « Fragmentation Needed » / « Packet Too Big ».
• Vérifier si TCP/53 fonctionne ; si oui, vous regardez un problème de fragmentation UDP.

4) Appliquer la mitigation la moins risquée en premier

• Réduire la taille UDP EDNS sur les clients/résolveurs (par ex. 1232).
• Autoriser TCP/53 lorsque c’est approprié.
• Corriger la MTU du tunnel/interface et le MSS clamping correctement (ne devinez pas ; mesurez).

Prouvez-le avec des commandes : 12+ tâches et décisions réelles

Les tâches suivantes sont écrites comme si vous étiez en astreinte : vous exécutez une commande, interprétez la sortie, puis prenez une décision. Exécutez-les depuis un client qui subit les échecs, et si possible depuis un hôte proche du résolveur aussi.

Task 1: Reproduce the failure with dig and capture timing

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +tries=1 +time=2
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Ce que ça signifie : Vous avez un problème de reachability client→résolveur au niveau DNS. Pas encore assez pour l’appeler MTU.

Décision : Comparez avec un domaine « petit » puis forcez TCP pour voir si UDP est le problème.

Task 2: Compare with a known small response

cr0x@server:~$ dig @10.20.30.40 example.com A +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 example.com A +tries=1 +time=2
;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34
;; Query time: 18 msec

Ce que ça signifie : Le DNS de base vers le résolveur fonctionne. Il s’agit donc probablement d’un problème dépendant des données : taille de réponse, fragmentation, DNSSEC ou filtrage de paquets.

Décision : Forcez TCP pour le nom qui échoue. Si TCP réussit, suspectez une fragmentation UDP/PMTUD.

Task 3: Force TCP DNS (bypasses UDP fragmentation issues)

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +tcp +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +tcp +tries=1 +time=2
;; ANSWER SECTION:
large-dnssec-domain.example. 300 IN A 203.0.113.77
;; Query time: 42 msec

Ce que ça signifie : TCP/53 fonctionne et renvoie une réponse. Le chemin UDP est probablement en cause, pas les données du résolveur.

Décision : Confirmez que la réponse est volumineuse et provoque le comportement EDNS/fragmentation.

Task 4: Inspect EDNS and UDP payload size negotiation

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=4096

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=4096
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; connection timed out; no servers could be reached

Ce que ça signifie : Annoncer un grand tampon UDP déclenche l’échec. Cela est cohérent avec des problèmes de MTU/fragmentation.

Décision : Essayez un tampon plus petit (1232) et voyez si cela devient fiable.

Task 5: Reduce EDNS buffer to avoid fragmentation

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=1232 +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=1232 +tries=1 +time=2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; ANSWER SECTION:
large-dnssec-domain.example. 300 IN A 203.0.113.77
;; Query time: 29 msec

Ce que ça signifie : Une charge UDP plus petite réussit. Votre chemin ne supporte probablement pas de grandes réponses UDP de façon fiable.

Décision : Maintenant vous devez prouver la limitation MTU/chemin, pas seulement « bizarrerie EDNS ». Mesurez la PMTU ensuite.

Task 6: Measure IPv4 path MTU with DF pings

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1472

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Ce que ça signifie : La MTU de votre interface (ou d’un saut proche) est inférieure à ce que vous attendiez, ou vous êtes sur un lien avec une MTU réduite. L’erreur locale indique que la pile locale ne peut pas envoyer cette taille sur cette interface.

Décision : Trouvez la MTU réelle de l’interface puis faites une recherche binaire le long du chemin avec des tailles plus petites. Vérifiez aussi si le résolveur est atteint via une interface tunnel.

Task 7: Find interface MTU and the egress interface used

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.8.0.1 dev tun0 src 10.8.0.10 uid 1000
    cache

cr0x@server:~$ ip link show dev tun0
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Ce que ça signifie : Le DNS vers le résolveur passe par tun0 avec une MTU de 1400. C’est déjà inférieur aux 1500 Ethernet ; ajoutez les en-têtes et vous pouvez facilement étouffer de grands UDP.

Décision : Testez la PMTU vers le résolveur avec des tailles inférieures à 1400 et confirmez où ça casse.

Task 8: Confirm the largest unfragmented payload to resolver (binary-ish search)

cr0x@server:~$ ping -M do -s 1372 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1380 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=31.2 ms
1380 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=30.7 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

cr0x@server:~$ ping -M do -s 1392 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1392(1420) bytes of data.
From 10.8.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.8.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1400)

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss

Ce que ça signifie : Votre PMTU est de 1400 sur ce chemin, et le message ICMP « Frag needed » vous parvient réellement (c’est positif). Si l’ICMP était bloqué, vous verriez seulement des expirations.

Décision : Puisque la PMTU est 1400, demandez-vous : pourquoi EDNS 4096 a-t-il échoué ? Parce qu’un chemin MTU 1400 fragmentera les réponses UDP supérieures à cela. Si les fragments sont perdus, vous obtenez des expirations. Ensuite : confirmez la perte de fragments avec tcpdump.

Task 9: Capture DNS packets and look for fragmentation behavior

cr0x@server:~$ sudo tcpdump -ni tun0 -vvv 'host 10.20.30.40 and (udp port 53 or tcp port 53)' -c 20
tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
IP 10.8.0.10.50821 > 10.20.30.40.53: 12345+ [1au] A? large-dnssec-domain.example. (56)
IP 10.20.30.40.53 > 10.8.0.10.50821: 12345* 1/0/1 A 203.0.113.77 (1492)
IP 10.8.0.10.42233 > 10.20.30.40.53: 54321+ [1au] A? large-dnssec-domain.example. (56)
IP 10.8.0.10.42233 > 10.20.30.40.53: Flags [S], seq 101, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
IP 10.20.30.40.53 > 10.8.0.10.42233: Flags [S.], seq 202, ack 102, win 65160, options [mss 1360,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0

Ce que ça signifie : Vous pouvez voir une grande réponse UDP (1492 octets sur le fil) qui dépasse la MTU 1400 sur le tunnel ; selon le point de capture, vous pouvez ou non voir la fragmentation explicitement. La présence d’un SYN TCP ensuite suggère que le client réessaie et bascule sur TCP.

Décision : Si vous ne voyez pas la réponse UDP complète arriver (ou si vous la voyez partir du serveur mais pas arriver au client), vous avez une perte de fragments. Mitigez en réduisant la taille EDNS et/ou en corrigeant la MTU du tunnel et en autorisant l’ICMP.

Task 10: Confirm whether TCP/53 is allowed end-to-end

cr0x@server:~$ nc -vz 10.20.30.40 53
Connection to 10.20.30.40 53 port [tcp/domain] succeeded!

Ce que ça signifie : TCP/53 est ouvert sur ce chemin. C’est un filet de sécurité ; de nombreux réseaux ne l’ont pas.

Décision : Si TCP fonctionne, vous pouvez mitiger rapidement en vous assurant que les clients/résolveurs utilisent correctement le basculement TCP et en réduisant les tailles UDP. Si TCP est bloqué, corrigez cela immédiatement — puis poursuivez la recherche de la cause MTU.

Task 11: Check resolver-side settings for EDNS buffer size (BIND example)

cr0x@server:~$ sudo named-checkconf -p | grep -E 'edns-udp-size|max-udp-size' || true
        max-udp-size 4096;

Ce que ça signifie : Le résolveur est prêt à envoyer des réponses UDP très grandes. C’est optimiste dans des réseaux d’entreprise avec tunnels et pare-feu.

Décision : Réduire à un nombre plus sûr (souvent 1232) à moins que vous ne contrôliez chaque saut et puissiez prouver que des tailles plus grandes fonctionnent de manière fiable.

Task 12: Apply a safer max UDP size on the resolver (BIND) and validate config

cr0x@server:~$ sudo sed -i 's/max-udp-size 4096;/max-udp-size 1232;/' /etc/bind/named.conf.options
cr0x@server:~$ sudo named-checkconf
cr0x@server:~$ sudo systemctl reload bind9
cr0x@server:~$ sudo systemctl status bind9 --no-pager -l
● bind9.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
     Active: active (running)

Ce que ça signifie : Le résolveur est maintenant limité à des réponses UDP plus petites, réduisant le risque de fragmentation.

Décision : Retestez les domaines qui échouaient avec dig sans forcer +bufsize. Si le problème disparaît, vous avez prouvé une sensibilité à la MTU/fragmentation sur le chemin. Corrigez néanmoins le réseau de fond.

Task 13: Check if ICMP “frag needed” is being dropped by host firewall (Linux)

cr0x@server:~$ sudo iptables -S | grep -E 'icmp|fragmentation|RELATED' || true
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT

Ce que ça signifie : L’ICMP est autorisé sur l’hôte. Si vous n’aviez vu que des expirations plus tôt, le blocage pourrait être sur un pare-feu réseau plutôt que sur l’hôte.

Décision : Si l’ICMP est bloqué quelque part sur le chemin, corrigez la politique pour autoriser les types ICMP essentiels (pas « tout l’ICMP pour toujours », mais assez pour PMTUD).

Task 14: Check MSS clamping on a VPN gateway (common mitigation for TCP, not UDP)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i clamp || true
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ce que ça signifie : Le MSS clamping est en place, ce qui aide TCP à éviter les problèmes de MTU. Cela ne fait rien pour la fragmentation UDP du DNS.

Décision : Ne vous arrêtez pas là. Les gens voient « clamp-mss-to-pmtu » et se déclarent victorieux, puis se demandent pourquoi le DNS sur UDP meurt toujours. Vous avez besoin d’ajuster la taille EDNS et/ou la MTU.

Task 15: Quick Kubernetes check: does CoreDNS see truncation or retries?

cr0x@server:~$ kubectl -n kube-system logs deploy/coredns --tail=50 | grep -E 'timeout|truncated|SERVFAIL' || true
[ERROR] plugin/errors: 2 large-dnssec-domain.example. A: read udp 10.244.2.15:46122->10.20.30.40:53: i/o timeout

Ce que ça signifie : CoreDNS subit des timeouts en lecture UDP vers le résolveur amont. Si TCP réussit depuis le même pod/réseau, suspectez la MTU/fragmentation entre le cluster et le résolveur (souvent un décalage MTU d’overlay).

Décision : Vérifiez la MTU du réseau de pods et la MTU des nœuds, et définissez CoreDNS (ou l’amont) sur une taille EDNS sûre. Puis corrigez proprement la MTU de l’overlay/tunnel.

Trois mini-histoires d’entreprise (comment ça se passe vraiment)

1) L’incident causé par une mauvaise hypothèse

Ils ont déployé un nouveau VPN site-à-site entre deux bureaux. Il est venu avec les promesses habituelles : « connectivité transparente », « aucune modification d’application », « c’est juste du routage ». L’équipe réseau a laissé la MTU du tunnel à une valeur par défaut qu’ils utilisaient depuis des années, puis est passée à autre chose. Personne n’a mesuré quoi que ce soit, parce que pourquoi mesurer ce qui est « standard » ?

Lundi matin, le volume de tickets a explosé. Les utilisateurs pouvaient accéder aux applis internes par IP, mais les noms étaient instables. Certaines pages web se chargeaient, d’autres tournaient indéfiniment, et le portail d’authentification échouait comme si c’était un problème d’authent. Les graphiques du résolveur avaient l’air propres. CPU ok. QPS normal. L’astreinte a commencé à chasser la « performance du serveur DNS ».

Il a suffi d’une personne pour lancer dig +tcp. Soudain, les domaines qui échouaient se résolvaient instantanément, et l’« incident d’authentification » ressemblait beaucoup à une « taille de réponse DNSSEC ». Les captures de paquets ont montré des réponses UDP quittant le résolveur et n’arrivant jamais intactes au client. Le chemin du tunnel avait une MTU effective plus petite que prévu, et le pare-feu au milieu laissait tomber les fragments.

La mauvaise hypothèse n’était pas une erreur de calcul MTU ; c’était une question de responsabilité. Tout le monde supposait « le VPN le gère » et « DNS, c’est petit ». La correction a été embarrassante de simplicité : corriger la MTU du tunnel, autoriser l’ICMP nécessaire, et plafonner la taille UDP EDNS sur le résolveur comme mesure de précaution. L’action en post-mortem a été encore plus simple : tout nouveau tunnel doit inclure un test PMTU mesuré dans la checklist de déploiement.

2) L’optimisation qui a mal tourné

Une autre organisation avait une initiative de performance : réduire la latence en évitant TCP pour le DNS. Quelqu’un a remarqué que les requêtes TCP représentaient une fraction non négligeable du trafic du résolveur lors des heures de pointe. Ils ont donc « optimisé » en augmentant les tampons EDNS sur toute la flotte et en ajustant les pare-feu pour « privilégier UDP ». Le changement avait l’air bon sur un benchmark étroit : moins de handshakes TCP, latence moyenne légèrement plus basse.

Deux semaines plus tard, un sous-ensemble d’employés distants a commencé à signaler que « certains sites n’existent pas » et que « le VPN est instable ». C’était intermittent et maddening. L’équipe résolveur a vu plus de retransmissions et d’expirations mais ne pouvait pas reproduire depuis le datacenter. L’équipe VPN a blâmé le Wi‑Fi. L’équipe poste de travail a blâmé l’OS. Chacun avait une histoire plausible ; aucune n’était correcte.

La cause racine était l’optimisation : des réponses UDP plus grandes augmentaient la fréquence de fragmentation sur des liens VPN à MTU effective plus petite. Le chemin incluait un dispositif de sécurité qui supprimait les fragments non-premiers comme partie d’un « baseline de durcissement ». L’ancienne configuration forçait plus de troncation et le basculement TCP, qui — bien que plus lent — était fiable. Ils avaient optimisé la marge de sécurité.

Le rollback a réduit la taille UDP EDNS à une valeur conservatrice, et ils ont explicitement autorisé TCP/53. Ensuite ils ont corrigé la configuration du dispositif de sécurité pour cesser de jeter aveuglément les fragments et ont autorisé les types ICMP nécessaires pour PMTUD. La leçon n’était pas « ne jamais optimiser ». C’était « n’optimisez que ce que vous pouvez observer de bout en bout », surtout quand le protocole est UDP et que le réseau est rempli de middleboxes opiniâtres.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe avait une règle qui semblait ennuyeuse : tout changement de résolveur requérait un test canari depuis au moins trois points de vue réseau — datacenter, VPN et une VPC cloud. Le jeu de tests n’était pas sophistiqué. C’était une poignée de dig, quelques noms connus volumineux DNSSEC, et un cas forcé +bufsize pour simuler le pire comportement.

Pendant une mise à jour routinière, leur canari depuis le VPN a commencé à échouer uniquement sur les noms à « grosse réponse ». Tout le reste passait. La mise à jour elle-même était correcte. La différence était que le pool de concentrateurs VPN avait été rafraîchi la même semaine, et un nouveau modèle d’appliance avait une MTU effective plus petite due à une couche d’encapsulation supplémentaire.

Parce qu’ils ont testé depuis la périphérie, ils l’ont attrapé avant les utilisateurs. Ils ont réduit la taille UDP EDNS sur le résolveur comme mitigation immédiate, puis ont corrigé la MTU VPN et assuré que les ICMP « Packet Too Big » étaient autorisés. Pas d’appel incident, pas d’escalade exécutive, pas de tickets. Juste des tests ennuyeux qui ont évité le drame.

Blague #2 : Le travail fiabilité ennuyeux, c’est comme se brosser les dents — personne n’en parle, mais tout le monde remarque quand vous ne le faites pas.

Corrections durables (et ce qu’il faut éviter)

Catégorie A : Rendre le DNS moins susceptible de fragmenter

Définir une taille UDP EDNS conservatrice

Si vous ne faites qu’une mitigation, faites celle-ci. De nombreux résolveurs et clients permettent d’ajuster la taille de charge utile UDP annoncée/acceptée. Une cible opérationnelle courante est 1232 octets, choisie pour bien s’entendre avec IPv6 et les overheads d’overlay typiques.

Côté résolveur (exemples) :

• BIND : max-udp-size 1232;
• Unbound : ajuster edns-buffer-size / msg-buffer-size selon le cas
• PowerDNS Recursor : configurer les limites EDNS UDP

Le bouton exact diffère, mais l’intention opérationnelle est la même : arrêter d’émettre des réponses UDP « héroïques » qui comptent sur la fragmentation à travers des réseaux inconnus.

Autoriser TCP/53 et s’assurer que le basculement fonctionne

Le basculement TCP n’est pas un « nice-to-have ». C’est la sortie de secours du protocole quand UDP échoue ou que la troncation survient. Bloquer TCP/53 est un classique auto-sabotage en entreprise.

N’essayez pas de « préférer UDP » en bloquant TCP. Ce n’est pas une préférence ; c’est du sabotage. Autorisez TCP/53 au minimum entre les clients et les résolveurs récursifs, et entre résolveurs et upstreams si vous opérez ainsi.

Catégorie B : Corriger le chemin (la vraie cause racine)

Corriger la MTU sur les tunnels et overlays

Si le DNS transite par un tunnel, la MTU du tunnel doit tenir compte de l’overhead d’encapsulation. IPsec, WireGuard, OpenVPN, GRE, VXLAN — choisissez votre poison. L’overhead varie et peut s’empiler. L’approche correcte :

1. Mesurer la PMTU entre les points de terminaison.
2. Fixer les MTU des interfaces en conséquence.
3. Vérifier avec des ping DF et des tests DNS réels.

Arrêter de bloquer l’ICMP essentiel

PMTUD a besoin des messages ICMP. Vous n’avez pas besoin d’autoriser tous les types ICMP de partout, mais vous devez autoriser ceux qui font fonctionner le réseau. Pour IPv4, c’est « Fragmentation Needed ». Pour IPv6, « Packet Too Big » est non négociable.

Si votre politique de sécurité dit « pas d’ICMP », réécrivez-la. Si vous ne pouvez pas, soyez au moins honnête que vous échangez la correction opérationnelle contre une impression de sécurité.

Gérer les fragments de manière intentionnelle

Certaines infrastructures choisissent de supprimer les fragments comme posture de sécurité. Si vous faites cela, vous devez compenser : plafonner la taille EDNS, assurer le basculement TCP, et vérifier que les applications qui dépendent d’UDP ne dépasseront pas la MTU. Le DNS en est l’exemple type, mais pas la seule victime.

Catégorie C : Corriger le comportement des clients (utile, mais ne cachez pas le bug chemin)

Les piles clientes varient. Certains stub resolvers annoncent de grands tampons EDNS et sont agressifs sur les retries UDP. D’autres basculent rapidement en TCP. Certains sont… créatifs.

Dans des parcs managés, vous pouvez imposer des valeurs par défaut plus sûres :

• Utiliser un résolveur local de cache (systemd-resolved, Unbound, dnsmasq) avec une taille EDNS conservatrice.
• S’assurer que les clients VPN définissent une MTU raisonnable et ne comptent pas uniquement sur PMTUD, surtout si l’ICMP est filtré.
• Préférer DNS over TLS/HTTPS seulement si vous comprenez les implications MTU/PMTUD (c’est sur TCP, ce qui peut aider, mais cela ajoute aussi d’autres composants en mouvement).

Ce qu’il faut éviter (parce que ça « répare » la mauvaise chose)

• Éviter le changement de résolveur à la pelle comme correctif principal. Cela peut changer les tailles de réponse et le cache, masquant le problème.
• Éviter d’augmenter la taille EDNS UDP comme astuce de performance, sauf si vous contrôlez et testez tout le chemin.
• Éviter de « juste bloquer les fragments » sans stratégie DNS compensatoire (plafond EDNS + basculement TCP).
• Éviter de deviner les valeurs MTU. Mesurez la PMTU. Puis fixez la MTU.

Erreurs courantes : symptôme → cause racine → correction

1) « Seulement certains domaines ne se résolvent pas »

Symptôme : Une poignée de domaines expire ; la plupart fonctionnent. Le serveur DNS semble sain.

Cause racine : Grandes réponses UDP (DNSSEC/TXT/beaucoup d’enregistrements) fragmentées ; fragments supprimés ou ICMP bloqué.

Correction : Réduire la taille UDP EDNS (commencez à 1232), autoriser TCP/53, corriger MTU/ICMP sur tunnels/pare-feux.

2) « Le DNS fonctionne sur mon hotspot mais échoue sur le VPN corporate »

Symptôme : Même client, même résolveur, comportement différent selon le chemin réseau.

Cause racine : Le VPN réduit la MTU effective et/ou bloque l’ICMP ; la fragmentation échoue.

Correction : Configurer correctement la MTU du VPN, autoriser ICMP « frag needed/packet too big », plafonner la taille EDNS.

3) « TCP DNS marche, UDP DNS expire »

Symptôme : dig +tcp réussit de façon fiable ; dig normal échoue parfois.

Cause racine : Fragmentation UDP ou trou PMTUD.

Correction : Enquêter sur la PMTU ; autoriser les fragments ou réduire la taille UDP ; s’assurer que TCP/53 n’est pas bloqué.

4) « Nous avons activé MSS clamping, mais le DNS échoue toujours »

Symptôme : Quelqu’un montre --clamp-mss-to-pmtu et s’attend à des miracles.

Cause racine : Le MSS clamping n’affecte que TCP. Le DNS utilise principalement UDP.

Correction : Plafonner la taille UDP EDNS et corriger MTU/ICMP ; ne confondez pas les mitigations TCP avec le comportement UDP.

5) « Nous avons bloqué l’ICMP et maintenant des choses aléatoires se figent »

Symptôme : Les gros transferts se figent ; le DNS expire occasionnellement ; IPv6 se comporte pire.

Cause racine : PMTUD échoue ; des trous noirs apparaissent ; les points de terminaison continuent d’envoyer des paquets trop grands.

Correction : Autoriser les types ICMP essentiels ; valider avec ping DF et capture de paquets.

6) « Le DNS du cluster Kubernetes est instable après activation du chiffrement d’overlay »

Symptôme : Les pods subissent des timeouts DNS intermittents ; les nœuds peuvent être corrects.

Cause racine : La MTU de l’overlay réduite par l’encapsulation ; les pods supposent encore 1500 ; perte ou suppression de fragments sur les nœuds.

Correction : Configurer correctement la MTU du CNI, vérifier l’alignement MTU nœud/pod, plafonner la taille EDNS dans CoreDNS/upstream.

Listes de contrôle / plan étape par étape

Étape par étape : du symptôme à la cause racine (validé sur le terrain)

1. Choisissez deux noms : un qui échoue, un qui réussit. Préférez un nom lourd DNSSEC pour celui qui échoue.
2. Exécutez trois requêtes : UDP normal, TCP forcé, UDP avec +bufsize=1232.
3. Si TCP réussit et que la petite bufsize réussit : traitez cela comme MTU/fragmentation jusqu’à preuve du contraire.
4. Identifiez la route : ip route get <resolver_ip> et notez l’interface egress.
5. Vérifiez la MTU de l’interface : ip link show dev <if>.
6. Mesurez la PMTU vers le résolveur : ping DF (IPv4) ou ping dimensionné (IPv6). Enregistrez la plus grande taille fonctionnelle.
7. Capturez les paquets : sur l’interface egress pendant la reproduction. Cherchez retries, troncatures, réponses manquantes.
8. Vérifiez la politique de pare-feu : assurez-vous que l’ICMP essentiel passe ; vérifiez la gestion des fragments.
9. Mitigez rapidement : définissez max-udp-size du résolveur (ou équivalent) à 1232 ; assurez-vous que TCP/53 est autorisé.
10. Corrigez définitivement : corrigez la MTU tunnel/overlay ; évitez d’empiler des tunnels sans recalculer l’overhead.
11. Test de régression : canari depuis VPN + datacenter + cloud avec des requêtes grandes (DNSSEC).
12. Documentez : enregistrez les valeurs PMTU par chemin majeur et intégrez les tests dans la gestion des changements.

Checklist opérationnelle : « nous allons changer MTU/tunnels/pare-feux »

• Mesurer la PMTU avant et après le changement depuis au moins deux points.
• Tester DNS UDP avec EDNS à 1232 et à une valeur plus grande (pour exposer les problèmes de fragment tôt).
• Vérifier que TCP/53 est permis pour les clients vers les résolveurs récursifs.
• Vérifier que les types ICMP nécessaires pour PMTUD sont permis (surtout ICMPv6 Packet Too Big).
• Décider de la politique de fragments intentionnellement ; ne pas hériter des valeurs par défaut aveuglément.
• Mettre à jour la taille UDP max EDNS du résolveur si l’environnement inclut des tunnels/overlays que vous ne contrôlez pas entièrement.

FAQ

1) Pourquoi le DNS utilise-t-il UDP s’il est fragile ?

Latence et simplicité. UDP évite l’établissement de connexion et s’adapte bien aux petites requêtes. Le protocole inclut un basculement TCP pour les réponses plus grandes et des retries pour les pertes. La fragilité vient des middleboxes et d’une PMTUD cassée, pas du DNS en lui-même.

2) Si j’autorise TCP/53, dois-je quand même réparer la MTU ?

Oui. Le basculement TCP est un filet de sécurité, pas une cure. Si votre chemin est un trou noir PMTU, d’autres protocoles basés sur UDP (et même TCP dans certains cas) peuvent aussi souffrir. Réparez le réseau pour qu’il se comporte de manière prévisible.

3) Quelle taille EDNS UDP devrais-je choisir ?

Si vous opérez à travers VPNs/overlays/pare-feux d’entreprise, commencez par 1232 octets. Si vous contrôlez chaque saut et pouvez prouver que plus grand fonctionne, vous pouvez l’augmenter. Mais ne l’augmentez pas parce qu’un benchmark l’a aimé.

4) Comment distinguer fragmentation d’un « mauvais serveur DNS » ?

La preuve classique : dig +tcp fonctionne alors que UDP expire, et dig +bufsize=1232 fonctionne tandis que +bufsize=4096 échoue. Les captures de paquets montreront des réponses UDP manquantes ou des retries.

5) Pourquoi IPv6 est-il souvent pire pour ça ?

Les routeurs IPv6 ne fragmentent pas en transit. Les points de terminaison doivent gérer la fragmentation, et PMTUD repose sur ICMPv6 « Packet Too Big » atteignant l’émetteur. Si votre réseau bloque cet ICMPv6, vous construisez un trou noir IPv6 par conception.

6) DNSSEC peut-il déclencher ça même si je n’utilise pas DNSSEC ?

Oui. Les résolveurs récursifs peuvent valider DNSSEC et récupérer des enregistrements supplémentaires, et les clients peuvent demander DNSSEC (bit DO). Même sans demandes clients, le comportement en amont peut augmenter la taille des réponses pour certains noms.

7) Qu’en est-il de DNS over HTTPS (DoH) ou DNS over TLS (DoT) ?

Ils passent sur TCP (et souvent TLS), donc ils sont moins sensibles à la fragmentation UDP. Mais ils introduisent d’autres modes de panne (interception proxy, inspection TLS, limites de connexions, latence). N’utilisez pas DoH/DoT comme pansement pour une MTU cassée à moins d’accepter ces compromis.

8) Je vois des réponses « truncated » (bit TC). Est-ce la MTU ?

Pas nécessairement. La troncation signifie que le serveur a volontairement coupé la réponse UDP et demande au client de réessayer en TCP. Cela peut être causé par des limites de taille, une politique ou un comportement amont. Les problèmes de MTU ressemblent souvent à des expirations plutôt qu’à une troncation propre parce que la réponse est perdue en vol.

9) Une seule règle de pare-feu peut-elle vraiment casser uniquement les grosses réponses DNS ?

Absolument. Une règle qui supprime les fragments IP, ou bloque l’ICMP « frag needed », nuit sélectivement aux paquets dépassant la PMTU. Les petites réponses DNS continuent de fonctionner, d’où la longévité de ce problème en production.

Prochaines étapes à faire aujourd’hui

Les bugs de MTU ne se présentent pas clairement. Ils se déguisent en DNS instable, en expirations « aléatoires » et en plaintes utilisateur subjectives jusqu’à ce que vous réalisiez que les tailles de paquets sont objectives.

1. Prouvez-le : lancez dig normal vs +tcp vs +bufsize=1232 pour un nom qui échoue.
2. Mesurez-le : trouvez l’interface egress et la PMTU vers l’IP du résolveur en utilisant des ping DF.
3. Mitigez rapidement : plafonnez la taille UDP EDNS du résolveur à 1232 et assurez-vous que TCP/53 est autorisé.
4. Corrigez pour de bon : corrigez la MTU des tunnels/overlays et autorisez l’ICMP essentiel pour PMTUD ; décidez d’une politique fragments de manière intentionnelle.
5. Maintenez la correction : ajoutez un test canari depuis VPN + datacenter + cloud qui inclut au moins une grosse réponse DNSSEC.

Faites ces cinq choses et vous cesserez de traiter le DNS comme un service mystique pour commencer à le considérer comme ce qu’il est : des paquets, des tailles et des chemins. Le réseau trouvera toujours de nouvelles façons de vous décevoir, mais au moins vous saurez où regarder en premier.