REFUSED DNS response code (RCODE 5)

What’s actually happening

You get a fast, deliberate REFUSED — the server isn't broken or slow, it's saying no on purpose. Two situations dominate. Either you asked an authoritative server to recurse for a domain it doesn't host, or you queried a server for a zone it isn't actually authoritative for. Note the missing ra flag in the header: recursion available is off, so the server won't chase the query for you.

Common causes

• Querying an authoritative-only server as if it were a recursive resolver (no ra flag)
• Asking a nameserver for a zone it isn't authoritative for
• Resolver ACL / allow-query restricting which clients or source IPs may query
• Registrar still delegating to old nameservers that no longer host the zone
• Recursion deliberately disabled (correct hardening) but the client expected an open resolver

How to fix it

1. Match the query to the server's roleIf you need recursion, ask a recursive resolver (1.1.1.1, 8.8.8.8, or your ISP's), not the domain's authoritative NS. Authoritative servers answer only for their own zones and refuse the rest.
2. Verify the server is authoritative for the zonedig SOA example.com @ns-in-question — if it refuses or returns no SOA, that host doesn't serve the zone. Point the query at the correct nameservers from dig NS example.com.
3. Fix delegation at the registrarIf the public answer is REFUSED, the TLD may still delegate to retired nameservers. Update the NS records at the registrar to the hosts that actually carry the zone, then wait out the TTL.
4. Open or correct resolver ACLsOn BIND/Unbound, check allow-query and access-control. If legitimate clients are refused, add their subnet; if it's meant to be private, that REFUSED is the server doing its job — query from an allowed network.
5. Confirm whether recursion should be onA public authoritative server should refuse recursion. A LAN resolver should allow it for internal clients only. Set recursion yes/no to match intent rather than exposing an open resolver.