DNS RCODE 5

What DNS RCODE 5 Means in Practice

RCODE 5, Refused, is not a “name not found” result. It tells the client that the server understood the query but declined to answer it, which usually points to policy enforcement, access control, or a deliberate configuration decision. That distinction matters because the server is signalling refusal, not data absence.

In operational terms, Refused is often used when the queried client, zone, recursion request, or query pattern falls outside what the server is willing to serve. A resolver, authoritative server, or upstream filtering layer can all generate it, so the response alone does not tell you which control made the decision.

Why Refused Responses Happen

DNS servers use refusal when answering would violate policy, exceed scope, or expose functionality that should stay restricted. Common reasons include blocking recursion from untrusted networks, refusing access to particular zones, denying certain query types, or rejecting requests from sources that fail ACL checks.

That makes Refused different from NXDOMAIN and other negative responses. With Refused, the server is not making a statement about the domain’s existence; it is making a statement about authorization or service policy. For defenders, that means the root cause is usually in access rules, resolver exposure, or upstream filtering rather than in the zone data itself.

The DNS protocol’s response handling is standardised through the IANA registries for protocol parameters and response codes, which is why consistent interpretation across tools and logs matters. IANA is the authoritative reference for those DNS parameter assignments.

How Refused Affects Troubleshooting and Detection

Refused responses can look like application failure when the real issue is policy. If only some clients, subnets, or recursive paths receive RCODE 5, the likely cause is selective control rather than a global DNS outage. That is why troubleshooting should separate server reachability, resolver behaviour, and access policy before assuming a zone defect.

For defenders, repeated Refused responses can also be a signal. They may indicate misrouted internal clients, attempted use of a resolver from disallowed networks, or automated tooling probing DNS services that are intentionally fenced off. In environments where DNS is part of detection, the pattern of refusal can be as useful as a successful answer.

Good DNS troubleshooting also benefits from understanding the surrounding protocol behaviour, including negative caching and recursion rules. NHIMG’s DNS Protocol Fundamentals for Defenders Guide covers the message-level details that help distinguish refusal from other DNS outcomes.

Operational Implications for DNS Policy

Refused is often the cleanest way to enforce a DNS policy without revealing more than necessary. A well-tuned server can deny unauthorized recursion, restrict internal zones, or block unwanted sources while still leaving authorised resolvers fully functional. The challenge is making sure the refusal is intentional, documented, and consistent with the intended trust boundary.

When Refused appears unexpectedly, the main operational question is whether the server is protecting something correctly or misclassifying legitimate traffic. That is especially important in split-horizon DNS, segmented networks, and environments with layered resolvers, where one refusal upstream can mask the real source of the problem downstream.

Risk and Threat Considerations

Refused responses can conceal both misconfiguration and active enforcement. If an organisation depends on DNS for internal resolution, over-restrictive access rules can break legitimate lookups, while under-restrictive rules can expose recursion or zones that should remain private.

Failure mechanism: A server that refuses queries because ACLs, recursion settings, or zone policies are wrong can block valid clients, or, conversely, signal that the environment is deliberately limiting access to reduce abuse and exposure.

Impact: The visible effect ranges from application failures and hard-to-diagnose connectivity issues to reduced attack surface when the refusal is deliberate and correctly scoped. In abuse scenarios, repeated refusal patterns can also reveal probing of protected DNS services.

Practitioner Guidance

What to watch for: Treat Refused as a policy event first, not a data-quality event. Check whether the affected client, network path, or query class is meant to be allowed, and compare the result across authoritative servers, recursive resolvers, and forwarders before changing zone data.

Governance implication: DNS refusal behaviour should be owned as part of resolver policy and network control design, with clear decisions about which sources may recurse, which zones are exposed, and which query patterns should be declined. That prevents accidental outages and makes the response code meaningful during incident triage.

Related resources from NHI Mgmt Group

• What breaks when internal DNS names are preserved but access governance is not updated?
• Why do DNS and edge configuration changes create IAM and security risk?
• What breaks when DNS resolver bugs affect an identity-aware proxy?
• How should teams control high-risk DNS changes in Route53?