Subject: TCP response with truncated bit set?

From: Stuart Cheshire <[email-masked]>
Date: Wed, 1 Dec 2004 11:20:27 -0800

If you do a DNS query over UDP and get a response with the TC bit set, 
the client retries using TCP.

If the response received over TCP also has the TC bit set, what does that 
mean?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

--
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: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2004 08:33:54 +1100

> If the response received over TCP also has the TC bit set, what does that 

	It means that the answer would not fit into the buffer used to
	assemble the TCP response.  Note not all implementations use /
	have used 64k buffers.
 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 1 Dec 2004 16:09:01 -0800

>	assemble the TCP response.  Note not all implementations use /

Presumably, even when both the client and authoritative server can handle 
the RR Set, a caching server between them could introduce this behaviour?

Is there any reasonable action a client can take in this case, or is 
giving up the only option?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2004 11:38:32 +1100

> the RR Set, a caching server between them could introduce this behaviour?

	Yes.
 
> giving up the only option?

	Give up at this point.  There have been a number of proposals
	to extend TCP handling to support answers bigger than 64k.

	AXFR really should have been implemented this way rather
	than the way it was.  In other words we knew when the DNS
	was being designed that answers to certian queries would
	exceed 64k and we should have provided a mechanism to handle
	those cases in a standard way.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Dec 2004 11:09:53 +0200

At 19:38 -0500 12/1/04, Mark Andrews wrote:

>>  Stuart Cheshire <[email-masked]>:

>	to extend TCP handling to support answers bigger than 64k.

Not being an implementer, but as a protocol wonk, I agree.  There's 
no fall back from that point within the DNS protocol.

'Course - there's a difference between there being "no fall back" and 
"a fall back is not defined."  The truth is the latter, pragmatically 
this means you can't count on consistent implementation of such a 
situation, hence there isn't a reliable "fall back."

One of the principles of protocol layering is that occasionally you 
encounter an error that can't be handled within the plane and should 
design to kick up a level.  (I think this is expressed in 
Tannenbaum's text, unfortunately mine is in two different hemispheres 
from me now.)  This is such a case.

If I encountered this and had all my tools available to me, etc., the 
next layer up would be FTP.  Okay, maybe SCP to the youngsters out 
there.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

I think my jabber client and SMS phone are talking about me behind my back.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2004 22:43:51 +1100

> next layer up would be FTP.  Okay, maybe SCP to the youngsters out 

	Well there was always a full AXFR and extract the answer from
	that.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Dec 2004 16:00:53 +0000

> Well there was always a full AXFR and extract the answer from that.

or try again with the MD feature originally proposed as part of EDNS1:

   MD       ``More data'' flag.  Valid only in TCP streams where message
            ordering and reliability are guaranteed.  This flag indicates
            that the current message is not the complete request or
            response, and should be aggregated with the following
            message(s) before being considered complete.  Such messages are
            called ``segmented.''  It is an error for the RCODE (including
            the EXTENDED-RCODE), AA flag, or DNS Message ID to differ among
            segments of a segmented message.  It is an error for TC to be
            set on any message of a segmented message.  Any given RR must
            fit completely within a message, and all messages will both
            begin and end on RR boundaries.  Each section in a multipart
            message must appear in normal message order, and each section
            must be complete before later sections are added.  All segments
            of a message must be transmitted contiguously, without
            interleaving of other messages.

it still amazes me to look at the number of things that this WG decided
were too complex and unnecessary, many of which will therefore show up as
vendor-specific extensions.