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

From: The IESG <[email-masked]>
Date: Mon, 23 Nov 2015 05:58:08 -0800

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNS Transport over TCP - Implementation Requirements'
  <draft-ietf-dnsop-5966bis-04.txt> as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-12-07. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies the requirement for support of TCP as a
   transport protocol for DNS implementations and provides guidelines
   towards DNS-over-TCP performance on par with that of DNS-over-UDP.
   This document obsoletes RFC5966.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 23 Nov 2015 21:37:48 +0530

Hi all

[sending this to only dnsop@ for our discussion]

>    This document obsoletes RFC5966.

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.

Similarly, describe IXFR too.

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 Nov 2015 10:31:23 -0800

At Mon, 23 Nov 2015 21:37:48 +0530,

> messages, the individual messages of a single transfer must not be sent

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?

--
JINMEI, Tatuya

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 23 Nov 2015 19:42:16 +0000

> On Nov 23, 2015, at 8:07 AM, Mukund Sivaraman <[email-masked]> wrote:
> 

Hi Mukund,

The document authors have discussed this and we feel the addition of this
paragraph in section 7 addresses the issue that you've raised:

   Note that AXFR [RFC5936] and IXFR [RFC1995] have the property that
   one query message might result in multiple response messages.
   Therefore, those protocols have their own specific ordering
   requirements.

Look reasonable?

DW

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 24 Nov 2015 01:28:26 +0530

Hi Jinmei

> necessarily sent/received first and/or Message4 is not necessarily

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 24 Nov 2015 01:31:17 +0530

Hi Duane

>    Therefore, those protocols have their own specific ordering

It does, but I suggest (as this is published after RFC5936 and RFC1995)
that the draft explicitly state that these messages corresponding to a
transfer are not reordered, and also whether they could be multiplexed
with other messages.

		Mukund

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 23 Nov 2015 20:25:29 +0000

> On Nov 23, 2015, at 11:58 AM, Mukund Sivaraman <[email-masked]> wrote:
> 
> Hi Jinmei
> 

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 24 Nov 2015 02:10:07 +0530

Hi Duane

On Mon, Nov 23, 2015 at 08:25:29PM +0000, Wessels, Duane wrote:
> 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.

Because 5966bis talks about reordering, if reordering of individual AXFR
messages were possible, the above would not hold. That's the concern
that I ask to be addressed explicitly in 5966bis, and also the point
about multiplexing other DNS messages with individual AXFR messages.

5966bis currently talks about reordering replies, not individual
messages, so it isn't incorrect. It is worth adding text stating what
happens with transfers clearly.

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 Nov 2015 13:31:07 -0800

At Tue, 24 Nov 2015 01:28:26 +0530,

> How can client know that in (2), the whole transfer was not received?

In both cases the client should simply consider it the end of AXFR
when it sees Message4 (and the client would treat it as an error when
it sees subsequent Message2 or Message3).  To me, that's a quite obvious
consequence of the fact that an AXFR must begin and end with an SOA
and there's no required ordering in the intermediate RRs.

If there's indeed an implementation that doesn't interpret *the
obvious* that way, it might be worth noting explicitly, but from what
I heard and if I understood it correctly, that rather seems to be a
pure implementation problem than a protocol documentation issue.

--
JINMEI, Tatuya

---

From: John Heidemann <[email-masked]>
Date: Tue, 24 Nov 2015 13:26:13 -0800

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

For AXFRs, the DNS message maybe large enough that it is split into
multiple TCP segments (each a separate packet).

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.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Nov 2015 09:23:50 +1100

> draft-hoffman-dns-terminology-02).

A query is a DNS message.  A response is one or more DNS messages.
 
> 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.

> of 3 DNS messages, it is ONE DNS message that is split into 3 or more

No.  It consists of a sequence (one or more) messages.

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

---

From: John Heidemann <[email-masked]>
Date: Tue, 24 Nov 2015 15:47:33 -0800

>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