Chris Buxton chris.p.buxton at gmail.com
Fri Jul 8 17:15:51 UTC 2011

On Jul 8, 2011, at 9:05 AM, Kevin Darcy wrote:
> On 7/8/2011 3:04 AM, Chris Buxton wrote:
>> As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard.
> OK, I stand corrected. It's mandatory per a Proposed Standard that hasn't had any major objections, reported flaws, or updates in years, and is implemented in virtually every authoritative nameserver -- including load-balancers, pretending to be auth nameservers, and which break a whole raft of other standards and/or best practices -- and resolver.
> *Technically* a negative response can be given that does not conform to RFC 2308, and no RFC Police will show up at one's doorstep wielding an arrest warrant...

I'm not disagreeing with your points above, merely being a pedant. Obviously it's a good thing when negative answers are cacheable.

>> Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point.
> Um, Section 8 talks about how resolvers deal with negative caching.

Interesting, then, that it's titled, "Changes from RFC 1034". You're right, of course, but the title is confusing.

> Section 3 talks about responses from authoritative servers, and that was the subject of this thread. Section 3 is quite clear on the point:

Agreed. I stand corrected on this point.

A bit confusing, though, that Mark chose to include in his examples in section 2 cases where the authority section is empty.

Regardless, my primary point was that, while returning a cacheable negative answer is now pretty much standard behavior, a resolver should still be able to cope with a completely empty negative response. I do still see them from time to time, although I don't have an example to hand.

Chris Buxton
BlueCat Networks

More information about the bind-users mailing list