Remediation Guides

DNS Server Recursive Query Cache Poisoning Weakness: How to Fix Nessus 10539

26 September 2026 7 min read

DNS Server Recursive Query Cache Poisoning Weakness means your DNS server resolves names on behalf of any client that can reach it, including the scanner. Fix it by allowing recursion only for internal networks: in BIND use an allow-recursion ACL or recursion no;, on Windows DNS disable recursion or use recursion scopes, then rescan.

What the scanner is actually detecting

The check is simple. The scanner asks your server to resolve a third-party name, one your server is not authoritative for, with recursion requested. If the server goes out, resolves it and returns an answer, the finding fires. Nothing is exploited during the test.

  • Nessus plugin 10539, “DNS Server Recursive Query Cache Poisoning Weakness” (family: DNS, severity Medium, CVSS v2 base 5.0, references CVE-1999-0024). Tenable’s synopsis says the name server allows recursive queries to be performed by the host running the scanner.
  • Rapid7 and Fortra (formerly Digital Defense) run equivalent checks under their own titles, typically phrased around a nameserver that processes recursive queries. The underlying condition and the fix are the same.

That wording matters: the result is relative to where the scanner sits. An internal resolver that answers an internal scanner is doing its job. The same server answering a scanner on the Internet is an open resolver.

Real-world risk, stated honestly

The “cache poisoning” in the title reflects the plugin’s age (it dates from 2000 and cites a 1997 CERT advisory). Current BIND and Windows DNS releases include defenses that make classic poisoning much harder, and DNSSEC validation adds another layer. Poisoning is still the reason you do not want strangers driving your cache, but it is not the main practical concern today.

The concrete risks are:

  • Reflection and amplification. Germany’s BSI (CERT-Bund) warns that open resolvers are abused for DDoS reflection attacks against third parties. Your server becomes the weapon, and your uplink carries the traffic.
  • Resource exhaustion. Microsoft notes that a DNS server configured as an open resolver might be vulnerable to resource exhaustion.
  • Cache influence. Anyone who can make your server recurse can choose what it fetches and caches.

If the server is reachable only from internal networks, the finding is usually low priority or expected. If it answers from the Internet, fix it now. Checking which DNS servers are actually reachable from outside is a core part of defining your external attack surface scope.

How to confirm it on the host

Test from a network the server should not serve (a cloud VM or an external vantage point). Use a name that is unlikely to be cached, because the BIND manual notes that recursion no; does not stop clients reading data already in the cache.

dig @203.0.113.53 example.com A +recurse

An open resolver returns status: NOERROR, an answer section and the ra (recursion available) flag. A restricted server typically returns status: REFUSED and dig prints “recursion requested but not available”.

Nmap has an equivalent check:

nmap -sU -p 53 --script=dns-recursion 203.0.113.53

On the server itself, check the current configuration:

# BIND: print the effective config and look for recursion settings
named-checkconf -p | grep -E "recursion|allow-query"

# Windows DNS (PowerShell)
Get-DnsServerRecursion
Get-DnsServerRecursionScope

A common BIND cause is worth knowing: if allow-recursion is not set, BIND falls back to allow-query-cache and then allow-query. A server with allow-query { any; }; for its public zones and no explicit allow-recursion will recurse for everyone.

How to fix it

BIND 9: allow-recursion ACL example for an internal resolver

Define an ACL of the networks you serve and restrict both recursion and cache access to it. Edit /etc/named.conf (RHEL family) or /etc/bind/named.conf.options (Debian and Ubuntu).

acl "internal" {
    localhost;
    localnets;
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
    // add VPN pools, remote sites and IPv6 prefixes you serve
};

options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
    // keep allow-query { any; }; only if this server also hosts public zones
};

Both allow-recursion and allow-query-cache are valid in options and in view blocks, so if you use views, set them in each view. Then check and apply:

named-checkconf
rndc reconfig

BIND 9: authoritative-only server

If the server only publishes your zones and no client uses it as a resolver, turn recursion off entirely. With recursion no;, BIND defaults allow-query-cache to none.

options {
    recursion no;
};

How to disable DNS recursion on Windows Server

For a Windows DNS server that only hosts zones (for example, an external authoritative server), disable recursion. In DNS Manager, right-click the server, choose Properties, open the Advanced tab and, under Server options, select Disable recursion. The PowerShell equivalent:

Set-DnsServerRecursion -Enable $false -PassThru

On older builds without the DnsServer module, dnscmd . /Config /NoRecursion 1 does the same. Microsoft warns that with recursion disabled you cannot use forwarders on that server.

Domain controllers and Windows DNS servers that must resolve for clients

Do not tick “Disable recursion” on a domain controller whose clients rely on it for Internet names; they will stop resolving external domains. Instead, either block port 53 from untrusted networks (next section) or, on Windows Server 2016 and later, use DNS policy recursion scopes so only internal subnets get recursion:

# 1. Define the networks allowed to recurse
Add-DnsServerClientSubnet -Name "InternalNets" -IPv4Subnet "10.0.0.0/8","192.168.0.0/16"

# 2. Create a recursion scope with recursion on
#    (add -Forwarder with your current forwarders if you use them)
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $true

# 3. Send internal clients to that scope
Add-DnsServerQueryResolutionPolicy -Name "RecursionForInternal" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ClientSubnet "EQ,InternalNets"

# 4. Only now switch off recursion in the default scope "."
Set-DnsServerRecursionScope -Name . -EnableRecursion $false

Doing step 4 last avoids a window in which nobody can resolve. DNS policies are stored locally and are not replicated through Active Directory, so repeat this on every DNS server. Microsoft’s own example uses -ServerInterfaceIP instead of -ClientSubnet, which suits servers with separate internal and external interfaces.

Also consider Set-DnsServerRecursion -SecureResponse $true, which makes the server cache only records within the zone of authority of the queried server, to limit cache pollution.

Firewall restriction (any platform)

Where recursion must stay on, restrict UDP and TCP 53 at the perimeter and host firewall to the client networks the server actually serves. This is the least disruptive option for domain controllers and is a sensible second layer even after an ACL change.

How to verify the fix and rescan

  1. Repeat the dig test from the untrusted network with a fresh name. Expect REFUSED or no answer, and no ra flag.
  2. Repeat it from an internal client. Expect a normal answer.
  3. Test IPv6 and TCP too if the server listens on them: dig @2001:db8::53 example.com A +tcp.
  4. Rescan from the same scanner position that raised the finding. If the scanner sits inside your allowed range, the finding will correctly persist (see false positives below).

What can break and how to roll back

  • Missed networks. VPN pools, branch offices, DMZ hosts and IPv6 prefixes left out of the ACL or client subnet get REFUSED. Watch helpdesk tickets and resolver logs after the change.
  • Downstream DNS servers. Other DNS servers that forward to this one need to be inside the allowed range.
  • Forwarders. Disabling recursion on Windows also stops forwarding on that server.
  • Clients on a DC with recursion disabled lose Internet name resolution.

Rollback is quick:

# BIND: restore the previous named.conf, then
named-checkconf
rndc reconfig

# Windows: re-enable recursion
Set-DnsServerRecursion -Enable $true

# Windows with recursion scopes: re-enable default scope, remove policy
Set-DnsServerRecursionScope -Name . -EnableRecursion $true
Remove-DnsServerQueryResolutionPolicy -Name "RecursionForInternal"

Common false positive reasons

  • Internal scanner, internal resolver. The scanner is inside the allowed range, so recursion is intended. Record it as accepted or expected rather than disabling recursion.
  • The IP is not your DNS server. Firewalls, routers and load balancers often run a DNS proxy on port 53. The finding belongs to that device’s configuration.
  • Answers from cache. A server with recursion off may still return cached data if cache access is not restricted.
  • Load-balanced or anycast addresses. One misconfigured backend can make the result appear intermittently.

A related DNS hygiene check while you are in the zone files: stale records pointing at deprovisioned cloud resources, covered in our guide to dangling DNS and subdomain takeover.

FAQ

Should I disable recursion on a domain controller?

Usually not. Clients depend on it for Internet names. Restrict who can reach port 53 or use recursion scopes on Windows Server 2016 and later.

How do I fix Nessus 10539 on BIND?

Set allow-recursion { internal; }; with an ACL of your networks, or recursion no; on authoritative-only servers, then run rndc reconfig and rescan from outside the ACL.

Does DNSSEC fix this finding?

No. DNSSEC validation helps against poisoning, but an open resolver can still be used for reflection attacks. Limiting recursion is the fix.

Is this the same as an open DNS resolver?

Only when the server answers recursive queries from the Internet. The same finding from an internal scanner often describes intended behavior.

Tracking this finding across many hosts

When plugin 10539 shows up on dozens of DNS servers and domain controllers, it helps to keep one list. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results come in by uploading the exported .nessus file), merges duplicates per scanner and can retest individual Nessus findings to confirm closure after the change.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles