Subject: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-01

From: Alfred Hönes <[email-masked]>
Date: Fri, 30 Oct 2009 17:38:28 +0100 (MEZ)

Hello,
I'd like to suggest a few improvements to the text in
  draft-ietf-dnsext-dns-tcp-requirements-01.

All details mentioned are deemed editorial in nature, except for the
last item, (5).

(1)  Abstract

"TCP protocol" is weird, since the "P" already stands for "protocol".
(Reading it loud, spelling out the acronym will show the mess.)

Suggestion:

   This document updates the requirements for the support of the TCP
|  protocol for the transport of DNS traffic.
---                                                                 vvv
|  This document updates the requirements for the support of the TCP as
|  a transport protocol for DNS traffic.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(2)  Section 1

(2a)  1st para

Similarly, I suggest to modify the 1st paragraph in Section 1 to
avoid that nasty "xxP protocol" issue:

   Most DNS [RFC1035] transactions take place over the UDP [RFC0792]
   protocol.  The TCP [RFC0793] protocol is used for zone transfers and
   is supported by many implementations for the transfer of other
   packets which exceed the protocol's original 512 byte packet-size
   limit.
---
|  Most DNS [RFC1035] transactions take place over UDP [RFC0792].
|  TCP [RFC0793] is used for zone transfers and is supported by many
   implementations for the transfer of other packets which exceed the
   protocol's original 512 byte packet-size limit.

Or if you prefer to be more verbose and expand the acronyms:

|  Most DNS [RFC1035] transactions take place over the User Datagram
|  Protocol (UDP, [RFC0792]).  The Transmission Control Protocoll (TCP,
|  [RFC0793]) is used for zone transfers and is supported by many
   implementations for the transfer of other packets which exceed the
   protocol's original 512 byte packet-size limit.

However, since the judgement over the implementation level is
elaborated upon in the sequel, it might be better to strip down the
second sentence, by striking "is supported by many implementations";
 continuing with the above variant, that would end up with:

|  Most DNS [RFC1035] transactions take place over the User Datagram
|  Protocol (UDP, [RFC0792]).  The Transmission Control Protocoll (TCP,
|  [RFC0793]) is used for zone transfers and for the transfer of other
   packets which exceed the protocol's original 512 byte packet-size
   limit.

(2b) last para

Again   s/the TCP protocol/TCP/ .

(3)  Section 3

(3a)  1st para (near the end)

How about   s/TC flag as notice that/TV flag as a hint that/   ?
                         ^^^^^^                 ^^^^^^
(3b)  after quotation from RFC 1123

I recommend to additionally quote from RFC 2181, Section 9:

|9. The TC (truncated) header bit
|
|...
|
|  Where TC is set, the partial RRSet that would not completely fit may
|  be left in the response.  When a DNS client receives a reply with TC
|  set, it should ignore that response, and query again, using a
|  mechanism, such as a TCP connection, that will permit larger replies.
              !!!!!!!!!!!!!!!!!!!!!!!!

(3c)  4th para ("Since ...")

Although EDNS0 performs various field and protocol extensions,
I would regard it as a single extension _Mechanism_ and therefore
avoid plural here:

   Since the original core specifications for DNS were written, the
|  Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
---                  ^^^                          ^^^^
   Since the original core specifications for DNS were written, the
|  Extension Mechanism for DNS (EDNS0 [RFC2671]) has been introduced.
                     ^^                          ^^^

(3d)  5th para

I would prefer to present the reasoning in the logical chain by
reasons and immediate effects for clarity; this way, the term
"unreliable" is getting attributed to exactly that mechanism that
indeed is unreliable in practice:

   However, transport of UDP packets which exceed the size of the path
|  MTU has been found to be unreliable in some circumstances because of
|  IP packet fragmentation.  [...]
---
   However, transport of UDP packets which exceed the size of the path
|  MTU causes IP packet fragmentation, which has been found to be
|  unreliable in some circumstances.  [...]

(3e)  last para

The draft says:

   The future that was anticipated in RFC 1123 has arrived, and the only
|  standardised mechanism which may have resolved the packet size issue
   has been found inadequate.

This could be read by some interested parties rhat TCP were also
inadequate.  I suggest to insert "UDP-based" to disambiguate the text:

   The future that was anticipated in RFC 1123 has arrived, and the only
|  standardised UDP-based mechanism which may have resolved the packet
               ^^^^^^^^^^^
   size issue has been found inadequate.

(4)  Section 4

(4a)  1st para

Again, I suggest to reduce the density of "P" / "protocol":

   All DNS implementations MUST support both UDP and TCP transport
|  protocols, except as set out below.
---^^^^^^^^^
|  All DNS implementations MUST support both UDP and TCP transport,
|  except as set out below.

(4b)  last para

IMO, the most important "operational reason" should be spelled out
explicitely, since it is of major influence on resource consumption:
(re-)use of already established TCP connections!

For instance:

   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
   query first, but MAY elect to send a TCP query instead if it has good
   reason to expect the response would be truncated if it were sent over
   UDP (with or without EDNS0) or for other operational reasons.
---
   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
   query first, but MAY elect to send a TCP query instead if it has good
   reason to expect the response would be truncated if it were sent over
|  UDP (with or without EDNS0) or for other operational reasons, in
|  particular if it already has an open TCP connection to the server.

(5)  Section 5

The 2nd para spells out the burden on servers and the network by
parallel TCP connections to HTTP servers.  Similar behavior does not
make sense for (non-zone transfer) DNS transactions (cf. Section 6!).
I recommend to add the requirement for clients to not do that:

   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
   persistent TCP connections and operational experience has shown that
   long timeouts can easily cause resource exhaustion and poor response
   under heavy load.  Intentionally opening many connections and leaving
   them dormant can trivially create a "denial of service" attack.

   This document therefore RECOMMENDS that the idle period should be of
   the order of TBD seconds.
|
|  DNS clients SHOULD not open more than one TCP connection to a single
|  recursive resolver or authoritative server.

DISCUSS:   SHOULD --> MUST ??

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alex Bligh <[email-masked]>
Date: Fri, 30 Oct 2009 17:27:37 +0000

> DISCUSS:   SHOULD --> MUST ??

If, e.g., a library stub resolver is bound to userspace program X, and
userspace program Y, each with different users, it would be a sizeable
amount of work to get them to share the same TCP connection. I don't
know whether technically that's two clients running on the same host,
or one client. However, from a caching resolver's point of view they
are indistinguishable from 2 clients behind a NAT.

I would avoid changing SHOULD to MUST on the basis that it's difficult
to tell whether it is complied with anyway, and we don't want to
encourage a naive server operator to limit connections to one per
IP or something similarly horrible. Perhaps we should add "Hosts
SHOULD attempt to minimise the number of outgoing TCP connections
made by clients" or similar.

-- 
Alex Bligh

---

From: Douglas Otis <[email-masked]>
Date: Sat, 31 Oct 2009 01:05:46 -0700

On 10/30/09 10:27 AM, Alex Bligh wrote:
>> | DNS clients SHOULD not open more than one TCP connection to a
>> single | recursive resolver or authoritative server.
>>
> If, e.g., a library stub resolver is bound to userspace program X,
> and userspace program Y, each with different users, it would be a
> sizeable amount of work to get them to share the same TCP connection.
> I don't know whether technically that's two clients running on the
> same host, or one client. However, from a caching resolver's point of
> view they are indistinguishable from 2 clients behind a NAT.
>
> I would avoid changing SHOULD to MUST on the basis that it's
> difficult to tell whether it is complied with anyway, and we don't
> want to encourage a naive server operator to limit connections to one
> per IP or something similarly horrible. Perhaps we should add "Hosts

There is no meaningful method of enforcement against clients wanting to
obtain a greater portion of available bandwidth.  They are likely to use
multiple connections as a common strategy, which is indistinguishable
from that seen from a NAT.  How would someone ensure compliance?  Of
course, there are other transports that will not confront this issue.

This is a concern as multiple connections bring TCP sooner to resource
exhaustion. RFC 793 defines the TIME_WAIT state as 2 times the Maximum
Segment Lifetime.  The Maximum Segment Lifetime is specified as 2
minutes. RFC 1337 describes the problem TIME_WAIT is intended to avoid.
(Not just ensuring receipt of FIN acknowledgment.)

-Doug