APNIC 62 convened in Mumbai, India, from 4 to 10 September 2026, bringing together network operators, researchers, and Internet infrastructure experts from across the Asia Pacific region to examine operational experience, emerging technologies, and ongoing challenges in Internet operations. Technical Session 1 focused on Internet Operations, with presentations spanning DHCP and DNS management, the upcoming DNSSEC root Key-Signing Key (KSK) rollover, 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 at Internet Systems Consortium (ISC), presented on the organization's foundational role in Internet service delivery. BIND 9 remains widely deployed as both an authoritative server and recursive resolver, while Kea DHCP serves as the successor to the legacy ISC DHCP server, which has reached end of life.
Stork, a graphical management platform, addresses the complexity of DHCP environments by integrating with BIND 9 and PowerDNS. The tool connects with Prometheus and Grafana to deliver monitoring, reporting, dashboards, and web-based management capabilities. Through Kea, operators can oversee high-availability configurations, failover systems, lease tracking, and log inspection.
DNS management represents a relatively recent addition to Stork's capabilities. Current functionality encompasses monitoring, configuration views, zone browsing, and zone transfer monitoring, including detection of serial number mismatches between servers. PowerDNS integration remains experimental and aims to provide unified management across mixed deployments.
The roadmap includes stale DNS record detection and removal in dynamic DNS environments, zone cloning and validation, BIND 9 configuration editing, DNS catalogue zone support, and enhanced BIND 9 log monitoring. These features are expected throughout 2026 and 2027.
Root zone KSK rollover
Champika Wijayatunga, Technical Engagement Director for Asia Pacific at ICANN, outlined the upcoming rollover of the DNSSEC root KSK, scheduled for 11 October 2026. The KSK represents the public component of a public-private key pair, with the private key maintained offline within ICANN-managed hardware security modules at secure facilities on the east and west coasts of the United States.
Periodic key rollovers constitute established operational practice, reducing long-term security risks and enabling the adoption of stronger algorithms and key lengths as technology advances. This approach carries particular significance given emerging threats such as quantum computing, which may diminish the effective lifetime of RSA key pairs.
ICANN manages key material through public key ceremonies at both facilities, with Trusted Community Representatives participating in events that are live-streamed. Under normal circumstances, key material refreshes every three to four years, though the current rollover experienced delays.
Operators performing DNSSEC validation must ensure their resolver systems maintain current Trust Anchors. Many systems update automatically through RFC 5011, though some deployments may require manual intervention. Champika stressed the importance of verifying resolver behavior during and after the rollover, with updated Trust Anchors available from IANA for independent validation.
Certificate revocation
Geoff examined ongoing challenges in X.509 certificate management, which underpins authentication and privacy for HTTPS and TLS. A certificate represents third-party attestation of identity issued by a Certificate Authority, which creates cryptographic credentials based on applicant-supplied information.
Using unauthorized banking websites as an example, Geoff explored whether certificate revocation actually prevents use of compromised sites. He demonstrated that www.westpac.com.au resolves to Amazon-hosted infrastructure rather than Westpac-operated systems, and uses a DigiCert certificate issued more than nine months earlier. During such periods, security failures including CA compromise, key theft, or operational mistakes could occur.
The traditional X.509 Certificate Revocation List (CRL) publishes serial numbers of certificates no longer trusted. In principle, browsers fetch the CRL, validate its signature, and check certificate presence. However, the process operates too slowly for routine browser validation. Geoff showed an example CRL updated weekly containing 17,527 revoked certificates.
The Online Certificate Status Protocol (OCSP), defined in RFC 2560, offers real-time status queries but creates privacy concerns by revealing browsing activity and introduces potential denial-of-service risks through centralized lookups. OCSP stapling allows servers to provide signed OCSP responses during the TLS handshake, improving privacy and reducing latency, but compromised servers are unlikely to provide evidence of revocation.
Browser support varies considerably. Let's Encrypt, the world's largest CA, discontinued OCSP services in 2025 after handling more than 140,000 requests per second through Akamai, while 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, while Firefox did. Given the market share of Chrome and Safari, certificate revocation remains largely ineffective in practice.
One response has been shortening certificate lifetimes. Let's Encrypt 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 proves insufficient because security incidents occur in milliseconds while certificate lifetimes remain measured in days.
As an alternative, Geoff proposed leveraging DNS and its built-in cache expiry mechanisms. DNS-based Authentication of Named Entities (DANE), combined with DNSSEC, allows keying material publication 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 moving away from the X.509 ecosystem toward DNSSEC-based trust models. The challenge involves transitioning from infrastructure designed around certificate lifetimes measured in days to systems capable of responding to threats almost immediately.
The good neighbor problem: BGP security beyond your own prefix
Ritesh Mukherjee, Product Management Leader for NOS and AI at Nokia, 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 AS path integrity. He presented several routing incidents affecting the Asia Pacific region.
In one case, Reliance (AS18101) blackholed Telegram prefixes, with the RIPE RIS system quickly detecting the event as 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 data showed AS18101 was not authorized to originate the affected routes. Route Origin Validation would have detected the issue and prevented broader propagation, yet only 27% of ASes currently enforce ROV, with adoption in India remaining 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 toward AS55410. Low ROV adoption, limited path filtering, and the absence of maximum-prefix controls contributed to the incident's scale.
ROV deployment across the Asia Pacific remains behind other Regional Internet Registry 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:
- BMP for anomaly detection
- ASPA for path validation
- ROV with enforcement
He 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 integrates with RPKI validators such as Routinator. It also supports Grafana dashboards, webhooks, FlowSpec integration, and command-line audits.
Ritesh strongly advocated deploying BMP at the Adj-RIB-In to provide visibility into routing behavior and help operators become better neighbors. He also encouraged maximum-prefix limits on eBGP sessions to prevent route leaks from overwhelming routing infrastructure, long-term ASPA deployment, ROV with drop policies, and active participation in MANRS.