DNSSEC : protéger votre trafic de la falsification

Chaque nom que votre machine a résolu aujourd’hui, elle l’a cru. Votre banque, vos mises à jour, votre serveur de messagerie. Une réponse est revenue du réseau et rien n’a vérifié si elle venait de l’organisation qui détient le nom ou de celui qui a placé un paquet en premier. Une réponse DNS ordinaire ne porte pas de signature, rien à vérifier, rien qui remarquerait que quelque chose cloche. C’était une conception raisonnable en 1983 et elle a cessé de l’être depuis longtemps.

DNSSEC est le correctif de très exactement ça, et il n’est ni nouveau ni coûteux. Le propriétaire de la zone signe ses enregistrements. La zone au-dessus publie une empreinte de sa clé et la signe, et ainsi de suite en remontant, jusqu’à l’unique clé racine que votre résolveur connaît de naissance. Tout ce qui vérifie la chaîne distingue une vraie réponse d’une falsifiée. C’est une norme depuis 2005, la racine est signée depuis juillet 2010, et les registres publient les enregistrements pour rien.^{1 2}

Le haut de l’arbre est terminé. J’ai compté la zone racine en direct pour ce billet et 1 351 domaines de premier niveau sur 1 438 sont signés, dont les 1 038 génériques. Puis ça tombe d’une falaise. Sur les 2 390 domaines gov.uk qui résolvent encore, trente-neuf sont signés, et neuf d’entre eux sont des conseils de paroisse. Le MI6 y est arrivé. Le Centre national de cybersécurité, non.

Voici ce que coûte réellement une réponse falsifiée et ce que la signature y change, compté sur la zone racine en direct le 27 septembre 2026 et en descendant à travers l’État, les banques, les distributions d’où vous installez et les autorités de certification. Une commande par domaine, la permission de personne, et chaque nom listé pour que vous discutiez mes choix plutôt que mon arithmétique. En dessous, la question à laquelle je voulais vraiment une réponse. Quarante-deux ans après que Mockapetris a mis le DNS par écrit, si presque personne ne signe, est-ce que personne n’a jamais compris ce que le DNS promettait ?

Ce qu’est DNSSEC, et à quoi il sert

En une phrase : DNSSEC pose une signature cryptographique sur les réponses DNS, pour qu’un résolveur puisse prouver qu’une réponse vient du propriétaire de la zone plutôt que de celui qui a répondu en premier.

Ce n’est ni du chiffrement, ni un pare-feu, ni un filtre. C’est une signature et une chaîne de clés qui remonte à une unique clé à laquelle votre résolveur fait déjà confiance. C’est toute l’idée.

Maintenant l’attaque, parce que le protocole ne prend son sens qu’une fois vu à quoi il sert.

Un résolveur qui demande un nom envoie une requête et attend. La réponse est appariée sur une poignée de champs : le nom demandé, le type, les adresses et ports source et destination, et un identifiant de transaction sur 16 bits. Quiconque produit un paquet correspondant à ces champs avant la vraie réponse gagne. Le résolveur met la falsification en cache et la sert à tous les clients, aussi longtemps que l’attaquant l’a décidé.

Le travail de Dan Kaminsky en 2008 est celui dont tout le monde se souvient à moitié.³ Ce qui compte n’est pas que l’empoisonnement de cache existait : il était connu depuis des années. C’est qu’il a trouvé un moyen de retenter la devinette indéfiniment. Demandez un nom qui n’existe pas : chaque échec ne coûte rien et laisse réessayer aussitôt, si bien que l’attaquant ne court plus une seule course contre un enregistrement mis en cache pour une journée. La réponse de l’industrie a été d’ajouter de l’aléatoire : des ports source aléatoires en plus de l’identifiant de transaction aléatoire, ce qui a fait passer la devinette de une sur 65 536 à environ une sur deux milliards.

C’est un plus grand nombre. Ce n’est pas une preuve.

Et l’atténuation s’érode depuis, parce que chacun de ces champs est une devinette rendue plus difficile et non un fait rendu vérifiable. Un NAT qui réécrit les ports de façon prévisible défait la randomisation. Les attaques par fragmentation contournent l’appariement entièrement. Les attaques hors chemin reviennent sans cesse sous de nouvelles formes, et chacune reçoit son propre correctif.

La signature clôt le débat. Une réponse signée se vérifie contre une clé que le résolveur peut chaîner jusqu’à la racine, ou pas, et aucune devinette n’obtiendra à un attaquant une signature valide.

Ce que gagne réellement celui qui remporte cette course

Soyons concrets, parce que « empoisonnement de cache » sonne abstrait et que les conséquences ne le sont pas.

La troisième ligne transforme un problème DNS en problème de certificat. La délivrance validée par domaine vous demande de publier un enregistrement puis va le consulter. Si un attaquant peut contrôler la réponse que l’autorité voit pendant cette consultation, elle lui délivre du vrai papier pour votre nom, et après ça le cadenas du navigateur est le sien. Tout ce qu’on a appris à un utilisateur à vérifier dira que le site va bien.

La quatrième ligne est la discrète. Une réponse falsifiée n’a besoin d’envoyer personne nulle part. Pointer un service de mise à jour vers un trou noir suffit, et rien dans la pile n’est fait pour crier sur des mises à jour jamais arrivées.

Ce que la signature y change

Le mécanisme est plus simple que sa réputation.

Toute zone signée détient une paire de clés. Le propriétaire de la zone signe chaque jeu d’enregistrements avec la moitié privée et publie un RRSIG à côté. La moitié publique va dans la zone en tant que DNSKEY. Jusqu’ici ça ne prouve rien, parce qu’un attaquant capable de falsifier un enregistrement A peut falsifier un DNSKEY pour aller avec.

Ce qui referme la boucle, c’est l’enregistrement DS, et le DS vit dans la zone parente, pas dans la vôtre. C’est une empreinte de votre clé, publiée et signée par la zone au-dessus de vous. Donc uk se porte garant de votre clé, la racine se porte garante de uk, et votre résolveur est né en sachant exactement une chose : la clé de la racine.²

Trois types d’enregistrements font le travail, et vous avez intérêt à savoir lequel est lequel, parce qu’un seul relève du travail de quelqu’un d’autre :

Vous pouvez publier les deux premiers tout l’après-midi, ça ne change rien. Tant que le parent ne publie pas de DS, vous êtes une zone signée que personne ne peut vérifier, ce qui revient à une zone non signée avec du travail en plus dedans.

$ dig +short @127.0.0.53 uk DS
43876 8 2 A107ED2AC1BD14D924173BC7E827A1...

$ dig +short @127.0.0.53 damiendye.uk DS
2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F

$ dig +short @127.0.0.53 bbc.co.uk DS
                                          (nothing)

C’est la zone de ce site au milieu. uk se porte garant d’elle, l’algorithme 13 est ECDSA P-256, et un résolveur validant peut donc prouver chaque réponse à son sujet jusqu’à la racine. bbc.co.uk ne renvoie rien, donc il ne peut pas.

Une seule commande vous dit si une zone est dans la chaîne de confiance. Si le parent ne publie pas de DS pour vous, vous n’êtes pas signé, quoi que vous ayez configuré par ailleurs, et un résolveur validant traitera chaque réponse sur votre domaine comme invérifiable.

Cet unique enregistrement est tout le test.

Ce qu’il ne fait pas

Ça vaut d’être dit franchement : le survendre est la moitié de la raison pour laquelle les gens s’en méfient.

Les gens butent sur cette dernière ligne. DNSSEC prouve que la réponse vient de celui qui contrôle la zone. Il n’a absolument aucun avis sur son honnêteté.

Il fait exactement une chose. Il rend la falsification d’une réponse arithmétiquement infaisable plutôt que seulement improbable.

Comment vérifier n’importe quelle zone, y compris celle de quelqu’un d’autre

C’est la partie qui rend le reste de ce billet possible, et elle tient en une commande.

Une zone est dans la chaîne de confiance si son parent publie un DS pour elle. C’est tout le test, et vous pouvez le passer sur n’importe qui, sans permission, depuis n’importe quelle machine :

dig +short damiendye.uk DS

Quelque chose en retour veut dire signé. Rien en retour veut dire non signé, quoi que la zone ait configuré par ailleurs.

Si vous voulez mieux qu’un oui ou non, trois autres valent d’être connues :

Deux pièges à connaître avant de croire vos propres résultats : les deux m’ont eu en mesurant ce billet.

dig +short … DS affichera une chaîne de CNAME si le nom est un alias, et un nom d’hôte contenant des chiffres ressemble assez à un enregistrement DS pour tromper un script naïf. Un vrai DS a quatre champs : étiquette de clé, algorithme, type d’empreinte, empreinte hexadécimale. Vérifiez cette forme, ou vous compterez comme signées des zones qui ne le sont pas.

Un DS sous un parent non signé ne veut rien dire. La chaîne doit atteindre la racine. update.microsoft.com a un DS, et microsoft.com n’en a pas, donc la branche est invérifiable quoi qu’il arrive. Vérifiez toujours le chemin entier, pas un seul niveau.

Tout ce que compte la suite de ce billet a été mesuré ainsi. Pas de scanner, pas de tableau de bord tiers, pas de classement d’éditeur. Demandez au parent s’il se porte garant de l’enfant, et exigez que la réponse s’analyse comme un DS.

La zone racine est terminée

C’est là que la sagesse reçue est tout simplement périmée. Les gens parlent encore de DNSSEC comme si l’infrastructure était le problème.

J’ai récupéré la zone racine en direct le 27 septembre 2026, numéro de série 2026092701, et compté les délégations contre les enregistrements DS.⁴

Chaque domaine générique de premier niveau est signé, sans exception. Tous les 1 038, parce que le contrat de registre de l’ICANN l’exige de tout ce qui est délégué sous le programme des nouveaux gTLD. Les 87 non signés sont presque entièrement des codes pays, et la liste est surtout faite de petits territoires et d’une poignée d’États :

ae ao aq ba bb bo bs cd cf cg ck cu cv cw do eg fk gb gf gh gm gp gq gt gu
hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz ne ni np nr om pa pf
pk pn ps qa sd sl sm so st sv sy sz td tg tj tk to va vg vi ye zw

gb y figure, curiosité plutôt que problème, puisque personne ne s’en sert. Le Vatican, la Corée du Nord, Cuba et la Syrie aussi. Et tk aussi, des années durant la plus grande source de domaines gratuits sur internet, et une source fiable d’abus avec ça.

Donc le haut de l’arbre est fait. Les registres ont fait la partie difficile, la coûteuse et celle qui demandait une coordination internationale, et ils l’ont terminée. Du coup, rien en dessous de ce point ne peut être mis sur le dos de l’infrastructure.

Et puis ça s’arrête net

Sous le TLD, le tableau s’inverse complètement.

J’ai mesuré de la même façon pour chaque ensemble ci-dessous : demander un DS au parent, n’accepter qu’un enregistrement qui s’analyse réellement comme tel. Tout ici a été compté le 27 septembre 2026.

Quatre-vingt-quatorze pour cent en haut. Un et demi pour cent en bas. La chaîne de confiance est une chaîne dont une extrémité est boulonnée au mur et l’autre traîne par terre.

Une note de méthode, parce qu’un chiffre aussi mauvais en mérite une. La ligne gov.uk est un recensement et non un échantillon : c’est chaque domaine de second niveau du registre publié par le gouvernement, filtré aux 2 390 qui résolvent encore. Les autres lignes sont des listes choisies d’organisations dont la falsification ferait réellement mal, ce qui est un jugement, et j’ai listé chacun de leurs noms ci-dessous pour que vous contestiez mes choix plutôt que mon arithmétique.

Le recensement de l’État : 39 sur 2 390

La liste officielle des domaines gov.uk publiée par le gouvernement compte 3 004 noms de second niveau. Là-dessus, 2 390 résolvent encore. Trente-neuf sont signés.

Avant le détail, une chose sur ce registre. La version la plus récente que gov.uk publie est datée du 1er octobre 2016.⁵ Dix ans, pour la liste faisant autorité des domaines sur lesquels l’État britannique répond. C’est un petit constat en soi et je le laisse là.

Maintenant regardez lesquels, ces trente-neuf.

Relisez cette première colonne. Le service de renseignement extérieur a signé sa zone. Le Centre national de cybersécurité, non.

Le GCHQ non plus, pourtant l’organisation dont le NCSC dépend. Le dispositif Cyber Essentials non plus, qui existe pour certifier que la sécurité des autres est adéquate. Je ne vais pas faire semblant que ce soit autre chose que remarquable.

Et neuf des trente-neuf sont des conseils de paroisse et de commune. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Des endroits avec un secrétaire, un site web à temps partiel et un budget qui ne couvrirait pas une journée de conseil à Whitehall. Ils y sont arrivés. Le fisc britannique, qui détient le dossier fiscal de chaque adulte du pays, non.

Je peux demander ce qui, dans le processus, permet ça. Pas qui : quoi. Parce que le NCSC publie des recommandations qui disent aux autres de déployer DNSSEC, et le service qui les écrit n’a pas fait ce qu’elles disent. Soit c’est important, auquel cas l’organisme qui le dit aurait dû le faire il y a des années, soit ça ne l’est pas, auquel cas les recommandations devraient dire ça à la place.

L’excuse qu’on proposera sera l’échelle et l’existant. Elle ne survit pas à la première colonne. somerset.gov.uk est une collectivité unitaire qui sert 580 000 personnes et elle est signée. birmingham.gov.uk est une collectivité unitaire qui en sert 1,1 million et elle ne l’est pas. Même pays, même registre, mêmes bureaux d’enregistrement, même argent disponible pour les mêmes prestataires. L’une l’a fait.

Le logiciel depuis lequel vous mettez à jour

C’est la partie qui devrait vous inquiéter plus que les banques, et c’est la partie que presque personne ne mesure.

Chaque machine que vous exploitez va chercher du code quelque part, selon un calendrier, et elle trouve ce quelque part en demandant au DNS.

Quatre-vingt-dix-neuf distributions et BSD, quatre-vingt-seize qui résolvent encore. Dix-neuf sont signées.

Dix-neuf sur quatre-vingt-seize. Et les noms de cette liste de non signés n’ont rien d’obscur : Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, toutes les déclinaisons d’Ubuntu, et kernel.org et gnu.org tous les deux.

Les distributions de sécurité et de vie privée sont celles que je m’attendais à voir différentes, et pour l’essentiel elles ne le sont pas. Tails et Whonix ont signé, ce qui colle. Kali, Parrot, Qubes, Trisquel et PureOS non, ce qui ne colle pas. OpenBSD s’est bâti vingt-cinq ans de réputation en traitant précisément cette classe de choses correctement et n’a pas signé openbsd.org, quand FreeBSD, NetBSD, HardenedBSD et MidnightBSD l’ont tous fait.

Les registres de paquets frôlent le sans-faute dans la mauvaise colonne : npm, crates.io, RubyGems, Packagist, Docker Hub et Quay sont tous non signés. pypi.org fait exception, et il faut lui rendre justice, parce que c’est aussi l’un des plus attaqués.

Microsoft, et le canal de mise à jour

Quatre zones Microsoft sur vingt-six sont signées, et elles sont toutes dans un même coin du patrimoine :

Les noms Outlook et Office sont signés et rien d’autre ne l’est, ce qui ressemble à la décision d’une équipe plutôt qu’à celle d’une entreprise. Notez ce qu’il y a dans la colonne de droite aux côtés du service de mise à jour : github.com et npmjs.com, deux des plus gros points de distribution de code sur internet, tous deux détenus par Microsoft, tous deux non signés.

$ dig +short @127.0.0.53 windowsupdate.com DS
                                          (nothing)
$ dig +short @127.0.0.53 microsoft.com DS
                                          (nothing)
$ dig +short @127.0.0.53 com DS
19718 13 2 8ACBB0CD28F41250A80A491389424...

com est signé, donc rien de technique ne fait obstacle. Microsoft pourrait publier un DS cet après-midi.

La réponse toute faite, c’est que le DNS n’est qu’une couche parmi d’autres. Les charges de mise à jour sont signées à la compilation, le client vérifie la signature, et le trafic passe sur TLS. Cassez le DNS et vous n’arriverez toujours pas à faire exécuter du code.

Cette réponse dépend entièrement de la solidité de la signature. Elle ne l’a pas été.

Soyons précis sur cette dernière ligne, parce que les gens l’exagèrent. La clé volée a signé des jetons d’identité, pas des binaires. Elle figure au tableau pour une autre raison : la garde du matériel de signature de Microsoft a échoué, sans être détectée pendant deux ans, via un vidage mémoire et un compte d’ingénieur compromis.

Les lignes au-dessus sont les échecs de signature de code, et elles sont pires. Deux fois la même année, le propre programme de certification matérielle de Microsoft a posé une signature Microsoft sur un rootkit fonctionnel et l’a expédié. Pas un certificat falsifié, pas une clé volée. Le processus légitime, signant un logiciel malveillant, exactement comme prévu.

Donc la défense qui vous autorise à traiter le DNS comme optionnel a été subvertie par falsification, détournement de processus et vol de clé, sur onze ans. Un attaquant détenant une signature que la machine acceptera n’est pas une expérience de pensée. Pour un acteur soutenu par un État, c’est un problème d’achat, pas de recherche.

Donnez à cet attaquant une réponse DNS falsifiée et le tableau est complet : du code signé qu’il contrôle, livré depuis un serveur que la machine croit être celui de Microsoft, sur une connexion que rien dans la pile ne remettra en question. C’est Flame, avec du meilleur matériel de clé.

DNSSEC est la seule couche de cette chaîne qui se moque de savoir quelle clé de signature détient l’attaquant. Il ne valide pas la charge utile, il valide où la machine a été envoyée, et il échoue indépendamment de tous les certificats et signatures en jeu. Ce qui est précisément ce qu’on attend d’une seconde couche, et précisément pourquoi elle ne devrait pas être celle qui est coupée.

Et il existe une attaque moins chère qui n’a besoin d’aucune clé. Falsifiez la réponse pour que le service de mise à jour ne résolve vers rien d’utile, et la machine ne se met simplement jamais à jour. Aucune erreur sur laquelle l’utilisateur agira, aucune alarme, juste un parc qui prend tranquillement du retard pendant que le tableau de bord dit que tout va bien. Si je voulais un parc prêt à être exploité dans six mois, je ne lui pousserais rien du tout. Je m’assurerais juste que rien n’arrive.

Les banques, au complet

Pas un échantillon cette fois. Quatre-vingt-dix-huit banques et sociétés de crédit immobilier britanniques, toutes résolvant le jour même, de la grande rue jusqu’aux sociétés à une seule agence et au nom victorien.

Treize sont signées.

Trente-huit sociétés de crédit immobilier. Pas une seule signée. Ce sont les établissements qui détiennent l’hypothèque d’un très grand nombre de maisons.

Deux motifs ressortent de cette colonne des signées. Lloyds Banking Group a signé trois de ses marques, lloydsbank.com, halifax.co.uk et bankofscotland.co.uk, et la Co-operative Bank a signé les deux siennes. Donc la décision se prend une fois, au niveau de l’organisation, puis s’applique. Aucun obstacle par domaine là-dedans.

Et Monzo a signé alors que Starling non. Deux banques challenger fondées à un an d’écart, sur des infrastructures modernes comparables, avec le même régulateur et les mêmes bureaux d’enregistrement disponibles. L’une l’a fait.

Le seul endroit où tout le monde le fait

Regardez les deux derniers noms de la colonne des signées : allica.bank et weatherbys.bank.

.bank est un domaine de premier niveau restreint exploité par fTLD Registry Services, et ses exigences de sécurité rendent DNSSEC obligatoire, aux côtés de TLS et de l’authentification du courrier, avec une re-vérification annuelle de chaque titulaire.⁹

Deux est un petit nombre, alors prenez-le comme une démonstration plutôt qu’une statistique. L’exigence reste la seule chose qui ait changé.

C’est la réponse à toutes les excuses plus bas dans ce billet, et elle arrive avant les excuses. Les mêmes banques, les mêmes prestataires, les mêmes budgets et les mêmes compétences produisent 13 % de conformité quand c’est optionnel et 100 % quand quelqu’un vérifie tous les ans. Rien de technique n’a bougé. Quelqu’un a simplement demandé.

Personne ne garde les gardiens

Une autorité de certification sur neuf.

Ce sont les organisations dont tout le métier est de prouver qu’une chose est bien ce qu’elle prétend être. Ce sont aussi les organisations qui valident le contrôle d’un domaine par le DNS, en vous demandant de publier un enregistrement puis en allant le consulter. La consultation qui décide si vous obtenez un certificat pour un domaine est, chez huit de ces neuf, une consultation que personne ne peut vérifier.

Rien d’hypothétique là-dedans. C’est la forme documentée : falsifiez la consultation de validation, faites-vous délivrer le certificat, et vous voilà détenteur de papier valide pour un nom qui ne vous appartient pas. DNSSEC est l’une des rares choses qui rendent ça nettement plus difficile, et ceux qu’il protégerait le plus ne l’ont pas déployé.

Et je vais vous le dire tout net. Si votre modèle d’affaires est l’identité, et que vous n’avez pas signé votre propre zone, l’argument de la difficulté ne vous est pas ouvert.

Et qui vérifie réellement ?

Signer n’est que la moitié du travail. Une zone signée ne protège personne si rien à l’autre bout ne vérifie la signature, et c’est là que le tableau empire au lieu de s’améliorer.

Deux endroits où la validation peut se produire, et ils ne sont pas équivalents :

La quasi-totalité de la validation dans le monde est du premier type. Google, Cloudflare et Quad9 valident tous, et couvrent entre eux un nombre énorme d’utilisateurs. Ça compte pour quelque chose. Mais ça veut dire que la propriété dont la plupart des gens disposent est mon résolveur dit que c’était bon.

Ce que chaque système d’exploitation sait faire

Deux de ces lignes méritent mieux qu’une ligne.

Apple a fait le travail discrètement. iOS 16 et macOS Ventura ont ajouté la validation DNSSEC côté client, dans les mots d’Apple elle-même à la WWDC 2022 : « iOS 16 and macOS Ventura now support client side DNSSEC validation », ce qui veut dire qu’iOS 16 et macOS Ventura prennent désormais en charge la validation DNSSEC côté client.¹⁰ C’est sur adhésion plutôt qu’automatique, et l’adhésion est à la bonne granularité, si bien qu’une application qui s’en soucie peut la demander par session ou par requête :

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true

Un vrai résolveur validant sur un téléphone, vérifiant les signatures sur l’appareil, et presque personne n’a remarqué sa sortie. Avant ça, mDNSResponder exposait kDNSServiceFlagsValidate à qui voulait bien utiliser l’API C.

Android ne le propose pas. Le résolveur DNS est un module actualisable depuis Android 10 et il a gagné DNS over TLS dans Android 9, donc la plateforme n’est pas restée immobile sur le DNS. Mais ni la documentation du résolveur AOSP ni l’API publique DnsResolver ne documentent la validation DNSSEC, et si des bibliothèques comme MiniDNS existent et se vantent d’amener « DNSSEC close to your application », c’est-à-dire DNSSEC au plus près de votre application, c’est que la plateforme ne l’amène pas. Je n’ai pas trouvé de source primaire affirmant platement que c’est impossible, donc je ne le formulerai pas plus fort que : pas proposé, et vous l’écririez vous-même.

Et il est jeté même là où il marche

Encore une chose, depuis cette machine, que je ne m’attendais pas à trouver.

Le résolveur amont ici valide et le dit. systemd-resolved, avec DNSSEC=no, jette ça avant qu’aucune application ne le voie :

# ---- before: stock Fedora, DNSSEC=no ----------------------------------
$ dig @192.0.2.53  damiendye.uk A | grep flags      # the upstream
;; flags: qr rd ra ad

$ dig @127.0.0.53  damiendye.uk A | grep flags      # the local stub
;; flags: qr rd ra

# ---- the fix: two lines in a drop-in ----------------------------------
$ sudo mkdir -p /etc/systemd/resolved.conf.d
$ printf '[Resolve]\nDNSSEC=allow-downgrade\n' \
    | sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf
$ sudo systemctl restart systemd-resolved

# ---- after: same query, same stub, nothing else changed ---------------
$ resolvectl status | grep -m1 DNSSEC=
                    DNSSEC=allow-downgrade/supported

$ dig @127.0.0.53  damiendye.uk A | grep flags
;; flags: qr rd ra ad

Même nom, même réponse, même seconde. Avant le drop-in, l’amont faisait le travail, posait le bit AD, et le démon local le jetait par terre, si bien que le défaut n’est pas simplement on ne valide pas ici, c’est on ne valide pas ici, et on ne transmettra pas non plus le verdict de quelqu’un qui l’a fait. Après, le bit est de retour et cette fois il est à nous plutôt qu’une affirmation de quelqu’un d’autre.

resolvectl met le verdict en mots, et il sépare les deux choses qui comptent :

$ resolvectl query damiendye.uk | tail -2
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no

$ resolvectl query ncsc.gov.uk | tail -2
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

Notez ce que la seconde n’est pas. Ce n’est pas une erreur. Une zone non signée revient non authentifiée plutôt que falsifiée, la résolution réussit, et rien nulle part ne se plaint. C’est tout le problème des 1,63 % reformulé en commande : activer la validation ne fait pas échouer les zones non signées, ça les rend visibles, et seulement pour qui va regarder.

Le plus grand OS client échoue à la vérification la plus élémentaire

Maintenant l’autre bout de l’échelle, et ce n’est pas serré.

Le client DNS de Windows est, selon la description de Microsoft elle-même, « security-aware » mais « non-validating », conscient de la sécurité mais non validant. Il n’effectue pas de validation DNSSEC. On ne peut pas l’y forcer. Ce qu’il fait à la place, c’est demander à son serveur DNS configuré de valider, puis chercher le bit AD dans la réponse.¹¹

Trois choses là-dessus, et aucune n’est petite :

• Il ne vérifie jamais une signature. La garantie la plus forte offerte au plus grand système d’exploitation client au monde est un unique bit posé par la machine qui a répondu, quelle qu’elle soit.
• Il ne fait même pas ça par défaut. Le client ne pose le bit DO et n’exige AD que pour les espaces de noms listés dans la Name Resolution Policy Table, un objet de stratégie de groupe que quelqu’un doit configurer délibérément. Sans règle dedans, la requête ne porte aucune attente DNSSEC du tout.
• Microsoft dit que le bit a besoin d’IPsec pour signifier quoi que ce soit. Leur documentation est explicite : parce que le client est non validant et s’appuie sur le serveur, « IPsec is used to establish this trust relationship », c’est-à-dire qu’IPsec sert à établir cette relation de confiance. Un bit AD arrivant sur un lien non authentifié est une affirmation de celui qui est arrivé le premier, ce qui est très exactement l’attaque que toute cette technologie existe pour arrêter.

Donc sur le bureau au plus grand parc installé, tel quel d’origine : pas de validation, pas d’exigence d’AD, et pas de canal authentifié vers le résolveur. La vérification la plus élémentaire n’est pas seulement coupée. Elle n’a jamais été implémentée.

Et la défense habituelle, selon laquelle les systèmes d’exploitation client ne font pas ce genre de chose, est morte en 2022. Apple a livré la validation côté appareil à chaque iPhone et chaque Mac l’année même où Microsoft ne l’a pas fait. La comparaison n’est plus bureau contre serveur, ni mobile contre fixe. C’est un éditeur qui l’a construite contre un autre qui ne l’a pas fait.

Ça compte davantage que le même écart sous Linux, à cause de qui est concerné. Un serveur Linux est d’ordinaire exploité par quelqu’un qui pourrait activer la validation cet après-midi et sait ce qu’est un enregistrement DS. Les machines qui ne peuvent pas valider du tout, à aucun réglage, sont celles posées sur les bureaux des organisations dont les zones ne sont pas signées dans les tableaux plus haut. systemd-resolved livre la capacité coupée, ce qui est une décision que vous pouvez inverser en une ligne.¹² Le Fisher-Price OS (Windows) livre sans la capacité.

Le service qui tient entièrement au DNS

Tout ce qui précède portait sur des noms de l’internet public. Le même trou existe à l’intérieur du bâtiment, et là-dedans il est porteur.

Active Directory n’a d’adresse fixe pour rien. Une machine jointe au domaine ne sait pas où vit son contrôleur de domaine, alors elle demande au DNS. Le processus de localisation interroge _ldap._tcp.dc._msdcs.<domain> pour les contrôleurs et _kerberos._tcp pour le KDC, et ce qui revient est ce contre quoi elle va s’authentifier.¹³

dig +short _ldap._tcp.dc._msdcs.corp.example SRV

Falsifiez cette réponse et la machine emmène son trafic d’authentification vers un hôte que vous avez choisi. Soyons clairs : Kerberos ne remettra pas de ticket à un imposteur qui ne détient pas les clés, donc ce n’est pas une prise de contrôle du domaine en soi. C’est une position sur le chemin, et c’est de ça que sont faites les attaques intéressantes. Forcer le repli sur NTLM et le relayer. S’asseoir au milieu d’un trafic censé aller vers un contrôleur. Ou pointer tout le parc vers rien du tout et regarder les ouvertures de session s’arrêter.

La stratégie de groupe, les scripts de connexion, les lecteurs réseau montés et toutes les relations d’approbation en aval de l’ouverture de session se trouvent de la même façon. C’est le jeu de noms de plus grande valeur que possèdent la plupart des organisations, et il est posé là, non signé.

Microsoft a construit la moitié serveur du correctif, et l’a bien construite. Une zone intégrée à l’AD peut être signée, la signature en ligne des zones dynamiques est arrivée dans Windows Server 2012, et comme la zone vit dans l’annuaire, les clés de signature privées se répliquent vers les autres serveurs DNS par la réplication AD elle-même.¹⁴ La partie véritablement pénible de DNSSEC, amener les clés aux machines qui en ont besoin, a été résolue ici il y a quatorze ans par ce par quoi la zone se répliquait déjà.

Puis ça s’arrête aux deux mêmes endroits que tout le reste :

Donc la zone interne qui décide quelle machine a le droit d’être votre contrôleur de domaine est, dans la plupart des parcs, tout aussi non signée que la publique. La différence, c’est qu’aucun étranger ne peut la compter, donc aucun tableau de ce billet ne fait honte à personne. Allez regarder la vôtre avant de présumer.

Le système d’exploitation devrait faire ça, et ce devrait être activé

Ce qui m’amène à la partie de tout ceci que je veux argumenter plutôt que compter.

Valider une réponse DNS est un travail de système d’exploitation. Ça relève de la même classe de tâches que tenir l’horloge à l’heure, porter un magasin de certificats de confiance et avoir une pile TLS, et pour les mêmes raisons : toutes les applications en ont besoin, presque aucune ne devrait l’écrire, et la vérification doit se faire une fois, à un endroit où elle peut être faite correctement. On a tranché ce débat pour les certificats il y a bien longtemps. Personne ne livre un client de messagerie avec son avis personnel sur les autorités racine.

Trois des quatre plateformes ci-dessus savent déjà le faire. Aucune ne le fait d’origine :

$ grep DNSSEC= /usr/lib/systemd/resolved.conf   # Fedora 44, systemd 259.9
#DNSSEC=no

C’est le défaut compilé, écrit en commentaire pour qu’un administrateur voie ce qu’il est. Le manuel de systemd lui-même a un autre avis, et recommande allow-downgrade en général et true partout où l’on peut compter sur l’amont.¹⁵ Le code est livré, l’ancre de confiance racine est livrée, et la documentation est livrée en recommandant de l’activer. Le défaut dit toujours non.

Cette colonne est tout le problème. Une exigence est un levier, et le décompte .bank plus haut montre ce qu’il produit. Un défaut est le même levier sans que personne n’ait rien à faire appliquer, parce qu’il décide du résultat pour tous ceux qui n’ouvrent jamais le fichier de configuration, et c’est à peu près tout le monde. L’optionnel nous a donné 1,63 % dans l’État et 13 % dans la banque. Les gens n’adhèrent pas à une sécurité qu’ils ne voient pas, et avoir raison sur la technique n’a jamais rien changé à ça.

L’objection honnête, c’est que valider par défaut casse des utilisateurs quand c’est le résolveur amont qui est cassé plutôt que la zone. C’est à ça que sert allow-downgrade, et c’est un vrai compromis plutôt qu’un cadeau, parce qu’un déclassement est quelque chose qu’un attaquant peut provoquer délibérément. Même ainsi, livrer allow-downgrade au lieu d’un no sec serait une amélioration énorme, et ça mettrait la casse là où elle doit être, sur quiconque fait encore tourner en 2026 un résolveur incapable de gérer DNSSEC.

Activer la validation, et quelle part revient à Fedora

La quasi-totalité de ce qui suit relève de systemd et non de Fedora, et tourne pareil sur Debian, Ubuntu ou Arch. Deux choses ici relèvent véritablement de la distribution :

L’amont choisit allow-downgrade dans meson_options.txt, qui est le réglage de compromis, pas le courageux.¹⁶ Fedora le compile à no puis livre un second fichier de configuration principal, et comme seul le premier fichier trouvé est utilisé, celui qui documente les défauts n’est plus celui qui fait foi.¹⁵ Alors n’éditez ni l’un ni l’autre. La copie de l’éditeur appartient au paquet et une mise à jour vous rendra votre modification ; la copie dans /etc est un fichier dont les autres lignes sont silencieusement absentes.

Utilisez plutôt un drop-in, ce que fait le bloc plus haut. Il outrepasse le fichier principal qui l’a emporté, il survit aux mises à jour de paquets, et il ne contient que ce que vous avez changé. Vérifiez le résultat avec systemd-analyze cat-config systemd/resolved.conf, qui affiche chaque fichier dans l’ordre d’application et tranche ce qui l’a réellement emporté.

Trois réglages, et le choix entre les deux derniers en est un vrai :

Commencez sur allow-downgrade, parce qu’un résolveur cassé ne vous coûte alors rien. Passez à yes une fois que resolvectl status a dit supported pendant quinze jours et que vous savez ce qu’est réellement votre amont. Le détail par distribution pour tout ce qui n’est pas Fedora est dans le billet sur resolved.¹²

Alors qu’est-ce qui arrête les gens, au juste

Bon. Les chiffres sont les chiffres. Pourquoi ?

Quatre raisons sont avancées, et elles ne sont pas toutes des bêtises.

La gestion des clés était un obstacle authentique et ne l’est plus vraiment. Signer voulait dire autrefois mener ses propres cérémonies de clés, penser à re-signer avant l’expiration des signatures, et faire tourner les clés à la main sur un calendrier à suivre soi-même. Ce travail est aujourd’hui fait par le fournisseur DNS sur la plupart des plateformes gérées, et signer est une case à cocher. Ce n’est pas rien, mais ce n’est plus un projet.

Le mode de défaillance est l’objection honnête, et c’est la seule des quatre pour laquelle j’ai une vraie sympathie. Ratez DNSSEC et votre domaine ne se dégrade pas, il disparaît. Chaque résolveur validant refuse vos enregistrements, comme il est censé le faire, et les gens qui ne peuvent pas vous joindre ne peuvent pas apprendre pourquoi de votre bouche, parce que le leur dire exige le DNS.

Trois choses le rendent pire qu’une panne ordinaire :

• Ça échoue sur une horloge, pas sur un changement. Les signatures portent une expiration. Une zone que personne n’a touchée depuis mardi peut avoir disparu dimanche parce qu’une tâche de re-signature s’est tranquillement arrêtée.
• Ça échoue pour certains et pas pour d’autres. Seuls les résolveurs validants vous rejettent. Votre propre supervision, si elle ne valide pas, rapportera un site en parfaite santé pendant qu’une fraction croissante d’internet ne peut pas vous atteindre.
• Ça échoue à la couche dont vous vous servez pour réparer. L’accès distant, votre page d’état et votre propre messagerie peuvent tous être sous le nom qui vient de disparaître.

Cette peur est rationnelle, elle a mis de gros opérateurs hors d’antenne, et tout plaidoyer honnête pour DNSSEC doit s’asseoir avec elle plutôt que la balayer.

Mais remarquez sa forme : c’est la peur d’une discipline opérationnelle que vous n’avez pas aujourd’hui, pas la peur de la technologie.

Et remarquez qui paie dans chaque colonne. Une zone non signée qui se fait falsifier coûte à vos clients, en silence, et personne ne déclare jamais d’incident parce que personne ne l’apprend jamais. Une zone signée qui expire vous coûte à vous, immédiatement, en public, avec votre nom sur le post-mortem. Les deux sont des échecs. Un seul apparaît dans les objectifs de quelqu’un.

Les certificats ont eu le même problème et l’ont résolu deux fois plutôt qu’une : l’échec a été rendu visible, puis il a été automatisé. Un avertissement de navigateur a fait d’un certificat expiré le problème de tout le monde, la supervision a suivi, puis Let’s Encrypt a fait du renouvellement une chose qu’une tâche cron fait à trois heures du matin. Rien de tout ça n’a rendu les certificats plus faciles dans l’absolu. Ça a rendu plus difficile de les oublier.

Le support des fournisseurs mérite dix minutes de vérification plutôt qu’une supposition. Certains bureaux d’enregistrement font encore de la publication d’un DS un ticket de support. Beaucoup non.

Et la dernière est la vraie réponse, ce que le registre .bank a déjà prouvé plus haut dans ce billet. Il n’y a pas de cadenas de navigateur pour DNSSEC. Aucun client n’a jamais choisi une banque parce que sa zone était signée, aucun auditeur ne vous recale là-dessus, et aucune réglementation générale au Royaume-Uni ne l’exige. Le bénéfice est entièrement invisible quand ça marche, le coût d’une erreur est une panne avec votre nom dessus, et la personne qui porte cette panne n’est pas celle qui en aurait eu le mérite.

Mettez une exigence et un contrôle annuel devant les mêmes établissements et la conformité passe de 13 % à la totalité. Rien de la technologie n’a changé entre ces deux chiffres. Rien des budgets, des prestataires ou des compétences non plus. La seule variable était de savoir si quelqu’un allait regarder.

Vu ces incitations, ce qui surprend n’est pas que 1,63 % des domaines de l’État soient signés. C’est que trente-neuf le soient.

L’activer sans se retirer d’antenne

Tout le risque tient à un seul endroit, alors mettez l’effort là. L’expiration de signature est l’échec qui arrive sans que personne n’ait rien touché, alors mettez une alarme dessus :

dig +dnssec damiendye.uk SOA | awk '/RRSIG/ {print "sig expires", $9}'

Traitez-la comme un certificat. Surveillez la date, alarmez bien avant, et rendez le renouvellement automatique pour que l’alarme soit un filet de sécurité et non un mode de fonctionnement.

Puis activez-le à une heure calme, sur autre chose que votre domaine principal, et laissez passer quinze jours avant de faire celui qui compte. Si votre DNS est sur une plateforme gérée, la signature elle-même est très probablement une case à cocher, et la seule étape véritablement manuelle est le dépôt du DS chez votre bureau d’enregistrement.

Est-ce le même échec qu’IPv6 ?

C’est la comparaison évidente, alors j’ai mesuré les deux normes dans les mêmes populations le même jour. Mêmes organisations, mêmes gens, deux décisions.

Dix-neuf fois plus avancé dans l’État, sur les mêmes domaines.

Maintenant asseyez-vous avec ce qui est quoi. IPv6 touche chaque routeur, chaque hôte et chaque application, et veut une double pile qui tourne en parallèle pendant des années. Signer DNSSEC est une case à cocher et un enregistrement collé chez votre bureau d’enregistrement.

Le travail de loin le plus dur bat le facile partout où j’ai regardé. Ce qui écarte l’explication confortable selon laquelle c’est juste comme ça que vont les normes d’infrastructure, lentement et à contrecœur. DNSSEC n’avance pas lentement. Il n’avance pas.

Une différence appartient à DNSSEC seul. Déployez IPv6 et vous récupérez quelque chose : de la joignabilité, pas de NAT d’opérateur à acheter. Signez votre zone et vous, personnellement, ne récupérez rien. La protection atterrit sur vos utilisateurs, et seulement sur ceux qui sont derrière un résolveur validant. Vous assumez un risque de panne permanent au nom de gens que vous ne rencontrerez jamais, et c’est plus difficile à présenter à un conseil d’administration que n’importe quel obstacle technique de ce billet.

J’ai écrit la moitié IPv6 de cet argument ailleurs et je ne la répéterai pas ici.¹⁷

Est-ce qu’on ne comprend toujours pas le DNS ?

Quarante-deux ans depuis que Mockapetris l’a mis par écrit en novembre 1983.¹⁸ Seize depuis que la racine est signée.

Je pense que le problème de compréhension est réel, et je pense qu’il est plus précis que « les gens ne savent pas comment marche le DNS ». Beaucoup d’ingénieurs compétents savent très bien décrire la récursion, la délégation et le cache. Ce qui manque est un cran plus loin, et c’est le cran qui compte.

Presque personne n’a intériorisé que le DNS est un système d’autorisation.

On le traite comme de la plomberie. Une table de correspondance. Une chose qui transforme des noms en numéros et qui appartient à celui qui exploite le réseau, rangée mentalement à côté de DHCP. Et ce cadrage est faux d’une manière qui décide tranquillement de beaucoup, parce qu’en pratique la réponse DNS est ce qui décide vers quelle machine va votre trafic, de quel serveur viennent vos mises à jour, et quel hôte une autorité de certification croit être le vôtre. Celui qui contrôle la réponse contrôle les trois.

On voit le malentendu dans le motif de qui a signé. Pas le budget, et pas la compétence non plus, et une fois qu’on l’aligne il est difficile de le lire autrement que comme un motif de ce que chacun pense que le DNS est :

Les gens les plus proches du DNS en tant que chose en soi ont tous signé. Ceux qui le consomment comme un service ne l’ont pas fait, à peu près sans exception, si bien dotés et si soucieux de sécurité qu’ils se croient. Le GCHQ n’a pas signé. Huit autorités de certification sur neuf n’ont pas signé. Ce ne sont pas des organisations à court de gens intelligents ni de modèles de menace.

C’est aussi pourquoi la réponse de 2008 à Kaminsky a été de rendre la devinette plus difficile plutôt que de finir de déployer la chose qui rend la devinette sans objet. Rendre la devinette plus difficile est une réparation de plomberie, et la plomberie est la rubrique sous laquelle l’industrie avait rangé le DNS.

Une génération a appris le DNS comme un annuaire, et n’a jamais révisé la fiche quand il est tranquillement devenu la chose qui décide à qui vous parlez.

On l’a construit, puis on l’a laissé là

Les registres, les opérateurs et les gens des normes ont fait la partie difficile. Ils l’ont écrite, l’ont débattue à l’IETF pendant une décennie, ont signé la racine lors d’une cérémonie avec témoins, et ont obtenu 100 % des domaines génériques de premier niveau signés. C’est une véritable pièce d’ingénierie collective et elle est terminée.

Et ensuite nous autres n’avons pas fait notre part, parce que notre part est ennuyeuse, invisible, porte tout l’inconvénient personnel et aucun des lauriers, et que personne ne vérifie.

C’est la forme de toute norme que personne ne fait appliquer : le coût est porté seul, et le bénéfice n’apparaît qu’une fois qu’assez d’autres l’ont porté aussi. Donc les registres l’ont porté, et ceux qui publient les recommandations sur le fait de le porter ne l’ont pas fait.

Sauf que le travail ici était plus petit que presque tous les autres. La chaîne était déjà bâtie, et payée, par quelqu’un d’autre. Il ne restait qu’un enregistrement.

Et si c’est ça, la partie qu’on voit

Une dernière pensée, et je veux être clair : c’est une inférence et non une mesure, parce que tout le reste de ce billet est compté et pas ça.

DNSSEC est à peu près le contrôle de sécurité le plus facile à évaluer qui soit. Il ne coûte rien, le travail tient en un après-midi, la norme est finie depuis vingt ans, et n’importe qui peut le vérifier de l’extérieur en une commande sans demander la permission. Pas d’audit, pas de questionnaire, pas d’accord de confidentialité. Un dig.

Alors qu’est-ce que 1,6 % vous dit sur les contrôles que vous ne pouvez pas voir d’ici ?

Chaque ligne sous la première est plus difficile que signer une zone, coûte de l’argent réel, demande que quelqu’un la porte, et partage la propriété exacte qui a coulé DNSSEC : invisible quand ça marche, et personne de l’extérieur pour vérifier. La seule chose qui sépare la première ligne des autres, c’est que vous pouvez la vérifier, gratuitement, sur n’importe qui, tout de suite.

Si une organisation n’a pas fait la chose gratuite qui prend un après-midi et qu’un inconnu peut vérifier en une commande, je ne suis pas enclin à supposer qu’elle a fait les choses coûteuses qui demandent un programme et ne peuvent être vérifiées que par quelqu’un qu’elle laisse entrer.

Alors le geste évident est de tester ça contre l’historique des compromissions, et j’ai essayé. Sur 23 organisations britanniques ayant connu des incidents majeurs documentés, 22 ne sont pas signées.

Ce chiffre ne prouve rien et je ne vais pas faire semblant du contraire. À un taux de base de 1,6 %, une organisation signée dans une liste de 23 est très exactement ce que le hasard prédit. Pire, les signées, c’est neuf conseils de paroisse et trois parcs nationaux, quand les non signées, c’est tous les grands ministères et toutes les grandes villes : la taille détermine donc à la fois qui se fait attaquer et qui finit dans les journaux. Toute comparaison de taux de compromission entre les deux groupes mesurerait la taille d’une organisation, pas le fait qu’elle ait signé.

Donc non, je ne peux pas vous montrer que les organisations signées se font moins compromettre. Personne ne le peut, pas avec des données accessibles, et quiconque vous dit le contraire se raconte des histoires.

Les organisations qui ont été touchées ont écrit ce qui avait lâché

Vous n’avez pas besoin de mon inférence, parce qu’elles l’ont publiée elles-mêmes, et ce qui a lâché, c’est la liste ci-dessus.

La British Library est le meilleur des cas, parce qu’ils l’ont écrit volontairement et en détail après leur attaque par rançongiciel de 2023. Leur propre revue nomme les causes : une entrée très probablement par un compte tiers sur un serveur Terminal Services sans authentification multifacteur, puis une infrastructure ancienne et une segmentation réseau limitée qui ont laissé les attaquants circuler dans tout le patrimoine, la complexité croissante des accès tiers ayant été signalée comme un risque en interne en 2022 et toujours présente un an plus tard.¹⁹ L’ICO est arrivée aux mêmes conclusions.²⁰

Trois lignes du tableau ci-dessus, donc, confirmées de l’intérieur par l’organisation elle-même plutôt qu’inférées par moi depuis l’extérieur.

Et avant que quiconque s’en serve comme d’un bâton, la British Library mérite l’inverse, et je vais être catégorique sur le pourquoi.

Ils ont été ouverts. Presque personne d’autre ne l’est. Rien ne les obligeait à en écrire un traître mot. Le manuel standard après un incident consiste à en dire le moins possible dans la limite de la loi, à le faire passer par une équipe de communication, à refuser de confirmer quoi que ce soit, et à attendre que le cycle médiatique passe à autre chose. C’est ce qu’ont fait la plupart des organisations des colonnes non signées ci-dessus quand leur tour est venu, et c’est pourquoi écrire cette section dépend de la décision d’un seul établissement de se comporter autrement.

Au lieu de ça, ils ont publié une revue de dix-huit pages nommant leurs propres échecs, en public, pour que d’autres établissements puissent en tirer des leçons. C’est le comportement qu’on voudrait de chaque organisation de ce billet et qu’on obtient de presque aucune. Si je peux vous montrer ce qui lâche réellement à l’intérieur d’une organisation compromise, c’est parce que la British Library a choisi de vous le dire.

Et il y a une seconde raison pour laquelle les autres se taisent, pire qu’une stratégie de communication. Certaines d’entre elles ne sont plus là.

KNP Logistics déplaçait du fret sous le nom de Knights of Old depuis 1865. En juin 2023, le groupe Akira est entré, a chiffré l’entreprise et a demandé environ cinq millions de livres. En septembre, le groupe était insolvable et 730 personnes se retrouvaient sans emploi.²¹ Cent cinquante-huit ans, partis en quatorze semaines, et personne là-bas n’écrit de retour d’expérience pour vous.

Alors quand les colonnes non signées ci-dessus ont l’air calmes, ce calme est fait de trois choses différentes : des organisations qui n’ont pas encore été touchées, des organisations qui l’ont été et en ont dit le moins possible dans la limite de la loi, et des organisations qui l’ont été et ne sont plus là. Seul le premier groupe a encore le temps d’agir.

Ce qui fait de la suite le test honnête de mon propre argument plutôt qu’un coup bas. J’ai vérifié leur zone :

$ dig +short bl.uk DS
                                          (nothing)
$ dig +short bl.uk DNSKEY
                                          (nothing)

bl.uk n’est pas signé. britishlibrary.co.uk non plus. Deux ans après une attaque par rançongiciel qui a fermé l’établissement pendant des mois, après une revue publique, après une conclusion de l’ICO, et après le tour d’attention sécurité le plus approfondi qu’une organisation reçoive jamais, le contrôle gratuit qui prend un après-midi et qu’un inconnu peut vérifier en une commande n’est toujours pas fait.

Je n’y lis pas de la négligence, et je ne pense pas que ça les rende pires que les organisations non signées qui n’ont rien publié. J’y lis la preuve la plus forte de ce billet sur ce dont il a été question tout du long. Si DNSSEC ne se fait pas ici, dans une organisation qui est passée par le feu, a écrit les leçons et a eu le régulateur qui repasse derrière, alors ce n’est pas par négligence qu’il est sauté. Il est sauté parce que rien ni personne ne le met jamais sur la liste.

C’est la version honnête de l’argument. Pas les zones non signées causent des compromissions, qui est indémontrable et probablement faux. Plutôt : les contrôles que personne de l’extérieur ne peut voir sont, sur la foi des publications des organisations qui y sont passées, tout aussi négligés que le seul contrôle que tout le monde peut voir de l’extérieur. DNSSEC n’est pas la cause. C’est l’échantillon qu’on vous autorise à prélever.

C’est pourquoi la mesure vaut la peine d’être prise. Pas parce qu’une zone non signée est la fin du monde en soi, mais parce que c’est l’une des très rares propriétés de sécurité qu’un étranger peut vérifier honnêtement, gratuitement, sur n’importe qui, sans qu’on le laisse entrer. Traitez-la comme un détecteur de fumée plutôt que comme un verdict, puis allez poser les questions plus difficiles à qui le déclenche.

La seule partie que vous contrôlez

Ce qui laisse la seule partie que chacun de nous contrôle réellement. Votre propre zone. Pas celle du NCSC, pas celle de Microsoft, pas celle de votre banque.

Allez demander à votre parent s’il se porte garant de vous :

dig +short yourdomain.uk DS

Si ça revient vide, vous n’êtes pas signé, et sur la plupart des DNS gérés en 2026 le correctif est une case à cocher et un enregistrement DS chez votre bureau d’enregistrement. Activez-le, puis surveillez l’expiration comme vous surveillez déjà vos certificats, parce que c’est la discipline dont tout ça a réellement besoin.

C’est tout le travail. Un enregistrement, et une date dans votre supervision.

Alors s’il vous plaît, faites au moins celui-là. Pas parce qu’un régulateur arrive, parce que pour la plupart d’entre vous il n’arrive pas, et pas parce que quelqu’un vous en remerciera, parce que personne ne le fera. Faites-le parce que personne ne vient, et qu’une norme qu’on tient quand personne ne vérifie est la seule qui ait jamais valu quelque chose.

Trente-neuf secrétaires de paroisse et un barbouze y sont arrivés. Alors ressaisissez-vous et faites-le.