Subject: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis

From: Tim Wicinski <[email-masked]>
Date: Fri, 9 Oct 2015 15:21:14 -0400

I've spent some time reviewing this document and I feel that all the 
outstanding issues have been addressed, and the document is very well 
put together.  This is ready for the next step.

This starts a Working Group Last Call for draft-ietf-dnsop-5966bis

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 
20:00 UTC 23 October 2015.

thanks
tim

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 09 Oct 2015 15:53:30 -0400

On 9 Oct 2015, at 15:21, Tim Wicinski wrote:

> feels the document is *not* ready for publication, please speak out 
> with your reasons.
>

This document is clear, easy to read, fills a need, and I support its 
publication as-is. I made a few notes as I read through, but it would be 
entirely fine with me if they were all ignored.

Section 4 -- a reference to 6891 at the first mention of EDNS(0) seems 
like it might be helpful. It's cited in the fourth paragraph, but not 
the first paragraph.

Section 5, third bullet point: the final phrase seems a bit awkward (it 
seems to suggest TCP being required between a stub resolver library and 
its clients, which I don't think is intended. Suggest:

OLD:

    o  Stub resolver implementations (e.g., an operating system's DNS
       resolution library) MUST support TCP since to do otherwise would
       limit their interoperability with their own clients and with
       upstream servers.

NEW:

    o  Stub resolver implementations (e.g., an operating system's DNS
       resolution library) MUST support TCP since to do otherwise would
       limit the interoperability between their own clients and
       upstream servers.

Section 5, second to last paragraph: the word "resolver" here is used 
without clarifying whether it means a recursive resolver, a stub 
resolver, or both. Suggest:

OLD:

    This requirement is hereby relaxed.  A resolver MAY elect to send
    either TCP or UDP queries depending on local operational reasons.

NEW:

    This requirement is hereby relaxed.  Stub resolvers and recursive
    resolvers MAY elect to send either TCP or UDP queries depending on
    local operational reasons.

Section 6.2.1.1: I found the third paragraph hard to parse, mainly I 
think because of the phrase "that do not both". I understand the 
intention, but I think it would be clearer if re-case slightly. Suggest:

OLD:

    DNS clients will benefit from noting that DNS servers that do not
    both process pipelined queries concurrently and send out-of-order
    responses will likely not provide performance on a par with UDP.

NEW:

    It is likely that DNS servers need to process pipelined
    queries concurrently and also send out-of-order responses
    concurrently over TCP in order to provide the level of performance
    possible with UDP transport.

Section 6.2.2: the final clause in the last sentence ("multiple clients 
behind NAT") seems to be missing an article, because NAT is not expanded 
upon first use and my natural interpretation of the T is "translator" 
not "translation". Clearly I'm insane, but perhaps I'm not the only one. 
Suggest spelling it out.

OLD:

    These limits SHOULD be much looser than the client
    guidelines above, because the server does not know, for example, if 
a
    client IP address belongs to a single client or is multiple 
resolvers
    on a single machine, or multiple clients behind NAT.

NEW:

    These limits SHOULD be much looser than the client
    guidelines above, because the server does not know, for example, if 
a
    client IP address belongs to a single client or is multiple 
resolvers
    on a single machine, or multiple clients behind a device performing
    Network Address Translation (NAT).

Section 7: matching responses to queries "by port number" seems a little 
vague, and also very slightly odd given that every response received 
over the same TCP session is going to have the same source and 
destination port numbers. Matching by query ID with a (reasonable) 
requirement that query IDs be guaranteed unique across a single TCP 
session seems sufficient? No suggested replacement text, open question.

Section 8: is there benefit perhaps in including a matching SHOULD for 
the desired server behaviour? The paragraph notes that servers may 
respond in an unhelpful way if the message length and the message itself 
don't arrive in the same segment, but doesn't specify in a normative way 
what we think of that. Perhaps they SHOULD NOT do that?

Section 11: the text uses the phrase "reflector attacks", whereas I seem 
to think the more common phrase is "reflection attacks". I realise that 
5358 says "reflector" though.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 10 Oct 2015 18:34:32 +0200

On Fri, Oct 09, 2015 at 03:21:14PM -0400,
 Tim Wicinski <[email-masked]> wrote 

> This starts a Working Group Last Call for draft-ietf-dnsop-5966bis

This document describes several important changes (theoretically,
often clarifications, but in practice, changes) to TCP handling in DNS
to make it usable intensively. Such use will help a lot against
reflection attacks and also for DNS privacy efforts (DNS over
TLS). So, the goal is laudable.

[Warning: I'm not an implementor so I cannot comment on the ease of
programming these changes in DNS servers.]

The document itself is well written, clear and without any serious
issue, except one discussed later. To me, it can be publsihed as soon
as this issue is addressed.

I regret a bit that it mixes specification and discussion or diffs
with previous RFC but it may be more understandable that way to
long-time DNS people. I hope that in the future, we will get an effort
similar to what happened with HTTP, with a serious merging and
rewriting of the base DNS specification, including TCP support.

In the mean time, the issue I see is in section 7 "Since pipelined
responses can arrive out-of-order, clients MUST match responses to
outstanding queries using the ID field and port number." This has been
recently discussed in the DPRIVE working group and seems questionable,
specially for TCP (since the source and destination port are fixed for
a given connection). Clients should use the ID field and
QCLASS+QTYPE+QNAME instead, to demultiplex.

Editorial (warning: I don't speak english) :

Section 6.2.1.1 "will likely not provide performance on a par with
UDP" Should be "on par", no?

---

From: Warren Kumari <[email-masked]>
Date: Sun, 11 Oct 2015 14:15:42 -0400

On Fri, Oct 9, 2015 at 3:21 PM, Tim Wicinski <[email-masked]> wrote:
> outstanding issues have been addressed, and the document is very well put
> together.  This is ready for the next step.
>
> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.

Explicit no objections here (especially after Joe's thoughts and
Stephane's nits are incorporated)

W

>
> This starts a two week Working Group Last Call process, and ends on 20:00
> UTC 23 October 2015.
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Oct 2015 11:57:45 +0100

> This starts a Working Group Last Call for draft-ietf-dnsop-5966bis

I have re-read the draft and it looks good to me.

A couple of suggestions for section 7:

   For the avoidance of future doubt, this requirement is clarified.
   Authoritative servers and recursive resolvers are RECOMMENDED to
   support the sending of responses in parallel and/or out-of-order,
   regardless of the transport protocol in use.

I suggest deleting "in parallel and/or" since sending parallel responses
on a TCP query doesn't make sense, and even UDP responses have to be
serialized at some level. Perhaps change the clause to "preparing
responses in parallel and sending them out-of-order".

   Since pipelined responses can arrive out-of-order, clients MUST match
   responses to outstanding queries using the ID field and port number.

I think this should be:

   Since pipelined responses can arrive out-of-order, clients MUST match
   responses to outstanding queries using the DNS query ID, the
   contents of the question section (QNAME, QCLASS, QTYPE), and the
   transport tuple (protocol, source and destination addresses, source and
   destination ports).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

---

From: sara <[email-masked]>
Date: Mon, 12 Oct 2015 13:09:38 +0100

> On 10 Oct 2015, at 17:34, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Joe, Stephane, (and I just saw Tim too)

Many thanks for the detailed reviews.

> QCLASS+QTYPE+QNAME instead, to demultiplex.

On this point, I agree that the wording could be clarified by talking about matching responses on a single TCP connection, rather than using port number.

Section 6.2.1. of the draft says:

"When sending multiple queries over a TCP connection clients MUST take
 care to avoid Message ID collisions.  In other words, they MUST not
 re-use the DNS Message ID of an in-flight query.”

So under normal circumstances matching on just the Message ID should be sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE
part was removed when changing the ‘must' here to ‘MUST' in the last revision of this draft.

However it is true that requiring matching on all the fields would be more consistent with Section 9 of RFC5452 (even though that document is mostly UDP focussed) and there seems to be consensus to do that. 

Regards

Sara.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 14:36:57 +0200

On Mon, Oct 12, 2015 at 01:09:38PM +0100,
 sara <[email-masked]> wrote 
 a message of 107 lines which said:

> So under normal circumstances matching on just the Message ID should
> be sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE

OK, but why adding the port number, useless for TCP?

> However it is true that requiring matching on all the fields would
> be more consistent

And more robust, if the client is stupid enough to re-use Query IDs.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 12 Oct 2015 14:00:20 +0100

> On 12 Oct 2015, at 13:36, Stephane Bortzmeyer <[email-masked]> wrote:
> 

It was meant to restrict the matching to messages on a single TCP connection, but it clearly just caused confusion. I think Tony’s suggested text works well. 

Sara.

---

From: "Visweswaran, Gowri" <[email-masked]>
Date: Mon, 12 Oct 2015 13:23:27 +0000

I spent some time reviewing this document and I have one point I would
like some clarification on,
is there any supporting documentation that outlines recommendations on
how a recursive server can identify expected clients?

"Operators of recursive servers are advised to ensure that they only
   accept connections from expected clients, and do not accept them from
   unknown sources.  In the case of UDP traffic, this will help protect
   against reflector attacks [RFC5358
<https://tools.ietf.org/html/rfc5358>] and in the case of TCP traffic it
   will prevent an unknown client from exhausting the server's limits on
   the number of concurrent connections.²

Thanks,

Gowri

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Oct 2015 14:49:36 +0100

Visweswaran, Gowri <[email-masked]> wrote:

> like some clarification on, is there any supporting documentation that
> outlines recommendations on how a recursive server can identify expected
> clients?

Do you mean something like http://www.zytrax.com/books/dns/ch9/close.html
or do you mean something generic about only allowing queries that require
recursion from a specific set of IP addresses?

Tony.

---

From: "Visweswaran, Gowri" <[email-masked]>
Date: Mon, 12 Oct 2015 14:47:02 +0000

Hi Tony,

I was looking for guidelines similar to the link you sent below in an IETF
document,
and if anyone knows of any other documentation on the policies of the
current major recursive servers.

Gowri

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 17:14:28 +0200

On Mon, Oct 12, 2015 at 01:23:27PM +0000,
 Visweswaran, Gowri <[email-masked]> wrote 
 a message of 51 lines which said:

> is there any supporting documentation that outlines recommendations
> on how a recursive server can identify expected clients?

Don't think it is written down somewhere. The most common method is
restricting access to some IP prefixes. Some people probably use TSIG
instead (or SIG(0)?). OpenNIC apparently uses DNScrypt.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Oct 2015 16:20:56 +0100

Visweswaran, Gowri <[email-masked]> wrote:
>
> I was looking for guidelines similar to the link you sent below in an
> IETF document,

There isn't anything AFAIK. Even the Open Resolver Project doesn't have
any helpful guidance, as I thought it might.

> and if anyone knows of any other documentation on the
> policies of the current major recursive servers.

BIND defaults to localhost and localnets, i.e. the nameserver's
directly-connected subnets. See "allow-recursion" in
ftp://ftp.isc.org/isc/bind9/9.10.2-P4/doc/arm/Bv9ARM.ch06.html

Unbound defaults to localhost only. See "access-control" in
http://unbound.nlnetlabs.nl/documentation/unbound.conf.html

The PowerDNS recursor defaults to RFC1918 addresses.
https://doc.powerdns.com/md/recursor/settings/#allow-from

The Knot resolver listens on localhost by default.
https://github.com/CZ-NIC/knot-resolver/tree/master/daemon#network-configuration

Dnsmasq seems to default to open unless you specify --local-service (?!)
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Oct 2015 07:35:05 +1100

For de-multiplexing the responses off the socket the *only* field
you should be using is the ID field.  There are error conditions
that result in only the DNS header being returned.  All responses
are *supposed* to be constucted in the DNS.  Setting rcode to
formerr/notimp and setting qr to 1 does *not* generate valid error
messages despite some servers doing this.

For sanity checking responses you use other field like you do with
UDP.

Mark

In message <[email-masked]>, sara writes:
> 
> --===============8675959396934527956==
> Content-Type: multipart/alternative;
>  boundary="Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451"
> 
> 
> --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> 	charset=utf-8
> 
> 
> > On 10 Oct 2015, at 17:34, Stephane Bortzmeyer <[email-masked]> =
> wrote:
> >=20
> 
> >=20
> On this point, I agree that the wording could be clarified by talking =
> about matching responses on a single TCP connection, rather than using =
> port number.
> 
>  re-use the DNS Message ID of an in-flight query.=E2=80=9D
> 
> So under normal circumstances matching on just the Message ID should be =
> sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE
> part was removed when changing the =E2=80=98must' here to =E2=80=98MUST' =
> in the last revision of this draft.
> 
> However it is true that requiring matching on all the fields would be =
> more consistent with Section 9 of RFC5452 (even though that document is =
> mostly UDP focussed) and there seems to be consensus to do that.=20
> 
> Regards
> 
> Sara.=20=
> 
> --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/html;
> 	charset=utf-8
> 
> <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
> charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
> class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
> class=3D"">On 10 Oct 2015, at 17:34, Stephane Bortzmeyer &lt;<a =
> href=3D"mailto:[email-masked]" class=3D"">[email-masked]</a>&gt; =
> wrote:</div><div class=3D""><br class=3D""></div></blockquote><div><br =
> class=3D""></div>Joe, Stephane, (and I just saw Tim too)</div><div><br =
> class=3D""></div><div>Many thanks for the detailed =
> reviews.</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><br=
>  class=3D"">In the mean time, the issue I see is in section 7 "Since =
> pipelined<br class=3D"">responses can arrive out-of-order, clients MUST =
> match responses to<br class=3D"">outstanding queries using the ID field =
> and port number." This has been<br class=3D"">recently discussed in the =
> DPRIVE working group and seems questionable,<br class=3D"">specially for =
> TCP (since the source and destination port are fixed for<br class=3D"">a =
> given connection). Clients should use the ID field and<br =
> class=3D"">QCLASS+QTYPE+QNAME instead, to demultiplex.<br =
> class=3D""></blockquote></div><div class=3D""><br class=3D""></div><div =
> class=3D"">On this point, I agree that the wording could be clarified by =
> talking about matching responses on a single TCP connection, rather than =
> using port number.</div><div class=3D""><br class=3D""></div><div =
> class=3D"">Section 6.2.1. of the draft says:</div><div class=3D""><br =
> class=3D""></div><div class=3D"">"<span style=3D"widows: 1;" =
> class=3D"">When sending multiple queries over a TCP connection clients =
> MUST take</span></div><pre class=3D"newpage" style=3D"margin-top: 0px; =
> margin-bottom: 0px; page-break-before: always; widows: 1;"><font =
> face=3D"Helvetica" class=3D""> care to avoid Message ID collisions.  In =
> other words, they MUST not
>  re-use the DNS Message ID of an in-flight query.=E2=80=9D</font></pre><pr=
> e class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; =
> page-break-before: always; widows: 1;"><font face=3D"Helvetica" =
> class=3D""><br class=3D""></font></pre><pre class=3D"newpage" =
> style=3D"margin-top: 0px; margin-bottom: 0px; page-break-before: always; =
> widows: 1;"><font face=3D"Helvetica" class=3D"">So under normal =
> circumstances matching on just the Message ID should be sufficient for =
> TCP, which was the reason the QCLASS+QNAME+QTYPE</font></pre><div =
> class=3D"">part was removed w<font face=3D"Helvetica" style=3D"widows: =
> 1;" class=3D"">hen changing the =E2=80=98must' here to =E2=80=98MUST' in =
> the last revision of this draft.</font></div><div class=3D""><span =
> style=3D"widows: 1;" class=3D""><br class=3D""></span></div><div =
> class=3D""><span style=3D"widows: 1;" class=3D"">However it is true that =
> requiring matching on all the fields would be more consistent with =
> Section 9 of RFC5452 (even though that document is mostly UDP =
> focussed)&nbsp;</span><span style=3D"widows: 1;" class=3D"">and there =
> seems to be consensus to do&nbsp;that</span><span style=3D"widows: 1;" =
> class=3D"">.&nbsp;</span></div><div class=3D""><span style=3D"widows: =
> 1;" class=3D""><br class=3D""></span></div><div class=3D""><span =
> style=3D"widows: 1;" class=3D"">Regards</span></div><div class=3D""><span =
> style=3D"widows: 1;" class=3D""><br class=3D""></span></div><div =
> class=3D""><span style=3D"widows: 1;" =
> class=3D"">Sara.&nbsp;</span></div></body></html>=
> 
> --Apple-Mail=_432A5B83-C240-4934-9A74-E90B5F954451--
> 
> 
> --===============8675959396934527956==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============8675959396934527956==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 14 Oct 2015 13:20:39 +0100

> On 9 Oct 2015, at 20:53, Joe Abley <[email-masked]> wrote:

Joe, 

Thanks for the review. 

>  I made a few notes as I read through, but it would be entirely fine with me if they were all ignored.

All your suggested rewordings improve the document and have been committed - thanks.

> 
> Section 8: is there benefit perhaps in including a matching SHOULD for the desired server behaviour? The paragraph notes that servers may respond in an unhelpful way if the message length and the message itself don't arrive in the same segment, but doesn't specify in a normative way what we think of that. Perhaps they SHOULD NOT do that?

That seems reasonable. Would the following additions (which go a little further) clarify this point enough?

Section 6.2.3  Idle Timeouts

@@ -477,6 +477,12 @@
    specified in [RFC1035].  Servers MAY use zero timeouts when
    experiencing heavy load or are under attack.
 
+   DNS messages delivered over TCP might arrive in multiple segments.  A
+   DNS server that resets its idle timeout after receiving a single
+   segment might be vulnerable to a "slow read attack."  For this
+   reason, servers SHOULD apply the idle timeout to the receipt of a
+   full DNS message, rather than to receipt of a TCP segment.
+

Section 8   TCP Message Field Lengths

@@ -542,7 +549,18 @@
    problems due to some DNS servers being very sensitive to timeout
    conditions on receiving messages (they might abort a TCP session if
    the first TCP segment does not contain both the length field and the
-   entire message)
+   entire message).  Such behavior is certainly undesirable.  As
+   described in [6.2.3], servers SHOULD apply connection timeouts to the
+   receipt of a full message and MUST NOT close a connection simply
+   because the first segment does not contain the entire message.

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 14 Oct 2015 13:21:55 +0100

> On 12 Oct 2015, at 11:57, Tony Finch <[email-masked]> wrote:
> 

Thanks.

> responses in parallel and sending them out-of-order”.

Text updated - thanks.

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 14 Oct 2015 13:53:44 +0100

> On 12 Oct 2015, at 21:35, Mark Andrews <[email-masked]> wrote:
> 
> 

Ah, OK. So, would the following be acceptable?

  Since pipelined responses over TCP can arrive out-of-order, clients MUST match
  responses to outstanding queries using the DNS query ID and the
  transport tuple (protocol, source and destination addresses, source and
  destination ports). If the response contains a question section the client MUST
  match the QNAME, QCLASS and QTYPE fields. 

Sara.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Oct 2015 14:32:06 +0100

>   match the QNAME, QCLASS and QTYPE fields. 

Strictly speaking, the O/S should be taking care of matching the
transport tuple before it ever reaches the client, and that's already
called out in the last sentence of §5 where it's required that the
response must arrive on the same TCP connection as was used for the request.

Ray

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 14 Oct 2015 09:36:03 -0400

> Section 6.2.3  Idle Timeouts

I think that's a great improvement and I think the advice is clear and good.

Joe

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Oct 2015 15:55:47 +0100

> response must arrive on the same TCP connection as was used for the request.

Yes. Perhaps "transport tuple" is an excessively clever way of saying
"same connection". When I wrote that I wanted to allow independent choice
of query ID per connection (rather than implying a single global ID).

Also, for UDP if you don't match the transport tuple then you lose (some
of) the benefit of port randomization, I think (depending on how many
ports you keep open).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Southwest 5 to 7. Moderate or rough, occasionally very rough at
first in west. Fair. Good.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Oct 2015 16:02:58 +0100

> of query ID per connection (rather than implying a single global ID).

Hmm, §6.2.1 talks about not re-using Message ID's but that's supposed to
be in the context of a single connection.

Across connections the Message ID space is of course independent.

> of) the benefit of port randomization, I think (depending on how many

That's true, but this document isn't about UDP ;-)

Ray

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 14 Oct 2015 17:15:37 +0100

> On 14 Oct 2015, at 16:02, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

> Across connections the Message ID space is of course independent.

Yes, it says:

“ When sending multiple queries over a TCP connection clients MUST take
   care to avoid Message ID collisions.  In other words, they MUST NOT
   re-use the DNS Message ID of an in-flight query. "

So maybe that should actually read (to avoid any doubt):

"  When sending multiple queries over a TCP connection clients MUST take
   care to avoid Message ID collisions.  In other words, they MUST NOT
   re-use the DNS Message ID of an in-flight query on the same TCP connection. “

And then the wording for section 7 can become:

“Since pipelined responses over TCP can arrive out-of-order, clients MUST match
 responses to outstanding queries on the same TCP connection using the DNS query ID. 
 If the response contains a question section the client MUST
 match the QNAME, QCLASS and QTYPE fields.”

Sara.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Oct 2015 17:17:44 +0100

>  match the QNAME, QCLASS and QTYPE fields.”

That works for me.

Ray

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Oct 2015 17:19:07 +0100

> >  match the QNAME, QCLASS and QTYPE fields.”

Yes, nice.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, North Biscay: Northeast 4 or 5, increasing 6 at times.
Slight or moderate. Showers later. Good.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 14 Oct 2015 17:52:09 -0700

At Wed, 14 Oct 2015 13:20:39 +0100,

> Section 6.2.3  Idle Timeouts

I think the additional text for these sections has the same problem I
pointed out before for the sending side of Section 8: a DNS server
implementation usually cannot know which TCP segment contains what
amount of data.  All it can know in practice is which amount of data a
single "read" API call returns.  I suggest you rephrasing the text as
we did for the sending side of Section 8.

--
JINMEI, Tatuya

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 15 Oct 2015 13:20:29 +0100

> Begin forwarded message:
> 
> From: 神明達哉 <[email-masked]>
> Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis
> Date: 15 October 2015 01:52:09 BST
> To: Sara Dickinson <[email-masked]>
> Cc: Joe Abley <[email-masked]>, dnsop <[email-masked]>
> 
> we did for the sending side of Section 8.@@ -477,6 +477,12 @@

Point taken! How about the following:

@@ -477,6 +477,12 @@

+   DNS messages delivered over TCP might arrive in multiple segments.  As
+   a result a DNS server that resets its idle timeout after each “read” system call
+   might be vulnerable to a "slow read attack."  For this
+   reason, servers SHOULD apply the idle timeout to the receipt of a
+   full DNS message, rather than to receipt of any part of a DNS message.
+

@@ -542,7 +549,18 @@
   problems due to some DNS servers being very sensitive to timeout
   conditions on receiving messages (they might abort a TCP session if
   the first TCP segment does not contain both the length field and the
-   entire message)
+   entire message).  Such behavior is certainly undesirable.  As
+   described in [6.2.3], servers SHOULD apply idle timeouts to the
+   receipt of a full message and MUST NOT close a connection simply
+   because the first “read” system call for a new message does 
+   not contain the entire message.

Sara.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 15 Oct 2015 09:40:39 -0700

At Thu, 15 Oct 2015 13:20:29 +0100,
Sara Dickinson <[email-masked]> wrote:

> > pointed out before for the sending side of Section 8: [...]
>

Looks good to me.  You might want to avoid the technical term of
"system call" as the concept may have a different name on different
platforms.  But I'd leave it to you.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 27 Oct 2015 03:39:33 -0400

Hi

The WGLC ended on this, and there was strong consensus to move this 
document forward.  Thanks to all the folks who gave very constructive 
comments, and thanks to the authors for addressing all the issues raised 
during the process.  I'll be submitting this shortly.

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 27 Oct 2015 09:19:55 +0100

On Tue, Oct 27, 2015 at 03:39:33AM -0400,
 Tim Wicinski <[email-masked]> wrote 
 a message of 36 lines which said:

> document forward.

Can you clarify what was the resolution for the problem of matching
replies to questions? I believe that most people (like me) are happy
with the ID+QNAME+QCLASS+transport_tuple of
<http://mailarchive.ietf.org/arch/msg/dnsop/YCkm0bc3c0XjnU71kyGU8V8SGZg>
but it seems we may have at least a dissent
<https://mailarchive.ietf.org/arch/msg/dnsop/egQ4zEMacf_JmohgNNguOBXjVJA>

---

From: Shane Kerr <[email-masked]>
Date: Tue, 27 Oct 2015 17:18:09 +0800

Stephane and all,

On Tue, 27 Oct 2015 09:19:55 +0100

> <https://mailarchive.ietf.org/arch/msg/dnsop/egQ4zEMacf_JmohgNNguOBXjVJA>

Sara's proposal does seem to take into account Mark's concern, since
she specified using the QNAME/QCLASS/QTYPE only if they are present in
the reply.

I guess Mark's argument might be that since we have to take into
account the ID-only case, why not add extra code complexity to deal
with ID+QNAME+QCLASS+QTYPE matching?

I have no strong feelings either way on this, so (like Stephane) I am
happy with the proposed matching.

Cheers,

--
Shane

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 27 Oct 2015 05:20:09 -0400

There is an -04 version which missed the cut off but will be the one we 
submit:

https://raw.githubusercontent.com/DNSOP/draft-5966-bis/master/draft-ietf-dnsop-5966bis-04.txt

https://github.com/DNSOP/draft-5966-bis/pull/24/files#diff-1

I believe Sara addresses all concerns.

tim

---

From: sara <[email-masked]>
Date: Tue, 27 Oct 2015 09:28:52 +0000

>> she specified using the QNAME/QCLASS/QTYPE only if they are present in

Yes, my response above was posted after Marks comment and adjusted the proposed text to take his point into account. There were 2 indications of support for the new text and no other comments so I hope this has correctly addressed the concern.

Sara.