Première rédaction de cet article le 6 novembre 2025
Ce matin, si vous avez testé, un de mes domaines personnels,
bortzmeyer.fr, présentait des problèmes
DNSSEC. Que s'est-il passé ? Était-ce de ma
faute ? Va t-on tous mourir ?
Le signalement a été fait par un collègue (via
Matrix puisqu'il était en télétravail et pas
moi) : son résolveur DNS
répondait SERVFAIL (SERver FAILure) pour
l'enregistrement de type TXT de
bortzmeyer.fr. C'est le type utilisé pour
SPF donc c'est
ennuyeux (le domaine principal, bortzmeyer.org,
avait le même problème) :
% dig bortzmeyer.fr TXT ; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> bortzmeyer.fr TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28082 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; EDE: 6 (DNSSEC Bogus) ;; QUESTION SECTION: ;bortzmeyer.fr. IN TXT ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Thu Nov 06 08:17:48 UTC 2025 ;; MSG SIZE rcvd: 48
On voit que c'est un problème DNSSEC puisque l'EDE (Extended DNS Error, cf. RFC 8914) nous le dit (« 6 (DNSSEC Bogus) ») et aussi parce que, si on désactive la validation (cd = Checking Disabled), ça marche :
% dig +cd bortzmeyer.fr TXT ; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> +cd bortzmeyer.fr TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; EDE: 6 (DNSSEC Bogus) ;; QUESTION SECTION: ;bortzmeyer.fr. IN TXT ;; ANSWER SECTION: bortzmeyer.fr. 45 IN TXT "DNS is innocent" bortzmeyer.fr. 45 IN TXT "v=spf1 mx -all" bortzmeyer.fr. 45 IN TXT "BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax" bortzmeyer.fr. 45 IN RRSIG TXT 13 2 86400 ( 20251113173453 20251030142433 32088 bortzmeyer.fr. J1arZUBP+G5nc54zetyD45rqDyURJeZyFjRRkixQrPok BPxNkyt1RHzdH78a0rM93Zzu0q+N/zzxMQScl0KVHw== ) bortzmeyer.fr. 45 IN RRSIG TXT 13 2 86400 ( 20251113215344 20251030142433 32088 bortzmeyer.fr. bWAlKMSQPDALOeEmwwfh47qGjloBK3YRH3rGydVJBis4 lFIsIsE09bkqviBiGyjNqpS/loFaiMS4FRIeh06jwg== ) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Thu Nov 06 08:17:51 UTC 2025 ;; MSG SIZE rcvd: 372
Le résultat de dig donne aussi une première explication : il y a deux signatures DNSSEC, faites avec la même clé, la 32088. Ce n'est pas normal. (Les enregistrements des autres types, comme SOA ou MX, n'avaient pas de problème.)
Le test avec Zonemaster montrait que les enregistrements NSEC3, qui servent à prouver la non-existence d'un nom ou d'un type d'enregistrement, étaient également cassés. Le test avec DNSviz donne une idée du problème : « RRSIG bortzmeyer.fr/TXT alg 13, id 32088: The cryptographic signature of the RRSIG RR does not properly validate. ».
Un test avec les sondes RIPE Atlas montre que le problème n'est pas local. Toutes les sondes utilisant un résolveur DNS validant voient le problème (les seules où ça marche sont celles qui ne valident pas) :
% blaeu-resolve --displayvalidation --requested 200 --type TXT bortzmeyer.fr [ERROR: SERVFAIL] : 147 occurrences ["btc" "1htnj6zfuc9yu9u2qawb4tgdgwpqasqgax" "dns is innocent" "v=spf1 mx -all"] : 31 occurrences Test #136108974 done at 2025-11-06T08:24:58Z
L'explication du problème a été trouvée en examinant les fichiers de zone, avant et après la signature. Dans le fichier non signé, celui que j'édite, on trouve cette ligne :
; Type WALLET, enregistré à l'IANA, mais pas encore connu des logiciels @ IN TYPE262 \# 39 03425443 223148744E4A365A465563397975397532714177423474476447775051617351476178
Mais dans le fichier signé par OpenDNSSEC, on trouve :
bortzmeyer.fr. 86400 IN TXT "BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax"
Le type 262 (WALLET) est devenu un type 16 (TXT). Ce n'est pas du tout normal, c'est clairement une bogue du signeur d'OpenDNSSEC. Creusons un peu. Le type WALLET est un type d'enregistrement, et ce type est officiellement enregistré à l'IANA. Cela fait plus d'un an qu'il est annoncé dans mes domaines personnels. Comme, à l'époque, il n'était pas connu des logiciels, j'ai utilisé la syntaxe des types inconnus, syntaxe normalisée depuis plus de vingt ans, dans le RFC 3597. La traduction en TXT n'a pas de sens, car, si l'enregistrement de type WALLET a bien des données structurées comme le TXT, c'est un type différent. Le signeur a apparemment calculé une signature pour les TXT, une pour le WALLET, puis traduit le WALLET en TXT, cassant tout (les signatures s'appliquent à un ensemble d'enregistrements, pas à un enregistrement unique, donc deux TXT n'ont qu'une signature) :
bortzmeyer.fr. 86400 IN TXT "v=spf1 mx -all" bortzmeyer.fr. 86400 IN TXT "DNS is innocent" bortzmeyer.fr. 86400 IN RRSIG TXT 13 2 86400 20251113215344 20251030142433 32088 bortzmeyer.fr. bWAlKMSQPDALOeEmwwfh47qGjloBK3YRH 3rGydVJBis4lFIsIsE09bkqviBiGyjNqpS/loFaiMS4FRIeh06jwg== bortzmeyer.fr. 86400 IN TXT "BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax" bortzmeyer.fr. 86400 IN RRSIG TXT 13 2 86400 20251113173453 20251030142433 32088 bortzmeyer.fr. J1arZUBP+G5nc54zetyD45rqDyURJeZyF jRRkixQrPokBPxNkyt1RHzdH78a0rM93Zzu0q+N/zzxMQScl0KVHw==
C'est ce fichier erroné (l'erreur cassait aussi les chaines NSEC3) qui a été produit et distribué aux serveurs faisant autorité, provoquant les problèmes détectés. La rupture des NSEC3 se voyait lorsqu'on demandait un nom non existant (ici avec les sondes Atlas) :
% blaeu-resolve --displayvalidation --requested 200 --type TXT doesnotexist.bortzmeyer.fr [ERROR: SERVFAIL] : 144 occurrences [ERROR: NXDOMAIN] : 28 occurrences Test #136110101 done at 2025-11-06T08:35:32Z
Ce problème a été signalé sur la liste de diffusion d'OpenDNSSEC. Notez que ce logiciel est en fin de vie (son successeur, Cascade, est actuellement en version alpha) donc je ne sais pas encore si la bogue sera traitée.
Pour réparer le problème, j'ai retiré l'enregistrement WALLET et tout remarche. Ça va mieux (ici, certains résolveurs avaient encore les données erronnées dans leur mémoire) :
% blaeu-resolve --displayvalidation --requested 200 --type TXT bortzmeyer.fr ["dns is innocent" "v=spf1 mx -all"] : 65 occurrences [ (Authentic Data flag) "dns is innocent" "v=spf1 mx -all"] : 128 occurrences [ERROR: SERVFAIL] : 4 occurrences [] : 1 occurrences Test #136145680 done at 2025-11-06T14:29:36Z
Le plus curieux est que cette bogue se soit déclenchée en l'absence de tout changement. Douze jours auparavant, il y avait le même fichier de zone (l'enregistrement WALLET datait de plus d'un an) et tout allait bien.
Quelle(s) leçon(s) à en tirer ? Que l'informatique, c'est compliqué, que les logiciels ont des bogues et que, si on est très intolérant aux problèmes, il ne faut pas chercher les cas exotiques. Et que le bon fonctionnement de l'Internet ne repose pas sur des règles bureaucratiques et des processus mais sur la réactivité, à la fois pour signaler les problèmes (merci à Marc van der Wal pour cela), et pour les traiter lorsqu'ils sont signalés.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)