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

Mukund Sivaraman <muks@isc.org> Mon, 23 November 2015 19:58 UTC

Return-Path: <muks@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 D6EE51B2F15 for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 11:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Level:
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no
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 pORmZK3x02i6 for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 11:58:32 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC91B2C80 for <dnsop@ietf.org>; Mon, 23 Nov 2015 11:58:32 -0800 (PST)
Received: from jurassic.l0.malgudi.org (unknown [115.118.222.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 1F72C2BA0E27; Mon, 23 Nov 2015 19:58:29 +0000 (GMT)
Date: Tue, 24 Nov 2015 01:28:26 +0530
From: Mukund Sivaraman <muks@isc.org>
To: 神明達哉 <jinmei@wide.ad.jp>
Message-ID: <20151123195826.GA4556@jurassic.l0.malgudi.org>
References: <20151123135808.2730.32721.idtracker@ietfa.amsl.com> <20151123160748.GA3031@jurassic.l0.malgudi.org> <CAJE_bqc4=_s0rioJdOORJQaXDOrBXcy0yFJc9n0UZbRcuHsy+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU"
Content-Disposition: inline
In-Reply-To: <CAJE_bqc4=_s0rioJdOORJQaXDOrBXcy0yFJc9n0UZbRcuHsy+Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/yWgwh7Hq0lUouut4felLYF8cmy8>
Cc: dnsop <dnsop@ietf.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: Mon, 23 Nov 2015 19:58:34 -0000

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?

		Mukund