[bind10-dev] SERVFAIL vs REFUSED in case of 'no such zone'
Peter Koch
pk at DENIC.DE
Tue Dec 7 13:32:57 UTC 2010
On Tue, Dec 07, 2010 at 10:06:39PM +0900, JINMEI Tatuya / ?$B?@L at C#:H wrote:
> Again, if we prefer REFUSED for the compatibility with (the most
> typical behavior of) BIND 9, I'm fine with that. But if we want to
> find the RCODE that best matches the situation for a pure
> authoritative only server, I personally think SERVFAIL is a better
> choice.
FWIW, I tend to agree with Tony. First, not sending a response
at all would be the worst option. Second, inventing a new RCODE or
picking one that hasn't yet been used for this case (NotAuth), is likely
to face deployment and backwards compatibility issues.
On SERVFAIL vs REFUSED I understand the reasoning for BIND9 and why it
doesn't apply similarly to BIND10. Looking at RFC 1035 might help here:
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
Of course, neither code is the perfect match, since an expired zone
isn't necessarily strictly a 'problem with the name server' and
an unavailable zone isn't not served because of policy, but because
data isn't available. Still, I'd see SERVFAIL for expired/not-yet-loaded
zones and REFUSED for not configured ones.
-Peter
More information about the bind10-dev
mailing list