Subject: [dnsext] WGLC: DNS Proxy Implementation Guidelines

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 12 Mar 2009 18:21:50 -0400

This note starts a Working Group Last Call for this Standards Track document
ending on midnight April 2'nd UTZ 2009.

URL for the document and its history:
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnsproxy/

We are planning to ask for publication as a BCP.  We think that it does not
update any RFC.  Some may think that the recommendations in the document
do in fact update a Standards Track document.  If you believe that,
please tell us the specific text you think is problematic, and
what RFC it updates.

Please read the document carefully, this is an important document that
the DNS community can use to improve the behavior of an important segment of
the industry.

The document process rules in this working group, require that at least
5 members of the working to state that they have reviewed the document
and there is consensus of support to publish it as a BCP.

Notes: the final wording of section 4.5 will be determined during 
this last call.
Some issues have been raised about SHOULD/MUST language in there, see
http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00289.html

         Olafur (for the chairs)

---

From: Paul Selkirk <[email-masked]>
Date: Thu, 12 Mar 2009 23:25:11 +0000 (UTC)

I have read this draft, and I generally approve.  However, there are a
couple sections that left me puzzled.  Given that this document is
intended as guidance to the vendor community, it should probably be as
clear as possible.

5.1.  Domain Name Server (DHCP Option 6)
   It is therefore RECOMMENDED that gateways SHOULD support end-user
   configuration of values for the "Domain Name Server" DHCP option.

As near as I can tell (after several close readings), what this is
suggesting is that, if the DHCP client sends Option 6, the gateway's
DHCP server should echo it back, rather than sending its own IP
address.  This means the DNS server option would be hardcoded in the
DHCP client configuration, rather than being hardcoded in the stub
resolver.

5.2.  Domain Name (DHCP Option 15)
   Since no standard exists for a "local" scoped domain name suffix it
   is RECOMMENDED that the default value for this option SHOULD be
   empty, and that this option SHOULD NOT be sent to clients when no
   value is configured.

I'm not sure what you're suggesting here.  Don't misconfigure this
option?

				paul

--
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, 13 Mar 2009 08:30:41 +0000

> DHCP client configuration, rather than being hardcoded in the stub

It's nothing to do with echoing any Option 6 supplied by the DHCP client.

It means hard-coded in the gateway's GUI, such that any mobile client can 
still learn the correct settings.

> I'm not sure what you're suggesting here.  Don't misconfigure this

In particular, it means don't put in something like '.vendor'.

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 13 Mar 2009 08:18:50 -0700

I've read this document and am generally happy with it.

No nits/etc jumped out at me either, either on a reread or looking at  
the DIFFs.

---

From: "Griffiths, Chris" <[email-masked]>
Date: Fri, 13 Mar 2009 11:51:30 -0400

Hello,

I have read through the latest version of the draft and I want to voice
my support for this document.  It is very important that we get a set of
guidelines on DNS proxies particularly with gateways given the current
lack of support for EDNS0, DNSSEC, etc for these types of devices.  I
also support the standardized approach of allowing users to set
transparency to enable support for sending queries directly to caching
name servers up stream as detailed in section 3 and 5.1 in the draft
instead of forcing the end user to only use the proxy.

Thanks

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Mar 2009 16:12:09 +0000

--On 12 March 2009 18:21:50 -0400 "Ólafur Guðmundsson /DNSEXT chair" 
<[email-masked]> wrote:

> the DNS community can use to improve the behavior of an important segment
> of the industry.
>

I have reviewed this document. I support its publication as a BCP.

I suspect there may be scope for an RFC with many of the recommendations
in here made mandatory; I do not, however, think this should impede
publication of this document as a BCP.

Alex

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Mar 2009 12:21:09 -0400

At 18:21 -0400 3/12/09, Ólafur Guðmundsson /DNSEXT
  chair wrote:
This note starts a Working Group Last Call for this Standards Track document
ending on midnight April 2'nd UTZ 2009.

Re-reading this, it is much more clear to me that 
this applies to broadband gateways.  (Last time I 
was thinking stateful firewalls and such.) 
Knowing that this document talks about things 
like broadband joining devices increases the 
readability.

I have one suggestion, and I mean this as a 
suggestion.  I think the title should be changed 
to:

                DNS Broadband Proxy Implementation Guidelines

(addition of "Broadband")

I know this sounds a little petty, but in the 
history of this WG a lot of good work has gone 
into documents that were given grand titles and 
drew criticism because the work was focused on 
something particular.  In this revision, the 
abstract and intro do a good job of limiting the 
scope.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Alan Barrett <[email-masked]>
Date: Fri, 13 Mar 2009 18:39:32 +0200

>    configuration of values for the "Domain Name Server" DHCP option.

"end user" here means "the administrator of the gateway device", not
"the user of some other device that is a dhcp client of the gateway".

Perhaps this and other uses of the term "end user" should be
edited for clarity.

--apb (Alan Barrett)

---

From: Paul Selkirk <[email-masked]>
Date: Sat, 14 Mar 2009 00:49:33 +0000 (UTC)

> Perhaps this and other uses of the term "end user" should be

Okay, that makes more sense.  When I hear "end-user", I think of the
guy with the laptop, not the gateway admin.  I suppose the local
gateway admin is the "end-user" from the perspective of the gateway
equipment vendor.

In the following sections, "end-user" appears to refer to the user of
a device attached to the gateway (the guy with the laptop):

section 3, line 182:
   Except when required to enforce an active security or network policy
   (such as maintaining a pre-authentication "walled garden"), end-users
   SHOULD be able to send their DNS queries to specified upstream
   resolvers, thereby bypassing the proxy altogether.  In this case, the
   gateway SHOULD NOT modify the DNS request or response packets in any
   way.

section 5.1, line 413:
   As per Section 3, end-users SHOULD be able to send their DNS queries
   directly to specified upstream resolvers, ideally without hard-coding
   those settings in their stub resolver.

section 5.3, line 439:
   In general this behaviour is highly desirable, but the effect for the
   end-user is that the settings used depend on whether the DHCP lease
   was obtained before or after the WAN link was established.

Suggest changing other occurrences of "end-user" to something like
"local gateway admin".

> In particular, it means don't put in something like '.vendor'.

Which would be misconfiguring the option.

It seems sad that we'd have to tell people that the value of the
Domain Name Option has to be a valid Domain Name, but that's humans
for you.

Notwithstanding the ability of local gateway admins to manually bollux
their own configs, I wholeheartedly agree that equipment vendors
shouldn't be shipping pre-bolluxed gateways.

I would only change the SHOULD NOT to a MUST NOT: "this option MUST
NOT be sent to clients when no value is configured".

				paul

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 20 Mar 2009 11:23:32 -0400

Reminder, we still need more reviewers
thanks.
         Olafur

At 07:08 13/03/2009, Ólafur Guðmundsson /DNSEXT wrote:

>Notes: the final wording of section 4.5 will be 
>determined during this last call.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Mar 2009 10:54:29 +0100

On Thu, Mar 12, 2009 at 06:21:50PM -0400,
 Ólafur Guðmundsson /DNSEXT chair <[email-masked]> wrote 

> the DNS community can use to improve the behavior of an important segment of

I have read (seriously, I believe), the document, and I do not have
specific typos to fix or technical changes to make.

I regret that it seems to acknowledge the idea of "DNS proxies",
things which are not real proxies (like a BIND or Unbound configured
with forwarders are) but neither real and (transparent to DNS)
routers. The middleboxes mentioned in the document seem to me to be
real hacks and their usage should be discouraged. Section 3 is far
from perfect in that respect.

But I understand that there is a big problem today with broken proxies
and, should we have these hacks, it is better to have them behave not
too badly. 

Therefore, publication of this document seems OK to me. Without the
last paragraph of 5.3, I would have hesitated a lot.