[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dnsext] draft-ietf-dnsext-dns-tcp-requirements-01
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: ah@TR-Sys.de |
+------------------------+--------------------------------------------+