What's the difference between REFUSED and SERVFAIL?

Intent. REFUSED (RCODE 5) is a deliberate 'no' — the server is configured not to answer this query and is telling you so on purpose, usually because of an access policy or because you asked it to recurse and it won't. SERVFAIL (RCODE 2) is a failed attempt — the server tried to resolve and something broke. REFUSED means 'I won't'; SERVFAIL means 'I tried and couldn't.' That's why REFUSED almost always points at who you're asking or where you're asking from, not at the domain itself.

Why do I get REFUSED from a nameserver that clearly hosts the domain?

You're probably asking an authoritative-only server to do recursion. Authoritative nameservers answer for the specific zones they host, but most refuse to chase down names they aren't responsible for — that's a recursive resolver's job. If you point a stub query or a forwarder at an authoritative server and ask for a name (or a recursion-required behavior) it doesn't serve, it returns REFUSED. Use a real recursive resolver like 1.1.1.1 or 8.8.8.8 for general lookups, and query the authoritative server only for its own zones.

Our internal DNS started returning REFUSED to some clients — what changed?

Almost always an ACL. Recursive resolvers are normally locked to a set of allowed source networks so they don't become open resolvers abused for amplification attacks. If a client's subnet, VPN range, or NAT egress IP isn't on the allow-list — or someone tightened the list — the server answers REFUSED. Check the resolver's allow-recursion / allowed-clients configuration against the actual source IP the client presents, remembering that VPN and NAT can change that IP.

Views: 7

DNS REFUSED: Fix the Policy Block Response

DNS REFUSED means a server won't answer you on purpose — wrong nameserver, no recursion, or an ACL. Find which in 4 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A lookup returns status: REFUSED, or a tool reports “recursion not available” / “query refused.” The server is reachable and responding — it just won’t give you the answer you asked for.

Symptoms

dig or nslookup shows status: REFUSED in the header.
nslookup prints “Got recursion not available from , trying next server.”
The same name resolves fine through a public resolver but REFUSED through a specific server.
It started after a network change, a new VPN, or a DNS server config update.

What REFUSED Actually Means

REFUSED is DNS response code 5 (RFC 1035): the name server refuses to perform the specified operation for policy reasons. The key word is policy. The server isn’t broken, isn’t overloaded, and didn’t fail to find an answer — it made a decision not to serve you. REFUSED is the only common DNS error that’s a deliberate “no” rather than a failure.

That reframes the whole investigation. With NXDOMAIN you ask “does the name exist?” With SERVFAIL you ask “did resolution break?” With REFUSED you ask two different questions: who am I querying, and where am I querying from? Nearly every REFUSED comes down to one of those. Either you’re asking a server to do something it doesn’t do for anyone — typically recursion on an authoritative-only nameserver — or you’re asking from a place the server’s access-control list doesn’t trust. The server is working exactly as configured. The configuration just doesn’t include you.

Top 3 Causes

You’re asking an authoritative server to recurse - Authoritative nameservers publish answers for their own zones; they aren’t general-purpose resolvers. Point a normal lookup at one and ask it to resolve a name outside its zones (which needs recursion) and a correctly configured server returns REFUSED rather than acting as an open resolver. The tell: REFUSED from the domain’s own nameservers, success from 1.1.1.1.
An ACL is blocking your source IP - Recursive resolvers restrict who may use them, usually by source network, to avoid being abused in DNS amplification attacks. If your client’s IP — including a VPN exit or a NAT egress address — isn’t on the allow-list, the resolver answers REFUSED. The tell: it works from one network and REFUSED from another, or it broke the moment you connected a VPN.
Wrong server or split-horizon view - You’re pointed at a resolver that simply doesn’t serve the zone you want: an internal-only DNS view that refuses external names, a forwarder aimed at the wrong upstream, or a stale /etc/resolv.conf from an old network. The server refuses because, from its configuration’s point of view, this query isn’t its job.

Diagnose with DechoNet

DNS Check resolves the name through a public recursive resolver, independent of your local DNS. If it returns a clean answer while your machine gets REFUSED, the domain is fine — your configured resolver or your network position is the problem, not the zone.
Propagation Check queries multiple resolvers at once. Consistent answers everywhere except your network confirm the REFUSED is local policy (an ACL or a mispointed resolver), not something wrong with the domain’s nameservers.

Resolution Checklist

Read the RCODE: dig example.com and confirm status: REFUSED, not SERVFAIL or NXDOMAIN — they have different fixes.
Check whether you’re hitting an authoritative server by accident: if you used dig @ns1.example.com somethingelse.com, that REFUSED is expected. Use a recursive resolver for general lookups.
Retry against a known recursive resolver: dig @1.1.1.1 example.com and dig @8.8.8.8 example.com. Success here means your local/upstream resolver is refusing you.
Identify your real source IP (VPN and NAT change it) and check it against the resolver’s allow-recursion / allowed-clients list. Add the network or query from an allowed one.
Inspect what your system is actually using: cat /etc/resolv.conf (or your network DNS settings). A stale or wrong resolver address is a common cause after switching networks.
If it’s an internal split-horizon resolver, confirm you’re on the network/view that’s allowed to see the zone you’re asking for.

When to Escalate

If public resolvers answer but your organization’s resolver returns REFUSED, escalate to whoever runs that DNS server: your source network needs to be added to the recursion ACL, or the resolver is misconfigured.
If a domain’s own authoritative nameservers REFUSED a legitimate query for a zone they should serve, that’s a server-side policy error for the domain operator to fix — a client can’t work around an ACL that excludes it.