Dnssec

Le plus dur de DNSSEC était fini il y a des années. Compté sur la zone racine en direct le 27 septembre 2026, 1 351 domaines de premier niveau sur 1 438 portent un enregistrement DS, et les 1 038 gTLD sont signés sans exception. Puis ça s’arrête net. Un recensement de tous les domaines gov.uk du registre officiel du gouvernement en trouve 39 signés sur les 2 390 qui résolvent encore, dont neuf conseils de paroisse, tandis que le fisc, le NHS, le GCHQ et le Centre national de cybersécurité n’en font pas partie. Une autorité de certification sur neuf a signé. Une distribution Linux sur trois aussi. windowsupdate.com n’a aucun DS. Voici ce que coûte réellement une réponse falsifiée, ce que la signature y change, pourquoi les excuses habituelles ne survivent pas au contact des chiffres, et si, quarante-deux ans après Mockapetris, le vrai problème n’est pas que presque personne ne comprend ce que le DNS promet.

systemd-resolved tourne en ce moment même sur la plupart des bureaux Linux, met chaque recherche en cache et n’en valide aucune. Ce billet suit le chemin de résolution depuis nss-resolve jusqu’aux deux stubs, mesure ce que vaut le cache sur une vraie machine, active DNSSEC et montre les trois verdicts qu’il peut rendre, puis explique pourquoi la validation est coupée par défaut alors que l’amont la livre activée. Ensuite un recensement du peu de web réellement signé, DNS over TLS et son piège du mode strict contre l’opportuniste, et le support de DNS over HTTPS demandé depuis 2018 et toujours inexistant. Pour finir : ce que livrent Fedora, Ubuntu, Debian et la famille RHEL, comment le câbler dans chacune, et pourquoi les fonctionnalités que votre distribution a désactivées sont des défauts et non du code manquant.

La racine de l’internet est un fichier texte de 1,5 Mo qu’une seule entreprise américaine édite et signe. Qui contrôle vraiment le DNS, ce que la transition IANA de 2016 a changé et n’a pas changé, et le dossier documenté de la façon dont l’ICANN a usé de ce contrôle.

Chaque machine jointe au domaine trouve son contrôleur de domaine en demandant à DNS un enregistrement SRV, donc les locators _msdcs sont les enregistrements les plus critiques pour la sécurité que vous possédiez. Voici comment les publier et les signer correctement depuis un DC Samba4 : BIND avec dlz_bind9 qui lit l’annuaire, signature en ligne, un primaire caché que les clients n’atteignent jamais, et les mises à jour dynamiques des clients tenues hors de la zone qui porte les locators. Puis comment forcer les clients Windows et Linux à vérifier réellement les signatures, parce qu’une zone signée que personne ne valide se comporte exactement comme une zone non signée.