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

Mark Andrews <marka@isc.org> Tue, 24 November 2015 22:23 UTC

Return-Path: <marka@isc.org>
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 5CA171A8ADF for <dnsop@ietfa.amsl.com>; Tue, 24 Nov 2015 14:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] 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 O7bkUNoWhwUj for <dnsop@ietfa.amsl.com>; Tue, 24 Nov 2015 14:23:55 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F581A906A for <dnsop@ietf.org>; Tue, 24 Nov 2015 14:23:53 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 52B971FCAD0; Tue, 24 Nov 2015 22:23:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2AA90160045; Tue, 24 Nov 2015 22:25:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0DBF916006E; Tue, 24 Nov 2015 22:25:13 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 21mwOjs2wDtE; Tue, 24 Nov 2015 22:25:12 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 8A05E160045; Tue, 24 Nov 2015 22:25:12 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DF72E3D84B26; Wed, 25 Nov 2015 09:23:50 +1100 (EST)
To: John Heidemann <johnh@isi.edu>
From: Mark Andrews <marka@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>
In-reply-to: Your message of "Tue, 24 Nov 2015 13:26:13 -0800." <17673.1448400373@dash.isi.edu>
Date: Wed, 25 Nov 2015 09:23:50 +1100
Message-Id: <20151124222350.DF72E3D84B26@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/bBtd-rVTFKRNbCv4F94gHQvs91E>
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: Tue, 24 Nov 2015 22:23:57 -0000

In message <17673.1448400373@dash.isi.edu>du>, 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.
 
> Proposed 5966bis reiterates what was first said in RFC5966: DNS messages
> over TCP may have replies sent in different order than queries.
> However, TCP guarantees that the CONTENTS of each DNS message will be
> provided in strict order, even if it spans multiple TCP segments.

>    -John Heidemann
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org