Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-06.txt

From: [email-masked]
Date: Thu, 2 Jul 2009 13:00: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 Proxy Implementation Guidelines
	Author(s)       : R. Bellis
	Filename        : draft-ietf-dnsext-dnsproxy-06.txt
	Pages           : 14
	Date            : 2009-07-02

This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-06.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: Thu, 2 Jul 2009 21:33:28 +0100

>    Filename        : draft-ietf-dnsext-dnsproxy-06.txt

This update addresses comments from AD review:

      Section 4.1 - cleaned up tautological language and changed SHOULD
      to MUST (Adrian Farrel)
      Section 4.4.1 - made TCP support mandatory (from Lars Eggert)
      Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko)
      Section 6.3 - clarified rationale for handling errors (from Robert
      Sparks)

Ray

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

---

From: Florian Weimer <[email-masked]>
Date: Fri, 03 Jul 2009 10:13:36 +0000

>       Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko)

At the DNS layer, you can't pass through EDNS0 without actually
understanding it.  For example, I think you should drop options which
you don't implement because they could result in a reply you can't
process, and you have no way to signal this failure to your downstream
recipient.  You can't even attribute it to a particular option.

If you want to handle EDNS0, you really have to mandate clear UDP and
TCP channels to the actual DNS servers, as if the proxy was performing
destination NAT.  No payload inspection is allowed, and certainly no
caching.  This is somewhat at odds with language in section 6.1, which
suggests that it's okay with the draft if the proxy changes
transaction IDs, as long as it properly randomizes them.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 3 Jul 2009 11:51:10 +0100

> understanding it.

Actually many DNS proxies do "pass-through" EDNS0 perfectly happily, 
because those proxies literally do almost nothing except forward the 
packet to an upstream resolver.  They pretty much do provide the clear 
channel that you mention below.

The only time this is a problem is if the EDNS0 buffer size sent by the 
client is larger than the maximum response size that the proxy itself can 
handle.

> transaction IDs, as long as it properly randomizes them.

TBH I can't recall exactly _why_ some proxies generate their own 
transaction IDs.  It is the only packet modification that's allowable 
without breaking TSIG though.

Ray

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 03 Jul 2009 14:00:12 +0200

> without breaking TSIG though.

I would think to provide multiplexing, to make IDs unique per query.

Best regards,
   Wouter

---

From: [email-masked]
Date: Fri, 3 Jul 2009 13:05:01 +0100

> I would think to provide multiplexing, to make IDs unique per query.

That's what I thought, but then I couldn't figure out why they couldn't do 
it on the locally chosen source port instead.  (By which I mean the one 
chosen by the proxy for the forwarded packet, not the original source port 
used by the client).

Clearly resolvers which always use port 53 as the source port would have 
to use the QID, but the proxies don't do that.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Jul 2009 00:42:13 +1000

In message <[email-masked]>, [email-masked] writes:
> transaction IDs.

	So you can correctly match responses to the request and
	forward the correct response to the correct requestor.  You
	only have the first 12 bytes of the request to do this with
	and "id" is often the only differentiator.   If you have
	two request from two sources with the same "id" you can't
	correctly do that.  You need to maintain your own "id" space
	and use that to map back to the original id.

	Mark

> It is the only packet modification that's allowable 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Jul 2009 00:52:42 +1000

> to use the QID, but the proxies don't do that.

	Each port can have its own id space.  That way you can
	support more than 2^16 outstanding queries.

	Mark

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 3 Jul 2009 08:28:45 -0700

One minor nit:

On fragmentation.  (4.4.3)

Method 1 (dropping fragments) must not be used, because it is  
incapable of ensuring that 4096B EDNS0 fragments can be passed.

It is implied in the text, but it should be made explicit, because the  
de-facto MTU is the ethernet MTU, which is considerably less.

Additionally, any NAT or firewall that allows through the first part  
of a UDP packet that is fragmented must allow the subsequent fragments  
through unless the specific fragment should be blocked by a security  
policy.  If not, thats a bug that should be fixed.

Any proxy MUST reassemble IP fragments before proceeding.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 3 Jul 2009 12:38:06 -0400

On Fri, Jul 03, 2009 at 08:28:45AM -0700, Nicholas Weaver wrote:
> Method 1 (dropping fragments) must not be used, because it is incapable 
> of ensuring that 4096B EDNS0 fragments can be passed.

Do you have a text patch, please?  This document went through WGLC
already, and I'd expect that most details are worked out by this WG
now, so if you have something you want "fixed" please state how you
want it fixed.  Thanks.

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 3 Jul 2009 10:42:19 -0700

On Jul 3, 2009, at 9:38 AM, Andrew Sullivan wrote:

>> incapable

Existing text:
  Therefore (irrespective of which of the methods above is in use)
  proxies SHOULD be capable of forwarding UDP packets up to a payload
  size of at least 4096 octets.

Suggested change the paragraph:

Therefore proxies SHOULD be capable of forwarding UDP packets up to a  
payload  size of at least 4096 octets.  Unfortunately, this is  
significantly greater than the Ethernet MTU of 1500 octets, which has  
become the de-facto MTU over most networks in use today.  Therefore,  
method 1, dropping fragments, is not an advisable solution, and SHOULD  
NOT be used.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 03 Jul 2009 19:39:30 +0100

> method 1, dropping fragments, is not an advisable solution, and SHOULD

This would appear to be a tautology. Ignoring the exception case where
the MTU on either side of the NAT is at least 4096 octets, there
is no way I can immediately see that a NAT satisfying the first
'SHOULD' could use method 1 anyway. My worry is that this looks
like a separate requirement.

I thus don't think anything needs changing. If it does, I would
simply do this:
  Therefore (irrespective of which of the methods above is in use)
  proxies SHOULD be capable of forwarding UDP packets up to a payload
  size of at least 4096 octets **which almost invariably precludes
  using method 1 as lower MTUs are commonplace**.

-- 
Alex Bligh

---

From: [email-masked]
Date: Fri, 3 Jul 2009 19:57:03 +0100

>   using method 1 as lower MTUs are commonplace**.

Please note that as of earlier this afternoon the draft has been approved 
by the IESG for submission to the RFC Editors (although the datatracker 
doesn't reflect this yet).

Ray