Re: negative caching support

Chris Thompson <cet1@cus.cam.ac.uk> Thu, 03 October 2002 12:02 UTC

From: Chris Thompson <cet1@cus.cam.ac.uk>
Subject: Re: negative caching support
Date: Thu, 03 Oct 2002 13:02:16 +0100
Lines: 30
Sender: owner-namedroppers@ops.ietf.org
References: <20021003111512.GA12928@outpost.ds9a.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
To: ahu@ds9a.nl
In-Reply-To: <20021003111512.GA12928@outpost.ds9a.nl> from "bert hubert" at Oct 3, 2 01:15:12 pm
Content-Length: 1221
Precedence: bulk
Message-ID: <20140418071640.2560.42593.ARCHIVE@ietfa.amsl.com>

ahu@ds9a.nl (bert hubert) writes:

> RFC 1034 mentions the following about negative response caching:
> 
>  The method is that a name server may add an SOA RR to the additional
>  section of a response when that response is authoritative.  The SOA must
>  be that of the zone which was the source of the authoritative data in
>  the answer section, or name error if applicable.  The MINIMUM field of
>  the SOA controls the length of time that the negative result may be
>  cached.
> 
> However, bind 8 and 9 add the SOA RR to the authority section.

RFC 1034 section 4.3.4, which you quote, is *explicitly* obsoleted by RFC 2308.

> In the interest of interoperability, what do you suggest an authoritive DNS
> implementation should do? Follow the RFC or bind?

If anyone seriously imagines they can create a new DNS server implementation 
by looking only at RFC 1034-5, and not bothering about all those tedious
updating RFCs until later (if at all), they are out of their tiny minds! 

Chris Thompson
Email: cet1@cam.ac.uk

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

negative caching support bert hubert
Re: negative caching support Peter Koch
Re: negative caching support Chris Thompson
Re: negative caching support bert hubert
Re: negative caching support Don Moore
Re: negative caching support bert hubert
Re: negative caching support Peter Koch
Re: Re: negative caching support Marcos Sanz/Denic