Open Resolver on Authoritative NS

An authoritative nameserver should only answer queries about zones it is authoritative for. An open resolver answers recursive queries about anything, including zones it has nothing to do with. That makes it usable as an amplification engine for DDoS attacks: an attacker sends a small spoofed query to your nameserver, which sends a much larger answer to the spoofed victim. Once a nameserver gets used in attacks at any scale, it tends to attract takedown notices from ISPs and eventual blocklisting from upstream networks.

Fail: a nameserver answered a recursive query for a domain it is not authoritative for

RedScore probes each of your authoritative nameservers (up to six) by sending a recursive A query for google.com over UDP/53. A correctly configured authoritative server returns REFUSED (rcode 5) or simply does not answer. An open resolver returns NOERROR with the recursion-available (RA) flag set and one or more answer records. The evidence lists each probed NS as open, refused, timeout, or error.

Almost every open-resolver finding traces back to the same root cause: a single nameserver process is configured to do both authoritative service and recursive resolution. Authoritative-only software (NSD, Knot DNS, PowerDNS Authoritative) cannot recurse at all. If your scan flagged this, you are most likely running BIND or Windows DNS Server with default or hand-edited recursion settings.

BIND (named)

Edit the global options in named.conf and disable recursion:

options {
    recursion no;
    allow-recursion { none; };
    allow-query-cache { none; };
    additional-from-cache no;
};

Reload BIND (rndc reconfig, or systemctl reload named) and re-probe. If your operators legitimately need recursion for an internal client base, run a separate recursive resolver (Unbound, dnsmasq) on a different host or interface and keep the authoritative process recursion-free.

Microsoft Windows DNS Server

Disable recursion in DNS Manager: right-click the server, Properties, Advanced tab, check "Disable recursion (also disables forwarders)". Or via PowerShell:

Set-DnsServerRecursion -Enable $false
Restart-Service DNS

If the same Windows DNS server is also being used as a resolver by domain-joined clients, that role needs to be moved to a separate server before disabling recursion on the authoritative one.

PowerDNS Authoritative, NSD, Knot DNS

These are authoritative-only and cannot serve recursive queries themselves. If RedScore is reporting open resolver behaviour from one of them, the problem is upstream: a load balancer, firewall, or NAT in front of port 53 is forwarding inbound queries to a different host (often a recursive resolver behind the same public IP). Audit the network path between the public IP and the actual nameserver process.

Managed DNS (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS)

Major managed providers are not open resolvers. If your scan flagged one, two things are worth checking before opening a vendor ticket. First, confirm the IP being probed is actually the provider's anycast IP by running dig +short A <ns-hostname>. Second, check whether your zone is delegated to a hostname under your own domain (in-bailiwick NS) that resolves to a host you operate, rather than to the provider directly.

Verify the fix

• From outside your network, run dig @<ns-ip> google.com. You want REFUSED in the status line, or no answer at all. Anything else (NOERROR with answers and the RA flag set) means recursion is still on.
• Repeat for every nameserver IP in the evidence. Fixing one server is not enough; every authoritative NS for your domain must refuse recursion.
• Re-run the RedScore lookup. The check only returns pass when every probed NS refuses.

Common pitfalls

• Recursion off but cache still served. Some servers will return cached answers from prior recursion without resolving anything new. Add allow-query-cache none and additional-from-cache no in BIND, or restart the service to clear the cache.
• Internal allow-list mistakes. allow-recursion { trusted; } only works if the trusted ACL is correct. A misconfigured ACL that includes 0.0.0.0/0 makes the server open from anywhere.
• Source-IP allow-lists fail behind NAT. If your edge firewall NATs all inbound traffic, the source IP visible to BIND is the firewall, not the original client. IP-based recursion controls have no meaning in that case.
• Forwarders. forwarders { 8.8.8.8; }; alone does not enable recursion, but pairing it with recursion yes; turns the server into an open recursive forwarder.