Subject: [dnsext] Editor needed

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Aug 2009 18:47:31 -0400

Dear colleagues,

One of the milestones on the Charter that we've been waiting to send
to our AD is a document that clarifies that TCP transport is mandatory
for DNS.  We need a volunteer to edit that draft.  Does anyone want to
do this?

Best regards,

Andrew (for the Chairs)

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Tue, 25 Aug 2009 23:05:52 +0000

i've written it - but the nits/tools folks are intolerent of format
 anomolies.  I'm kind of wrapped around another axel for the mo, but 
 fully expect to whip that draft into shape in the next week.

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 25 Aug 2009 16:24:01 -0700

> for DNS.  We need a volunteer to edit that draft.  Does anyone want to

What's the rationale for this?  I don't see why TCP transport should
be mandatory for authoritative name servers that only send responses
that fit within the 512 byte limit for UDP.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 13:09:12 +1000

In message <[email-masked]>, Matth
ew Dempsky writes:
> > for DNS. =A0We need a volunteer to edit that draft. =A0Does anyone want t=
> o
> > do this?
> 

Why do people only think about QUERY.  There are multiple opcodes
and for some of operations involving these opcodes TCP is the
better/only way to talk to the authoritative servers to achieve the
desired aims.   Being able to say "go way" with a NOTIMP/REFUSED
will allow the client to stop making the attempts rather than continually
retrying as the TCP connection keeps failing.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 25 Aug 2009 20:16:11 -0700

On Tue, Aug 25, 2009 at 8:09 PM, Mark Andrews<[email-masked]> wrote:
> desired aims.

If you want to require TCP for name servers providing those services,
I'm less opposed.  But for a server that only supports QUERY and only
returns responses within the 512 byte limit for UDP, I don't think TCP
transport should be mandatory.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Aug 2009 15:03:14 +1000

In message <[email-masked]>, Matth
ew Dempsky writes:
> > Why do people only think about QUERY. =A0There are multiple opcodes

It should be manditory because it people get that analysis wrong.

It should be manditory because the SHOULD allows shoddy vendors to
ship servers without any TCP support despite all the problems it
causes and yet claim RFC compliance.

It should be manditory because there are lots of sites that are
scared to make their responses bigger than 512 bytes due to the
existance of the shoddy products above.

If you can get away with blocking TCP well and good but the moment
it causes any problem the onest should be on you to fix the problem
and it won't be there until TCP support is a MUST.

Mark

---

From: [email-masked]
Date: Thu, 27 Aug 2009 14:26:30 +0000

> for DNS.  We need a volunteer to edit that draft.  Does anyone want to

ok - so i -loath- the hoops that one must jump through to properly wrap 
six pages of boilerplate, disclaimers, table of contents, copywrite notices,
references, attributions and whatnot around a couple of paragraphs of an
idea.   To borrow an analogy, the IETF used to be the seedbank for heirloom
tomatoes.  Lots of diversity in shape, color, flavor.  Now... not so much.
Its manufactured/square tomatoes.  If the inputs arent all the same, its
rejected.   But enough of my rant.  (and yes, I -will- get this into the 
system somehow)  Here is an early proof of the draft for your consideration:

----

Intended Status: Standard Track                               B. Manning

Network Working Group                                             EP.NET

Internet-Draft                                               August 2009

Intended status: Informational

Expires: Dec 2009

                   Transport Considerations for DNS

               draft-manning-dnsop-transport-for-dns-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the

   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF), its areas, and its working groups.  Note that

   other groups may also distribute working documents as Internet-

   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappropriate to use Internet-Drafts as reference

   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at

   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF Documents in effect on the date of

   publication of this document (http://trustee.ietf.org/license-info).

   Please review these documents carefully, as they describe your rights

   and restrictions with respect to this document.

Abstract

   DNS queries and responses are available over a variety of transports 
(UDP/TCP) and may be ported to use other transports in the future. Current 
use profiles show that most user generated DNS traffic prefers one 
transport over another.  This historical usage pattern has or may lead
to the presumption that any DNS traffic, regardless of transport, should
be considered on equal footing. 

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Motivating factors . . . . . . . . . . . . . . . . . . . . . .  4

     2.1.  UDP vs TCP for DNS messages  . . . . . . . . . . . . . . .  4

   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8

   5.  IANA Considerations: . . . . . . . . . . . . . . . . . . . . .  9

   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10

     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10

     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   Familiarity with the DNS[RFC1034] [RFC1035], EDNS0[RFC2671] DNS

   Security Extensions[RFC4033], [RFC4034] [RFC4035] is assumed.

DNS queries and responses are available over a variety of transports 
(UDP/TCP) and may be ported to use other transports in the future. Current 
use profiles show that most user generated DNS traffic prefers one 
transport over another.  This historical usage pattern has or may lead
to the presumption that any DNS traffic, regardless of transport, should
be considered on equal footing.   

However, not all choices for transport share an equal cost to the DNS
operator.  This note is intended to inform and educate - that while
all transport options MUST/need to be supported, because of the different
cost and risk profiles of some transports, an operator may chose to
apply different processing criteria to different transports, prefering
some transport options over others.

1.1.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in RFC 2119.  [RFC2119]

2.  Motivating factors

2.1.  UDP vs TCP for DNS messages

   TCP requires more/longer-living state on both parties of a

   transaction.  For high volume DNS servers even small states per each

   query that need to be kept for "long" time is a potential DoS vector.

   Number of DNS servers are answering 50-100 Kq/s thus any state will

   consume significant memory resources.  UDP requires no state past the
   lifetime of the query.

3.  Acknowledgments

   Number of people have provided usefull feeback on

   this document, Daniel Karrenberg,

5.  Security Considerations

   Some transport options have different risk profiles and as their
   use increases, their use may be curtailed by the operator as a means
   of protecting their infrastructure.

6.  IANA Considerations:

   This document does not have any IANA actions.

7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and

              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [MATT]     Larson, M. and D. Blacka, "Port and Message ID Analysis of

              Resolvers Querying .com/.net Name Servers", Sept 2008.

Author's Address

 	Bill Manning
	EP.NET
	PO 12317
	Marina del Rey, CA 90295

---

From: Alex Bligh <[email-masked]>
Date: Thu, 27 Aug 2009 19:34:36 +0100

--On 27 August 2009 14:26:30 +0000 [email-masked] wrote:

> 1 Introduction.

This seems to be the only use of the word "MUST". It says
"all transport options MUST/need to be supported". "all transport options"
could include more than TCP/UDP (see previous paragraph "may be ported
to use other transports in the future"). Why not just say, as a stand
alone paragraph:

"DNS servers MUST support both UDP and TCP transports".

> 2.1.  UDP vs TCP for DNS messages

As this section is already stating what is (at least to us) obvious, you
might as well enumerate some other factors:

TCP transport will in general result in more latency as more packets
are exchanged prior to the party issuing the query receiving an
answer.

TCP transport may perform better when the answer expected is large, as
UDP transport may require fragmentation to be supported, and poorly
implemented or configured middleboxes may drop UDP fragments.

It is harder for a third party to spoof answers where TCP is used when
compared to UDP.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Thu, 27 Aug 2009 19:34:36 +0100

-- 
Alex Bligh

---

From: [email-masked]
Date: Fri, 28 Aug 2009 11:27:06 +0000

> "DNS servers MUST support both UDP and TCP transports".

	this wording change is not desirable.  this document is
	not intended to specify which transports may or may not be
	supported.  thats a function of the DNS core specs ..

	transports may change ... i don't want this docuement to 
	be the place where they are defined (again).

> It is harder for a third party to spoof answers where TCP is used when

	all true.  some of these are germaine to the primary motivation
	for this draft.   thanks.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 28 Aug 2009 13:40:41 +0100

----- Original Message ----- 
From: <[email-masked]>
To: "Alex Bligh" <[email-masked]>
Cc: <[email-masked]>; "Andrew Sullivan" <[email-masked]>; <[email-masked]>
Sent: Friday, August 28, 2009 12:27 PM
Subject: Re: [dnsext] Editor needed

> supported.  thats a function of the DNS core specs ..

I'm getting confused here...

Andrew originally asked

"One of the milestones on the Charter that we've been waiting to send
to our AD is a document that clarifies that TCP transport is mandatory
for DNS.  We need a volunteer to edit that draft.  Does anyone want to
do this?"

Actually I think Andrews suggestion is too strong.

I think TCP should be mandatory only for authorities that generate
responses in excess of 512 bytes.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Aug 2009 07:36:02 -0700

>responses in excess of 512 bytes.

Does this make sense from an operational standpoint? That is, assume that I am an authority who today doesn't emit responses in excess of 512 bytes, and I set up a system that will *only* do UDP, and a later improvement to DNS (like DNSSEC, but there could be others) would cause me to emit responses that are now longer. I will then have a broken system. I should now update the system to also, but I don't actually have to (the problems are for other people, not me), and so I now have an operationally broken system that looks OK to me.

We may be better off telling people that they need to support UDP and TCP from the beginning.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Fri, 28 Aug 2009 16:10:45 +0000

> We may be better off telling people that they need to support UDP and TCP from the beginning.

	i don't care what transports (multiple) are defined for use by the DNS.
	if its defined for use - then i posit in this document that it MUST be 
	supported...  be it avian carrier, STCP, UDP, TCP, NCP... I don't care.
	and this document should not be the place to define DNS transports.

--bill

---

From: Alex Bligh <[email-masked]>
Date: Fri, 28 Aug 2009 17:47:39 +0100

Bill,

> 	be the place where they are defined (again).

I can't disagree with your logic that the core specs are the place
> for DNS.  We need a volunteer to edit that draft.  Does anyone want to

That implied to me that:

a) the existing set of RFCs needs clarification (in respect of the
   fact that TCP is mandatory); and

b) the new draft should clarify that TCP transport is mandatory.

I read wording within the draft as "all transports are mandatory", which,
either means all transports currently defined within the DNS specs, or
(with reference to the preceding para in the draft) all transports that
might in the future be defined). It cannot be the case that all future
defined transports are mandatory to support, or someone could write an
experimental draft of DNS over avian carrier or whatever. It presumably
thus either means "all transports defined to date" which is a finite
enumerable set (of 2, as far as I know, UDP and TCP, though who knows,
there may be more deprecated ones), or "all current and future standards
track transports defined as mandatory to support within the relevant RFC",
which I'm not sure needs encoding as any future RFC would merely update
this one. I'm thus genuinely puzzled as to what it does mean. If it is
something like

  "DNS Servers MUST support all mandatory standards track transports,
   which at the date of publication of this RFC means both UDP and
   TCP, though this list may be added to (or subtracted from) in the
   future."

then let's say that, else it is no more clear than it was before.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Aug 2009 16:58:59 +0000

> From: "George Barwood" <[email-masked]>
> Date: Fri, 28 Aug 2009 13:40:41 +0100
> ...

+1.

---

From: [email-masked]
Date: Fri, 28 Aug 2009 17:12:00 +0000

> > responses in excess of 512 bytes.

	good - but that is not germaine to this proposal/draft.
	you write up a draft to change the core DNS specs to state
	that if you'd like.

--bill

---

From: Florian Weimer <[email-masked]>
Date: Fri, 28 Aug 2009 21:35:38 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> responses in excess of 512 bytes.

Uhm, isn't the technical criterion, "sets TC on an UDP response"?

Do you still want to say "SHOULD support TCP"?  Or do you want to make
TCP completely optional?

---

From: Alex Bligh <[email-masked]>
Date: Fri, 28 Aug 2009 22:43:32 +0100

--On 28 August 2009 23:29:01 +0200 [email-masked] wrote:

> TCP support is NOT currently mandatory.

I'm thus confused by Andrew's statement that we should clarify that
support is mandatory.

-- 
Alex Bligh

---

From: [email-masked]
Date: Fri, 28 Aug 2009 23:29:01 +0200

See §6.1.3.2 of RFC 1123:

  "DNS resolvers and recursive servers MUST support UDP, and SHOULD 
support TCP"

We had significant discussion with the IESG when RFC 5625 was in last call 
over this question. 

Ultimately 5625 says "MUST support TCP" for proxies, on the basis that if 
your client supports TCP, and the recursor supports TCP, it's damned rude 
of the middle-box sat in the path to sit their refusing to talk to either.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Aug 2009 10:35:35 +1000

In message <[email-masked]
rg.uk>, [email-masked] writes:
> See 6.1.3.2 of RFC 1123:

	And if you read all the discussion in that section it is
	clear that for any product designed to operate on the
	Internet the SHOULD becomes a MUST support TCP.  I can't
	see how any vendor could even start to think that TCP could
	be optional but clearly they did.  This leads us to saying
	that TCP needs to become a MUST as vendors can't be trusted
	to do the right thing.

            DISCUSSION:
                 UDP is preferred over TCP for queries because UDP
                 queries have much lower overhead, both in packet count
                 and in connection state.  The use of UDP is essential
                 for heavily-loaded servers, especially the root
                 servers.  UDP also offers additional robustness, since
                 a resolver can attempt several UDP queries to different
                 servers for the cost of a single TCP query.

                 It is possible for a DNS response to be truncated,
                 although this is a very rare occurrence in the present
                 Internet DNS.  Practically speaking, truncation cannot
                 be predicted, since it is data-dependent.  The
                 dependencies include the number of RRs in the answer,
                 the size of each RR, and the savings in space realized
                 by the name compression algorithm.  As a rule of thumb,
                 truncation in NS and MX lists should not occur for
                 answers containing 15 or fewer RRs.

                 Whether it is possible to use a truncated answer
                 depends on the application.  A mailer must not use a
                 truncated MX response, since this could lead to mail
                 loops.

                 Responsible practices can make UDP suffice in the vast
                 majority of cases.  Name servers must use compression
                 in responses.  Resolvers must differentiate truncation
                 of the Additional section of a response (which only
                 loses extra information) from truncation of the Answer
                 section (which for MX records renders the response
                 unusable by mailers).  Database administrators should
                 list only a reasonable number of primary names in lists
                 of name servers, MX alternatives, etc.

                 However, it is also clear that some new DNS record
                 types defined in the future will contain information
                 exceeding the 512 byte limit that applies to UDP, and
                 hence will require TCP.  Thus, resolvers and name
                 servers should implement TCP services as a backup to
                 UDP today, with the knowledge that they will require
                 the TCP service in the future.

---

From: "George Barwood" <[email-masked]>
Date: Sat, 29 Aug 2009 07:46:38 +0100

Ultimately DNS proxy servers are "evil" because they have to be updated if 
the DNS transport protocol changes in any way.

My understanding is that these proxies have come about due to DHCP timing issues.

That is, the list of DNS servers is sent over DHCP at a time when the middle box
may not have received the list of DNS servers from the WAN.

Unfortunately I'm not too familiar with the details of DHCP, but the fix would seem to be something roughly as follows:

If the box is connected to the WAN, it must return the WAN DNS servers, and not a proxy.

Clients that perform DHCP before the WAN is available, should retry the DHCP process after discovering a proxy with limited capabilities, and should be guarunteed to obtain a fully functional DNS server provided that the WAN is now functional.

In other words it's a clarification of DHCP implemention that is required ( or an update to DHCP if what I have just described is in fact not compatible with the DHCP standard ).

This would be a permanent fix, whereas mandating support for specific protocols is a temporary patch. Any IPv6 issues should be addressed at the same time.

George

---

From: "George Barwood" <[email-masked]>
Date: Sun, 30 Aug 2009 05:11:29 +0100

Well, I should have consulted the recently published RFC5625

http://tools.ietf.org/html/rfc5625#section-5

which describes how it can work using DHCP lease expiry,
although maybe the lease expiry mechanism is not quite ideal,
so maybe resolvers should take active steps (via DHCP) when
they discover an unsatisfactory proxy.

RFC5625 could perhaps have been more strongly worded with 
regards to proxies - that is it does explain they are bad, but then
describes how they should behave, rather than condemning them
outright, so a casual reading (and the abstract on it's own) might
lead to the wrong impression.

Regardless, I think an EDNS option to bootstrap a good list
of DNS servers through the currently deployed middleboxes could be
very useful in practice, and give a high return on investment.

George