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

From: [email-masked]
Date: Mon, 26 Oct 2009 04:30:03 -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-01.txt
	Pages           : 8
	Date            : 2009-10-26

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-01.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: [email-masked]
Date: Mon, 26 Oct 2009 11:58:00 +0000

As you'll have just seen I've just made a (minor) update to this draft.

I've addressed most (if not all) of the editorial nits and comments.

However for now I've left out wider discussion of the TCP tuning issues, 
references to UTO, etc, as "(currently) out of scope", pending 
face-to-face discussion in Hiroshima.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Doug Otis <[email-masked]>
Date: Tue, 27 Oct 2009 16:57:40 -0700

On 10/26/09 4:58 AM, [email-masked] wrote:
> However for now I've left out wider discussion of the TCP tuning
> issues, references to UTO, etc, as "(currently) out of scope",
> pending face-to-face discussion in Hiroshima.

Updating RFC 1123 should consider the functional alternative made
possible with RFC2671.  The maximal DNS message size of 512 should
not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit,
should TCP become required.  After all, most CPE equipment can not
proxy DNS over TCP, so DNS operation is not better accomplished with
this over reaching TCP mandate.

If smaller key sizes become practical, why not permit exclusive
operation of UDP within a known supported range?

4. Transport Protocol Selection

Change:
  o  all requests and responses are guaranteed to be <= 512 bytes

To:
  o  all requests and responses can be contained within a 1476 byte IP
packet to avoid IP fragmentation.

Change:

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.

To:

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 EDNS0, or for other operational
reasons.

7. Security Considerations

This section makes an unsupportable supposition that TCP dependence will
prove safe because it has not yet resulted in successful DDoS attack.
However, following adoption of this TCP mandate, UDP use for frames 
still within 1476 bytes might be unnecessarily withdrawn. If this were 
to occur for any DNS message over 512 bytes in conjunction with DNSSEC, 
a substantial portion of DNS traffic may become limited to only using 
TCP.  TCP, even with SYN cookies, still needs to buffer unacknowledged 
data which creates a significant resource exposure with a DDoS 
vulnerability.

-Doug

---

From: Alex Bligh <[email-masked]>
Date: Wed, 28 Oct 2009 09:13:21 +0000

--On 28 October 2009 08:25:48 +0000 George Barwood 
<[email-masked]> wrote:

> If TCP is required, it seems logical to limit UDP responses to the
> original size and deprecate the EDNS response buffer size mechanism.
> I'm not sure if this is Ray's intention, but I think I agree with this.

I very much hope it isn't Ray's intention. That would be to use a
sledge-hammer to crack a nut, though that metaphor perhaps does not
encompass sufficient collateral damage.

You are advocating preventing UDP packets with a payload greater than 512
bytes. For those worried about TCP loading, this would increase it hugely,
as any client compliant with your recommendations would end up making a TCP
request just in case the response didn't fit into a 512 byte UDP payload.

This is quite apart from the fact that there is a huge volume of
EDNS0-supporting clients out there which will continue to make EDNS0
queries, so the deprecation as such will have little effect.

Where UDP works, there is no issue in using it. UDP is in the vast majority
of cases totally unproblematic, it seems to me, for communication between
caching resolver and authoritative server, and EDNS0 works just fine, even
above 1500 bytes, as people in general don't have firewalls et al. in the
way. The problem would appear to be in a small minority of those cases
(generally where the caching resolver is itself behind some form of
defective proxy), plus a significant portion of communication between stub
resolver and caching proxy. proxy-bypass will I hope go a little way to
alleviate the latter problem, but it won't cure it totally. TCP support
(possibly combined with proxy-bypass) will, I think, address the vast
majority of the cases.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Oct 2009 14:01:11 +0000

> From: "George Barwood" <[email-masked]>
> Date: Wed, 28 Oct 2009 08:25:48 -0000
> 

EDNS0 was never intended to be a backfill for supposed TCP optionalness --
TCP was not considered optional by the people who created or approved EDNS0.

> I don't think this should be the end of it though, at risk of boring
> readers with repetition, for which I apologise, I'm advocating either
> SCTP or something like
> 
> http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/QRP.htm

there's some off-list work going on along these lines, but it wasn't ready
for the hiroshima meeting, which agenda seems rather overfull in any case.