Subject: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt

From: [email-masked]
Date: Tue, 6 Oct 2009 11:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : DNS Transport over TCP
	Author(s)       : R. Bellis
	Filename        : draft-ietf-dnsext-dns-tcp-requirements-00.txt
	Pages           : 8
	Date            : 2009-10-06

This document updates the requirements for the support of the TCP
protocol for the transport of DNS traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirements-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 6 Oct 2009 12:12:36 -0700

I have a two comments on section 4 of this draft.

First, regarding the list of conditions under which a server may opt
to disable TCP support: is there a reason why DNSSEC specifically
requires TCP?  I assume the main rationale for this is because DNSSEC
responses will frequently be larger than 512 bytes, but this more
general condition is already listed.  I would rather suggest removing
the DNSSEC condition from the list, and separately adding an
informative comment pointing out that supporting DNSSEC will likely
require >512 byte responses.

Rationale: Current DNSSEC signature/key algorithms and record formats
frequently require large responses, but if new algorithms and formats
later allow smaller responses, I don't see a reason TCP support should
be required then.

Second, regarding the relaxation of requiring UDP before TCP: I'm not
opposed to this, but I think it should be again mentioned that some
servers may not support TCP (as permitted earlier in the section) and
it's the client's responsibility to ensure this doesn't cause
problems.

Rationale: The current RFCs (and even this draft) allow some servers
to not support TCP and currently clients are required to try UDP
before TCP; it's the responsibility of new clients that have differing
behavior to be compatible with existing servers.

Otherwise, I like the draft right now.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 06 Oct 2009 20:30:51 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirement

I support this draft.

Comments

1. Section 4.

I think you should a clear section of mandatory support. IE start the
section with "all DNS servers and clients MUST support both UDP and TCP
transports, except as set out below". I know this is partly handled within
section 1, but I think given the lack of clarity to date, it is worth
spelling out.

2. Section 4
>    A proprietary stub resolver implementation MAY omit support for TCP
>    if it is operating in an environment where truncation will not occur,
>    or if it is prepared to accept a DNS lookup failure should truncation
>    occur.

At the least, I would suggest making this "where truncation can never
occur" (as opposed to "will not"), and thus also applying this only to
proprietary stub resolvers that do not support DNSSEC, because in practice
it seems impossible to guarantee truncation won't occur with DNSSEC and or
have truncated responses be considered acceptable (i.e. presumably the same
reason you carved out DNSSEC supporting servers). By "truncation will not
occur" do you mean "transactions will never exceed 512 bytes" (the
criterion you applied to servers) or do you mean that if the stub resolver
can guarantee its path MTU is >512, and the recursive server supports
EDNS0, and it supports EDNS0, then otherwise guaranteeing that truncation
won't occur is OK? It just seems a little bit peculiar to have one rule for
the server and one for the client. I'm also slightly concerned about the
apparent need for psychic powers on the client's side.

However, my preference would be to make your carve-out apply only "if the
resolver can guarantee that any response to its query can be expressed in a
response of fewer than 512 bytes (or where truncation to 512 bytes would be
acceptable in all circumstances), and where no queries are made with DO
set".

3. Section 6

Before you get to re-ordering, you should consider pipelining. I'm
not sure there is yet a MUST for support for a second query to be
issued on a TCP connection before the first one is answered (I am
prepared to be proved wrong here); previous namedroppers dialog
suggests at least some servers support it, and at least some
clients support it. I think if the server isn't going to support
it, it should close the connection.

It seems to me that we need something like:
* Having sent one or more queries on a TCP connection, the client
  MAY, if the TCP connection remains open, send further queries
  before receiving responses to outstanding queries.
* The client MUST NOT (?) close the TCP connection whilst responses
  remain outstanding unless [timeout occurs]
* The server MAY close the TCP connection at any time when no
  response is outstanding, or MAY leave the connection open allowing
  the client to close it.

Nits:

4. End of section 3:
>   The future that was anticipated in RFC 1123 is now here, and the only

"now" is not a good word to use, as at the time of reading many years
in the future, "now" will mean something different. Suggest replacing
paragraph by:
   "The new record types needed by (inter alia) DNSSEC thus require,
    as predicted by RFC 1123, universal support for TCP transport".

-- 
Alex Bligh

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 07 Oct 2009 10:59:13 -0400

>behavior to be compatible with existing servers.

Matthew,
In my mind there are two cases to consider,

"First" query to a server in this case yes UDP is required before TCP
Is "Subsequent" query different ?

For example every time someone asks for a non existent .gov name the
answer is 1700+ bytes. Can a resolver that has detected lots of TC's from
a server for .gov to just ask all future queries over TCP ?
(This is a resolver behind a pipe that restricts answers to 1500 bytes).

>Otherwise, I like the draft right now.

Glad to hear it. Ray generated this 00 draft in about 24 hours.

         Olafur

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 20 Oct 2009 20:19:21 -0700

(Sorry, missed this response until now.)

> Is "Subsequent" query different ?

My understanding of the current wording is each individual query
SHOULD be tried over UDP first.  I'm fine with this interpretation,
subject to the constraints I mentioned in my last email (i.e., that
clients need to be prepared to interoperate with servers that don't
offer TCP because of constrained circumstances).

It sounds like you're interpreting it as the first query to a server
MUST be tried over UDP, but subsequent queries to the same server
(after ensuring TCP support) only SHOULD be tried over UDP.  I'm okay
with this as well, though as an informative remark, I'd suggest
pointing out that servers may change configuration over time, and one
that supported TCP at one time may no longer support it in the future.

> (This is a resolver behind a pipe that restricts answers to 1500 bytes).

My assumption is that as long as the TCP socket is still open, the
client should be free to send as many queries over it as it can/wants.

Assuming there are no open TCP connections to the server though, I
think as long as the last TC response was fairly recent (e.g., within
the last 5 minutes), then it seems reasonable to try over TCP first if
the resolver expects a truncated response.