RR and rrset

[Mark.Andrews at nominum.com]

> 
> Hmmm.
> I'm not sure how to phrase this, but 5.4 has me a bit confused :
> 
> Since the (owner, class, type) would be the same for a matching request
> (by definition), why would a server ever be getting an answer for
> something that's already in its cache?

	CNAMES chains into previously cached data
	Addditional section processing
	Authority section processing

	Also fetching authoratative data to replace additional data
	
>  Wouldn't it have just answered
> with what was in the cache?
> 
> Or are we, here, talking about data in the sections of the response
> other than the actual query?
>    (e.g., a NS rrset (authority section) coming back in a request
>     for an address (A record) replacing the NS rrset in cache?
>     )
> 
> 
> 
> -------------------------------------------------
> Tks        | <mailto:BVance at sbm.com>
> BV         | <mailto:BobVance at alumni.caltech.edu>
> Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
> Vox 770-623-3430           11455 Lakefield Dr.
> Fax 770-623-3429           Duluth, GA 30097-1511
> =================================================
> 
> 
> 
> 
> 
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
> Behalf Of Paul Vixie
> Sent: Saturday, April 07, 2001 4:26 PM
> To: bind-users at isc.org
> Subject: Re: RR and rrset
> 
> 
> bobvance at alumni.caltech.edu ("Bob Vance") writes:
> 
> > Is it safe to say, then, that all the "RR"s in an "rrset" always have
> > the same owner name and type?
> 
> Yes.  But beware of RFC 1034's use of the term "resource set" which
> refers
> to all RR's sharing a particular domain name, irrespective of type (or
> class,
> which is part of another even larger problem with this document.)
> 
> RFC 2181 also addresses this topic:
> 
>    5.4. Receiving RRSets
> 
>    Servers must never merge RRs from a response with RRs in their cache
>    to form an RRSet.  If a response contains data that would form an
>    RRSet with data in a server's cache the server must either ignore the
>    RRs in the response, or discard the entire RRSet currently in the
>    cache, as appropriate.  Consequently the issue of TTLs varying
>    between the cache and a response does not cause concern, one will be
>    ignored.  That is, one of the data sets is always incorrect if the
>    data from an answer differs from the data in the cache.  The
>    challenge for the server is to determine which of the data sets is
>    correct, if one is, and retain that, while ignoring the other.  Note
>    that if a server receives an answer containing an RRSet that is
>    identical to that in its cache, with the possible exception of the
>    TTL value, it may, optionally, update the TTL in its cache with the
>    TTL of the received answer.  It should do this if the received answer
>    would be considered more authoritative (as discussed in the next
>    section) than the previously cached answer.
> ...
>    5.5. Sending RRSets (reprise)
> 
>    A Resource Record Set should only be included once in any DNS reply.
>    It may occur in any of the Answer, Authority, or Additional
>    Information sections, as required.  However it should not be repeated
>    in the same, or any other, section, except where explicitly required
>    by a specification.  For example, an AXFR response requires the SOA
>    record (always an RRSet containing a single RR) be both the first and
>    last record of the reply.  Where duplicates are required this way,
>    the TTL transmitted in each case must be the same.
> 
> > IOW, would I be correct to say that an "rrset" is that set of all
> > records that match a given (owner, class, type) triplet?
> 
> Yes.
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com