De sleutels van het internet veranderen op 11 oktober 2026. Ben je klaar?

Toen we in 2018 schreven over de eerste root KSK-rollover, zagen we dat resolvers hun aangeleerde vertrouwen in de nieuwe sleutel verloren tijdens software-upgrades of verplaatsingen tussen machines. Het vroegtijdig publiceren van de sleutel was slechts een deel van de oplossing. We moesten ook weten of resolvers de sleutel hadden behouden, maar we konden gebruikers geen praktische manier bieden om dit te controleren.

De meeste website-exploitanten hoeven voor deze rollover geen wijzigingen door te voeren. Als u een DNSSEC-validerende resolver beheert, controleer dan of deze de nieuwe root-sleutel, KSK-2024, vertrouwt en volg de instructies van uw softwareleverancier om de trust anchors bij te werken als de sleutel ontbreekt. Als u Cloudflare gebruikt voor de DNS van uw domein of vertrouwt op 1.1.1.1 en Gateway DNS, hoeft u geen actie te ondernemen — onze systemen vertrouwen KSK-2024 al.

Om dit vooraf te controleren, kunt u onze rollover readiness test bezoeken. Deze test vraagt aan de resolver die uw browser gebruikt of deze de nieuwe sleutel vertrouwt. De test maakt gebruik van RFC 8509: A Root Key Trust Anchor Sentinel for DNSSEC, die we ter voorbereiding op de rollover in 1.1.1.1 hebben geïmplementeerd.

Waar het DNSSEC-vertrouwen begint

Een DNS-resolver zoekt de adressen op van websites en andere diensten voor uw apparaat. DNSSEC stelt de resolver in staat om digitale handtekeningen op DNS-records te controleren om te verifiëren dat deze authentiek zijn en niet zijn gewijzigd. De resolver moet ook controleren of de openbare sleutels die worden gebruikt om die handtekeningen te verifiëren, bij de juiste domeinen horen.

Voor cloudflare.com volgt dit een vertrouwensketen van de DNS-root naar .com, en vervolgens naar cloudflare.com. Elke ouder publiceert een Delegation Signer (DS)-record met een vingerafdruk van de openbare sleutel van het kind. Bijvoorbeeld: .com publiceert het DS-record voor cloudflare.com, waardoor de resolver de sleutel van dat domein kan controleren.

Die keten heeft een startpunt nodig. De root heeft echter geen ouder die kan bevestigen welke sleutels bij hem horen. In plaats daarvan begint een resolver die DNSSEC controleert met een openbare root-sleutel, of de vingerafdruk daarvan, die hij al vertrouwt. Dit wordt een trust anchor (vertrouwensanker) genoemd.

De signeringssleutels van de root hebben twee verschillende taken:

  • De zone-signing key (ZSK) signeert de DNS-records van de root, inclusief de DS-records voor topdomeinen zoals .com.
  • De key-signing key (KSK) signeert de lijst met openbare sleutels die door de root worden gepubliceerd, genaamd de DNSKEY-recordset.

De resolver gebruikt zijn vertrouwde KSK om die lijst te verifiëren, en gebruikt vervolgens de ZSK uit de lijst om de andere records van de root te verifiëren.

Onze berichten over de rollover-fouten bij .de en .al lieten de gevolgen zien van mislukte DNSSEC-controles: websites kunnen normaal functioneren maar toch onbereikbaar zijn. De root KSK-rollover wijzigt het startpunt van deze controles. Als een resolver de vervangende sleutel niet vertrouwt, kunnen gebruikers mogelijk geen websites onder enig topdomein bereiken.

De nieuwe sleutel is KSK-2024, geïdentificeerd door sleuteltag 38696. Deze zal KSK-2017 (sleuteltag 20326) vervangen als de ondertekenaar van de DNSKEY-set van de root. Validerende resolvers moeten de nieuwe sleutel vertrouwen vóór die overstap.

Hoe resolvers de nieuwe root-sleutel verkrijgen

RFC 5011 stelt resolvers in staat om automatisch een nieuw root-vertrouwensanker aan te leren. De root publiceert de nieuwe KSK naast de bestaande in zijn DNSKEY-set. De bestaande KSK blijft die set signeren, zodat een resolver de sleutel die hij al vertrouwt kan gebruiken om de records met de vervanging te verifiëren.

Voordat de resolver de nieuwe sleutel accepteert als trust anchor, wacht hij minimaal 30 dagen en blijft hij de gesigneerde DNSKEY-records van de root controleren. De nieuwe sleutel moet gedurende die periode in de records blijven staan. Na de wachttijd moet de resolver de records met de nieuwe sleutel opnieuw succesvol verifiëren voordat hij deze accepteert.

Voor deze rollover is KSK-2024 sinds 11 januari 2025 gepubliceerd in de DNSKEY-set van de root. Dit gaf resolvers met automatische trust-anchor-updates tijd om deze te ontdekken en te accepteren vóór de geplande wijziging op 11 oktober 2026. De wachttijd van elke resolver begint op het moment dat deze de nieuwe sleutel voor het eerst ziet en verifieert.

Voor onze resolver hebben we KSK-2024 in juli 2024 direct toegevoegd aan de ingebouwde trust anchors van de software, naast KSK-2017. Een resolver die de bijgewerkte software draait, heeft de nieuwe anchor dus vanaf de opstart beschikbaar.

We kozen voor deze aanpak vanwege onze ervaringen tijdens de voorbereidingen voor de eerste rollover. Zoals beschreven in ons bericht uit 2018, zorgden software-upgrades en verplaatsingen tussen machines ervoor dat sommige resolvers hun aangeleerde trust-anchor-status verloren. We hebben dit opgelost door de software bij te werken zodat de nieuwe anchor standaard is inbegrepen. Door KSK-2024 in de software op te nemen, vermijden we afhankelijkheid van het feit of elke resolver een automatisch aangeleerde sleutel behoudt.

Ondanks dat we KSK-2024 in juli 2024 aan de ingebouwde trust anchors van onze resolver hebben toegevoegd, hadden gebruikers van 1.1.1.1 en Gateway DNS geen directe manier om te controleren of de resolver die hun queries beantwoordde de nieuwe sleutel vertrouwde.

Vraag het de resolver

RFC 8509 definieert de root key trust anchor sentinel, een manier om een ondersteunende resolver te vragen of hij een specifieke root-sleutel vertrouwt. Dit gebeurt via gewone DNS-queries met speciaal benoemde domeinen.

Onze website voor gereedheidstests gebruikt dit protocol om te controleren op KSK-2024. Twee namen stellen tegenovergestelde vragen: is-ta-38696 vraagt of de sleutel wordt vertrouwd, not-ta-38696 vraagt of deze niet wordt vertrouwd.

Beide namen hebben geldige DNSSEC-gesigneerde adresrecords. Een resolver die de sentinel ondersteunt, valideert eerst deze records en geeft vervolgens ofwel het antwoord direct terug, of vervangt het antwoord door SERVFAIL, afhankelijk van of de sleutel wordt vertrouwd.

Voor een validerende resolver met sentinel-ondersteuning zijn de verwachte resultaten:

QueryKSK-2024 wordt vertrouwdKSK-2024 wordt niet vertrouwd
is-ta-38696Geeft een geldig antwoordGeeft SERVFAIL
not-ta-38696Geeft SERVFAILGeeft een geldig antwoord

Voor een validerende resolver met sentinel-ondersteuning is SERVFAIL voor not-ta-38696 verwacht wanneer KSK-2024 wordt vertrouwd. De resolver wijst de "niet vertrouwd"-query dan bewust af.

Sentinel-labels zoals root-key-sentinel-is-ta-38696 kunnen onder elk DNSSEC-gesigneerd domein worden gebruikt. Wij gebruiken dnstest.dev voor onze tests. U kunt de twee queries direct uitvoeren tegen 1.1.1.1:

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44476
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; ANSWER SECTION:
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.6.197
root-key-sentinel-is-ta-38696.dnstest.dev. 300 IN A 104.18.7.197

$ dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
; <<>> DiG 9.10.6 <<>> @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3285
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

De website controleert ook of een gewone gesigneerde naam wordt opgelost, of een opzettelijk ongeldige DNSSEC-naam wordt afgewezen, en of de resolver reageert op een sentinel-query voor de huidige root-sleutel. Deze controles helpen om een betekenisvol resultaat te onderscheiden van een mislukte opzoeking of een niet-ondersteund protocol. Als sentinel-ondersteuning niet kan worden vastgesteld, is het resultaat onbeslist; dit betekent niet noodzakelijkerwijs dat de nieuwe sleutel ontbreekt.

De browsertest controleert de resolver die uw browser gebruikt, die beïnvloed kan worden door Secure DNS of een VPN. De bovenstaande dig-commando's queryen expliciet 1.1.1.1. Beiden geven een momentopname van het resolver-pad dat deze verzoeken beantwoordt.

Nieuwe sleutel, hetzelfde algoritme

Zowel KSK-2017 als KSK-2024 maken gebruik van RSA/SHA-256. De rollover vervangt het sleutelpaar, terwijl dezelfde methode voor het maken en verifiëren van handtekeningen behouden blijft.

In ons bericht uit 2018 schreven we dat een succesvolle rollover de deur zou openen voor een discussie over een algoritme-wijziging. Acht jaar later gebruikt de root nog steeds RSA.

Het vervangen van de sleutel blijft echter nuttig. Het beperkt hoe lang een enkele private sleutel in gebruik blijft en oefent het proces van het distribueren van nieuwe trust anchors, het bijwerken van resolvers en het uitfaseren van oude sleutels. Zoals de eerste rollover liet zien, kunnen deze stappen mislukken, zelfs wanneer de cryptografie zelf correct werkt.

De Internet Assigned Numbers Authority (IANA) streeft naar een ideaal rollover-interval van drie jaar, om een balans te vinden tussen regelmatige oefening en het werk en risico van het te vaak wijzigen van de root-sleutel. De kloof sinds 2018 is groter geweest. De Internet Corporation for Assigned Names and Numbers (ICANN) schrijft deze vertraging toe aan verstoringen door de pandemie en upgrades aan de hardware die de private signeringssleutels beschermt.

Een wijziging van algoritme betekent dat resolvers zowel een nieuw trust anchor als software nodig hebben die de nieuwe handtekeningen kan verifiëren. Regelmatige sleutel-rollovers stellen operators in staat om de trust-anchor-updates te testen terwijl het algoritme hetzelfde blijft.

Wat komt er na oktober?

De overstap op 11 oktober wijzigt welke KSK de DNSKEY-set van de root signeert. De rollover loopt door in 2027, wanneer ICANN van plan is KSK-2017 in te trekken, te verwijderen uit de root-zone en de private sleutel te verwijderen. Het stoppen van het signeren met een sleutel en het intrekken van het vertrouwen in die sleutel zijn aparte stappen.

ICANN heeft ook een toekomstige root-algoritme-rollover naar ECDSA P-256 voorgesteld. ECDSA produceert kleinere sleutels en handtekeningen dan het huidige RSA-algoritme. Dat voorstel staat los van de sleutelvervanging van dit oktober, en ECDSA is geen post-quantum algoritme.

1.1.1.1 valideert nu ML-DSA-44 handtekeningen, die zijn ontworpen om veilig te blijven tegen aanvallen met quantumcomputers. Om de gehele vertrouwensketen van DNSSEC post-quantum veilig te maken, moeten gesigneerde domeinen, hun parent-zones en de root ook post-quantum cryptografie adopteren. Voor de root betekent dit het introduceren van een post-quantum KSK en ervoor zorgen dat resolvers deze vertrouwen.

Dat zal een nieuwe root-sleutel-rollover vereisen. De rollovers die we nu uitvoeren, stellen operators in staat te testen hoe ze vervangende trust anchors distribueren, te controleren of resolvers deze hebben geaccepteerd en de oude sleutels uit te faseren. De rollover van dit oktober behoudt RSA, maar oefent de trust-anchor-updates die we nodig zullen hebben wanneer de root overstapt op post-quantum cryptografie. De sentinel geeft ons een manier om te controleren of resolvers deze updates hebben gevolgd.

We moedigen DNS-providers en resolver-ontwikkelaars aan om RFC 8509 trust anchor sentinels te ondersteunen. Als uw resolver dit niet ondersteunt, vraag uw provider of softwareleverancier dan om ondersteuning toe te voegen. Gebruikers zouden moeten kunnen controleren of hun resolver de volgende root-sleutel vertrouwt voordat een rollover plaatsvindt.

Voor nu is de volgende deadline 11 oktober. U kunt de gereedheid van uw resolver controleren via https://dnstest.dev/ksk-2024. Als u een DNSSEC-validerende resolver beheert, bevestig dan dat deze KSK-2024 (sleuteltag 38696) vertrouwt, en volg de richtlijnen van ICANN en de instructies van uw softwareleverancier als de sleutel ontbreekt.