DNS in 2026, in depth: the root KSK-2024 cutover, SHA-1 leaving DNSSEC, fragmentation-free UDP, HTTPS records with ECH, encrypted resolver discovery and .internal

Where each change sits in a lookup

Read the diagram as a checklist. Clients may now discover an encrypted path to their resolver. The resolver validates a chain that starts with a new root key. Zones should be signed with algorithms that resolvers still accept. Answers should fit in a UDP packet that is never fragmented, or move to TCP. And the answer itself may be an HTTPS record that changes how the client connects.

The root key rollover: KSK-2024 takes over on 11 October 2026

A validating resolver trusts DNSSEC answers because it holds a copy of the root zone's key-signing key, the trust anchor, and checks every chain against it. Since 2018 that key has been KSK-2017, key tag 20326. Its successor, KSK-2024 with key tag 38696, was first published in the root zone on 11 January 2025, and according to ICANN the root zone begins using only KSK-2024 on 11 October 2026.

Most resolvers update their trust anchor automatically using RFC 5011: when a new key-signing key appears in the root and is signed by the current one, the resolver waits 30 days and then trusts it. KSK-2024 has been visible for far longer than that, so a resolver that has been running and able to write its state file has picked it up. The ones at risk are those that cannot follow that process: appliances and container images with a trust anchor baked in at build time, resolvers whose state directory is read-only, systems restored from old backups, and machines that were powered off throughout the window. If such a resolver lacks KSK-2024 after the cutover, every validated lookup fails and the network effectively loses DNS.

# 1. What the root publishes (both keys during the rollover, then only the new one)
dig . DNSKEY +multi | grep -E "key id|257"

# 2. Does your resolver validate? A validating resolver sets the "ad" flag here...
dig @10.0.0.53 isc.org SOA +dnssec | grep flags
# ...and returns SERVFAIL for a deliberately broken test zone such as dnssec-failed.org
dig @10.0.0.53 dnssec-failed.org A

# 3. Which trust anchors does the resolver hold?
rndc managed-keys status            # BIND: look for key id 38696
cat /var/lib/unbound/root.key       # Unbound: the auto-trust-anchor-file

Where the trust anchor lives depends on the software: BIND keeps its built-in anchors in bind.keys and learned state in its managed-keys database, Unbound and the PowerDNS Recursor use a root.key file, and Knot Resolver uses root.keys. Check that the file is writable by the resolver process and that it contains 38696.

If you are reading this after 11 October 2026 because resolution broke, the symptom is SERVFAIL for nearly every name from a validating resolver while non-validating paths work. Resolvers that support Extended DNS Errors (RFC 8914) usually attach a DNSSEC-related reason, which dig prints as an EDE line. Install the KSK-2024 anchor from IANA's published root anchors, verify it through a second channel, restart and test. Switching validation off makes the outage go away but removes the protection; treat it as a short emergency measure with an owner and an end date, never as the fix.

SHA-1 leaves DNSSEC

RFC 9905, published in November 2025, deprecates the two DNSSEC signing algorithms built on SHA-1: algorithm 5 (RSASHA1) and algorithm 7 (RSASHA1-NSEC3-SHA1). Signers must not create new keys or signatures with them, and operators of validating resolvers must treat them as unsupported. Validator software still contains the code, because some domains still use these algorithms, but some operating systems have already removed SHA-1 signature support entirely.

The practical effect is easy to miss. A zone signed with an unsupported algorithm does not fail; it becomes insecure. Resolvers treat it as unsigned, answers still resolve, and nothing alerts. The DNSSEC protection you thought you had quietly disappears. That is why this needs an audit rather than waiting for a ticket.

import dns.resolver, dns.dnssec

SHA1_ALGS = {5: "RSASHA1", 7: "RSASHA1-NSEC3-SHA1"}

def root_ksk_tags(resolver_ip):
    r = dns.resolver.Resolver(configure=False)
    r.nameservers = [resolver_ip]
    keys = r.resolve(".", "DNSKEY")
    return sorted(dns.dnssec.key_id(k) for k in keys if k.flags == 257)

def zone_algorithms(zone):
    keys = dns.resolver.resolve(zone, "DNSKEY")
    return {k.algorithm for k in keys}

print("root KSKs seen via resolver:", root_ksk_tags("10.0.0.53"))   # expect 38696 present
for zone in ["example.com", "example.net"]:
    algs = zone_algorithms(zone)
    bad = [SHA1_ALGS[a] for a in algs if a in SHA1_ALGS]
    print(zone, sorted(int(a) for a in algs), "ROLL ALGORITHM" if bad else "ok")

The usual replacement is algorithm 13 (ECDSA P-256 with SHA-256), with algorithm 15 (Ed25519) a reasonable choice where your registrar and every signer support it. Changing algorithm is a rollover with stricter rules than a normal key change: introduce the new keys and sign the zone with both algorithms, wait for caches to expire, update the DS record at the parent, wait again, then remove the old algorithm. Managed DNS providers usually automate this; if you sign in-house, rehearse it on a test zone first.

The UDP size limit is settled: 1232 bytes, then TCP

A DNS answer larger than the path can carry in one IP packet gets fragmented, and fragments are fragile. Firewalls drop them, some networks never reassemble them, and a forged later fragment can carry poisoned data that the DNS layer cannot detect. After the 2020 DNS Flag Day, resolvers and servers converged on advertising an EDNS buffer of 1232 bytes. The number is not arbitrary: IPv6 guarantees a minimum MTU of 1,280 bytes, and subtracting the 40-byte IPv6 header and the 8-byte UDP header leaves 1,232 bytes for DNS.

RFC 9715, published in January 2025, collects the techniques for avoiding fragmentation: keep responses small, set the don't-fragment flag where the operating system allows, and when an answer does not fit, set the truncation bit so the client retries over TCP. It was published as Informational rather than Best Current Practice because some recommendations depend on socket options not every system offers, but the direction is clear.

Worked example: a signed DNSKEY answer with two RSA-2048 keys and two RSA-2048 signatures carries about 512 bytes of keys and 512 of signatures before names and headers. The same answer with ECDSA P-256 carries 64-byte keys and 64-byte signatures, about 256 bytes in total. During a key rollover the RSA answer can exceed 1232 bytes and fall back to TCP for every cache miss, while the ECDSA answer fits comfortably. Smaller algorithms are not only faster; they keep you on UDP.

Two operational consequences follow. TCP port 53 must be open to and from every authoritative and recursive server, because truncation is now an expected path rather than a rare one. And firewall rules that limit DNS packets to 512 bytes, still found in older configurations, must go.

HTTPS and SVCB records, and how ECH uses them

RFC 9460 (November 2023) defined the SVCB record and its HTTPS-specific form. Before connecting, a client can now learn which protocols a service speaks, which addresses to try first, and which parameters to use, in the same DNS round trip as the address lookup. Several major browsers already query HTTPS records alongside A and AAAA.

; ServiceMode record at the apex: protocols, address hints and an ECH config
example.com.      300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.10 ech="AEn+DQBF..."

; AliasMode (priority 0) at the apex: a CNAME-like pointer that is legal next to SOA and NS
example.com.      300 IN HTTPS 0 lb.cdn-provider.example.

; Check what clients will see
dig example.com HTTPS +short

Two forms matter. ServiceMode records (priority 1 and up) carry parameters: alpn lets a client open HTTP/3 directly without first connecting over TCP, and address hints save a round trip. AliasMode (priority 0) finally solves the old problem that a CNAME cannot sit at a zone apex: the apex can now point at a provider's hostname legitimately.

Encrypted Client Hello builds on this. ECH, published as RFC 9849 in November 2025, encrypts the inner TLS Client Hello, including the server name, under a public key the server publishes; RFC 9848 (December 2025) specifies how that key travels in the ech parameter of an HTTPS record. An observer on the path then sees only the provider's public name, not the site being visited. Operationally, the DNS record and the server's ECH keys must rotate together. ECH includes a recovery path in which the server returns fresh keys to a client holding stale ones, but each recovery costs a round trip, so keep the HTTPS record's TTL shorter than your key rotation period.

A quieter failure: an HTTPS record that still advertises h3 after you disable QUIC makes clients try UDP first and wait before falling back. Treat the record as configuration owned by the same team that owns the listener; HTTP/2 in depth covers the TCP-side negotiation it complements.

Encrypted resolvers that clients discover themselves

DNS over TLS (RFC 7858), over HTTPS (RFC 8484) and over QUIC (RFC 9250) are all standard, but for years a client could only use them if someone configured a specific provider. Two newer mechanisms let a client upgrade to its own network's resolver. Discovery of Designated Resolvers (DDR, RFC 9462) has the client ask its plain resolver for SVCB records at _dns.resolver.arpa; the answer names the encrypted endpoints the same operator runs, and the client verifies the resolver's certificate covers the address it already used. Discovery of Network-designated Resolvers (DNR, RFC 9463) delivers the same information in DHCP and IPv6 router advertisements.

For enterprises this is mostly good news: clients encrypt to your resolver instead of bypassing it for a public one, and your split-horizon names and filtering keep working. The work is to publish the SVCB records and certificates so clients can find you. Expect operating systems and browsers to differ in which mechanisms they honour and when, and test the ones in your fleet.

A safe private name: .internal

Organisations have long invented private top-level names such as .corp, .home or .lan, and their queries leak to the public root every day. Worse, a private name can collide if someone later registers it publicly. In July 2024 the ICANN Board resolved that .internal will never be delegated in the root zone, reserving it for private use. Use it for new internal namespaces, keep .local for multicast DNS (RFC 6762) where it belongs, use home.arpa (RFC 8375) for home networks, and plan migrations away from invented names when systems are next rebuilt. Note that publicly trusted certificate authorities will not issue for .internal; use a private certificate authority.

Resolver hygiene that 2026 assumes

• Patched validators. The KeyTrap disclosure in early 2024 (CVE-2023-50387) showed that a crafted zone could make validating resolvers burn CPU for a long time on one query. Fixed releases cap validation work; make sure yours has them.
• Serve-stale. RFC 8767 lets a resolver answer from expired cache when authorities are unreachable. It turns many upstream outages into non-events; enable it with a sensible maximum staleness.
• Extended DNS Errors. RFC 8914 attaches a reason code to failures. Log them; they make the difference between knowing an outage is DNSSEC and guessing.
• Anycast and health checks for authoritative service, covered in Anycast DNS explained, and sane search paths inside clusters, covered in DNS in microservices.

Trade-offs worth stating plainly

What to do next

1. Inventory every validating resolver, including appliances and container images, and confirm each holds key tag 38696 in a writable trust-anchor store.
2. Write down the emergency procedure for a trust-anchor failure, including who may disable validation and for how long.
3. Audit your signed zones for algorithms 5 and 7, and schedule rollovers to algorithm 13.
4. Confirm EDNS buffers of 1232 bytes, open TCP port 53 everywhere, and remove 512-byte packet limits from firewalls.
5. Publish HTTPS records for your main sites, and tie their alpn and ech values to the teams that own those listeners.
6. Publish DDR records for your internal resolvers so clients encrypt to you rather than around you.
7. Adopt .internal for new private names and log Extended DNS Errors on your resolvers.