[bind10-dev] SERVFAIL vs REFUSED in case of 'no such zone'

[Joao Damas]

I believe SERVFAIL is more appropriate. it means the server failed to obtain a response, because it doesn't have one (it does need to provide some answer, just not answering doesn't help anyone).
REFUSED on the other hand is more geared towards a policy related action, like an ACL or a restriction on query types (like axfr).

Not being able to answer because it doesn't know about the zone is not a policy decision, it is a failure to find the data.

Joao

On 7 Dec 2010, at 09:03, JINMEI Tatuya / 神明達哉 wrote:

> At Tue, 7 Dec 2010 14:32:57 +0100,
> Peter Koch <pk at DENIC.DE> 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.
> 
> Right, I believe most if not all of us agree with these.
> 
>> 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:
> [...]
>> 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.
> 
> Hmm...sounds like a matter of preference in the end:-)  If many of us
> prefer REFUSED for the no matching zone condition, I have no objection
> to that.
> 
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev