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