La clé qui signe Internet change le 11 octobre 2026.
Une seule clé cryptographique sert de point de départ à la vérification de tous les noms de domaine du monde. Elle est gardée dans deux coffres, sur deux continents, et remplacée en public. Voici comment tient le socle du réseau — et par où il casse.
Le 11 octobre 2026, KSK-2024 remplace KSK-2017 comme clé active de signature de la zone racine. Les résolveurs qui valident DNSSEC avec une ancre codée en dur et jamais mise à jour commenceront à renvoyer des erreurs à leurs utilisateurs. KSK-2017 restera publiée sans signer jusqu'à sa révocation en janvier 2027. Guide de l'ICANN
Algorithme 8 = RSA/SHA-256. Un changement d'algorithme vers ECDSA fait l'objet d'une consultation publique de l'ICANN ouverte en février 2026, pour un déploiement envisagé entre 2027 et 2029.
« Sécuriser les serveurs mondiaux » veut dire quatre choses distinctes
On parle souvent d'Internet comme d'un bloc. En pratique, quatre systèmes indépendants doivent tenir en même temps pour qu'une adresse tapée dans un navigateur aboutisse au bon serveur. Chacun a ses opérateurs, ses protocoles de protection et ses modes de défaillance.
Trouver le bon nom
Le DNS traduit exemple.be en adresse IP. Sa protection s'appelle DNSSEC : chaque réponse est signée, et les signatures forment une chaîne remontant jusqu'à la racine.
Trouver le chemin
BGP décide par où passent les paquets. Il repose historiquement sur la confiance entre opérateurs. RPKI ajoute des certificats pour prouver qui a le droit d'annoncer quelles adresses.
Prouver qui répond
TLS et les autorités de certification garantissent que le serveur au bout du chemin est bien celui qu'il prétend. Certificate Transparency rend chaque certificat émis publiquement auditable.
Tenir physiquement
NTP synchronise les horloges dont dépend toute vérification de signature. Sous l'eau, environ 500 câbles portent la quasi-totalité du trafic intercontinental.
Treize identités, douze organisations, aucune autorité unique
Les serveurs racines ne connaissent aucun site web. Ils ne détiennent qu'une liste : celle des extensions de premier niveau et des serveurs qui en ont la charge. Leur nombre est plafonné à treize par un héritage technique — la taille maximale d'une réponse DNS tenant dans un seul paquet UDP à l'époque de la conception. Derrière ces treize adresses, l'anycast a démultiplié les machines.
La chaîne de confiance, maillon par maillon
DNSSEC ne chiffre rien. Il signe. Chaque niveau du DNS certifie la clé du niveau inférieur, si bien qu'un résolveur qui connaît une seule clé — celle de la racine — peut vérifier n'importe quelle réponse. Sélectionnez un maillon, puis coupez-le pour voir ce qui se passe.
Le rituel le plus filmé de l'informatique mondiale
La clé privée qui signe la racine du DNS n'existe nulle part en clair. Elle vit à l'intérieur de modules matériels de sécurité conservés dans deux installations distantes — l'une sur la côte ouest des États-Unis, l'autre sur la côte est — de manière à ce qu'aucun incident local ne puisse détruire les deux.
Quatre fois par an environ, l'IANA réunit une cérémonie pour utiliser cette clé. Elle sert à signer les clés de zone (ZSK) du trimestre suivant. Rien d'autre. L'opération dure quelques heures et suit un script écrit à l'avance, ligne par ligne.
Le contrôle n'est pas confié à une organisation mais réparti entre des représentants de la communauté de confiance, bénévoles venus de plusieurs pays. Les uns détiennent les cartes à puce qui activent les modules, les autres des fragments permettant de reconstruire le système en cas de sinistre. Personne ne peut agir seul.
Tout est filmé et diffusé, les journaux d'audit sont publiés, et un auditeur externe certifie les contrôles. La sécurité ne repose donc pas sur le secret des procédures, mais sur le fait que n'importe qui peut les vérifier.
-
Avril 2024 — génération
KSK-2024 est produite lors d'une cérémonie dans la première installation, puis répliquée dans la seconde. La clé privée ne quitte jamais les modules matériels.
-
2024 → 2026 — pré-publication
La nouvelle clé publique est publiée dans la racine sans rien signer, pendant près de deux ans. Les résolveurs l'apprennent automatiquement via le mécanisme décrit par le RFC 5011.
-
Mars 2025 — mesure
Verisign estime, à partir des signaux d'ancre de confiance, que 91,3 % des résolveurs observés ont déjà enregistré KSK-2024 — un rythme comparable à celui de 2018.
-
11 octobre 2026 — bascule
KSK-2024 devient la seule clé qui signe la racine. Les résolveurs restés sur l'ancienne ancre échouent à valider et renvoient des erreurs.
-
Janvier → mi-2027 — retrait
KSK-2017 est formellement révoquée, puis effacée des deux installations de gestion de clés. Le cycle recommence.
Le DNS n'est qu'un des systèmes critiques
Un nom correctement résolu ne sert à rien si le trafic est détourné en route, si le certificat présenté est frauduleux ou si le câble a été sectionné. Cinq autres infrastructures méritent la même attention.
Routage BGP
Chaque opérateur annonce à ses voisins les plages d'adresses qu'il sait joindre. Le protocole ne vérifie rien par lui-même : une annonce erronée se propage en quelques minutes à l'échelle du globe.
La RPKI corrige cela avec des certificats signés (les ROA) qui déclarent quel réseau a le droit d'annoncer quelles adresses. Les grands opérateurs rejettent aujourd'hui les annonces invalides. L'extension ASPA vise en plus les fuites de routes, où une route valide emprunte un chemin qu'elle n'aurait jamais dû prendre.
Mode de défaillanceDétournement d'adresses, interception de trafic, disparition d'un service du réseau mondial.Certificats TLS
Le cadenas du navigateur repose sur quelques centaines d'autorités de certification. N'importe laquelle d'entre elles peut techniquement émettre un certificat pour n'importe quel domaine.
Certificate Transparency impose que tout certificat émis soit inscrit dans des journaux publics append-only. Un titulaire de domaine peut ainsi détecter un certificat émis à son insu. Les enregistrements CAA permettent en amont de restreindre les autorités autorisées.
Mode de défaillanceFaux certificat, interception TLS silencieuse, usurpation d'un service légitime.Le temps
Toute vérification de signature compare une date. Une horloge décalée fait accepter des certificats expirés ou rejeter des signatures valides — DNSSEC compris.
Les serveurs de temps de strate 1 sont raccordés à des horloges atomiques ou à des récepteurs GNSS, eux-mêmes brouillables ou leurrables. NTS ajoute une authentification cryptographique à la synchronisation.
Mode de défaillanceDécalage horaire massif, invalidation en cascade des signatures et des certificats.Points d'échange
Les réseaux s'interconnectent physiquement dans des points d'échange. Quelques-uns concentrent une part considérable du trafic européen, ce qui en fait à la fois des accélérateurs et des points de concentration.
L'anycast y répond : une même adresse annoncée depuis des centaines de sites, le réseau dirigeant chaque requête vers l'instance la plus proche. C'est ce qui permet à une attaque en déni de service d'être absorbée localement au lieu de saturer une cible unique.
Mode de défaillanceSaturation, panne d'un site majeur, effet domino sur les services hébergés.Câbles sous-marins
Environ 500 câbles portent la quasi-totalité du trafic entre continents, et empruntent des passages obligés : mer Rouge, détroits, zones d'atterrage partagées. Une ancre de navire suffit à en couper un.
La résilience vient de la redondance des routes plus que de la protection des câbles eux-mêmes : en Europe du Nord, plusieurs coupures récentes n'ont eu presque aucun effet visible, faute de dépendance à un seul chemin.
Mode de défaillanceCoupure accidentelle ou délibérée, isolement de régions entières, délais de réparation en semaines.Qui décide
Aucun État ni entreprise ne contrôle l'ensemble. L'IETF écrit les protocoles, l'ICANN et l'IANA coordonnent noms et numéros, cinq registres régionaux distribuent les adresses IP, et les opérateurs appliquent — ou non — les bonnes pratiques.
Cette dispersion est un choix de sécurité : elle rend une prise de contrôle unique très difficile. Elle rend aussi toute correction lente, puisqu'elle exige un consensus mondial.
Mode de défaillanceFragmentation réglementaire, concentration du marché autour de quelques fournisseurs.Ce qui a déjà cassé, et ce que chaque panne a corrigé
Le système racine n'a jamais subi de panne totale. Presque tous les mécanismes de protection décrits ici existent pourtant parce qu'un incident les a rendus nécessaires.
Attaque en déni de service contre les treize racinesDDoS
Une attaque coordonnée vise l'ensemble des serveurs racines. Plusieurs sont dégradés, aucun utilisateur ne s'en aperçoit. L'épisode accélère le déploiement de l'anycast, généralisé à partir de 2002-2003.
Le trafic mondial de YouTube détourné vers le PakistanBGP
Un opérateur national annonce une route plus précise pour bloquer le site localement. L'annonce fuit vers son fournisseur, puis vers le monde entier. Le service devient inaccessible pendant environ deux heures — l'exemple canonique du détournement BGP involontaire.
La faille Kaminsky rend l'empoisonnement de cache trivialDNS
Une méthode permet d'injecter de fausses réponses dans les caches des résolveurs en quelques secondes. Un correctif coordonné est déployé mondialement, puis DNSSEC — spécifié depuis des années — passe enfin au déploiement. La racine sera signée en juillet 2010.
Cinq millions de requêtes par seconde et par serveur racineDDoS
Deux vagues d'attaque frappent le système racine. La plupart des opérateurs continuent de répondre aux requêtes légitimes. La démonstration valide l'architecture : la charge est absorbée par des centaines d'instances au lieu d'une seule cible.
Mirai coupe l'accès à un opérateur DNS majeurDDoS
Un botnet d'objets connectés sature l'infrastructure DNS d'un seul prestataire. Des dizaines de grands sites deviennent injoignables aux États-Unis et en Europe. Leçon retenue : héberger ses noms de domaine chez un seul fournisseur est un point unique de défaillance.
Un groupe mondial se retire lui-même du réseauBGP + DNS
Une erreur de configuration retire les annonces BGP couvrant les serveurs de noms de l'entreprise. Ses domaines cessent d'exister pour le reste du monde pendant près de six heures, y compris pour ses propres outils internes d'accès aux locaux.
Quatre câbles coupés au large de l'Afrique de l'OuestPhysique
Des ruptures quasi simultanées privent plusieurs pays d'une grande partie de leur capacité internationale. La réparation prend des semaines et met en évidence la dépendance de régions entières à un très petit nombre de routes.
Coupures en mer Rouge et reroutage du trafic Europe-AsiePhysique
Plusieurs systèmes sont endommagés dans un corridor stratégique. Latence en forte hausse et services cloud basculés sur des chemins de secours pour l'Asie et le Moyen-Orient.
Une fuite de routes de 25 minutes depuis MiamiBGP
Un changement de configuration automatisé chez un grand fournisseur d'infrastructure produit une politique de routage trop permissive. Du trafic tiers en IPv6 est aspiré par un centre de données unique. L'opérateur publie une analyse détaillée et corrige son automatisation.
Des signatures DNSSEC erronées diffusées en AllemagneDNSSEC
Une erreur de signature rend des domaines invalides pour les résolveurs qui valident correctement — le rappel que DNSSEC transforme une erreur d'exploitation en indisponibilité franche, par conception.
Deux câbles endommagés au large de Perth, enquête ouvertePhysique
Deux systèmes reliant l'Australie tombent en avarie coup sur coup, à proximité l'un de l'autre et à l'intérieur d'une zone protégée. La police fédérale australienne enquête sur un possible sabotage.
Bascule de l'ancre de confiance mondialeÀ venir
Événement planifié, annoncé deux ans à l'avance, testé et mesuré. Le seul risque restant tient aux résolveurs dont personne ne s'occupe plus.
Ce qui dépend réellement de vous
Si vous exploitez un résolveur
- Vérifiez que votre logiciel gère la mise à jour automatique de l'ancre de confiance (RFC 5011) et qu'elle est activée.
- Cherchez les ancres codées en dur dans vos fichiers de configuration ou vos images de conteneurs : ce sont elles qui casseront.
- Testez la validation avant le 11 octobre 2026, pas le jour même.
- Surveillez le taux de SERVFAIL : c'est le premier signal visible d'un échec de validation.
Si vous exploitez un réseau
- Publiez des ROA pour vos préfixes et filtrez les annonces invalides à l'entrée.
- Appliquez le filtrage d'adresses source en bordure (BCP 38) pour ne pas alimenter les attaques par amplification.
- Répartissez vos noms de domaine sur au moins deux opérateurs DNS indépendants.
- Surveillez les journaux Certificate Transparency pour vos propres domaines.
Si vous êtes simplement utilisateur
- Le 11 octobre, une panne DNS soudaine viendra probablement du résolveur de votre fournisseur d'accès, pas de votre machine.
- Un résolveur qui valide DNSSEC protège contre les fausses réponses — la plupart des grands résolveurs publics le font.
- Mettez à jour vos systèmes : les ancres de confiance sont distribuées par les mises à jour logicielles.
- Un site inaccessible n'est pas forcément hors service : il peut être injoignable depuis votre chemin réseau uniquement.