Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — What Happens in 87 Days
What's Actually in the Root Zone Right Now
The Identity of the Two Keys — the IANA Trust Anchor File
8 Phases, 6 Years
RFC 5011 — Why Most People Don't Have to Do Anything
The October 11 Cliff — and a Common Misconception
The 2017 Lesson — What the Telemetry Actually Revealed
Is My Resolver Ready Right Now — and Why Checking Is Harder Than It Sounds
What's the Adoption Rate Right Now — There's No Published Number
What This Rollover Does Not Change — the Algorithm
The Algorithm Rollover's Paradox — the 1536-Bit Debate
When This Isn't Your Problem
Closing
References

Introduction — What Happens in 87 Days

On October 11, 2026, the DNS root zone's Key Signing Key (KSK) changes from KSK-2017 to KSK-2024. Today is July 16, so that's 87 days away.

That sentence reads two ways. If you're using a resolver that doesn't do validation, this isn't news — nothing happens. If you're running a resolver that does DNSSEC validation and its trust anchor hasn't updated, that resolver starts returning SERVFAIL for every name on that day. If you can't trust the root, you can't trust anything under it.

ICANN's FAQ puts this diplomatically: if you left DNSSEC turned on without being ready, you could see "significant financial impact," end users would see an error on every domain lookup, and that would translate into support calls.

This post starts by opening up the root zone directly, rather than with an abstract explanation.

What's Actually in the Root Zone Right Now

You can just ask a root server directly. Below is a run I did myself on July 16, 2026.

$ dig . DNSKEY +dnssec +norec @a.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
.  172800  IN  DNSKEY  256 3 8 AwEAAeCYD6Z7WWKVLeuWgowKP+3g...   ; ZSK
.  172800  IN  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WS...   ; KSK-2017
.  172800  IN  DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv...   ; KSK-2024
.  172800  IN  RRSIG   DNSKEY 8 0 172800 20260801000000 (
                                         20260711000000 20326 . ...

;; MSG SIZE  rcvd: 1139

There are a few things worth reading here.

There are four records: one ZSK with flag 256, two KSKs with flag 257 (KSK-2017 and KSK-2024), and one RRSIG. Both KSKs have already been sitting side by side in the zone for years.

But there's only one RRSIG, and the key tag that signed it is 20326 — that's KSK-2017. In other words, as of today the only key signing the root DNSKEY set is still KSK-2017. KSK-2024 is carried in the zone but hasn't signed anything yet. That's exactly what changes on October 11: the signer moves from 20326 to 38696.

You can also see the signature validity window: from 20260711000000 to 20260801000000, i.e., July 11 to August 1. Root KSK signatures are pre-generated at the quarterly key ceremony and published slot by slot.

And the response size is 1139 bytes. That number comes back later.

The Identity of the Two Keys — the IANA Trust Anchor File

If you fetch the trust anchor file IANA publishes and actually parse it, this is what you get.

id=Kjqmt7v  tag=19036  alg=8  validFrom=2010-07-15  validUntil=2019-01-11  (no public key)
id=Klajeyz  tag=20326  alg=8  validFrom=2017-02-02  validUntil=(none)     RSA 2048-bit, e=65537
id=Kmyv6jo  tag=38696  alg=8  validFrom=2024-07-18  validUntil=(none)     RSA 2048-bit, e=65537

Three things to note.

First, the file contains three keys. 19036 is KSK-2010, retired in 2019, with a validUntil set. If you write your own code to parse this file, you must check validFrom and validUntil. A naive implementation that "loads every key in the file as a trust anchor" will pull in an already-dead key.

Second, KSK-2024's validFrom is 2024-07-18. That's the date it appeared in the IANA file, not the date it was published in the root zone. This date matters again later.

Third, and most important — all three keys are algorithm 8. Decode the public keys directly and both KSK-2017 and KSK-2024 turn out to be RSA 2048-bit keys with exponent 65537. So this rollover changes the key, but the cryptographic algorithm stays the same. More on that separately, later.

8 Phases, 6 Years

According to ICANN's FAQ (dated May 22, 2026), the KSK lifecycle consists of 8 phases spanning about 6 years, with the key actually in use for signing for about 3 of those years. Each phase is tied to a key ceremony.

Phase A  Key Generation      April 2024      Generate KSK-2024 at the first key management facility
Phase B  Key Duplication     July 2024       Copy to the second facility -> becomes eligible for operational use
Phase C  Initial Signing     October 2024    Pre-generate the signatures Phase D will use
Phase D  Publication         February 2025   KSK-2024 appears in the root zone
Phase E  Rollover            2026 Q4         Only KSK-2024 signs the root zone   <- 2026-10-11
Phase F  Revoke              2027 Q1         Remove KSK-2017 from the root zone
Phase G  Delete 1            2027 Q2         Destroy KSK-2017 in the first facility's HSM
Phase H  Delete 2            2027 Q3         Destroy KSK-2017 in the second facility's HSM

There's a small but honest discrepancy worth flagging here. ICANN's FAQ lists Phase D (publication) as "February 2025," but Verisign, which operates the root zone, states the date KSK-2024 appeared in the root zone as January 11, 2025. Verisign's date lines up with its own data — it matches, precisely, the observation (discussed later) that adoption spiked starting February 10, right after the 30-day hold-down. The date it actually landed in the zone is correctly January 11.

So why does it always land on October 11, specifically? Not a coincidence. ICANN's algorithm rollover proposal explains the structure: each quarter is divided into 9 publication slots of about 10 days each, and a key change is published on the 11th day of the quarter — slot 2. Q4 starts October 1, so slot 2 is October 11. That's why the rollover originally scheduled for 2017, and the one actually carried out in 2018, both landed on October 11.

RFC 5011 — Why Most People Don't Have to Do Anything

The root zone has no parent. .com's key is vouched for by a DS record in the root zone, but there's no zone above the root to vouch for its key. So resolvers have to configure the root KSK directly as a trust anchor. So what happens when that key changes? That's RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors, now an Internet Standard).

Here's how it works. When a new KSK first appears in the trust point's DNSKEY set, the resolver remembers it as a candidate. If that key continues to exist, validly signed, an Add Hold-Down timer starts running. To quote RFC 5011's definition directly, the Add Hold-Down time is "30 days, or the original TTL expiration time of the first trust point DNSKEY RRSet that contained the new key, whichever is longer." The point of this condition is explicit: to make the resolver see at least two validated DNSKEY sets containing the new key before it accepts it. Since the root DNSKEY's TTL is 172800 seconds (2 days) per the dig output above, in practice 30 days is what governs.

After 30 days, the resolver adds the new key to its permanent trust anchor configuration. The operator did nothing.

This is why this rollover is a non-event for most people. KSK-2024 has been in the root zone since January 2025, and resolvers implementing RFC 5011 already accepted it back in February 2025. Even when the signer changes on October 11, those resolvers already know the new key, so nothing happens.

RFC 5011 has two more provisions worth knowing. One: a compliant resolver must be able to manage at least 5 SEP keys per trust point. The other is the revocation rule, which is the heart of the next section.

The October 11 Cliff — and a Common Misconception

I've seen this claim repeated in several posts about this rollover: "KSK-2017 stays in the DNSKEY set even after October 11 and isn't revoked until January 2027, so an operator who missed the deadline still has a last chance to fix it before then."

This is wrong. More precisely: the part about there being time is correct, but the implication that "it keeps working until then" is not.

Follow the DNSSEC validation chain and you can see why. For a resolver to trust the root DNSKEY set, one of the RRSIGs attached to that set has to be signed by a key it holds as a trust anchor. ICANN's FAQ describes Phase E in a single sentence: "Only KSK-2024 is used to sign the root zone." That means from October 11 on, there's only one RRSIG on the DNSKEY set — the one from 38696.

For a resolver that only trusts KSK-2017, seeing KSK-2017 inside the DNSKEY set does it no good at all — it has no way to validate that set, because there's no RRSIG signed by a key it knows. That resolver dies right on October 11. Not January 2027.

So why leave KSK-2017 in the zone at all? The answer is in RFC 5011's revocation rule. RFC 5011 is designed so that simply dropping a key from the set does not count as revocation. To quote the document's own explanation, without a revoke bit, any key B could invalidate A simply by publishing a key set that omits A — to prevent that, the mechanism added a requirement that a DNSKEY can only be revoked by someone who knows that DNSKEY's private key.

Specifically, RFC 5011 stipulates: for a key to be considered revoked, the resolver has to see it inside a self-signed RRSet with the REVOKE bit set to 1. And a self-signed RRSet means a set that contains that DNSKEY and carries an RRSIG that validates against that same key.

So for KSK-2017 to be properly revoked in Q1 2027, the DNSKEY set at that point has to be signed by both KSK-2024 and the revoked KSK-2017, so that an RFC 5011 resolver still holding KSK-2017 as a trust anchor can see that revocation and delete it from its own store. KSK-2017 staying in the zone after October is so that it can be properly revoked later, not to keep a resolver that failed to update alive.

As a side effect, this adds one more RSA 2048 signature to the DNSKEY response (256 bytes of signature data alone), meaning today's measured 1139 bytes grows by that much. Response size is the star of the second half of this post.

One more RFC 5011 detail: a DNSKEY with the REVOKE bit set has a different fingerprint than without it — meaning the key tag changes. Monitoring written to expect the tag 20326 to stay the same will misbehave during the revocation phase.

The 2017 Lesson — What the Telemetry Actually Revealed

To understand why this rollover plan is so deliberately slow — nearly two years of pre-publication, a 6-year lifecycle — you have to go back to 2017.

The original rollover from KSK-2010 to KSK-2017 was scheduled for October 11, 2017. Then, on September 27, ICANN announced a postponement. Read the announcement from that time directly and you can see the reasoning behind it.

Based on estimates of the number of internet users behind DNSSEC-validating resolvers, ICANN stated that roughly one in four global internet users — about 750 million people — could be affected by this rollover. (This is an exposure estimate, not a prediction of how many would actually be harmed — the original wording itself says "could be affected.") And it gave this reason for the postponement: newly obtained data showed that a significant number of the resolvers used by ISPs and network operators were not yet ready.

The announcement also explains what that "newly obtained data" was: a very recently added DNS protocol feature that lets a resolver report the key it has configured back to a root server. It's not named explicitly, but it's RFC 8145 (Signaling Trust Anchor Knowledge in DNSSEC). It came out in April 2017 — so within five months of the standard being published, the data it generated stopped the largest cryptographic key rollover in the world.

But the real lesson is in the next sentence. ICANN said there could be several reasons operators didn't have the new key, and among them wrote: a recently discovered issue in one widely used resolver program appears to prevent it from automatically updating the key the way it should, and the cause was still under investigation.

That's the key point. What the telemetry revealed was not "operators were lazy." It was that software implementing RFC 5011 automated updates had a bug. The automation was switched on, it was silently not working, and without the telemetry, nobody would have found out until October 11.

Göran Marby, ICANN's CEO at the time, put it this way: they chose to proceed cautiously and sensibly rather than force the rollover through on the announced October 11 date.

The rollover finally happened exactly one year later, on October 11, 2018.

Is My Resolver Ready Right Now — and Why Checking Is Harder Than It Sounds

The most reliable way is to ask your resolver directly. For BIND, that's rndc managed-keys status; for Unbound, open the root anchor file (usually root.key) and check whether 38696 is in there. If you have access to your own infrastructure, this is the answer.

For probing a resolver you can't access directly — say, an upstream ISP resolver — from the outside, there's RFC 8509 (A Root Key Trust Anchor Sentinel for DNSSEC). It's a mechanism that lets a client determine, from its own side, whether a resolver holds a specific key as a trust anchor.

Here's how it works. If the leftmost label of the query name is root-key-sentinel-is-ta-<key-tag> or root-key-sentinel-not-ta-<key-tag>, the resolver applies special handling. The RFC gives this truth table.

Label       | Trusts the key            | Does not trust the key
------------------------------------------------------------------
is-ta       | Returns original answer   | Returns SERVFAIL
not-ta      | Returns SERVFAIL          | Returns original answer

Two things to watch for. The key tag must be zero-padded to five digits (per the RFC's example, 42 becomes 00042). 38696 and 20326 happen to already be five digits, so they're used as-is. And the special handling only fires if every precondition is met: the response has to go through DNSSEC validation, the validation result has to be Secure, the CD bit has to be off, QTYPE has to be A or AAAA, and OPCODE has to be QUERY. If even one of those is off, the resolver leaves the response untouched.

These preconditions trip you up in practice. When I first tested by prefixing sentinel labels under iana.org, every result came back NXDOMAIN — since that's a nonexistent name, the sentinel condition never triggered. You need an underlying name that actually returns a Secure response.

So I set up a proper control group and re-measured. Key tag 00000 — guaranteed not to exist — serves as the control. If the sentinel is actually firing, is-ta-00000 must return SERVFAIL. If it doesn't, that measurement proves nothing.

Here's what I actually measured on July 16, 2026.

Quad9 (9.9.9.9)
  is-ta-38696   x12  ->  NOERROR 12
  is-ta-00000   x12  ->  SERVFAIL 9,  NOERROR 3      <- mixed results
  not-ta-38696  x14  ->  SERVFAIL 5,  NOERROR 9      <- mixed results

Cloudflare (1.1.1.1)
  is-ta-00000   x14  ->  NOERROR 14                  <- no sentinel behavior observed

Google (8.8.8.8)
  is-ta-00000   x14  ->  NOERROR 14                  <- no sentinel behavior observed

Here's how to read it.

The fact that is-ta-00000 returned SERVFAIL on Quad9 at least once is evidence that some backends actually implement RFC 8509 (the control passed). On those backends, not-ta-38696 being SERVFAIL means, by the truth table, that they trust KSK-2024 — and that's consistent with is-ta-38696 always returning NOERROR. All three results agree with each other.

But honestly, the real lesson of this measurement isn't that conclusion — it's the fact that the results came back mixed. Repeating the same query alternated between SERVFAIL and NOERROR. That's explained by there being multiple backend instances behind one anycast address, only some of which implement the sentinel. In fact, when I queried just once each the first time, I got a clean truth table and nearly drew a conclusion from it. Repeating it, it didn't reproduce.

So the fair summary is: the sentinel is a per-resolver-instance test, and it is not a decisive diagnostic tool against large anycast resolvers. A single query proves nothing. You need, at minimum, repeated measurements and a control key tag. And the fact that no sentinel behavior was observed on Cloudflare or Google does not at all mean they don't trust KSK-2024 — it just means this method can't tell.

What's the Adoption Rate Right Now — There's No Published Number

So what percentage of resolvers worldwide trust KSK-2024?

The latest published figure is from a post Verisign's Duane Wessels wrote on March 19, 2025: as of March 3, 2025, 91.3 percent of resolvers signaled that they trusted KSK-2024. This number is vendor-measured, and the conditions need to be made explicit — it covers a sampling of resolvers that send RFC 8145 signals, not the full population, and resolvers that don't implement RFC 8145 are simply invisible to begin with. Verisign added that this adoption pace matched the equivalent point in the previous rollover exactly.

No up-to-date adoption figure as of mid-2026 has been published. As far as I could find, there is no official number posted anywhere as of this moment, 87 days before the rollover. So I won't put a number here.

In the same post, two other observations are more interesting.

One: 100 percent of resolvers hold KSK-2017 as a trust anchor, and Verisign expects that to remain true until KSK-2017 is revoked in early 2027. That's expected — it's the only signing key right now.

Two: a fair number of resolvers still trust KSK-2010, which was retired in 2019. Verisign considers it likely this is because the key persists in operating-system software updates. A key that died seven years ago is still sitting in trust stores. This is the reality of DNSSEC deployment — the protocol is clean, and the deployed world is messy.

And remember the IANA file's validFrom was 2024-07-18? Verisign observed that a small number of resolvers started adding KSK-2024 as a trust anchor starting right after that — July 2024, when the key was added to the IANA trust anchor file. They attribute this to operators configuring it manually. Two independent sources line up on the same date.

What This Rollover Does Not Change — the Algorithm

Earlier I mentioned both KSKs are algorithm 8, RSA 2048-bit. Now it's time to talk about that.

ICANN's algorithm rollover proposal sums up the situation matter-of-factly: root zone DNSSEC signing started with an RSA-based algorithm in 2010, the KSK was swapped once in 2018, but the cryptographic algorithm itself has never changed, and the already-underway October 11, 2026 rollover also keeps the same algorithm. And then the decisive sentence: there is no established mechanism for transitioning the root zone to a different signing algorithm.

This gap was flagged by ICANN's second Security, Stability, and Resiliency Review (SSR2), published in 2021, and the Board adopted that recommendation in July of the same year. The result was a 2024 root zone algorithm rollover study, and building on that, the Proposal for Root Zone KSK Algorithm Rollover was put out for public comment on March 2, 2026.

The plan is this: transition from RSA/SHA-256 (algorithm 8) to ECDSA P-256 with SHA-256 (algorithm 13). It starts by generating a new ECDSA key in 2027 and runs roughly 4 years, through the final destruction of the replaced RSA KSK in 2030. The method is double-signing.

There's one thing worth pointing out here. This is not a move away from RSA/SHA-256 because it's weak.

The authoritative source for algorithm recommendations is RFC 9904 (DNSSEC Cryptographic Algorithm Recommendation Update Process, obsoleting RFC 8624), published in November 2025. Open the document's table directly and this is what it shows.

No. Mnemonics        Use/Signing   Use/Validation  Impl/Signing  Impl/Validation
 8  RSASHA256        RECOMMENDED   RECOMMENDED     MUST          MUST
13  ECDSAP256SHA256  RECOMMENDED   RECOMMENDED     MUST          MUST

The two algorithms have exactly the same rating. RSASHA256 is neither deprecated nor discouraged. ECDSA P-256 was chosen because it satisfies the criteria from ICANN's study — already standardized at the IETF, and designated MUST-implement for DNSSEC validation — while also already being deployed across many TLDs and supported by all the major software: BIND, Unbound, Knot Resolver, PowerDNS, and more.

So why move at all? The proposal's practical motivations are response-size management, and, fundamentally, "proving that a transition procedure exists." If you've never carried out an algorithm rollover, you won't be able to when you truly need to — when some algorithm breaks. This is precisely the gap SSR2 pointed at.

One more thing: RFC 9904 moved the authoritative source for algorithm requirements from an RFC document to an IANA registry. So the table above is a snapshot — future changes to recommendation ratings will update the registry, not require an RFC revision. If your code or docs reference RFC 8624, now's the time to fix that.

The Algorithm Rollover's Paradox — the 1536-Bit Debate

Now for the most interesting part of this post.

One reason for moving to ECDSA P-256 is that its signatures are smaller — but getting there requires making responses much bigger first. Because it's a double-signing method, during the transition the root zone is signed with both RSA and ECDSA, and the DNSKEY set carries both sets of keys.

The proposal addresses this head-on. Response size wasn't an issue in 2018 or the subsequent KSK rollover because, in a rollover that doesn't change the algorithm, only the size of the DNSKEY response is affected. And DNSKEY queries make up less than 0.5 percent of all queries a root server receives. Even if DNSKEY responses get truncated and retried over TCP, the impact on the root server system is negligible.

But with a double-signing algorithm rollover, referral responses and NXDOMAIN responses grow too. That's the majority of root traffic. This overlaps with the 2020 DNS Flag Day pushing the default maximum UDP buffer size to 1232 bytes. The proposal's conclusion is blunt: double-signing with a 2048-bit ZSK would cause most root server responses to be truncated and fall back to TCP retries.

So the countermeasure that came out of this is: lower the RSA ZSK from 2048 bits to 1536 bits before the algorithm rollover begins. 1536 is the midpoint between 1024 and 2048, and only at this size do nearly all responses stay under 1232 bytes (setting aside the DNSKEY response during the quarterly ZSK rollover).

In other words, the cryptographic key is deliberately weakened in order to protect response size. And for about 3 years, at that.

This was exactly the most contested point in the public comment period. According to the public comment summary report, 12 submissions came in total, including one late submission from ICANN's Security and Stability Advisory Committee (SSAC). RSSAC, RySG, and Verisign — three organizations — expressed support; four supported with attached recommendations; and four raised concerns or objections.

The opposing arguments are specific. 1536 bits is not a standard RSA key size recognized by NIST; this reduction lowers the ZSK's effective security strength from about 112 bits to about 90–96 bits; and that degraded state persists for the roughly 3-year duration of the rollover.

ICANN's response is also worth reading. The key point is the exposure window. Agreeing with SSAC's analysis, it holds that each ZSK key is actually in use and publicly observable for about 110 days, and that this window is too short for a brute-force attack on a 1536-bit key to be feasible with current capability. And it wrote: "The security reduction relative to a 2048-bit key is real but bounded by this operational window." It matters not to soften this sentence in translation — ICANN does not deny the fact that security is being lowered.

On the point that it isn't a NIST-standard size, ICANN's answer is that while NIST key-management guidance does list 1024, 2048, and 3072 bits as reference sizes, non-standard RSA key sizes are not unprecedented in DNSSEC operations — the root zone's own ZSK used to be 1280 bits.

On the numbers side, Verisign also submitted an empirical analysis based on RSSAC-002 traffic data, finding that a 1536-bit RSA ZSK combined with an ECDSA ZSK would push roughly 1 to 5 percent of responses above 1232 bytes. ICANN's judgment is that while not perfect, this is meaningfully better than keeping 2048 bits. This, too, is a submitter's own measurement, an estimate based on the specific RSSAC-002 traffic dataset.

One more concern raised was that the criteria for triggering a phase-schedule adjustment aren't defined. The point is that there's no written-down standard for judging when to extend the schedule and when to pull back. Given that the 2017 postponement ultimately came down to a judgment call, this is a fair criticism.

The outcome: there was no structural change to the plan. ICANN said it will proceed as proposed, but will separately publish phase-transition criteria and conduct targeted outreach to the operator community.

There was one more technically interesting objection. The proposed Phase DD publishes ECDSA signatures first, before the corresponding ECDSA DNSKEY is published. The objection was that publishing signatures alone provides no security benefit, since an ECDSA public key can be recovered from its signature anyway. Cryptographically, this is correct.

When This Isn't Your Problem

Honestly summarized: most people reading this post don't need to do anything.

You don't need to worry if:

You don't do DNSSEC validation. (Most internal corporate resolvers fall here.)
You use a public resolver like Cloudflare, Google, or Quad9. It's their problem, not yours.
You use a managed resolver and the vendor manages the trust anchor.
You're running a recent BIND/Unbound/Knot with default settings, RFC 5011 auto-update is on, and it's been up continuously since February 2025. In this case you already have KSK-2024.

You need to check if:

You operate a validating resolver yourself.
You configured the trust anchor manually, or you're distributing a root.key file through a configuration management tool. If RFC 5011 is off, automatic updates don't happen. This is exactly why ICANN publishes a trust anchor file on the IANA website for software that doesn't use RFC 5011, and the recommendation is to fetch that file at resolver startup and whenever the KSK in the root DNSKEY set changes.
The trust anchor is baked into a container image or appliance. If the image was built before February 2025 and hasn't been rebuilt since, and the RFC 5011 state file lives in a container layer rather than a persistent volume — so it resets on every restart — the 30-day hold-down will never complete. This is the most plausible failure mode in modern deployment environments.
You're in an air-gapped environment, or outbound access to root servers is restricted.

The check is simple. Look at your resolver's trust anchor store for 38696. If it's there, you're done.

Closing

To summarize: the root KSK moves from KSK-2017 to KSK-2024 on October 11, 2026. Open the root zone today and both keys are already sitting side by side, with KSK-2017 still doing the signing. A resolver with RFC 5011 turned on already accepted the new key back in February 2025, so it experiences nothing that day. A resolver that failed to accept it dies right on that day — there is no grace period running to January 2027. KSK-2017 stays in the zone so it can be properly revoked, not to keep anyone else alive.

The 2017 lesson still holds. What stopped that rollover for a year was not lazy operators but an auto-update bug in a widely used resolver, and what caught it was a telemetry standard only five months old. Having automation turned on and having automation that works are two different things. That's why this plan built in nearly two years of pre-publication.

And this rollover doesn't change the algorithm. The genuinely hard part — RSA to ECDSA — is a separate project starting in 2027 and running through 2030, and that plan drew the most objections over a proposal to deliberately weaken the RSA ZSK for 3 years in order to protect response size. ICANN acknowledges that the degradation is "real but bounded," and proceeds as planned.

These two things might be the real point of this post. Changing the internet's trust anchor is not a cryptography problem but a deployment problem — and in the deployed world, a key that died seven years ago is still sitting in trust stores. And when you design a safe transition, there comes a moment where you have to accept being less safe for the duration of the transition itself. An honest plan doesn't hide that — it writes it down.

If there's one thing to do right now, it's this: if you run a validating resolver, open your trust anchor store and check whether 38696 is there. 87 days left.