No OnlyDNS authoritative servers, Anycast edge nodes, or customer zones are affected by CVE-2026-94300. OnlyDNS does not run ISC BIND in any production environment. No customer action is required.
On October 21, 2026, the Internet Systems Consortium (ISC) published a high-severity security advisory for CVE-2026-94300 (ISC Advisory KB Article), disclosing a critical vulnerability in BIND 9's GSS-TSIG implementation that allows concurrent replayed UDP messages to corrupt memory in named, potentially leading to remote code execution (RCE).
Because security, transparency, and high availability are core tenets of OnlyDNS, we are issuing this advisory to explain the mechanics of the vulnerability, detail why the OnlyDNS global authoritative platform is completely unaffected by design, and share how our multi-layered PowerDNS + dnsdist architecture protects our users against DNS engine flaws.
Understanding CVE-2026-94300 in ISC BIND 9
The vulnerability affects ISC BIND 9 versions from 9.11.0 through 9.18.50, 9.20.0 through 9.20.29, and development branches up to 9.21.26. It carries a CVSS 3.1 base score of 8.1 (High) (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
Vulnerability Summary & Impact
- Vulnerability ID: CVE-2026-94300
- Vulnerability Title: Concurrent GSS-TSIG messages corrupt memory
- Affected Component: ISC BIND 9
namedGSS-TSIG (Generic Security Services for TSIG / RFC 3645 Kerberos authentication) - Root Cause: Replaying valid GSS-TSIG signed UDP messages concurrently with crafted queries against an attacker-controlled zone causes memory race conditions and heap corruption within the
namedprocess. - Consequences: Immediate daemon crash (Denial of Service) and possible arbitrary remote code execution (RCE) under the privileges of the nameserver daemon.
- Vendor Fix: Upgrading to patched releases BIND
9.20.30or9.21.27.
Why OnlyDNS Is Completely Immune by Design
OnlyDNS is not susceptible to CVE-2026-94300 because our entire authoritative DNS platform was architected from day one to avoid single-monolith software dependencies and legacy GSS-API complexity.
1. Zero BIND Dependency in Production
OnlyDNS does not run ISC BIND on any of our 23 global Anycast points of presence (PoPs), authoritative backend nodes, or management clusters. Flaws in BIND's C-codebase parser, resolver routines, or memory management have zero direct impact on our infrastructure.
2. Multi-Layered Architecture: dnsdist + PowerDNS
Instead of exposing a single monolithic daemon to raw Internet traffic, OnlyDNS separates packet ingress, DDoS mitigation, and query routing from authoritative record generation:
High-performance DNS-aware load balancer positioned at all 23 global Anycast nodes.
Engineered purely for authoritative response delivery with instant database replication. PowerDNS processes authorized DNS queries and standard Dynamic DNS updates (RFC 2136) in strict, non-root isolated execution rings.
3. Clean HMAC-SHA TSIG vs. Stateful Kerberos GSS-TSIG
CVE-2026-94300 stems from BIND's handling of GSS-TSIG (RFC 3645), which integrates complex Microsoft Active Directory / Kerberos negotiation contexts into UDP DNS packets.
OnlyDNS dynamic DNS (RFC 2136) intentionally uses standard, stateless HMAC TSIG (RFC 2845 / RFC 8945, using hmac-sha256 or hmac-sha512). HMAC TSIG keys calculate mathematical MAC digests independently per message without maintaining vulnerable, mutable in-memory session handles.
4. Sandboxed Execution & BGP Anycast Isolation
All daemon processes in OnlyDNS run with dropped Linux capabilities, unprivileged user accounts, and strict kernel seccomp filters. Furthermore, because each of our 23 Anycast locations announces independent BGP routes, any hypothetical node anomaly causes immediate local route withdrawal, directing traffic seamlessly to neighboring nodes with zero downtime.
Architectural Comparison
| Feature / Dimension | Traditional BIND 9 Setup | OnlyDNS Architecture |
|---|---|---|
| Primary Authoritative Engine | Monolithic ISC BIND named (Impacted by CVE-2026-94300) |
PowerDNS Authoritative Server (Immune) |
| Edge Ingress & Traffic Filtering | Direct exposure to raw port 53 traffic | Dedicated dnsdist load-balancing & scrubbing layer |
| TSIG Authentication Model | Legacy GSS-TSIG + HMAC | Cryptographic HMAC-SHA256/512 (RFC 2845 / 8945) |
| Global Resilience | Typically unicast or manual failover | 23-Node BGP Anycast with automatic edge failover |
| Customer Action Needed | Emergency patching to 9.20.30/9.21.27 | None (100% Protected) |
Guidance for Teams Running Self-Hosted BIND
If your organization operates internal or authoritative BIND 9 nameservers, ISC strongly recommends applying upstream updates immediately:
- Upgrade BIND: Deploy BIND version
9.20.30,9.21.27, or your Linux distribution’s security backport (e.g., Debian, Ubuntu, RHEL). - Review GSS-TSIG Usage: If your environment does not require Kerberos/Active Directory dynamic updates, ensure GSS-TSIG is disabled in configuration.
- Consider Delegating to Managed Anycast: Offloading public authoritative DNS zones to a specialized Anycast platform like OnlyDNS eliminates emergency patching cycles and isolates external query handling from your internal servers.
If you are planning to migrate existing BIND zone files to OnlyDNS, our platform supports seamless zero-downtime zone imports via our Web Interface and the OnlyDNS CLI (onlydns zone import).