[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