Rolling the Root Key

# Rolling the root key | APNIC Blog Source: [https://blog.apnic.net/2026/10/09/rolling-the-root-key-2/](https://blog.apnic.net/2026/10/09/rolling-the-root-key-2/)  The root key is special\. Image by[Alicja](https://pixabay.com/users/_alicja_-5975425/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3071329)from[Pixabay](https://pixabay.com//?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=3071329)\. As I write this on 8 October, the root key of the Domain Name System \(DNS\) is scheduled to roll on 11 October 2026\. Rolling the root key is ‘special’ because every other key in DNS Security Extensions \(DNSSEC\) has the notion of a parent key that is used to validate its authenticity\. In the case of a Zone\-Signing Key \(ZSK\), it’s the zone’s Key\-Signing Key \(KSK\)\. In the case of a KSK, it’s the key used to sign the entries in the parent domain\. For keys that are subordinate to another key, all that’s required is for the parent key to sign across the new key value \(or, more precisely, a hash of the public key component, published in the parent zone as a signed Delegation Signer \(DS\) resource record\)\. The root key is different, as it has no parent\. The way a new key is authenticated by a DNS resolver is by having the old KSK sign across the new KSK \(‘old signs new’\)\. Then an extended period is required to allow DNSSEC\-validating clients sufficient time to pick up and trust the incoming key\.[RFC 5011](https://www.rfc-editor.org/info/rfc5011/)— “Trust Anchor Update” provides guidance for this process\. It states: > “The add hold\-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater\. This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key’s acceptance\.” [RFC 5011](https://www.rfc-editor.org/info/rfc5011/) The new KSK is added to the root zone’s`DNSKEY`Resource Record Set \(RRSet\), so validating resolvers learn of this new key automatically when they retrieve this resource record\. They are supposed to add the key value into their local cache of trusted keys when the new key has been observed for the 30\-day hold\-down time interval\. So if the key roll observes these minimum hold periods for each stage of the key roll, then the entire process should be automatic\. The 2026 key roll is not a change of algorithm, but simply a change of the private/public key pair\. The incoming KSK \(`KSK\-2024`\) was published on the[Internet Assigned Numbers Authority \(IANA\) website](https://www.iana.org/dnssec/files)in July 2024, and added to the root zone’s`DNSKEY`resource record in January 2025\. IANA plans to roll the KSK on 11 October 2026, when it will be used to generate the root zone’s`DNSKEY`resource record digital signature\. How are we going with this KSK roll? Have all DNSSEC\-validating recursive resolvers learned of`KSK\-2024`by now and incorporated this key into their Trust Anchor \(TA\) sets? How can we measure this behaviour? ## Trust signal — RFC 8145 measurement There are two techniques we can use to peer into the Internet’s DNS infrastructure and find which DNS resolvers have added`KSK\-2024`to their local TA set\. The first is described in[RFC 8145](https://www.rfc-editor.org/rfc/rfc8145.html)— “Signaling Trust Anchor Knowledge in DNS Security Extensions \(DNSSEC\)”\. In this technique, the resolver embeds the key tags of its trusted keys in queries that are sent towards the authoritative servers for the root zone\. One method places the tag values of all trusted keys in a query name\. For example, a query name of ‘`\_ta\-4f66\-9728`‘ indicates that the resolver trusts keys with tag values 20326 and 38696\. An alternative method is to embed the trust key tag values into an`edns\-key\-tag`option in queries\. This information is visible in the log of queries managed by the operators of root servers\. An analysis of this RFC 8145 signal received by a root server operator \(Verisign\) is shown in Figure 1\. [](https://blog.apnic.net/wp-content/uploads/2026/10/Screenshot-2026-10-09-at-9.31.56-am.png)Figure 1— A sampling of resolvers and which KSK\(s\) they have configured in their TA, as of July 2026\. Source:[Verisign](https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-updates-observations/)\.What the data in Figure 1 does not show is the population of users who are using these recursive resolvers\. Some DNSSEC\-validating recursive resolvers serve millions of users, while others, including the one on my laptop, serve just one\. These figures show that around 90% of reporting resolvers have added`KSK\-2024`to their TA set\. This does not translate directly into an estimate of the end\-user population they serve, or the number of users who may be affected by the KSK roll\. [RFC 8509](https://www.rfc-editor.org/rfc/rfc8509)— “A Root Key Trust Anchor Sentinel for DNSSEC” proposes a different approach, where the signal of a recursive resolver’s trusted keys is folded back and sent to the querier, rather than onward towards a root zone server\. The approach involves the leftmost label of a DNS query name and requires the DNS resolver to recognize this label and generate a response based on the resolver’s set of trusted keys, as shown in Table 1\. **Label****Key is trusted****Key is not trusted**`root\-key\-sentinel\-is\-ta\-<key\-tag\>`Return original answerReturn`SERVFAIL``root\-key\-sentinel\-not\-ta\-<key\-tag\>`Return`SERVFAIL`Return original answerTable 1 – RFC 8509 measurement responses\.You can run these tests on your own DNS infrastructure with a[web page operated by the DNS team at Cloudflare](https://dnstest.dev/ksk-2024)\. We use[APNIC’s advertisement \(ad\)\-based measurement system](https://ad.labs.apnic.net/)to pose these queries to a collection of end users every day\. We do not identify individual validating recursive resolvers, but rather quantify the population of end users who are located exclusively behind DNSSEC\-validating resolvers where the resolver has so far failed to trust`KSK\-2024`\. The test we are using has three queries, as shown in Table 2\. A resolver that is configured to perform DNSSEC validation and supports this Root Key TA Sentinel mechanism will provide DNS responses, also shown in Table 2\. **DNS label****Response**https://root\-key\-sentinel\-is\-ta\-20326…`NOERROR`https://root\-key\-sentinel\-not\-ta\-20326…`SERVFAIL`https://root\-key\-sentinel\-is\-ta\-38696…Table 2 – RFC 8509 measurement responses for`KSK\-2024`\.The first two tests are intended to determine if the resolver supports this Root Key TA Sentinel mechanism by testing if it trusts`KSK\-2017`\(`key\-tag 20326`\)\. If it does not, it will return a validated response in both cases\. If it does report responses as per Table 2, then we can classify the sample point as a ‘reporting user’\. The third query is intended to determine if the resolver has loaded`KSK\-2024`\(`key\-tag 38696`\) into its local TA set\. ## Results A small\-scale test using RIPE Atlas probes on 5 October, covering 2,900 distinct Autonomous Systems \(ASes\), found 1,230 probes with a resolver behaviour consistent with a Root Key TA Sentinel that has loaded the new KSK\. 47 probes showed resolver behaviour consistent with not having loaded the new KSK value into local trusted key collections\. We conducted a larger set of ad\-based measurements between May and July 2026, and resumed them in early October 2026, averaging around 16 million tests per day\. The daily results of this measurement of the adoption of`KSK\-2024`as a TA are shown in Figure 2\. [](https://blog.apnic.net/wp-content/uploads/2026/10/Screenshot-2026-10-09-at-9.43.00-am.png)Figure 2 — Daily measurement of adoption of`KSK\-2024`as a TA using RFC 8509 Sentinel during 2026\.This larger sample indicates that around 70% of tests that appear to support RFC 8509 report that`KSK\-2024`has been loaded as a trusted key\. Figure 3 — Daily measurement of RFC 8509 Sentinel support during 2026\.While the measurement platform undertakes 16M tests per day, only around 6M tests per day show that the tested end system lies behind DNSSEC\-validating recursive resolvers\. Around 1\.8M tests per day provide a clear signal that they support the RFC 8509 Key Sentinel mechanism\. These average numbers are less than helpful, as they hide a significant variation\. What would be more useful is to list those networks where the RFC 8509 Root Key TA Sentinel tests indicate that the incoming key has not been loaded into the local trusted key set\. Table 3 shows the 50 networks with the lowest rate of acceptance of KSK\-2024\. I’ve filtered this list so that it only shows those networks where we observed 1,000 or more tests that showed that their DNS resolvers supported the Root Key TA Sentinel mechanism\. **ASN****Country code****KSK\-2024 \(%\)****Tests****Validating****RFC 8509****KSK\-2024 \(count\)****Not KSK\-2024 \(count\)****Name**262202CR49\.40%9,4419,3432,201469481Telefonica de Costa Rica, Costa Rica328169SZ48\.90%4,6944,6871,199276288Swazi Mobile, Swaziland328341ZA48\.90%2,5512,5221,352284297Capricom Networks, South Africa17470LK48\.70%15,01111,7492,952717756Hutchison Telecoms, Sri Lanka9335TH48\.40%4,9054,8771,355299319National Telco, Thailand45925BD48\.20%7,8867,8112,046465499Teletalk, Bangladesh29544MR47\.90%41,14940,7588,0321,8422,003Mauritanian Telecommunication, Mauritania30990DJ47\.40%9,4729,3932,701641711Dibjouti Telecom, Djiboutit329129LY46\.80%7,8797,8431,790384436Libya Tech, Lybia136336IN46\.00%8,1136,9721,818353414Thamizhaga, India9658PH45\.60%6,9206,2932,062555661Eastern Telecoms, Philippines135300MM45\.40%5,8134,6001,150228274Myanmar Broadband, Myanmar205368AM38\.60%4,2274,2092,349536852Fnet, Armenia24812UA32\.00%10,7913,4371,322205436HomeNet, Ukraine39065UA26\.10%1,7011,6661,238193546Southern Telecommunication s, Ukraine15108US16\.40%17,96617,20915,0362,01410,282Allo Comms, United States132199PH13\.10%73,17671,70535,3102,91519,310Globe Telecom, Philippines33915NL12\.70%170,61519,64213,2921,3289,105Vodafone Libertel, Netherlands5056US10\.70%7,5196,9334,8834273,556Aureon Network Services, United States12969IS10\.00%4,5674,5203,9543312,979Vodafone, Iceland327931DZ9\.00%160,97317,7019,7053573,627Optimum Telecom, Algeria58895PK8\.20%13,7575,5843,0341281,432Ebone, Pakistan16019CZ8\.20%45,08943,69232,2661,88521,166Vodafone\-CZ, Czechia38195AU6\.20%24,03819,61216,00478711,931Superloop, Australia54345US5\.20%2,3202,0891,05036661Jackson Energy, United States203214IQ4\.50%165,409153,024115,6573,63676,631HulumTele , Iraq205889IQ4\.50%4,8361,7501,10230636Giga Nineveh, Iraq5690CA4\.40%1,9831,9361,659611,323Vianet, Canada56207PH4\.20%12,11011,7206,8601493,399ComClark, Philippines4775PH4\.00%272,137268,811174,0844,439105,397Globe Telecoms, Philippines15547CH4\.00%3,0112,9672,508781,865Netplus, Switzerland47794SA3\.90%6,6656,4624,6931142,814Etihad GO, Saudi Arabia17639PH3\.70%259,256255,140165,9343,83098,347Converge, Philippines31898US3\.10%2,1042,0731,619391,230Oracle Corp, United States203409IQ2\.80%6,7454,1922,676441,542Nawafeth Al\-hadhara, Iraq55836IN2\.50%6,075,2375,084,1273,114,21735,8371,400,178Reliance Jio, India9534MY1\.60%163,667161,851116,1541,22373,955MAXIS Binarjang Berhad, Malaysia6661LU1\.50%10,39110,1979,1321137,493LU – POST, Luxembourg37119AO1\.40%63,22662,10341,11330821,624Unitel, Angola24432BD1\.20%127,742126,10079,23343735,570TM International, Bangladesh199739IQ1\.20%217,762217,286163,5871,293110,580Earthlink Telecommunications, Iraq14988BW1\.00%8,7308,6167,533656,533Botswana Telecommunications, Botswana48695SA0\.90%1,7421,7411,395101,144Etihad GO, Saudi Arabia212661OM0\.90%12,63412,5749,765627,163Vodafone\-Oman, Oman37054MG0\.70%19,31319,11713,628628,476Telecom Malagasy, Madagascar43766SA0\.70%158,163157,292131,327744108,836Mobile Telecommunication, Saudi Arabia29244BG0\.70%33,21733,07223,80910214,943Telenor BG\-AS, Bulgaria56665LU0\.60%3,7903,7273,273152,625Proximus, Luxembourg57293AZ0\.50%19,18619,13314,5314810,412Telekom MMC, Azerbaijan327697RE0\.40%1,8831,8761,45041,045TELCO OI, ReunionTable 3 — List of top 50 ISPs with low`KSK\-2024`trust signals\.The KSK roll may present the listed ISP resolvers with some problems\. If your ISP is listed in Table 3, then you may want to follow up using[Cloudflare’s test script](https://dnstest.dev/ksk-2024/)and ask your ISP to review their DNS settings\. --- The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC\. Please note a[Code of Conduct](https://blog.apnic.net/?p=395)applies to this blog\.