DNS Query Refused: Find the Server Policy Behind the Error

When a DNS lookup fails with REFUSED (standardized as RCODE 5 in RFC 1035), your network stack received a valid, authoritative DNS packet in return. That distinction is crucial: a timeout means no answer arrived before the socket deadline, while NXDOMAIN (RCODE 3) confirms the queried domain name does not exist. A REFUSED response means the target nameserver is running, healthy, and reachable, but its security policy explicitly forbids answering your query.

The mechanics of RCODE 5: Why nameservers refuse queries

Every production DNS server operates under one of two primary architectural roles: authoritative or recursive. Confusing these roles is the single most common cause of REFUSED errors in modern network infrastructure.

Authoritative nameservers publish records for specific forward and reverse zones. To protect themselves from being weaponized in distributed denial-of-service (DDoS) DNS amplification attacks, modern authoritative servers (like BIND 9, PowerDNS, Knot DNS, and NSD) disable recursion globally. If a client queries an authoritative nameserver for an arbitrary external domain (e.g., asking Cloudflare's authoritative nameservers for google.com), the server returns REFUSED immediately.

Conversely, recursive resolvers (like Unbound, Infoblox, or Microsoft DNS) perform iterative lookups across the global internet hierarchy on behalf of end users. Because open recursive resolvers are dangerous to the global internet routing fabric, network administrators restrict recursion to trusted IP subnets using Access Control Lists (ACLs). When a remote developer, an off-premise employee, or a split-tunnel VPN client attempts to resolve records through an enterprise resolver without being in the allowed subnet list, the resolver returns REFUSED.

Step 1: Reproduce and analyze the raw DNS response with dig

Browser error screens (like ERR_NAME_NOT_RESOLVED) conceal the exact DNS response code. To isolate the problem, run dig or Resolve-DnsName against both your default resolver and a public recursive resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8).

# 1. Test your default system resolver
dig example.com A

# 2. Test directly against your enterprise or ISP resolver
dig @192.0.2.53 example.com A

# 3. Test through a public open resolver to rule out global zone breakage
dig @1.1.1.1 example.com A

Examine the HEADER section in the output. When a query is refused, status: REFUSED appears prominently next to the opcode and query ID. In addition, check the flags section: if rd (Recursion Desired) was set in your request, look for whether ra (Recursion Available) is missing in the response. A missing ra flag confirms that the responding server does not offer recursive lookups to your client.

Step 2: Checking authoritative delegation vs. recursion

If you are querying your own domain and seeing REFUSED, verify whether the nameservers you are asking are actually delegated for that zone at the parent TLD registry. Use the non-recursive flag +norecurse to ask the authoritative server directly:

# Query the authoritative nameserver directly for its own zone
dig @ns1.yourdomain.com yourdomain.com SOA +norecurse

# Expected healthy answer:
# ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
# Note the 'aa' (Authoritative Answer) flag. If you get REFUSED here,
# the zone file is either not loaded or the server lacks a zone declaration.

If dig +norecurse returns REFUSED for a domain the server is supposed to host, check the following server configurations:

• Zone not loaded in named.conf / pdns.conf: The nameserver has started, but the zone definition file has a syntax error (e.g., missing semicolons, bad serial format) preventing it from loading into memory.
• BIND 9 view mismatch: If split-horizon DNS is configured with views, your client's IP may match an external view that does not include the internal zone definition.
• PowerDNS backend disconnect: PowerDNS cannot communicate with its MySQL or PostgreSQL backend database, causing it to refuse queries for unresolvable local zones.
• RPZ (Response Policy Zone) filtering: Security software or threat intelligence feeds running on the resolver are actively blocking the domain and returning administrative refusal.

Step 3: Fixing Access Control Lists (ACLs) in BIND and Unbound

If you manage the nameserver, the fix usually involves adjusting access controls. Here is how ACLs and recursion permissions are properly structured in production environments:

// Define trusted internal subnets
acl "trusted-clients" {
    127.0.0.1;
    192.168.1.0/24;
    10.0.0.0/8;
    localhost;
};

options {
    directory "/var/cache/bind";
    
    // Enable recursion only for authorized subnets
    recursion yes;
    allow-recursion { "trusted-clients"; };
    allow-query { any; }; // Allow anyone to query public authoritative zones
    allow-query-cache { "trusted-clients"; };
    
    listen-on port 53 { any; };
    listen-on-v6 { any; };
};

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.1.0/24 allow
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse  # Refuse recursion to unknown external IPs

Common corporate network scenarios: VPNs and Split-Horizon DNS

A frequent corporate IT problem occurs when remote workers connect through split-tunnel VPNs. If the VPN client pushes an enterprise DNS server as the primary resolver, but does not route DNS traffic through the encrypted VPN tunnel, the DNS query exits via the employee's residential internet connection. The corporate firewall or resolver sees an unknown residential Comcast or Vodafone IP address, and immediately returns REFUSED.

To resolve this, ensure that your VPN configuration either forces DNS traffic through the tunnel adapter (full-tunnel DNS), or adds the employee's assigned VPN IP pool (e.g., 10.8.0.0/16) to the resolver's allow-recursion ACL block.

Verification and tools

Verify your nameserver health using the nameserver lookup tool to audit delegated authoritative servers, and run a comprehensive query through the online DNS lookup tool to test record resolution across global public resolvers without local client ACL biases.