Re: [DNSOP] Last Call: <draft-ietf-dnsop-5966bis-04.txt> (DNS Transport over TCP - Implementation Requirements) to Internet Standard

John Heidemann <johnh@isi.edu> Wed, 25 November 2015 00:50 UTC

Return-Path: <johnh@isi.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01D11AC3A7 for <dnsop@ietfa.amsl.com>; Tue, 24 Nov 2015 16:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.485
X-Spam-Level:
X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKRf3Z5ukmDm for <dnsop@ietfa.amsl.com>; Tue, 24 Nov 2015 16:50:02 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9BD1A9250 for <dnsop@ietf.org>; Tue, 24 Nov 2015 16:50:01 -0800 (PST)
Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAP0nVni026968; Tue, 24 Nov 2015 16:49:31 -0800 (PST)
Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (Postfix) with ESMTP id BA3C02815DF; Tue, 24 Nov 2015 15:47:33 -0800 (PST)
From: John Heidemann <johnh@isi.edu>
To: Mark Andrews <marka@isc.org>
In-reply-to: <20151124222350.DF72E3D84B26@rock.dv.isc.org>
References: <20151123135808.2730.32721.idtracker@ietfa.amsl.com> <20151123160748.GA3031@jurassic.l0.malgudi.org> <CAJE_bqc4=_s0rioJdOORJQaXDOrBXcy0yFJc9n0UZbRcuHsy+Q@mail.gmail.com> <20151123195826.GA4556@jurassic.l0.malgudi.org> <6FFF2953-612E-4BC3-BB94-A77E9AF8E478@verisign.com> <17673.1448400373@dash.isi.edu> <20151124222350.DF72E3D84B26@rock.dv.isc.org>
X-url: http://www.isi.edu/~johnh/
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 24 Nov 2015 15:47:33 -0800
Message-ID: <24895.1448408853@dash.isi.edu>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: johnh@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/twLRHGMpT5t7t7V3NMO3qHzsZ0M>
Cc: dnsop <dnsop@ietf.org>, "Wessels, Duane" <dwessels@verisign.com>, Mukund Sivaraman <muks@isc.org>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-5966bis-04.txt> (DNS Transport over TCP - Implementation Requirements) to Internet Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 00:50:03 -0000

On Wed, 25 Nov 2015 09:23:50 +1100, Mark Andrews wrote: 
>
>
>In message <17673.1448400373@dash.isi.edu>, John Heidemann writes:
>> On Mon, 23 Nov 2015 20:25:29 +0000, "Wessels, Duane" wrote: 
>> >
>> >> On Nov 23, 2015, at 11:58 AM, Mukund Sivaraman <muks@isc.org> wrote:
>> >> 
>> >> Hi Jinmei
>> >> 
>> >> On Mon, Nov 23, 2015 at 10:31:23AM -0800, 神明達哉 wrote:
>> >>> At Mon, 23 Nov 2015 21:37:48 +0530,
>> >>> Mukund Sivaraman <muks@isc.org> wrote:
>> >>> 
>> >>>> While looking at a bug last week in an implementation of 5966bis and
>> >>>> AXFR, I found that there's no explicit mention of AXFR and out-of-order
>> >>>> replies. AXFR replies [RFC 5936] can arrive in several messages over
>> >>>> TCP. While 5966bis speaks only about re-ordering replies and not
>> >>>> individiual messages (and so, is not incorrect), I feel that explicitly
>> >>>> describing ordering in the AXFR case would avoid confusion.
>> >>>> 
>> >>>> It seems that AXFR messages would have to be sent in order to avoid
>> >>>> confusion at the client about when a transfer correctly completed
>> >>>> vs. when it timed out. While they can be multiplexed with other DNS
>> >>>> messages, the individual messages of a single transfer must not be sent
>> >>>> out of order.
>> >>> 
>> >>> I'm not sure if I understand the concern...do you mean, for example,
>> >>> if an AXFR consists of the following 3 messages:
>> >>> 
>> >>> Message1: beginning SOA and some RRs
>> >>> Message2: some intermediate RRs
>> >>> Message3: some more intermediate RRs
>> >>> Message4: some more RRs and ending SOA
>> >>> 
>> >>> the client side of AXFR receives them in the order of, e.g., Message2,
>> >>> Message3, Message4, and then Message1?  That is, Message1 is not
>> >>> necessarily sent/received first and/or Message4 is not necessarily
>> >>> sent/received last?
>> >> 
>> >> Yes. Without them being in order, it doesn't seem the client can
>> >> determine upon timeout if all messages corresponding to the transfer
>> >> have been received, or if the transfer is incomplete.
>> >> 
>> >> Example:
>> >> 
>> >> (1) Message1, Message4, Message2, Message3 received.
>> >> Timeout complete and TCP still connected.
>> >> 
>> >> (2) Message1, Message4, Message2 received. [Message3] not received when
>> >> timeout complete and TCP still connected.
>> >> 
>> >> How can client know that in (2), the whole transfer was not received?
>> >
>> >
>> >TCP preserves the order of delivery, so if the messages are received in
>> >the order above, it is an AXFR/IXFR protocol violation by the server.  The
>> >server must send Message4 last.
>> 
>> Perhaps some of the confusion here has to do with overloading the term
>> "message".
>> 
>> There are DNS query and response messages and TCP segments.
>> 
>> A DNS message is a query and response (as per RFC1034 and
>> draft-hoffman-dns-terminology-02).
>
>A query is a DNS message.  A response is one or more DNS messages.
> 
>> For AXFRs, the DNS message maybe large enough that it is split into
>> multiple TCP segments (each a separate packet).
>
>For AXFR/IXFR over TCP if the response is large enough or the server
>has been configured to send one record per message it will be split
>into multiple messages each proceeded by its length.  That sequence
>of messages is split into multiple TCP segments.  That sequence of
>messages and lengths may be interleaved with other responses to
>other requests over the same TCP connection with each <length,message>
>pair treated as a atomic unit on the TCP connection.
>
>A TCP segment boundaries and message boundaries are not required
>to be aligned.  The contents of two messages may appear in one
>segment.
>
>The sequence of DNS messages that make up a AXFR / IXFR response
>are orders as per the requirements of AXFR and IXFR.
>
>> The statement:  "an AXFR consists of the following 3 messages: Message1:
>> beginning SOA and some RRs, Message2: some intermediate RRs, Message3:
>> some more intermediate RRs..."  I think conflates these concepts (it
>> uses the term "message" incorrectly).  The AXFR reply does NOT consist
>> of 3 DNS messages, it is ONE DNS message that is split into 3 or more
>> TCP segments.
>
>No.  It consists of a sequence (one or more) messages.

Of course you're correct---with large zones the reply would easily
exceed the 16-bit DNS message length.  Sorry, it was I who misunderstood
the original post.  Apologies to Mukund and Duane.

(You know, clearly what this thing needs is some additional form of
message fragementation and reassembly :-)

   -John Heidemann