RR and rrset

[Bob Vance]

Thanks :)

>CNAMES chains into previously cached data

Ahhhhh!


>Addditional section processing
>Authority section processing

Which is what I was referring to in my guess ... I guess.


>Also fetching authoritative data to replace additional data

Now, this one I'm not sure about ~%\
and it kinda goes back to my original question -- why doesn't he just
use what's in cache?

So, is this some "special" "fetch" that happens in particular
circumstances?

OK, I'm looking in "The Book" ...
   Hmmm.  Not really discussed there, although I did (re?)learn
   about credibility.
OK. RFCs.
   Hmmm. RFC1034 and RFC1035 were not helpful.
   RFC1034 talks about when RRs are added to the "additional"
   section in replies, but does address the *use* of RRs in cache
   with credibility=addtnl.  In fact, the word "credibility"
   doesn't occur in either RFC.

Could you expand a little on what circumstances this occurs?
Or point me somewhere?

Or is this an implementation (i.e., BIND) issue?

Ahhh.  RFC2136 has:
   "7.3. The Additional Data Section can be used to supply ...
    Servers can use this information or ignore it, at the
    discretion of the implementor.  We discourage caching this
    information for use in subsequent DNS responses.
   "

Which completes my question.
Why cache additional data if it's not gonna be used subsequently?
Or, if it *is* used subsequently, then when is a "proactive" fetch done
to replace it -- and why?



-------------------------------------------------
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 Mark.Andrews at nominum.com
Sent: Saturday, April 07, 2001 7:49 PM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: RR and rrset



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