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: Pekka Savola <[email-masked]>
Date: Tue, 24 Aug 2004 16:14:19 +0300 (EEST)

[ Moderators note: This post needed manual approval.

   Either because it was posted by a non-subscriber or because it contained
   to many characters (> 20000).

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please fix your subscription addresses or shorten your postings by adding 
   links instead of attachments ] 

Hi,

I'm getting back to this very old message to verify one thing... 
inline..

On Fri, 7 May 2004, Paul Vixie wrote:
> > While do I agree with your recommendation (for the specific case of
> > glue), I'm unable to find the RFC1035 text you refer to.  There's also
> > the following text in RFC2181 section 9 which seems to contradict it:
> 
> oops.  you're right.
> 
> >    Where TC is set, the partial RRSet that would not completely
> >    fit may be left in the response.
> 
> which is why, if TC was set, BIND assumes that the last nonempty section
> has a partial rrset inside it therefore doesn't cache it.  sorry to confuse.

Which is it?

Note that by RFC2181 section 9 any results which have been received 
with TC bit set must be completely ignored:

  Where TC is set, the partial RRSet that would not completely fit may
  be left in the response.  When a DNS client receives a reply with TC
  set, it should ignore that response, and query again, using a
  mechanism, such as a TCP connection, that will permit larger 
  replies.

In other words, I'm interested whether that is operationally the case
in the implementations.

(I could think of cases where the implementation might ignore this
rule and use the result given in the UDP response, if there's useful
information there, if e.g., the TCP retry fails..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Aug 2004 02:34:33 -0000

> In other words, I'm interested whether that is operationally the case

To truncate a packet, I set TC and discard all records in the packet.

(Originally I set TC and truncated the packet at 512 bytes. This is the
most obvious interpretation of ``longer messages [than 512 bytes] are
truncated'' in RFC 1035. Unfortunately, the Squid cache---at least at
the time---died if it received a packet truncated between records.)

On the client side, if I see a TC, I discard the packet and try again
through TCP. This happens almost immediately after packet receipt. The
records in the packet aren't even read, let alone used in any way.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago