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

"Wessels, Duane" <dwessels@verisign.com> Mon, 23 November 2015 20:25 UTC

Return-Path: <dwessels@verisign.com>
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 F1DDF1B33D5 for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 12:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 Y75DEghnv4PZ for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 12:25:34 -0800 (PST)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B9E1B33CC for <dnsop@ietf.org>; Mon, 23 Nov 2015 12:25:33 -0800 (PST)
Received: by qgea14 with SMTP id a14so12226752qge.2 for <dnsop@ietf.org>; Mon, 23 Nov 2015 12:25:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=PXATpUksTPyJxyjInWvvTniXFPvAaf55B1TvCuv83I4=; b=Udnd1n5BllQohrWyOM94GSWgAet3Z5Xvg9iPColce4/CqHHCbRuOQQVb6uxrrAWbL+ SDFlOAsTL+uFmaMUDUlCSKCYD/3IpCcK1hBH0yW07+nion1+0fQax02hoXqJMkLjGrUf rvg0DfOdjPetMkIztxpeFN3cYJhnrZ0GNih7sxIDuyXDD2aEa9lH+V/T+eaZII5+BaZ1 OWdoHchD0JgQNoDtug8g8tqF+FzZi4UUxDHnoXmif64er+tEPYflYqkoOCT6XULtEm9c Z/oSsI2aJGnHECh6lBpiyqdjEiK/5Ia3tUhArBtErDYYEr3COgVLssHeqeJDFpzaFF3n lBuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=PXATpUksTPyJxyjInWvvTniXFPvAaf55B1TvCuv83I4=; b=LF0HVViOvQROhsVQo9CmlcU8y+39YZq6KgXxniPKfUry3w5Jn6I3N3QcrfWTgOyYRR qw9zf+YiCgcUhUA+3vZ5qcYv+S9LV9Psx76eTl+rxBUQln2WV5VsrmjOaWnWUl0ZHiHC 6zYdYsCBi3chZcctpXAZvud3xdrP3KG8eG51Leun9jfT+GegWDVK++CIb/g0BmNt6cyr uhc6RvMhh34XK1uveBvu921IGqGrGrn/S0dNXfTgUlhRe51jk6LCFF7Z6VfypvHBtpz+ z+LtV4dvnCmelHCeIQtE4PC7fhHrEdiKQx4auKKnu9mpo4t1Tc8n7i3nFzmOSPrPU01B duxA==
X-Gm-Message-State: ALoCoQk/5gNnqrgkGK1IJodlsijLK1GzWL9m0uQJdICIcDDjCrgNSI+2zt7Bw69iFhsPR/DufJmwbgR8bB8ifHdaukfDtK5UgQ==
X-Received: by 10.140.129.198 with SMTP id 189mr31181412qhb.10.1448310332858; Mon, 23 Nov 2015 12:25:32 -0800 (PST)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id c15sm1759342qkb.11.2015.11.23.12.25.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 23 Nov 2015 12:25:32 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id tANKPV0t001270 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2015 15:25:31 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 23 Nov 2015 15:25:30 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Mukund Sivaraman <muks@isc.org>
Thread-Topic: [DNSOP] Last Call: <draft-ietf-dnsop-5966bis-04.txt> (DNS Transport over TCP - Implementation Requirements) to Internet Standard
Thread-Index: AQHRJfb9U0Rd5c58I0i7V1QiSrSo+p6qGhQA///stpeAAFtIAA==
Date: Mon, 23 Nov 2015 20:25:29 +0000
Message-ID: <6FFF2953-612E-4BC3-BB94-A77E9AF8E478@verisign.com>
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>
In-Reply-To: <20151123195826.GA4556@jurassic.l0.malgudi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FB28DB0DAB5C744D8E6059935CCAB8CC@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/KBR1D91BAD3Y0h5rz0eO0tgS4tA>
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 20:25:36 -0000

> 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.

DW