The DNS vulnerabilities discussed in this article affect specific versions of PowerDNS Recursor, PowerDNS Authoritative Server, and BIND 9. Learn about the risks, the patched versions, and the precautions needed to update your company's infrastructure.
On October 21, 2026, PowerDNS and ISC released patches for vulnerabilities in software responsible for DNS resolution. The advisories include issues that can cause excessive resource consumption, service interruption, and, under specific conditions, cache poisoning or remote code execution.
For businesses, MSPs, and providers, the priority is to identify the components used, check the affected configurations, and apply the corresponding updates. The PowerDNS Recursor warnings and BIND 9 fixes can help you begin this review.
When DNS fails, users may be unable to access systems even if their internet connection is working. A vulnerability at this layer can also compromise the reliability of the responses used to locate services. Therefore, DNS security in companies includes maintaining the infrastructure that handles queries.
Who needs to review the environment?
The verification process begins with two distinct roles. The recursive resolver retrieves responses on behalf of devices and may cache them. The authoritative server publishes the records of a DNS zone, such as the addresses associated with a company's domain.
PowerDNS maintains separate products for these functions: Recursor and Authoritative Server. BIND 9 can be configured for different roles. Identifying only the vendor name is insufficient to choose the correct solution.
Those who manage these servers should check the product, version, and conditions of each notification. The review also covers DNS software embedded in appliances, virtual machines, and containers, according to the components present in each installation.
When the service is outsourced, it is necessary to request confirmation from the provider regarding the applicability of the vulnerabilities and the measures taken. A local DNS server that forwards queries to another service also needs to be included in the inventory: forwarding does not update the software installed on the company's premises.
PowerDNS Recursor and DNSSEC Validation Failure
CVE -2026-85555 allows bypassing DNSSEC validation in a specific situation: when a name server record, or NS, points to a local zone. In this resolution path, the program can also fail to validate subsequent steps of the query.
This opens the possibility of cache poisoning, where inappropriate DNS data is stored and begins to influence subsequent responses. For the operation, the risk is using incorrect information when locating a service.
The problem lies in the resolver's processing. The warning does not describe a breach of DNSSEC cryptography, which validates the authenticity and integrity of signed DNS data. The fix requires updating the vulnerable implementation.
Other malfunctions may affect the operation of the Recursor
Bulletin 2026-12 compiles seven CVEs. In addition to the DNSSEC failure, there are issues with packet handling, connections, and process resources.
| Vulnerability | Effect described in the warning |
|---|---|
| CVE-2026-73206 | Excessive resource consumption during DNS name decompression, with a risk of denial of service. |
| CVE-2026-73205 | An accumulation of terminated TCP connections in the TIME_WAIT state, which can prevent new outgoing connections. |
| CVE-2026-85556 | Accepting an EDNS option that should be rejected, bypassing a protection related to EDNS Client Subnet (ECS). |
| CVE-2026-85557 | A client can monopolize access to the internal web server when its TLS is enabled. |
| CVE-2026-85558 | Memory leak due to the retention of addresses of TCP clients that have already disconnected. |
| CVE-2026-85559 | Possible termination of the Recursor in configurations that accept EDNS Client Subnet in incoming queries. |
Conditions vary between failures. Web interface unavailability, for example, has a different scope than resolver shutdown. The team should use the bulletin to relate each problem to the resources enabled in the environment.
The PowerDNS Authoritative Server also received a fix
CVE-2026-73206 also appears in PowerDNS Authoritative Server advisory 2026-13, published on the same day. Processing packets prepared to exploit name decompression may consume excessive resources and cause denial of service.
This point is of particular interest to providers and teams that host DNS zones. An outage in authoritative servers can affect the retrieval of domain records, depending on the redundancy available and the responses still cached by resolvers.
The Resource Server and Authoritative Server have their own versions and updates. Fixing one does not automatically update the other.
BIND 9 has availability flaws and code execution risk
ISC has disclosed four vulnerabilities in BIND 9. Their applicability depends on the version and, in some cases, on specific configuration functionalities.
Excessive CPU and memory usage
CVE -2026-19630 affects the processing of certain DNS messages in the resolver. These messages may require a disproportionate amount of CPU and memory, leading to denial of service.
In operation, this may appear as delays in responses or unavailability. Increased consumption, on its own, does not prove exploitation: the investigation needs to consider service records and traffic conditions.
Memory corruption in GSS-TSIG messages
CVE -2026-94300 involves handling authenticated messages with GSS-TSIG. The advisory describes memory corruption, termination of the named , and the possibility of remote code execution.
Exploitation requires specific conditions, including access to a previously signed UDP message and its reuse while the negotiated key remains valid. The ability to execute code also depends on additional conditions described by the ISC.
Interruption in configurations with redirection and RPZ
CVE -2026-96888 may terminate a resolver that combines a redirect zone with qname -minimization strict.
CVE -2026-97313 involves servers that allow recursion and have at least two RPZ zones, used to apply policies to DNS responses. The described condition includes one zone with recursive-only yes and another with recursive-only no. Certain query patterns can terminate the process.
In the four bulletins consulted on October 23, the ISC reports that it is unaware of any active exploitation or known alternative solutions. The recommendations point to the need for updating. The existence of these vulnerabilities does not, in itself, demonstrate that a company has been attacked.
Which versions received the fixes?
The versions below are the first fixes indicated by the manufacturers for the branches presented, in the notices of October 21, 2026. They serve as a historical reference; before updating, check the current corrected and supported version.
| Product and branch | Affected versions in the branch | First correction |
|---|---|---|
| PowerDNS Resource 5.3 | Until 5.3.11 | 5.3.12 |
| PowerDNS Resource 5.4 | Up to 5.4.7 | 5.4.8 |
| PowerDNS Authoritative 4.9 | Until 4.9.17 | 4.9.18 |
| PowerDNS Authoritative 5.0 | Up to 5.0.7 | 5.0.8 |
| PowerDNS Authoritative 5.1 | Up to 5.1.4 | 5.1.5 |
| BIND 9.20 | 9.20.0 to 9.20.29 | 9.20.30 |
In PowerDNS, the releases of Recursor 5.3.12 and Authoritative Server include the fixes. The manufacturer also released Recursor 5.3.13 on the same day, with a performance adjustment related to the use of EDNS Client Subnet. Those following the 5.3 series should also consider this update.
In BIND, the stable version indicated by ISC at the time of verification is 9.20.30. Version 9.21.27 also received fixes, but belongs to the development branch. For Supported Preview Edition customers, the notifications indicate 9.20.30-S1.
Older versions require attention to support. BIND 9.18 appears as discontinued on ISC, and PowerDNS Recursor 5.2 and earlier are end-of-life in open source support. The absence of a fix for an older branch does not mean it is protected. For distribution packages, appliances, or extended support contracts, confirm the applicable bulletin and the update provided by the issuer.
What to review in the DNS infrastructure
Map the query path
Identify the resolvers used by workstations, servers, and branch offices. Include local forwarders and external services. For each component, record the product, version, function, and person responsible for maintenance.
In an MSP, perform this survey on a per-client basis. In an ISP, also check the different nodes that serve subscribers. A virtual or load-balanced address can represent multiple servers, and the update needs to reach each affected installation.
Plan the upgrade according to the function of each server
Read the update notes and keep a copy of your configuration before making the change. Verify the compatibility of local zones, integrations, and policies used. In redundant environments, plan the sequence to maintain serviceability during maintenance.
Two servers with the same vulnerable version remain exposed to the same flaw. Redundancy helps with continuity, but it also needs to be factored into the patch planning.
Check the conditions described in the bulletins
In PowerDNS, consider scenarios involving local zones, EDNS Client Subnet, and internal web server. In BIND, the review should consider GSS-TSIG, RPZ, and the combination of redirection with strict QNAME minimization.
These details help prioritize the environments. Improvised alterations to safety mechanisms can have other effects on operation; follow the correction indicated for the product and validate any temporary measure with the technical manager.
Validate the resolution after the change
Confirm that the processes are running the expected version. Test the resolution of the services used by the organization, access to internal zones, and existing blocking and allowing policies. Where DNSSEC validation is present, also verify its functionality.
Monitor latency, resolution errors, CPU and memory usage, and unexpected restarts. Compare the behavior to the environment's standard. A process that resumed functioning after restarting still needs the patch that addresses the vulnerability.
What to request from your managed DNS provider
A company can rely on these components without directly managing them. In that case, ask the supplier for information that allows you to monitor risk management:
- Does the service use any of the products and configurations covered by the warnings?
- Have the applicable fixes been deployed across all nodes serving the company?
- How does the provider monitor resolution issues and maintain support during updates?
- Is any action required on the routers, appliances, or other local components?
Document the response and any outstanding issues, including assigned responsibilities and deadlines. The guide on what to evaluate in a Protective DNS solution helps broaden this conversation to include service availability, redundancy, and visibility.
When to consider a managed recursive DNS
Maintaining your own recursive resolver requires monitoring vulnerabilities, applying updates, and ensuring service availability. For companies and MSPs that prefer to delegate this operation, Lumiun DNS is an alternative to handle internet domain resolution.
The service offers DNSSEC validation, which verifies the authenticity and integrity of signed DNS data, and supports DNS over HTTPS (DoH) and DNS over TLS (DoT). When configured on devices or forwarders, DoH and DoT encrypt communication between these components and Lumiun DNS.
The platform also includes security filters and access policies to block domains associated with phishing and malware, as well as logs and reports of queries and blocks. These features help the IT team investigate attempts to access suspicious domains and adjust browsing rules.
Adoption can be done by forwarding queries from an existing server. In environments with Active Directory or internal zones, the local DNS can continue to handle the organization's names, while internet queries are routed to Lumiun DNS. Components that remain in use will still require maintenance and updates.
