RR and rrset

Bob Vance bobvance at alumni.caltech.edu
Sat Apr 7 21:35:09 UTC 2001


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?  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.




More information about the bind-users mailing list