Het artikel bespreekt de geplande rotatie van de root-sleutel van het Domain Name System (DNS) op 11 oktober 2026. In tegenstelling tot andere DNSSEC-sleutels heeft de root-sleutel geen ouder-sleutel, waardoor authenticatie plaatsvindt via het principe 'oud ondertekent nieuw' volgens de richtlijnen van RFC 5011.
De auteur analyseert hoe men kan meten of DNS-resolvers de nieuwe sleutel (KSK-2024) al hebben geaccepteerd. Hiervoor worden twee technieken beschreven:
- RFC 8145: Waarbij resolvers hun vertrouwde sleuteltags meesturen in queries naar root-servers.
- RFC 8509: Een 'Root Key TA Sentinel' mechanisme dat het signaal terugstuurt naar de vragensteller.
Uit metingen blijkt dat ongeveer 70% van de resolvers die RFC 8509 ondersteunen, de nieuwe sleutel al hebben geladen. Het artikel bevat een lijst van ISP's met een lage acceptatiegraad, waarschuwend dat gebruikers van deze netwerken mogelijk problemen zullen ervaren tijdens de rotatie.
Het roteren van de root-sleutel
Terwijl ik dit schrijf op 8 oktober, staat de root-sleutel van het Domain Name System (DNS) gepland om te roteren op 11 oktober 2026.
Het roteren van de root-sleutel is 'bijzonder' omdat elke andere sleutel in DNS Security Extensions (DNSSEC) het concept heeft van een ouder-sleutel die wordt gebruikt om de authenticiteit te valideren. In het geval van een Zone-Signing Key (ZSK) is dat de Key-Signing Key (KSK) van de zone. In het geval van een KSK is dat de sleutel die wordt gebruikt om de vermeldingen in het bovenliggende domein te ondertekenen. Voor sleutels die ondergeschikt zijn aan een andere sleutel, is het voldoende dat de ouder-sleutel de nieuwe sleutelwaarde ondertekent (of, preciezer gezegd, een hash van het publieke sleutelcomponent, gepubliceerd in de ouder-zone als een ondertekend Delegation Signer (DS) resource record).
De root-sleutel is anders, aangezien deze geen ouder heeft. De manier waarop een nieuwe sleutel wordt geauthenticeerd door een DNS-resolver, is door de oude KSK de nieuwe KSK te laten ondertekenen ('oud ondertekent nieuw'). Vervolgens is een langere periode nodig om DNSSEC-validerende clients voldoende tijd te geven om de binnenkomende sleutel op te pikken en te vertrouwen. RFC 5011 — “Trust Anchor Update” biedt richtlijnen voor dit proces.
RFC 5011 stelt:
“De add hold-down time is 30 dagen of de vervaltijd van de oorspronkelijke TTL van de eerste trust point DNSKEY RRSet die de nieuwe sleutel bevatte, whichever is greater. Dit zorgt ervoor dat er ten minste twee gevalideerde DNSKEY RRSets die de nieuwe sleutel bevatten, door de resolver gezien MOETEN worden voordat de sleutel wordt geaccepteerd.”
De nieuwe KSK wordt toegevoegd aan de DNSKEY Resource Record Set (RRSet) van de root-zone, zodat validerende resolvers automatisch op de hoogte worden gesteld van deze nieuwe sleutel wanneer ze dit resource record ophalen. Zij dienen de sleutelwaarde in hun lokale cache van vertrouwde sleutels op te nemen wanneer de nieuwe sleutel gedurende het interval van de 30-daagse hold-down tijd is waargenomen. Als de sleutelrotatie deze minimale wachtperiodes voor elke fase van de rotatie naleeft, zou het gehele proces automatisch moeten verlopen.
De rotatie van 2026 is geen wijziging van het algoritme, maar simpelweg een wijziging van het private/publieke sleutelpaar. De binnenkomende KSK (KSK-2024) werd in juli 2024 gepubliceerd op de website van de Internet Assigned Numbers Authority (IANA) en in januari 2025 toegevoegd aan het DNSKEY resource record van de root-zone. IANA is van plan de KSK te roteren op 11 oktober 2026, waarna deze zal worden gebruikt om de digitale handtekening van het DNSKEY resource record van de root-zone te genereren.
Hoe verloopt deze KSK-rotatie? Hebben alle DNSSEC-validerende recursieve resolvers inmiddels KSK-2024 herkend en deze sleutel opgenomen in hun Trust Anchor (TA) sets? Hoe kunnen we dit gedrag meten?
Trust signal — RFC 8145 meting
Er zijn twee technieken die we kunnen gebruiken om in de DNS-infrastructuur van het internet te kijken en te ontdekken welke DNS-resolvers KSK-2024 aan hun lokale TA-set hebben toegevoegd.
De eerste wordt beschreven in RFC 8145 — “Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)”. Bij deze techniek bedraagt de resolver de sleuteltags van zijn vertrouwde sleutels in queries die naar de autoritatieve servers voor de root-zone worden gestuurd. Eén methode plaatst de tag-waarden van alle vertrouwde sleutels in een query-naam. Bijvoorbeeld, een query-naam van _ta-4f66-9728 geeft aan dat de resolver sleutels vertrouwt met tag-waarden 20326 en 38696. Een alternatieve methode is om de trust key tag-waarden in een edns-key-tag optie in queries te embedden.
Deze informatie is zichtbaar in het logboek van queries dat wordt beheerd door de operators van root-servers. Een analyse van dit RFC 8145-signaal ontvangen door een root-server operator (Verisign) is te zien in Figuur 1.
(Figuur 1 — Een steekproef van resolvers en welke KSK(s) zij in hun TA hebben geconfigureerd, per juli 2026. Bron: Verisign.)
Wat de data in Figuur 1 niet laat zien, is de populatie gebruikers die gebruikmaken van deze recursieve resolvers. Sommige DNSSEC-validerende recursieve resolvers bedienen miljoenen gebruikers, terwijl anderen, waaronder die op mijn laptop, er slechts één bedienen. Deze cijfers laten zien dat ongeveer 90% van de rapporterende resolvers KSK-2024 aan hun TA-set heeft toegevoegd. Dit vertaalt zich niet direct naar een schatting van de eindgebruikerspopulatie die zij bedienen, of het aantal gebruikers dat mogelijk beïnvloed kan worden door de KSK-rotatie.
RFC 8509 — “A Root Key Trust Anchor Sentinel for DNSSEC” stelt een andere aanpak voor, waarbij het signaal van de vertrouwde sleutels van een recursieve resolver wordt teruggestuurd naar de vragensteller (querier), in plaats van doorgestuurd te worden naar een root-zone server. Deze aanpak maakt gebruik van het meest linkse label van een DNS-query-naam en vereist dat de DNS-resolver dit label herkent en een respons genereert op basis van de set vertrouwde sleutels van de resolver, zoals getoond in Tabel 1.
Tabel 1 – RFC 8509 meetrespons
| Label | Sleutel wordt vertrouwd | Sleutel wordt niet vertrouwd |
|---|
root-key-sentinel-is-ta-<key-tag> | Retourneer origineel antwoord | Retourneer SERVFAIL |
root-key-sentinel-not-ta-<key-tag> | Retourneer SERVFAIL | Retourneer origineel antwoord |
Je kunt deze tests op je eigen DNS-infrastructuur uitvoeren met een webpagina die wordt beheerd door het DNS-team van Cloudflare.
Wij maken gebruik van het op advertenties (ad) gebaseerde meetsysteem van APNIC om deze queries dagelijks aan een verzameling eindgebruikers voor te leggen. We identificeren geen individuele validerende recursieve resolvers, maar kwantificeren de populatie eindgebruikers die zich uitsluitend achter DNSSEC-validerende resolvers bevinden waar de resolver KSK-2024 tot nu toe niet vertrouwt.
De test die we gebruiken bevat drie queries, zoals getoond in Tabel 2. Een resolver die is geconfigureerd om DNSSEC-validatie uit te voeren en dit Root Key TA Sentinel-mechanisme ondersteunt, zal DNS-responsen geven, eveneens getoond in Tabel 2.
Tabel 2 – RFC 8509 meetresponsen voor KSK-2024
| DNS label | Respons |
|---|
https://root-key-sentinel-is-ta-20326… | NOERROR |
https://root-key-sentinel-not-ta-20326… | SERVFAIL |
https://root-key-sentinel-is-ta-38696… | [Respons varieert per resolver] |
De eerste twee tests zijn bedoeld om te bepalen of de resolver dit Root Key TA Sentinel-mechanisme ondersteunt door te testen of hij KSK-2017 (key-tag 20326) vertrouwt. Als hij dat niet doet, zal hij in beide gevallen een gevalideerde respons teruggeven. Als hij responsen rapporteert volgens Tabel 2, kunnen we het monsterpunt classificeren als een ‘rapporterende gebruiker’. De derde query is bedoeld om te bepalen of de resolver KSK-2024 (key-tag 38696) in zijn lokale TA-set heeft geladen.
Resultaten
Een kleinschalige test met RIPE Atlas-probes op 5 oktober, die 2.900 verschillende Autonomous Systems (AS'en) besloeg, vond 1.230 probes met een resolver-gedrag dat consistent is met een Root Key TA Sentinel die de nieuwe KSK heeft geladen. 47 probes vertoonden een resolver-gedrag dat consistent is met het niet hebben geladen van de nieuwe KSK-waarde in lokale vertrouwde sleutelcollecties.
We hebben een grotere set op advertenties gebaseerde metingen uitgevoerd tussen mei en juli 2026, en deze hervat in begin oktober 2026, met gemiddeld ongeveer 16 miljoen tests per dag.
De dagelijkse resultaten van deze meting van de adoptie van KSK-2024 als TA zijn te zien in Figuur 2.
(Figuur 2 — Dagelijkse meting van de adoptie van KSK-2024 als TA met behulp van RFC 8509 Sentinel tijdens 2026.)
Deze grotere steekproef geeft aan dat ongeveer 70% van de tests die RFC 8509 lijken te ondersteunen, rapporteren dat KSK-2024 is geladen als een vertrouwde sleutel.
(Figuur 3 — Dagelijkse meting van RFC 8509 Sentinel-ondersteuning tijdens 2026.)
Hoewel het meetplatform 16 miljoen tests per dag uitvoert, laten slechts ongeveer 6 miljoen tests per dag zien dat het geteste eindsysteem zich achter DNSSEC-validerende recursieve resolvers bevindt. Ongeveer 1,8 miljoen tests per dag geven een duidelijk signaal dat ze het RFC 8509 Key Sentinel-mechanisme ondersteunen.
Deze gemiddelde getallen zijn weinig behulpzaam, omdat ze een aanzienlijke variatie maskeren. Wat nuttiger zou zijn, is een lijst van die netwerken waar de RFC 8509 Root Key TA Sentinel-tests aangeven dat de binnenkomende sleutel niet is geladen in de lokale vertrouwde sleutelset.
Tabel 3 toont de 50 netwerken met het laagste acceptatiepercentage van KSK-2024. Ik heb deze lijst gefilterd zodat alleen netwerken worden getoond waar we 1.000 of meer tests hebben waargenomen die aantoonden dat hun DNS-resolvers het Root Key TA Sentinel-mechanisme ondersteunden.
Tabel 3 — Lijst van top 50 ISP's met lage KSK-2024 trust-signalen
| ASN | Land | KSK-2024 (%) | Tests | Validerend | RFC 8509 | KSK-2024 (count) | Not KSK-2024 (count) | Naam |
|---|
| 262202 | CR | 49.40% | 9,441 | 9,343 | 2,201 | 469 | 481 | Telefonica de Costa Rica, Costa Rica |
| 328169 | SZ | 48.90% | 4,694 | 4,687 | 1,199 | 276 | 288 | Swazi Mobile, Swaziland |
| 328341 | ZA | 48.90% | 2,551 | 2,522 | 1,352 | 284 | 297 | Capricom Networks, South Africa |
| 17470 | LK | 48.70% | 15,011 | 11,749 | 2,952 | 717 | 756 | Hutchison Telecoms, Sri Lanka |
| 9335 | TH | 48.40% | 4,905 | 4,877 | 1,355 | 299 | 319 | National Telco, Thailand |
| 45925 | BD | 48.20% | 7,886 | 7,811 | 2,046 | 465 | 499 | Teletalk, Bangladesh |
| 29544 | MR | 47.90% | 41,149 | 40,758 | 8,032 | 1,842 | 2,003 | Mauritanian Telecommunication, Mauritania |
| 30990 | DJ | 47.40% | 9,472 | 9,393 | 2,701 | 641 | 711 | Dibjouti Telecom, Djiboutit |
| 329129 | LY | 46.80% | 7,879 | 7,843 | 1,790 | 384 | 436 | Libya Tech, Lybia |
| 136336 | IN | 46.00% | 8,113 | 6,972 | 1,818 | 353 | 414 | Thamizhaga, India |
| 9658 | PH | 45.60% | 6,920 | 6,293 | 2,062 | 555 | 661 | Eastern Telecoms, Philippines |
| 135300 | MM | 45.40% | 5,813 | 4,600 | 1,150 | 228 | 274 | Myanmar Broadband, Myanmar |
| 205368 | AM | 38.60% | 4,227 | 4,209 | 2,349 | 536 | 852 | Fnet, Armenia |
| 24812 | UA | 32.00% | 10,791 | 3,437 | 1,322 | 205 | 436 | HomeNet, Ukraine |
| 39065 | UA | 26.10% | 1,701 | 1,666 | 1,238 | 193 | 546 | Southern Telecommunication s, Ukraine |
| 15108 | US | 16.40% | 17,966 | 17,209 | 15,036 | 2,014 | 10,282 | Allo Comms, United States |
| 132199 | PH | 13.10% | 73,176 | 71,705 | 35,310 | 2,915 | 19,310 | Globe Telecom, Philippines |
| 33915 | NL | 12.70% | 170,615 | 19,642 | 13,292 | 1,328 | 9,105 | Vodafone Libertel, Netherlands |
| 5056 | US | 10.70% | 7,519 | 6,933 | 4,883 | 427 | 3,556 | Aureon Network Services, United States |
| 12969 | IS | 10.00% | 4,567 | 4,520 | 3,954 | 331 | 2,979 | Vodafone, Iceland |
| 327931 | DZ | 9.00% | 160,973 | 17,701 | 9,705 | 357 | 3,627 | Optimum Telecom, Algeria |
| 58895 | PK | 8.20% | 13,757 | 5,584 | 3,034 | 128 | 1,432 | Ebone, Pakistan |
| 16019 | CZ | 8.20% | 45,089 | 43,692 | 32,266 | 1,885 | 21,166 | Vodafone-CZ, Czechia |
| 38195 | AU | 6.20% | 24,038 | 19,612 | 16,004 | 787 | 11,931 | Superloop, Australia |
| 54345 | US | 5.20% | 2,320 | 2,089 | 1,050 | 366 | 61 | Jackson Energy, United States |
| 203214 | IQ | 4.50% | 165,409 | 153,024 | 115,657 | 3,636 | 76,631 | HulumTele , Iraq |
| 205889 | IQ | 4.50% | 4,836 | 1,750 | 1,102 | 30 | 636 | Giga Nineveh, Iraq |
| 5690 | CA | 4.40% | 1,983 | 1,936 | 1,659 | 61 | 1,323 | Vianet, Canada |
| 56207 | PH | 4.20% | 12,110 | 11,720 | 6,860 | 149 | 3,399 | ComClark, Philippines |
| 4775 | PH | 4.00% | 272,137 | 268,811 | 174,084 | 4,439 | 105,397 | Globe Telecoms, Philippines |
| 15547 | CH | 4.00% | 3,011 | 2,967 | 2,508 | 78 | 1,865 | Netplus, Switzerland |
| 47794 | SA | 3.90% | 6,665 | 6,462 | 4,693 | 114 | 2,814 | Etihad GO, Saudi Arabia |
| 17639 | PH | 3.70% | 259,256 | 255,140 | 165,934 | 3,830 | 98,347 | Converge, Philippines |
| 31898 | US | 3.10% | 2,104 | 2,073 | 1,619 | 39 | 1,230 | Oracle Corp, United States |
| 203409 | IQ | 2.80% | 6,745 | 4,192 | 2,676 | 44 | 1,542 | Nawafeth Al-hadhara, Iraq |
| 55836 | IN | 2.50% | 6,075,237 | 5,084,127 | 3,114,217 | 35,837 | 1,400,178 | Reliance Jio, India |
| 9534 | MY | 1.60% | 163,667 | 161,851 | 116,154 | 1,223 | 73,955 | MAXIS Binarjang Berhad, Malaysia |
| 6661 | LU | 1.50% | 10,391 | 10,197 | 9,132 | 113 | 7,493 | LU – POST, Luxembourg |
| 37119 | AO | 1.40% | 63,226 | 62,103 | 41,113 | 308 | 21,624 | Unitel, Angola |
| 24432 | BD | 1.20% | 127,742 | 126,100 | 79,233 | 437 | 35,570 | TM International, Bangladesh |
| 199739 | IQ | 1.20% | 217,762 | 217,286 | 163,587 | 1,293 | 110,580 | Earthlink Telecommunications, Iraq |
| 14988 | BW | 1.00% | 8,730 | 8,616 | 7,533 | 65 | 6,533 | Botswana Telecommunications, Botswana |
| 48695 | SA | 0.90% | 1,742 | 1,741 | 1,395 | 10 | 1,144 | Etihad GO, Saudi Arabia |
| 212661 | OM | 0.90% | 12,634 | 12,574 | 9,765 | 62 | 7,163 | Vodafone-Oman, Oman |
| 37054 | MG | 0.70% | 19,313 | 19,117 | 13,628 | 62 | 8,476 | Telecom Malagasy, Madagascar |
| 43766 | SA | 0.70% | 158,163 | 157,292 | 131,327 | 74 | 108,836 | Mobile Telecommunication, Saudi Arabia |
| 29244 | BG | 0.70% | 33,217 | 33,072 | 23,809 | 102 | 14,943 | Telenor BG-AS, Bulgaria |
| 56665 | LU | 0.60% | 3,790 | 3,727 | 3,273 | 15 | 2,625 | Proximus, Luxembourg |
| 57293 | AZ | 0.50% | 19,186 | 19,133 | 14,531 | 48 | 10,412 | Telekom MMC, Azerbaijan |
| 327697 | RE | 0.40% | 1,883 | 1,876 | 1,450 | 4 | 1,045 | TELCO OI, Reunion |
De KSK-rotatie kan voor de in de lijst vermelde ISP-resolvers problemen opleveren. Als jouw ISP in Tabel 3 staat, is het raadzaam om dit te controleren met het testscript van Cloudflare en je ISP te vragen hun DNS-instellingen te herzien.
Het roteren van de root-sleutel
Terwijl ik dit schrijf op 8 oktober, staat de root-sleutel van het Domain Name System (DNS) gepland om te roteren op 11 oktober 2026.
Het roteren van de root-sleutel is 'bijzonder' omdat elke andere sleutel in DNS Security Extensions (DNSSEC) het concept heeft van een ouder-sleutel die wordt gebruikt om de authenticiteit te valideren. In het geval van een Zone-Signing Key (ZSK) is dat de Key-Signing Key (KSK) van de zone. In het geval van een KSK is dat de sleutel die wordt gebruikt om de vermeldingen in het bovenliggende domein te ondertekenen. Voor sleutels die ondergeschikt zijn aan een andere sleutel, is het voldoende dat de ouder-sleutel de nieuwe sleutelwaarde ondertekent (of, preciezer gezegd, een hash van het publieke sleutelcomponent, gepubliceerd in de ouder-zone als een ondertekend Delegation Signer (DS) resource record).
De root-sleutel is anders, aangezien deze geen ouder heeft. De manier waarop een nieuwe sleutel wordt geauthenticeerd door een DNS-resolver, is door de oude KSK de nieuwe KSK te laten ondertekenen ('oud ondertekent nieuw'). Vervolgens is een langere periode nodig om DNSSEC-validerende clients voldoende tijd te geven om de binnenkomende sleutel op te pikken en te vertrouwen. RFC 5011 — “Trust Anchor Update” biedt richtlijnen voor dit proces.
RFC 5011 stelt:
“De add hold-down time is 30 dagen of de vervaltijd van de oorspronkelijke TTL van de eerste trust point DNSKEY RRSet die de nieuwe sleutel bevatte, whichever is greater. Dit zorgt ervoor dat er ten minste twee gevalideerde DNSKEY RRSets die de nieuwe sleutel bevatten, door de resolver gezien MOETEN worden voordat de sleutel wordt geaccepteerd.”
De nieuwe KSK wordt toegevoegd aan de DNSKEY Resource Record Set (RRSet) van de root-zone, zodat validerende resolvers automatisch op de hoogte worden gesteld van deze nieuwe sleutel wanneer ze dit resource record ophalen. Zij dienen de sleutelwaarde in hun lokale cache van vertrouwde sleutels op te nemen wanneer de nieuwe sleutel gedurende het interval van de 30-daagse hold-down tijd is waargenomen. Als de sleutelrotatie deze minimale wachtperiodes voor elke fase van de rotatie naleeft, zou het gehele proces automatisch moeten verlopen.
De rotatie van 2026 is geen wijziging van het algoritme, maar simpelweg een wijziging van het private/publieke sleutelpaar. De binnenkomende KSK (KSK-2024) werd in juli 2024 gepubliceerd op de website van de Internet Assigned Numbers Authority (IANA) en in januari 2025 toegevoegd aan het DNSKEY resource record van de root-zone. IANA is van plan de KSK te roteren op 11 oktober 2026, waarna deze zal worden gebruikt om de digitale handtekening van het DNSKEY resource record van de root-zone te genereren.
Hoe verloopt deze KSK-rotatie? Hebben alle DNSSEC-validerende recursieve resolvers inmiddels KSK-2024 herkend en deze sleutel opgenomen in hun Trust Anchor (TA) sets? Hoe kunnen we dit gedrag meten?
Trust signal — RFC 8145 meting
Er zijn twee technieken die we kunnen gebruiken om in de DNS-infrastructuur van het internet te kijken en te ontdekken welke DNS-resolvers KSK-2024 aan hun lokale TA-set hebben toegevoegd.
De eerste wordt beschreven in RFC 8145 — “Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)”. Bij deze techniek bedraagt de resolver de sleuteltags van zijn vertrouwde sleutels in queries die naar de autoritatieve servers voor de root-zone worden gestuurd. Eén methode plaatst de tag-waarden van alle vertrouwde sleutels in een query-naam. Bijvoorbeeld, een query-naam van _ta-4f66-9728 geeft aan dat de resolver sleutels vertrouwt met tag-waarden 20326 en 38696. Een alternatieve methode is om de trust key tag-waarden in een edns-key-tag optie in queries te embedden.
Deze informatie is zichtbaar in het logboek van queries dat wordt beheerd door de operators van root-servers. Een analyse van dit RFC 8145-signaal ontvangen door een root-server operator (Verisign) is te zien in Figuur 1.
(Figuur 1 — Een steekproef van resolvers en welke KSK(s) zij in hun TA hebben geconfigureerd, per juli 2026. Bron: Verisign.)
Wat de data in Figuur 1 niet laat zien, is de populatie gebruikers die gebruikmaken van deze recursieve resolvers. Sommige DNSSEC-validerende recursieve resolvers bedienen miljoenen gebruikers, terwijl anderen, waaronder die op mijn laptop, er slechts één bedienen. Deze cijfers laten zien dat ongeveer 90% van de rapporterende resolvers KSK-2024 aan hun TA-set heeft toegevoegd. Dit vertaalt zich niet direct naar een schatting van de eindgebruikerspopulatie die zij bedienen, of het aantal gebruikers dat mogelijk beïnvloed kan worden door de KSK-rotatie.
RFC 8509 — “A Root Key Trust Anchor Sentinel for DNSSEC” stelt een andere aanpak voor, waarbij het signaal van de vertrouwde sleutels van een recursieve resolver wordt teruggestuurd naar de vragensteller (querier), in plaats van doorgestuurd te worden naar een root-zone server. Deze aanpak maakt gebruik van het meest linkse label van een DNS-query-naam en vereist dat de DNS-resolver dit label herkent en een respons genereert op basis van de set vertrouwde sleutels van de resolver, zoals getoond in Tabel 1.
Tabel 1 – RFC 8509 meetrespons
| Label | Sleutel wordt vertrouwd | Sleutel wordt niet vertrouwd |
|---|
root-key-sentinel-is-ta-<key-tag> | Retourneer origineel antwoord | Retourneer SERVFAIL |
root-key-sentinel-not-ta-<key-tag> | Retourneer SERVFAIL | Retourneer origineel antwoord |
Je kunt deze tests op je eigen DNS-infrastructuur uitvoeren met een webpagina die wordt beheerd door het DNS-team van Cloudflare.
Wij maken gebruik van het op advertenties (ad) gebaseerde meetsysteem van APNIC om deze queries dagelijks aan een verzameling eindgebruikers voor te leggen. We identificeren geen individuele validerende recursieve resolvers, maar kwantificeren de populatie eindgebruikers die zich uitsluitend achter DNSSEC-validerende resolvers bevinden waar de resolver KSK-2024 tot nu toe niet vertrouwt.
De test die we gebruiken bevat drie queries, zoals getoond in Tabel 2. Een resolver die is geconfigureerd om DNSSEC-validatie uit te voeren en dit Root Key TA Sentinel-mechanisme ondersteunt, zal DNS-responsen geven, eveneens getoond in Tabel 2.
Tabel 2 – RFC 8509 meetresponsen voor KSK-2024
| DNS label | Respons |
|---|
https://root-key-sentinel-is-ta-20326… | NOERROR |
https://root-key-sentinel-not-ta-20326… | SERVFAIL |
https://root-key-sentinel-is-ta-38696… | [Respons varieert per resolver] |
De eerste twee tests zijn bedoeld om te bepalen of de resolver dit Root Key TA Sentinel-mechanisme ondersteunt door te testen of hij KSK-2017 (key-tag 20326) vertrouwt. Als hij dat niet doet, zal hij in beide gevallen een gevalideerde respons teruggeven. Als hij responsen rapporteert volgens Tabel 2, kunnen we het monsterpunt classificeren als een ‘rapporterende gebruiker’. De derde query is bedoeld om te bepalen of de resolver KSK-2024 (key-tag 38696) in zijn lokale TA-set heeft geladen.
Resultaten
Een kleinschalige test met RIPE Atlas-probes op 5 oktober, die 2.900 verschillende Autonomous Systems (AS'en) besloeg, vond 1.230 probes met een resolver-gedrag dat consistent is met een Root Key TA Sentinel die de nieuwe KSK heeft geladen. 47 probes vertoonden een resolver-gedrag dat consistent is met het niet hebben geladen van de nieuwe KSK-waarde in lokale vertrouwde sleutelcollecties.
We hebben een grotere set op advertenties gebaseerde metingen uitgevoerd tussen mei en juli 2026, en deze hervat in begin oktober 2026, met gemiddeld ongeveer 16 miljoen tests per dag.
De dagelijkse resultaten van deze meting van de adoptie van KSK-2024 als TA zijn te zien in Figuur 2.
(Figuur 2 — Dagelijkse meting van de adoptie van KSK-2024 als TA met behulp van RFC 8509 Sentinel tijdens 2026.)
Deze grotere steekproef geeft aan dat ongeveer 70% van de tests die RFC 8509 lijken te ondersteunen, rapporteren dat KSK-2024 is geladen als een vertrouwde sleutel.
(Figuur 3 — Dagelijkse meting van RFC 8509 Sentinel-ondersteuning tijdens 2026.)
Hoewel het meetplatform 16 miljoen tests per dag uitvoert, laten slechts ongeveer 6 miljoen tests per dag zien dat het geteste eindsysteem zich achter DNSSEC-validerende recursieve resolvers bevindt. Ongeveer 1,8 miljoen tests per dag geven een duidelijk signaal dat ze het RFC 8509 Key Sentinel-mechanisme ondersteunen.
Deze gemiddelde getallen zijn weinig behulpzaam, omdat ze een aanzienlijke variatie maskeren. Wat nuttiger zou zijn, is een lijst van die netwerken waar de RFC 8509 Root Key TA Sentinel-tests aangeven dat de binnenkomende sleutel niet is geladen in de lokale vertrouwde sleutelset.
Tabel 3 toont de 50 netwerken met het laagste acceptatiepercentage van KSK-2024. Ik heb deze lijst gefilterd zodat alleen netwerken worden getoond waar we 1.000 of meer tests hebben waargenomen die aantoonden dat hun DNS-resolvers het Root Key TA Sentinel-mechanisme ondersteunden.
Tabel 3 — Lijst van top 50 ISP's met lage KSK-2024 trust-signalen
| ASN | Land | KSK-2024 (%) | Tests | Validerend | RFC 8509 | KSK-2024 (count) | Not KSK-2024 (count) | Naam |
|---|
| 262202 | CR | 49.40% | 9,441 | 9,343 | 2,201 | 469 | 481 | Telefonica de Costa Rica, Costa Rica |
| 328169 | SZ | 48.90% | 4,694 | 4,687 | 1,199 | 276 | 288 | Swazi Mobile, Swaziland |
| 328341 | ZA | 48.90% | 2,551 | 2,522 | 1,352 | 284 | 297 | Capricom Networks, South Africa |
| 17470 | LK | 48.70% | 15,011 | 11,749 | 2,952 | 717 | 756 | Hutchison Telecoms, Sri Lanka |
| 9335 | TH | 48.40% | 4,905 | 4,877 | 1,355 | 299 | 319 | National Telco, Thailand |
| 45925 | BD | 48.20% | 7,886 | 7,811 | 2,046 | 465 | 499 | Teletalk, Bangladesh |
| 29544 | MR | 47.90% | 41,149 | 40,758 | 8,032 | 1,842 | 2,003 | Mauritanian Telecommunication, Mauritania |
| 30990 | DJ | 47.40% | 9,472 | 9,393 | 2,701 | 641 | 711 | Dibjouti Telecom, Djiboutit |
| 329129 | LY | 46.80% | 7,879 | 7,843 | 1,790 | 384 | 436 | Libya Tech, Lybia |
| 136336 | IN | 46.00% | 8,113 | 6,972 | 1,818 | 353 | 414 | Thamizhaga, India |
| 9658 | PH | 45.60% | 6,920 | 6,293 | 2,062 | 555 | 661 | Eastern Telecoms, Philippines |
| 135300 | MM | 45.40% | 5,813 | 4,600 | 1,150 | 228 | 274 | Myanmar Broadband, Myanmar |
| 205368 | AM | 38.60% | 4,227 | 4,209 | 2,349 | 536 | 852 | Fnet, Armenia |
| 24812 | UA | 32.00% | 10,791 | 3,437 | 1,322 | 205 | 436 | HomeNet, Ukraine |
| 39065 | UA | 26.10% | 1,701 | 1,666 | 1,238 | 193 | 546 | Southern Telecommunication s, Ukraine |
| 15108 | US | 16.40% | 17,966 | 17,209 | 15,036 | 2,014 | 10,282 | Allo Comms, United States |
| 132199 | PH | 13.10% | 73,176 | 71,705 | 35,310 | 2,915 | 19,310 | Globe Telecom, Philippines |
| 33915 | NL | 12.70% | 170,615 | 19,642 | 13,292 | 1,328 | 9,105 | Vodafone Libertel, Netherlands |
| 5056 | US | 10.70% | 7,519 | 6,933 | 4,883 | 427 | 3,556 | Aureon Network Services, United States |
| 12969 | IS | 10.00% | 4,567 | 4,520 | 3,954 | 331 | 2,979 | Vodafone, Iceland |
| 327931 | DZ | 9.00% | 160,973 | 17,701 | 9,705 | 357 | 3,627 | Optimum Telecom, Algeria |
| 58895 | PK | 8.20% | 13,757 | 5,584 | 3,034 | 128 | 1,432 | Ebone, Pakistan |
| 16019 | CZ | 8.20% | 45,089 | 43,692 | 32,266 | 1,885 | 21,166 | Vodafone-CZ, Czechia |
| 38195 | AU | 6.20% | 24,038 | 19,612 | 16,004 | 787 | 11,931 | Superloop, Australia |
| 54345 | US | 5.20% | 2,320 | 2,089 | 1,050 | 366 | 61 | Jackson Energy, United States |
| 203214 | IQ | 4.50% | 165,409 | 153,024 | 115,657 | 3,636 | 76,631 | HulumTele , Iraq |
| 205889 | IQ | 4.50% | 4,836 | 1,750 | 1,102 | 30 | 636 | Giga Nineveh, Iraq |
| 5690 | CA | 4.40% | 1,983 | 1,936 | 1,659 | 61 | 1,323 | Vianet, Canada |
| 56207 | PH | 4.20% | 12,110 | 11,720 | 6,860 | 149 | 3,399 | ComClark, Philippines |
| 4775 | PH | 4.00% | 272,137 | 268,811 | 174,084 | 4,439 | 105,397 | Globe Telecoms, Philippines |
| 15547 | CH | 4.00% | 3,011 | 2,967 | 2,508 | 78 | 1,865 | Netplus, Switzerland |
| 47794 | SA | 3.90% | 6,665 | 6,462 | 4,693 | 114 | 2,814 | Etihad GO, Saudi Arabia |
| 17639 | PH | 3.70% | 259,256 | 255,140 | 165,934 | 3,830 | 98,347 | Converge, Philippines |
| 31898 | US | 3.10% | 2,104 | 2,073 | 1,619 | 39 | 1,230 | Oracle Corp, United States |
| 203409 | IQ | 2.80% | 6,745 | 4,192 | 2,676 | 44 | 1,542 | Nawafeth Al-hadhara, Iraq |
| 55836 | IN | 2.50% | 6,075,237 | 5,084,127 | 3,114,217 | 35,837 | 1,400,178 | Reliance Jio, India |
| 9534 | MY | 1.60% | 163,667 | 161,851 | 116,154 | 1,223 | 73,955 | MAXIS Binarjang Berhad, Malaysia |
| 6661 | LU | 1.50% | 10,391 | 10,197 | 9,132 | 113 | 7,493 | LU – POST, Luxembourg |
| 37119 | AO | 1.40% | 63,226 | 62,103 | 41,113 | 308 | 21,624 | Unitel, Angola |
| 24432 | BD | 1.20% | 127,742 | 126,100 | 79,233 | 437 | 35,570 | TM International, Bangladesh |
| 199739 | IQ | 1.20% | 217,762 | 217,286 | 163,587 | 1,293 | 110,580 | Earthlink Telecommunications, Iraq |
| 14988 | BW | 1.00% | 8,730 | 8,616 | 7,533 | 65 | 6,533 | Botswana Telecommunications, Botswana |
| 48695 | SA | 0.90% | 1,742 | 1,741 | 1,395 | 10 | 1,144 | Etihad GO, Saudi Arabia |
| 212661 | OM | 0.90% | 12,634 | 12,574 | 9,765 | 62 | 7,163 | Vodafone-Oman, Oman |
| 37054 | MG | 0.70% | 19,313 | 19,117 | 13,628 | 62 | 8,476 | Telecom Malagasy, Madagascar |
| 43766 | SA | 0.70% | 158,163 | 157,292 | 131,327 | 74 | 108,836 | Mobile Telecommunication, Saudi Arabia |
| 29244 | BG | 0.70% | 33,217 | 33,072 | 23,809 | 102 | 14,943 | Telenor BG-AS, Bulgaria |
| 56665 | LU | 0.60% | 3,790 | 3,727 | 3,273 | 15 | 2,625 | Proximus, Luxembourg |
| 57293 | AZ | 0.50% | 19,186 | 19,133 | 14,531 | 48 | 10,412 | Telekom MMC, Azerbaijan |
| 327697 | RE | 0.40% | 1,883 | 1,876 | 1,450 | 4 | 1,045 | TELCO OI, Reunion |
De KSK-rotatie kan voor de in de lijst vermelde ISP-resolvers problemen opleveren. Als jouw ISP in Tabel 3 staat, is het raadzaam om dit te controleren met het testscript van Cloudflare en je ISP te vragen hun DNS-instellingen te herzien.
Groetjes,