Subject: Re: do implementations discard the response when TC is set? [Re: handling of additional data (fwd)]

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Aug 2004 15:26:48 +0000

> When Paul said, "doesn't cache it", it could be read two ways: the 
> resolver will use it locally (as long as it's not cached), or it won't 
> be used at all (i.e., it's discarded).
> 
> Which is it?

in the case of BIND, TCP retry is done.  BIND8 will cache nonempty sections
other than the last one, on the assumption that those sections were not
truncated.  (so, TC indicates end-first truncation, not best-fit.)

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Aug 2004 15:40:28 +0000

> Paul, you leave a lot unstated, so I must query again ;-).

Fine by me.  These are topics that "DNS Clarifications" might have covered.

> >in the case of BIND, TCP retry is done.  BIND8 will cache nonempty
> >sections other than the last one, on the assumption that those
> >sections were not truncated.  (so, TC indicates end-first truncation,
> >not best-fit.)
> 
> Does your latter sentence imply that BIND4 and BIND9 will discard 
> non-empty sections other than the last one (as specified as "should" 
> in RFC2181 section 9)?  Or if not, what is done?

BIND4's behaviour changed a lot.  4.9 and later certainly do the same
thing as I described for BIND8 above.  4.8 and earlier was berzerk --
it cached and reused everything, without regard for RRset boundaries.
For example, if there was deviance in the TTL across RRs within an
RRset, then each RR would expire separately, and BIND4.8 would continue
sending the shortened cached RRset in new answer/authority/additional
sections until finally the last RR expired at which point the RRset
would be re-fetched.  And the TC bit didn't affect caching at all --
everything in a response went into a cache, without regard for what
possible RRset-truncation may have occurred.  And when experienced
truncation while building an answer, it would set TC but possibly leave
a truncated RRset in the truncated section.  What a complete disaster.

I have no knowledge of BIND9's behaviour.  I suspect that it's the same
as what I describe for BIND8.  But I mostly stopped writing code a few
years ago, and the reason I didn't describe BIND9's behaviour above is
not that it's known by me to be different, but because I don't know it.

> Are there plans to change the behaviour, or are there specific good
> reasons to do so?

ISC's position is that we'll track the RFC's.  The current behaviour is
our interpretation of what the current RFC's tell, or imply, us to do.
If a new RFC comes along, or if someone argues convincingly that our
interpretation is wrong, then BIND will be changed.  (Note that DJB's
arguments that we misinterpreted the AXFR spec weren't very convincing,
so anyone who was thinking of using that as a counterexample, shouldn't.)

> This has some implications as it may lead to inconsistent data which
> cannot be retrieved in any other (when used for particular type of
> glue) way getting into the caches.

Please explain.  This is a strong area of interest for me, since BIND4's
berzerkness about caching is what caused me to have to start working on it
in the first place.  (I didn't always know what was wrong, but I knew what
I didn't like.)