Back to Blog
Rcode for error in dns5/17/2023 ![]() The error is often RCODE 5 (REFUSED), on the grounds that the nameserver refuses to perform the specified operation for policy reasons. It appears today that this answer is widely scorned by DNS operators (partly because it can be used in amplification attacks), and many nameservers these days will return an error. So, historically, many nameservers responded with a referral to the root. After all, the very act of delegating a nameserver from a parent involves claiming (authoritatively) that the nameservers named by the NS records are the right nameservers. In principle, it should be really strange that a nameserver receives a query for a name for which it is not authoritative. This is a refusal because the “the nameserver refuses to perform the specified operation for policy reasons”. Following RFC 1035, a conforming nameserver should issue an RCODE 5 (REFUSED) response. It has no zone file for that domain name and, therefore, it has nothing to respond with. Here's a partial answer, starting with this DynDNS blog post I found.įrom the nameserver’s perspective, it is being asked to answer a question outside of its configured response-ability (DNS pun!). Less clear than REFUSED in that it doesn't clearly indicate that the non-answer is deliberate SERVFAIL is normally used for unexpected errors encountered when processing valid queries. Status SERVFAILĪlso used by some server implementations. Overall a good fit, whether or not it's not explicitly mandated that it must be used in this particular case. ![]() REFUSED is generally considered the best approach, indicates that the server is configured not to answer this query. (I think this is probably the least silly form of NOERROR use in this context.) Other options Status REFUSED ![]() The contents of the answer are not useful per se but it is a validly formed referral response that at least makes it clear that the queried server doesn't know about that name. This was a very common way of dealing with this in the past. Return a canned referral to the root nameservers (this is even sillier) If this a query that cannot be answered, NOERROR seems like a bad fit. NOERROR indicates that the query was considered valid and answerable, so there should be some form of answer. The argument against NXDOMAIN applies to NODATA ( NOERROR + SOA in authority section) as well with only minor adjustment it's a status which is used to indicate that you know that there is no such RRset, not that you lack knowledge.Īdditionally, NODATA suggests that you know that this name exists in some shape or form (eg, it may have records of other types or it may be an empty non-terminal). Return a non-authoritative NOERROR response (this is silly, but I mention it for completeness)įirst of all, I'll note that the "referral to the root" alternative is a special case of this one. NXDOMAIN is used to indicate that you know that a name does not exist, not that you do not know anything about the name. This is not in line with how NXDOMAIN is otherwise used. (I would consider this the worst option.) Return a non-authoritative NXDOMAIN response It's also bad from the client perspective as it may lead to waiting until some timeout expires rather than quickly getting an error. ![]() This is bad for the operator of the authoritative server as this approach would make the server appear to be down, opening for scenarios where recursing servers have observed it repeatedly not answering their queries and give up on it entirely, regardless the QNAME. I'll outline some thoughts on some of the different options below: The options outlined in the question Blackhole the query entirely That said, over the years the consensus has more or less become that REFUSED is the best option out of what tools we have available. I do not believe that there is a outright statement in the standards documents (at least not the original DNS RFCs) of how to deal with this particular scenario.
0 Comments
Read More
Leave a Reply. |