DNSSEC root key rollover set for 11 October 2026

DNSSEC is the system of digital signatures that lets a computer check whether an answer it received from the Domain Name System is genuine, and one of its most important keys is about to be replaced. That change was one of four subjects discussed at APNIC 62, the conference of the Asia Pacific Network Information Centre, held in Mumbai, India, from 4 to 10 September 2026, where network operators, researchers and internet infrastructure experts met to compare operational experience and ongoing challenges. APNIC's write-up of Technical Session 1, Internet Operations, was published by George Michaelson on 21 September 2026.

Marcin Siodelski, a senior software engineer at the Internet Systems Consortium (ISC), presented Stork, a new management tool. ISC's DHCP and BIND software have been central to internet service delivery for decades, and while the organisation is perhaps best known today for operating the global F-root DNS service, software development remains a core part of its mission. BIND 9 continues to power DNS services worldwide as both an authoritative server (the machine that holds a domain's official records) and a recursive resolver (the machine that looks answers up on a user's behalf). Kea DHCP replaces the legacy ISC DHCP server, which has reached end of life. Because DHCP environments, the systems that hand out network addresses automatically, can be complex, Stork is presented as a significant step forward: a graphical management platform that integrates with BIND 9 and PowerDNS, and also with Prometheus and Grafana for monitoring, reporting, dashboards and a web-based management interface.

DHCP remains a fundamental part of network service delivery. It manages pools of IP addresses, allocates subnets, and maintains static address and prefix assignments for specific machines identified by MAC addresses (the hardware identifier built into a network card) or client identifiers. Through Kea, operators can manage high-availability configurations, failover systems, lease tracking and log inspection, and Marcin demonstrated Grafana integrations, subnet management interfaces and configuration tools. DNS management is a relatively new addition to Stork, and its integration with BIND 9 lets operators manage, monitor and report on complex DNS environments through a single interface, giving visibility across large server deployments and helping to bridge operational teams and DNS infrastructure. Current capabilities focus on monitoring, configuration views, zone browsing and zone transfer monitoring, including detection of serial number mismatches between servers, which signal that two copies of the same zone have drifted apart. PowerDNS integration remains experimental and aims to provide a unified management experience across mixed deployments. Further features are planned, including detection and removal of stale DNS records in dynamic DNS environments, which aligns closely with DHCP pool management, plus zone cloning and validation, BIND 9 configuration editing, DNS catalogue zone support and enhanced BIND 9 log monitoring. Those features are expected to be released through 2026 and 2027.

Champika Wijayatunga, ICANN's Technical Engagement Director for Asia Pacific, explained the upcoming rollover of the DNSSEC root Key-Signing Key (KSK), scheduled for 11 October 2026. He set out the DNSSEC chain of trust, which rests on the root zone Trust Anchor. A trust anchor sits at the top of the hierarchy and cannot be validated against another key: systems must be configured to treat it as a trusted starting point, an axiom. The key being rolled is the public half of a public and private key pair; the private key stays offline inside ICANN-managed hardware security modules at secure facilities on the east and west coasts of the United States. Private keys produce the cryptographic signatures over DNS data, while published public keys enable resolvers to verify that data's authenticity, integrity and completeness. Periodic rollovers are considered good operational practice: they reduce long-term security risks and allow stronger algorithms and key lengths to be introduced as technology evolves, which matters for emerging threats such as quantum computing that may shorten the effective lifetime of RSA key pairs. ICANN conducts key management through public key ceremonies at both facilities, with Trusted Community Representatives taking part, and the ceremonies are live-streamed. Under normal circumstances key material would be refreshed every three to four years, although this rollover was delayed. Operators that perform DNSSEC validation must ensure their resolver systems keep their trust anchors current: many systems update automatically through RFC 5011, but some deployments require manual intervention, and Wijayatunga emphasised the importance of verifying how resolvers behave during and after the rollover. Updated trust anchors are available from IANA and can be validated independently of RFC 5011 updates.

Geoff Huston, APNIC's Chief Scientist, examined the ongoing challenges of X.509 certificate management, the system that underpins the authentication and privacy mechanisms used by HTTPS and TLS. A certificate is a third party's attestation of identity: the issuing certificate authority is a private organisation that creates cryptographic credentials based on information supplied by applicants, and it is not necessarily the authority that issued a company name, a domain name or any other form of identity. Using an unauthorised banking website as his example, Huston asked a simple question: does certificate revocation actually prevent people from using a compromised site? Looking at www.westpac.com.au, he showed that the domain resolves to infrastructure hosted by Amazon rather than infrastructure operated directly by Westpac, and that the site uses a certificate issued by DigiCert more than nine months earlier. Over such a period a range of security failures could occur, including compromise of the certificate authority, theft of a key or an operational mistake, and the hard part is how to invalidate a certificate when one of these events happens.

The traditional mechanism is the X.509 Certificate Revocation List (CRL), which publishes the serial numbers of certificates that should no longer be trusted; in principle a browser fetches the list, validates its signature and checks whether the certificate in front of it appears there. Huston showed an example list that was updated weekly and contained 17,527 revoked certificates. In practice the process is far too slow to support routine browser validation: it is technically sound but rarely used as originally intended. The Online Certificate Status Protocol (OCSP), defined in RFC 2560, offered an alternative through real-time status queries, but it creates privacy concerns by revealing browsing activity and introduces potential denial-of-service risks through centralised lookups, and it