SOCLE

Accueil / Pratique

Listes de contrôle et outils

Cette page est faite pour être utilisée, pas lue. Quatre listes selon votre rôle, les outils de diagnostic correspondants, et le calendrier des échéances qui casseront des configurations aujourd'hui fonctionnelles.

Échéances

Ce qui va casser, et quand

Six dates entre aujourd'hui et 2029. Trois d'entre elles invalident des configurations qui fonctionnent parfaitement aujourd'hui.

  1. 11 octobre 2026 — dans — jours

    Bascule de l'ancre de confiance DNSSEC. KSK-2024 devient la seule clé signant la racine. Concerne tout exploitant de résolveur validant. Action : vérifier l'ancre, tester la validation, chercher les ancres codées en dur.

  2. Janvier 2027

    Révocation de KSK-2017. L'ancienne clé est publiée avec un indicateur de révocation. Les résolveurs correctement configurés la retirent automatiquement.

  3. 15 mars 2027

    Certificats TLS limités à 100 jours. Quatre renouvellements par an. C'est l'échéance qui rend le processus manuel intenable pour la plupart des organisations. Action : automatisation ACME complète avant cette date.

  4. Mi-2027

    Destruction de KSK-2017 dans les deux installations de gestion de clés.

  5. 2027 → 2029

    Changement d'algorithme de la racine. Sous réserve de la consultation publique ouverte en février 2026 : génération d'une clé ECDSA en 2027, retrait de la clé RSA en 2029. Concernera à nouveau tous les résolveurs validants.

  6. 15 mars 2029

    Certificats TLS limités à 47 jours, réutilisation de la validation de domaine limitée à 10 jours. Environ huit renouvellements par an et par certificat.

Rôle 1

Vous exploitez un résolveur DNS

Avant le 11 octobre 2026

  • Vérifier que la mise à jour automatique des ancres de confiance (RFC 5011) est bien activée, et pas seulement disponible.
  • Afficher l'état des ancres connues : rndc managed-keys status sur BIND, unbound-anchor -l sur Unbound.
  • Confirmer que l'ancre contient deux clés, dont l'identifiant de KSK-2024 publié par l'IANA.
  • Chercher les ancres écrites en dur dans les fichiers de configuration, les images de conteneurs, les modèles de déploiement et les équipements embarqués.
  • Tester la validation contre un domaine délibérément mal signé : si la résolution aboutit, vous ne validez pas.
  • Vérifier que les relais intermédiaires (box, pare-feu) transmettent correctement les réponses volumineuses et les enregistrements DNSSEC.

En permanence

  • Surveiller le taux de SERVFAIL : c'est le premier signal visible d'un échec de validation, chez vous ou chez un domaine tiers.
  • Activer la minimisation du nom demandé (RFC 9156) pour limiter ce que chaque niveau du DNS apprend de vos utilisateurs.
  • Activer les cookies DNS (RFC 7873) et la limitation du débit de réponse.
  • Refuser la récursion aux clients extérieurs : un résolveur ouvert alimente les attaques par amplification.
  • Envisager une copie locale de la zone racine (RFC 8806) si la latence internationale est un enjeu.
  • Documenter la procédure de retour arrière et l'avoir déjà exécutée au moins une fois.
Rôle 2

Vous êtes responsable d'un nom de domaine

Protéger le nom lui-même

  • Activer la double authentification sur le compte du bureau d'enregistrement, avec des comptes nominatifs et non partagés.
  • Demander le verrouillage au registre pour les domaines critiques : aucune modification sans procédure hors ligne.
  • Vérifier la date d'expiration et activer le renouvellement automatique. L'oubli d'expiration reste une cause fréquente de perte de nom.
  • Alerter sur toute modification des serveurs de noms ou des enregistrements de délégation.
  • Supprimer les délégations vers des hébergeurs DNS qui ne servent plus la zone : elles sont récupérables par un tiers.
  • Inventorier les enregistrements CNAME pointant vers des services tiers résiliés.

Protéger la résolution et les certificats

  • Signer la zone en DNSSEC et vérifier que le DS est bien publié chez le registre. Une zone signée sans DS n'est pas protégée.
  • Automatiser la rotation des clés via CDS/CDNSKEY plutôt que par saisie manuelle chez le bureau d'enregistrement.
  • Abaisser les TTL plusieurs jours avant tout changement structurant, puis les remonter après vérification.
  • Surveiller l'expiration des signatures RRSIG : elles expirent sans préavis.
  • Répartir les serveurs de noms sur au moins deux opérateurs indépendants.
  • Publier un enregistrement CAA désignant les seules autorités autorisées, avec une adresse de notification.
  • Surveiller les journaux Certificate Transparency pour être alerté de toute émission non demandée.
Rôle 3

Vous exploitez un réseau

Routage

  • Publier des ROA pour tous vos préfixes auprès de votre registre régional.
  • Fixer la longueur maximale du ROA à ce que vous annoncez réellement, jamais plus permissif.
  • Faire tourner un validateur (Routinator, rpki-client, Fort) et rejeter les annonces invalides sur vos routeurs.
  • Filtrer explicitement les préfixes acceptés de chaque client, à partir des registres de routage et de la RPKI.
  • Plafonner le nombre de préfixes acceptés par session, pour couper automatiquement une fuite.
  • Appliquer le filtrage d'adresses source en bordure (BCP 38).
  • Souscrire à une alerte de détournement sur vos propres préfixes.
  • Publier des ASPA lorsque votre équipement le permet.

Exploitation et physique

  • Déployer toute modification de configuration réseau progressivement, jamais partout en une fois.
  • Disposer d'un accès de secours hors bande qui ne dépend d'aucun service susceptible de tomber.
  • Vérifier que le contrôle d'accès physique aux locaux ne dépend pas de la résolution de vos propres noms.
  • Demander à vos fournisseurs de transit quels systèmes de câbles ils empruntent : deux contrats ne garantissent pas deux chemins.
  • Configurer au moins quatre sources de temps distinctes, d'opérateurs différents, et activer NTS lorsque c'est possible.
  • Ne pas dépendre uniquement d'un récepteur satellitaire pour la référence de temps.
  • Adhérer aux engagements MANRS : c'est vérifiable publiquement et cela structure les pratiques internes.
Rôle 4

Vous dirigez ou arbitrez

Cinq questions à poser à vos équipes

  1. Si notre principal fournisseur DNS disparaît demain, combien de temps pour basculer ? Si la réponse dépasse quelques heures, il n'y a pas de plan.
  2. Combien de certificats TLS publics possédons-nous, et combien sont renouvelés automatiquement ? L'écart entre les deux chiffres est votre exposition en mars 2027.
  3. Nos domaines critiques sont-ils verrouillés au registre ? C'est la mesure la moins chère et la plus efficace contre le détournement administratif.
  4. Avons-nous déjà exécuté un retour arrière complet, en conditions réelles ? Un plan jamais testé n'est pas un plan.
  5. Notre procédure de reprise dépend-elle de l'infrastructure qu'elle doit réparer ? C'est le piège de 2021, et il est très courant.

Ce qui relève vraiment d'un arbitrage budgétaire

La diversité de chemins physiques, le second opérateur DNS, l'automatisation de la gestion des certificats et l'accès hors bande coûtent de l'argent et ne produisent aucun bénéfice visible tant que rien ne tombe. Ce sont précisément les postes qui déterminent la durée d'une panne. Les mesures cryptographiques, elles, sont pour l'essentiel gratuites en licence et coûteuses en attention.

Trois gestes à coût quasi nul

Publier un enregistrement CAA. Activer le verrouillage au registre sur les domaines critiques. Mettre en place une alerte sur les journaux de transparence des certificats. À eux trois, ils couvrent une part importante des scénarios de détournement documentés.

Diagnostic

Quinze outils, tous publics

OutilDomaineÀ quoi il sert
dig / kdigDNSInterroger un serveur précis, inspecter les enregistrements, tester avec et sans validation (+cd)
delvDNSSECAfficher le détail de la validation de la chaîne de confiance
DNSVizDNSSECGraphe visuel complet de la chaîne d'un domaine, avec le maillon exact qui échoue
ZonemasterDNSContrôle global d'une délégation, développé par des registres européens
internet.nlMultipleTest public d'un domaine : DNSSEC, TLS, IPv6, sécurité du courrier
crt.shCertificatsRechercher tous les certificats émis pour un domaine dans les journaux de transparence
isbgpsafeyet.comRoutageVérifier depuis son navigateur si son fournisseur rejette les routes invalides
bgp.toolsRoutageExplorer les préfixes, AS et relations d'un réseau
Moniteur RPKI du NISTRoutageÉtat de validation de la table de routage mondiale, repérage de ses propres invalides
RIPE AtlasMesureLancer des mesures depuis des milliers de sondes réparties dans le monde
RIPE RIS / RouteViewsRoutageArchives BGP pour reconstituer un incident a posteriori
Cloudflare RadarObservationTendances de trafic, perturbations annotées, adoption des protocoles
IODAObservationDétection de coupures à l'échelle d'un pays ou d'un opérateur, en temps réel
submarinecablemap.comPhysiqueCarte interactive des câbles, stations d'atterrissage et propriétaires
root-servers.orgDNSCarte et décompte en direct des instances de serveurs racines

Trois commandes pour commencer

;; 1. mon résolveur valide-t-il DNSSEC ? dig +dnssec exemple.be A ;; chercher l'indicateur "ad" dans les flags ;; 2. la chaîne de confiance est-elle intacte ? delv +rtrace exemple.be A ;; 3. quels certificats existent pour mon domaine ? ;; https://crt.sh/?q=exemple.be