APNIC 62: Updates in DNS, DHCP, certificate security, and BGP routing resilience

Ritesh Mukherjee discusses the next stage of BGP security at APNIC 62.

APNIC 62, held in Mumbai, India, from 4 to 10 September 2026, brought together network operators, researchers, and Internet infrastructure experts from across the Asia Pacific region to discuss operational experience, emerging technologies, and ongoing challenges in Internet operations.

This post covers presentations from Technical Session 1 - Internet Operations, which featured presentations on DHCP and DNS management, the upcoming DNSSEC root Key-Signing Key (KSK) rollover, the limitations of X.509 certificate revocation, and the continuing evolution of BGP.

ISC Stork: New management tool for Kea DHCP and BIND DNS

Marcin Siodelski, Senior Software Engineer, Internet Systems Consortium (ISC)

ISC's DHCP and BIND software have been central to Internet service delivery for decades. While ISC 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 and a recursive resolver.

Kea DHCP replaces the legacy ISC DHCP server, which has reached end of life (EOL). Because DHCP environments can be complex, Stork represents a significant step forward. The graphical management platform integrates with BIND 9 and PowerDNS, making it easier for operators to manage services centrally. Stork also integrates with Prometheus and Grafana to provide monitoring, reporting, dashboards, and a web-based management interface.

DHCP remains a fundamental component of network service delivery. It manages IP address pools, allocates subnets, and maintains static address and prefix assignments for specific hosts using MAC addresses or client identifiers. Through Kea, operators can manage high-availability configurations, failover systems, lease tracking, and log inspection.

Marcin demonstrated Grafana integrations, subnet management interfaces, and configuration tools.

Stork's integration with BIND 9 allows operators to manage, monitor, and report on complex DNS environments through a single interface. It provides visibility across large server deployments and helps bridge operational teams and DNS infrastructure.

DNS management is a relatively new addition to Stork. Current capabilities focus on monitoring, configuration views, zone browsing, and zone transfer monitoring, including serial number mismatch detection between servers. PowerDNS integration remains experimental and aims to provide a unified management experience across mixed deployments.

Several new features are planned, including stale DNS record detection and removal in dynamic DNS environments, which closely aligns with DHCP pool management. Additional roadmap items include zone cloning and validation, BIND 9 configuration editing, DNS catalogue zone support, and enhanced BIND 9 log monitoring. These features are expected to be released throughout 2026 and 2027.

Marcin's slides include links to software downloads and package repositories.

Root zone KSK rollover

Champika Wijayatunga, Technical Engagement Director, Asia Pacific, ICANN

Champika discussed the upcoming rollover of the DNSSEC root KSK, scheduled for 11 October 2026.

To provide context, he explained the DNSSEC chain of trust, which underpins the root zone Trust Anchor (TA). At the top of the hierarchy, the TA cannot be validated against another key. Instead, systems must configure it as a trusted starting point and treat it as an axiom.

The KSK being rolled is the public component of a public-private key pair. The private key remains securely stored offline within ICANN-managed hardware security modules (HSMs) at secure facilities on the east and west coasts of the United States.

Private keys generate cryptographic signatures over DNS data, while published public keys enable resolvers to verify authenticity, integrity, and completeness.

Periodic key rollovers are considered good operational practice. They reduce long-term security risks and allow the introduction of stronger algorithms and key lengths as technology evolves. This is particularly important in the context of emerging threats such as quantum computing, which may shorten the effective lifetime of RSA key pairs.

ICANN conducts key management activities through public key ceremonies at both facilities. Trusted Community Representatives (TCRs) participate in these ceremonies, which are also live-streamed. Under normal circumstances, key material is expected to be refreshed every three to four years, although the current rollover was delayed.

Operators that perform DNSSEC validation must ensure their resolver systems maintain current Tas. Many systems update automatically through RFC 5011, but some deployments may require manual intervention.

Champika emphasized the importance of verifying resolver behaviour during and after the rollover. Updated TAs are available from IANA and can be validated independently of RFC 5011 updates.

Further resources and contact information are available in Champika's presentation.

Certificate revocation

Geoff Huston, Chief Scientist, APNIC

Geoff examined the ongoing challenges of X.509 certificate management, which underpins the authentication and privacy mechanisms used by HTTPS and TLS.

A certificate represents a third-party attestation of identity. The issuing Certificate Authority (CA) is a private organization that creates cryptographic credentials based on information supplied by applicants. It is not necessarily the authority that issued a company name, domain name, or other form of identity.

Using an unauthorized banking website as an example, Geoff explored a simple question: Does certificate revocation actually prevent people from using a compromised site?

Looking at , he showed that the domain resolves to infrastructure hosted by Amazon, rather than infrastructure directly operated by Westpac. The site also uses a certificate issued by DigiCert more than nine months earlier. During that period, a range of security failures could occur, including CA compromise, key theft, or operational mistakes. The challenge is determining how to invalidate a certificate when these events occur.

The traditional mechanism is the X.509 Certificate Revocation List (CRL), which publishes serial numbers of certificates that should no longer be trusted. In principle, browsers fetch the CRL, validate its signature, and check whether a certificate appears on the list. Geoff showed an example CRL that was updated weekly and contained 17,527 revoked certificates.

In practice, however, the process is too slow to support routine browser validation. While technically sound, it is rarely used as originally intended.

The Online Certificate Status Protocol (OCSP), defined in RFC 2560, provides an alternative approach through real-time status queries. However, OCSP creates privacy concerns by revealing browsing activity and introduces potential denial-of-service risks through centralized lookups. Deployment remains incomplete and inconsistent.

HTTPS and TLS also support OCSP stapling, which allows servers to provide signed OCSP responses during the TLS handshake. This improves privacy and reduces latency. However, a compromised server is unlikely to provide evidence that its certificate has been revoked, limiting the mechanism's effectiveness.

Browser support varies considerably. Let's Encrypt, now the world's largest CA, discontinued OCSP services in 2025 after handling more than 140,000 requests per second through Akamai. At the same time, support for 'Must Staple' effectively disappeared. Chrome stopped relying on OCSP in 2014 and never adopted stapling as a primary validation mechanism. Safari follows a different approach.

Geoff tested certificate issuance and revocation using Let's Encrypt within a seven-day CRL publication cycle. Although the revoked certificate appeared on the CRL, Chrome and Safari did not recognize the revocation. Firefox did. Given the market share of Chrome and Safari, certificate revocation remains largely ineffective in practice.

One response has been to shorten certificate lifetimes. Let's Encrypt has reduced certificate validity from 90 days to 45 days, and some CAs now issue certificates valid for as little as six days. Geoff argued that even this is insufficient because security incidents occur in milliseconds, while certificate lifetimes are still measured in days.

As an alternative, he proposed using DNS and its built-in cache expiry mechanisms. DNS-based Authentication of Named Entities (DANE), combined with DNSSEC, allows keying material to be published with much shorter lifetimes. A 'stapled DANE' model also exists, providing functionality similar to X.509 certificates and OCSP stapling.

Geoff concluded that achieving genuinely short-lived web credentials may require a shift away from the X.509 ecosystem and towards DNSSEC-based trust models. The challenge lies in moving from an infrastructure designed around certificate lifetimes measured in days to one that can respond to threats almost immediately.

View more details in Geoff's slides and his most recent APNIC Blog post on the topic.

The good neighbor problem: BGP security beyond your own prefix

Ritesh Mukherjee, Product Management Leader, NOS and AI, Nokia

Ritesh discussed the next stage of BGP security. Route Origin Validation (ROV) verifies whether a network is authorized to originate a route, while Autonomous System Provider Authorization (ASPA) helps validate the integrity of the AS path. He presented several examples of routing incidents.

In one case, Reliance (AS18101) blackholed Telegram prefixes. The RIPE RIS system quickly detected the event as a false route origination. Telegram responded by announcing more-specific prefixes, which AS18101 also propagated. Because these announcements extended beyond India, overseas networks selected what appeared to be shorter paths.

The incident became a BGP hijack because Internet Routing Registry (IRR) data showed that AS18101 was not authorized to originate the affected routes. Route Origin Validation (ROV) would have detected the issue and prevented broader propagation. However, only 27% of ASes currently enforce ROV, and adoption in India remains particularly low.

A second example involved SingNet (AS3758). Although a route announcement from AS17894 was filtered by AS37100, traffic was still diverted through Sparkle (AS6762), which propagated a more-specific route. Seacom had enabled ROV, but its dependency on Sparkle reduced its effectiveness. Partial deployment creates blind spots that allow hijacks to persist within sections of the default-free zone.

Ritesh also discussed a route leak from Vodafone Idea (AS55410), which announced thousands of prefixes that Bharti Airtel (AS9498) subsequently propagated. The event caused widespread traffic misdirection towards AS55410. Low ROV adoption, limited path filtering, and the absence of maximum-prefix controls contributed to the scale of the incident.

These examples illustrate routing security challenges that have affected networks across the Asia Pacific region for almost two decades. Addressing them requires a combination of ROV, path validation, and broader consideration of the 'good neighbor' problem. Although ASPA is still relatively new, wider deployment will be essential.

ROV deployment across the Asia Pacific remains behind other Regional Internet Registry (RIR) regions. Some economies, including Viet Nam, Indonesia, and the Philippines, have achieved stronger deployment levels. India has reached 88% Route Origin Authorization (ROA) coverage, but enforcement remains limited.

Ritesh proposed a three-part protection model:

1. BMP for anomaly detection.
2. ASPA for path validation.
3. ROV with enforcement.

He also highlighted RAVEN, Nokia's BGP Routing Security Monitor. Available through Nokia's GitHub repository, the tool helps operators assess routing security exposure before enforcing blocking policies. RAVEN runs as a single binary, receives routing data via BMP, and can integrate with RPKI validators such as Routinator. It also supports Grafana dashboards, webhooks, FlowSpec integration, and command-line audits.

Deploying BMP at the Adj-RIB-In provides visibility into routing behaviour and can help operators become better neighbours.

Ritesh strongly advocated the use of maximum-prefix limits on eBGP sessions to prevent route leaks from overwhelming routing infrastructure. He also encouraged long-term deployment of ASPA, ROV with drop policies, and active participation in MANRS.

His slides include a QR code linking to RAVEN and additional resources.

Watch the full session now.

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 applies to this blog.