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

From: Tony Finch <[email-masked]>
Date: Wed, 24 Mar 2010 21:06:58 +0000

A good document.

A typo: section 5 - connection handling: "in practise" should be "in
practice".

A small suggestion, also in section 5: I think the last sentence reads
better as "Therefore if the server needs to unilaterally close a
dormant TCP connection it SHALL be free to do so whenever required" with
SHALL instead of MUST (equivalent requirement levels).

Another bit of section 5 mustard: "RECOMMENDS" isn't an RFC 2119 keyword,
so I suggest rephrasing "This document therefore RECOMMENDS ..." to
"Therefore it is RECOMMENDED ..." (though I don't like the passive voice).

Regarding the number of TCP connections a client may open, is there ever
any reason for a resolver to open more than one? Section 6 allows response
re-ordering which avoids problems with head-of-queue blocking, and DNS
replies are relatively small, which eliminate two of the reasons for
multiple connections in HTTP. I don't know if current implementations
re-order replies over TCP - IME they don't but my experience is quite
dated. (I say connections per resolver rather than per host since hosts
often run many stub resolvers.)

Section 4 - transport protocol selection: what does "proprietary" mean?
non-standard? special-purpose? restricted? Isn't it redundant, since
non-standard implementations by definition don't have to follow the TCP
requirement.

Section 3 - discussion: I'm a bit uncomfortable about the last paragraph.
Obviously EDNS0 cannot by itself resolve the packet size issue, so it
seems unfair to suggest it is unexpectedly inadequate. It also seems
unfair to blame it for bad firewall configurations and propose TCP as the
fix when bad firewall configurations are likely to break TCP too.

I suggest removing the comment about firewalls that block EDNS0 (leaving
discussion of that to RFC 5625). I also suggest backing up the sentence
about fragmentation with a note that fragmented packets are easier to
spoof because they omit the UDP and DNS headers and so must rely on just
the IP ID for security. (Which is another reason for limiting the EDNS0
buffer size to fit within typical path MTUs.)

I suggest replacing the last paragraph of section 3 with "The future that
was anticipated in RFC 1123 is now here. Although EDNS0 reduces the
proportion of queries that require TCP, it does not elminate them."

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.