Re: TCP response with truncated bit set?

[Paul Vixie <paul@vix.com>]

> > >>  Is there any reasonable action a client can take in this case, or is
> > >>  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.
> > 
> > Not being an implementer, but as a protocol wonk, I agree.  There's 
> > no fall back from that point within the DNS protocol.
> 
> 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.


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