Subject: [dnsext] DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01

From: [email-masked]
Date: Tue, 6 Jan 2009 11:52:53 +0000

An update to this draft has been uploaded with revisions based on comments 
received so far.

> A new version of I-D, draft-ietf-dnsext-dnsproxy-01.txt has been
> successfuly submitted by Ray Bellis and posted to the IETF repository.
>
> Filename:        draft-ietf-dnsext-dnsproxy
> Revision:        01
> Title:           DNS Proxy Implementation Guidelines
> Creation_date:   2009-01-06
> WG ID:           dnsext
> Number_of_pages: 12

Would those who volunteered to review so that this could became a WG item 
please take another look?

  Srini Avirneni
  Stephane Bortzmeyer
  Shane Kerr
  Jim Reid
  Nicholas Weaver

kind regards,

Ray

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

--
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: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Jan 2009 09:32:59 -0800

> An update to this draft has been uploaded with revisions based on  

I looked at it.  I'm happy/think its a good document except for  
wanting a little more detail on bypassibility.  I sent ray some  
possible text to consider, noting that there are reasons to NOT allow  
bypassibility, and that NAT port rewriting is critical in how it works.

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Jan 2009 12:59:16 +0000

> please take another look?

I have reviewed the latest draft. Although it still needs some work,  
it's in pretty good shape. I support this draft becoming a work item  
for the WG.

---

From: [email-masked]
Date: Thu, 15 Jan 2009 14:35:28 +0000

> it's in pretty good shape. I support this draft becoming a work item 

Jim,

Thanks for reviewing the draft, although it is _already_ a WG item, as 
agreed in Minneapolis.

I was there when you promised to Olafur that you would review it, that 
promise being the last of the five that the chairs needed to progress the 
draft.  Your memory of that may be slightly hazy - we were sat in the bar 
at the time ;-) 

If you've got specific ideas or wording for the areas that you think need 
work, please do let me know!

kind regards,

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 16:33:12 +0100

On Tue, Jan 06, 2009 at 11:52:53AM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 35 lines which said:

> An update to this draft has been uploaded with revisions based on
> comments received so far.

I've read the document draft-ietf-dnsext-dnsproxy-01 and found it is
correct and well written. I did not find errors (editorial or technical).

I have a general remark, which is, it seems, quite close from the one
raised by Ed Lewis. Since the general advice in
draft-ietf-dnsext-dnsproxy-01 is "Do not mess with the DNS packets at
all, you will surely be wrong", why not saying frankly "Do not be a
DNS proxy, be a router"?

Or, said with different words, why is it useful to have "DNS proxies"
at all? I see two possible reasons:

* simplifying DHCP service, since the "box" just advertises its own IP
address as the DNS resolver.

* providing added value such as caching and/or firewalling against
some attacks,

Only the first reason is mentioned in the draft (section 5.1). The
second reason is doubtful since the typical CPE box does not cache DNS
responses and does not provide an useful security service.

Then, why not turning the draft into a "DNS proxy considered harmful"
document?

Disclaimer: my CPE box at home has no DNS proxy at all. It is a
Freebox provided by Free, the second largest IAP in France, and with
its default configuration. It advertises the DNS resolvers of Free on
the LAN (with DHCP).

---

From: [email-masked]
Date: Tue, 20 Jan 2009 15:45:11 +0000

> correct and well written. I did not find errors (editorial or 
technical).

Thank you :)
 
> address as the DNS resolver.

That appears to be the most common reason.  I don't believe any 
manufacturer has found a perfect solution to the bootstrap problem - how 
do you offer DNS settings via DHCP if you don't know what the upstream 
settings are when you boot - see below.

The solution they have chosen - the proxy - has its own problems, although 
I suspect many manufacturers are blissfully unaware of how bad those 
problems are.

> * providing added value such as caching and/or firewalling against

We've seen caching on a few units, but no DNS-specific "bad packet" 
rejection algorithms.

> responses and does not provide an useful security service.

Indeed.
 
> Then, why not turning the draft into a "DNS proxy considered harmful"

I'd certainly agree that they're generally harmful.  If there's a better 
solution for the bootstrap problem I'd be happy to propose it.
 
> its default configuration. It advertises the DNS resolvers of Free on

I'm curious - what DNS servers does it advertise via DHCP at:

1.  first boot
2.  once the WAN link is up
3.  on subsequent reboots (before and after WAN up)

Are they perhaps hard-coded, because this box is supplied by Free 
pre-configured, and is always used with their service?

kind regards,

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 16:51:12 +0100

On Tue, Jan 20, 2009 at 03:45:11PM +0000,
 [email-masked] <[email-masked]> wrote 

> pre-configured, and is always used with their service?

AFAIK (the box is closed), it advertises nothing on the network until
the WAN link is up (it displays a nice ASCII art, in french, "le
chenillard", when it waits for it). This is consistent with the fact
that the box upgrades itself over the WAN. Apparently, the Freebox
boots, waits for the WAN to be up (no PPPoE or similar stuff, 100 %
proprietary), tests if there is a new version of the code
(Linux-based), downloads it if necessary (it may downloads
configuration information as well), then, and only then, starts to
serve the LAN. At this stage, it knows the DNS resolvers.

---

From: [email-masked]
Date: Tue, 20 Jan 2009 15:53:55 +0000

> serve the LAN. At this stage, it knows the DNS resolvers.

So, if you have two machines on your network, they can't get DHCP from the 
router until the WAN is up?

If so, that's not ideal, since lack of WAN connectivity then prevents 
correct LAN operation, AIUI.

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 17:06:50 +0100

On Tue, Jan 20, 2009 at 03:53:55PM +0000,
 [email-masked] <[email-masked]> wrote 

> correct LAN operation, AIUI.

In the case of the Freebox, which serves triple play, the problem is
not too serious: since the telephone and the TV depend on it, it is
always on.

But we drift far away from DNS proxies :-)

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 20 Jan 2009 08:07:36 -0800

> its default configuration. It advertises the DNS resolvers of Free on

This is actually one of the big reasons TO be a proxy.

Upon startup, the box may not have an external DHCP lease, but should  
be able to assign values to the internal host.  Thus there are  
multiple boxes which, if they don't have a lease, return their own IP  
address (which acts as a proxy).  Until the box gets a DHCP lease, it  
returns its own IP as the DNS resolver and runs a proxy.  Once it gets  
a DHCP lease, it will then return the external DNS resolver addresses  
in response to lease requests.

---

From: [email-masked]
Date: Tue, 20 Jan 2009 16:12:05 +0000

> in response to lease requests.

Most Linksys units behave the way you describe.

Of the other units we tested for SAC035 almost all continued to offer 
their own IP address even once the WAN link was up.

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 20 Jan 2009 08:13:51 -0800

> their own IP address even once the WAN link was up.

There is one more reason to ALWAYS proxy:

DHCP lease changes.  On some services, your DHCP lease may be rather  
volatile, and this could also include changes in DNS servers.

By always proxying, you don't need to give your clients short leases,  
but can give them lease-lengths of practically-infinity, and not have  
to worry about your DNS server changing.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 20 Jan 2009 08:16:34 -0800

> serve the LAN. At this stage, it knows the DNS resolvers.

This means, however, you can't use the LAN unless the WAN is functional.

I have 1 printer and 3 computers on my LAN, including internal file  
sharing and printing services.  I would not want the WAN to MUST work  
for the LAN to be functional.

There are really only two options if the WAN is not functional but you  
want the LAN to function:

1) Return the address of a DNS proxy running on the NAT.

2) Return very short (<1 minute) DHCP leases until the WAN is  
functional and you have valid DNS settings.

---

From: [email-masked]
Date: Tue, 20 Jan 2009 16:20:10 +0000

> functional and you have valid DNS settings.

3) toggle the link-state on the router's LAN ports on WAN link-state 
change.

On many modern systems a link-state change will trigger renewal of the 
DHCP lease.

This is mentioned in §5.3, paragraph 4, but only as an idea and without 
any RFC2119 language.

Ray

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 17:33:19 +0100

On Tue, Jan 20, 2009 at 08:07:36AM -0800,
 Nicholas Weaver <[email-masked]> wrote 
 a message of 18 lines which said:

> Upon startup, the box may not have an external DHCP lease, but
> should be able to assign values to the internal host.  Thus there
> are multiple boxes which, if they don't have a lease, return their
> own IP address (which acts as a proxy).  Until the box gets a DHCP
> lease, it returns its own IP as the DNS resolver and runs a proxy.
> Once it gets a DHCP lease, it will then return the external DNS
> resolver addresses in response to lease requests.

I'm now completely lost. If the WAN link is down, what's the point of
having a proxy on the box? It will have nowhere to forward the
requests. And if the WAN link is up, you can get the IP addresses of
the resolvers, and you can distribute them on the LAN with DHCP.

Really, I do not see the point of having proxies.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 17:36:25 +0100

On Tue, Jan 20, 2009 at 08:16:34AM -0800,
 Nicholas Weaver <[email-masked]> wrote 

> This means, however, you can't use the LAN unless the WAN is

No, it means you cannot use the global DNS unless the WAN is
functional (a tautology, and independant of the specific techniques
you use).

But the LAN works, and RFC 3927, 4795 and 4862 are still there.

> for the LAN to be functional.

See the RFCs above.

---

From: [email-masked]
Date: Tue, 20 Jan 2009 16:52:17 +0000

> having a proxy on the box?

Because the router has to put *something* in the DHCP lease.

> It will have nowhere to forward the requests.

Yes, that's right.

> And if the WAN link is up, you can get the IP addresses of

You can, but most routers don't :(

> Really, I do not see the point of having proxies.

I'd prefer they weren't there either, but the fact is they are, so let's 
try and at least make sure they work right :)

cheers,

Ray

---

From: [email-masked]
Date: Tue, 20 Jan 2009 16:54:26 +0000

> But the LAN works, and RFC 3927, 4795 and 4862 are still there.

That's fine, so long as the WAN stays down.

However, when it does come back up, you're still left with a network that 
can't get to the rest of the internet, until you request new DHCP leases 
from the router.

Ray

---

From: [email-masked]
Date: Tue, 20 Jan 2009 17:32:14 +0000

> Unfortunately, this only works if there are no intermediate switches
> in the path.  While my home network may be atypical (3 deep tree and
> branch), even my dad's home network has a few switches thrown in.

Good point :(

Ray

---

From: Michael StJohns <[email-masked]>
Date: Tue, 20 Jan 2009 12:30:50 -0500

>On many modern systems a link-state change will trigger renewal of the 

Unfortunately, this only works if there are no intermediate switches in the path.  While my home network may be atypical (3 deep tree and branch), even my dad's home network has a few switches thrown in.

Mike

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 20 Jan 2009 09:33:57 -0800

> branch), even my dad's home network has a few switches thrown in.

Also, how does link-state work on WiFi?

And you often end up needing a switch out of port count necessity.

The Xbox, the media server, the printer, the Tivo, a hardline port for  
debugging/faster-transfers and you are up to 5 already!

Not to mention the advantage of putting the file server on a gig  
switch, so you can do wireline transfers at high speed.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 20 Jan 2009 23:59:02 -0500

> This is mentioned in §5.3, paragraph 4, but only as an idea and without 

Has anyone thought to forward this to the DHCP Working Group for their
input? You are ascribing a great deal to DHCP requirements, so they
should also comment on this draft.

Danny

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Jan 2009 08:46:29 +0100

> > I'm now completely lost. If the WAN link is down, what's the point
> > of having a proxy on the box?
> 

Why? Option 6 "Domain Name Server option" of the DHCP reply is... an
option.

---

From: [email-masked]
Date: Wed, 21 Jan 2009 08:16:27 +0000

> option.

Because if there's nothing there, the client device has to rely on local 
configuration.  That's no good for customers expecting "plug-and-play" 
networking with their router, and it's certainly no good for mobile 
devices.

You and I might not struggle with how to change the DNS settings on our PC 
or Mac laptop, but many users would.

Ray

---

From: [email-masked]
Date: Wed, 21 Jan 2009 08:19:51 +0000

> should also comment on this draft.

The draft itself makes no recommendations about the protocol.

The only recommendations are about what features the DHCP server that's 
found alongside the DNS proxy in broadband gateways should support.

That said, ISTR that Olafur said that he would liaise with the DHC WG if 
necessary.

Ray

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Jan 2009 09:05:01 +0000

> You and I might not struggle with how to change the DNS settings on our
> PC  or Mac laptop, but many users would.

Let's see if I can put it more clearly:

CPE vendors cannot rely on the order of boot up and line availability.
If the client device boots prior to the availability of a route to the
outside world, but when the CPE is available, and the client device
issues a DHCP request (still prior to the availability of a route
to the outside world), the client device has 4 choices:
  1. Don't respond (play dead)
  2. Respond without a DNS server option
  3. Respond with the last returned DNS server option (only possible
     if in NVRAM in the case of a reboot or hardcoded)
  4. Respond with own IP address and proxy

The problem with (1) is that networking won't work at all. Also, when
the line does come up, there is no reliable way to cause the client
to rerequest a DHCP lease.

The problem with (2) is that though local networking will work, DNS won't.
When the line does comes up, there is still no reliable way to cause
the client to rerequest a DHCP lease.

The problem with (3) is that if the line comes up with different DNS
servers, DNS access will/may be broken; also, it's necessary to store
things in NVRAM.

The problem with (4) is set out in Roy's draft.

The common theme here would seem to be that if there was a reliable way
to cause clients to rerequest a DHCP lease (toggling the ethernet
status won't work e.g. over wireless), /and/ client OS negative caching
worked reasonably (it might or might not), there would probably be less
perceived need for CPE to act as a proxy. But as currently there is no
such method, CPE vendors proxy.

I don't think Roy's draft attempts to say (or can be read as saying)
"here is a wonderful new technology to proxy DNS properly, please
go do this". It's saying "if you really have to do it, here's the
way of doing it in the least broken manner".

--
Alex

---

From: [email-masked]
Date: Wed, 21 Jan 2009 09:43:29 +0000

> The problem with (4) is set out in Roy's draft.

Thank you Alex - that's a good summary of the options.

I would possibly split (3) though, based on whether the values are 
hard-coded, or just remembered from the last WAN settings.

We have seen at least one router/firewall which remembers *learnt* DNS 
settings in NVRAM, and persists those over a reboot.  As you say that 
could be problematic, albeit only in unusual circumstances.

I don't have a problem with routers having hard-coded DNS settings if 
that's what the end user wants, and that avoids the bootstrap problem. 
However many routers *don't* allow end-user reconfiguration of the values 
to be supplied in DHCP :(

> perceived need for CPE to act as a proxy.

Indeed.  That maybe is something for the DHC group to consider.

> But as currently there is no such method, CPE vendors proxy.

Yes, that's my conclusion.  It's considered to be the "least bad", except 
that the implementation is usually pretty poor.

> way of doing it in the least broken manner".

That's it exactly.

Ray

p.s not Roy, BTW!  Our boss still mixes us up, though :)

---

From: Alex Bligh <[email-masked]>
Date: Wed, 21 Jan 2009 09:50:23 +0000

> p.s not Roy, BTW!  Our boss still mixes us up, though :)

Sorry.

Alex

---

From: Danny Mayer <[email-masked]>
Date: Wed, 21 Jan 2009 20:29:09 -0500

> The draft itself makes no recommendations about the protocol.

That wasn't the point. People here are making plenty of statements about
what DHCP needs and wants but noone seems to be asking them for what
their requirements really are and they can add a lot to the discussion.
They are an active group and are not shy about discussing issues!

> found alongside the DNS proxy in broadband gateways should support.

For which their opinion should be sought.

> That said, ISTR that Olafur said that he would liaise with the DHC WG if 

Well I copied the DHCP WG on this message.

Danny

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Jan 2009 08:41:16 -0500

in one archive and avoid burdening subscribers to both lists with  
duplicate traffic...

- Ralph

On Jan 21, 2009, at 8:29 PM 1/21/09, Danny Mayer wrote:

> [ 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. ]
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Jan 2009 11:35:48 -0500

contribute here)

So, I read the draft and then traced the thread in the namedroppers  
archive.

I came up with a couple of questions when I read the draft, some of  
which seemed to be answered in the discussion thread.

* Why DNS proxies?

So the DHCP server can send a consistent DNS recursive resolver  
address to clients ... which seemed to me to be a pretty cart-before- 
the-horse reason to go through this whole proxy exercise.  I know  
"something" has to be done, but my intuition is that the problems with  
proxies should encourage us to find a better solution.  This line of  
thought lead to my next couple of questions:

* How does the DNS proxy respond if there is no WAN connection?

...because once the WAN connection is in place, the BGW (broadband  
gateway) SHOULD default to sending the DNS recursive resolver it  
learned from the WAN DHCP server, and SHOULD allow the home network  
admin to override that setting.  So, the only time sending the BGW  
address as the DNS recursive resolver, employing a proxy, is when the  
WAN connection is not yet in place, but, if the WAN connection isn't  
in place, the DNS proxy has nowhere to proxy to, anyway.  The client  
doesn't get any additional function out of this proxy, right?

* Under what circumstances is there really a problem?

How often is it the case that the BGW doesn't have the address of a  
DNS recursive resolver to send via DHCP to hosts on the LAN?  In my  
opinion, the BGW SHOULD use the address of the resolver associated  
with the address it obtained through DHCP on its WAN connection.  Even  
if the WAN connection is down, the BGW SHOULD send that resolver  
address as long as the lease on the WAN address hasn't expired.

And, if the lease has expired, is there harm in sending the most  
recently obtained resolver address, anyway?  The BGW is still in the  
state, presumably, where the WAN connection is down, so there won't be  
any DNS resolution anyway.

Conversely, what happens to hosts if the DHCP server supplies no DNS  
resolver?

* Suppose the BGW doesn't have the address of a resolver

Well, as has been discussed in this thread, the problem is in the  
transition when the BGW is finally configured with the address of a  
resolver.  Prior to the WAN connection coming up, it doesn't much  
matter what address the BGW hands to hosts on the LAN; DNS resolution  
isn't going to work.  So, (and, again, I think this solution is hinted  
at in this thread and the draft) the BGW SHOULD use a short DHCP lease  
time until it can supply the hosts on the LAN with the address of a  
good resolver.

I recognize the impact of short DHCP leases on BGW performance.  It  
would be interesting to test the DHCP servers in these BGW with, say,  
20 hosts and a lease time of 1 minute.

Note that all of this discussion is aimed at solving the proxy problem  
by avoiding proxies.  I don't know if that goal is in scope of this  
draft.  Another solution, of course, would be to put a real recursive  
resolver in the BGW, which might have other advantages for DNSSEC.

Finally, after asking all this, I wondered...

* What do we want to get out of this recommendation?

Are we trying to change the future behavior of BGWs in some way?  If  
we're going to try to change the behavior of BGWs regarding DNS  
proxies, can we take a bigger step and try to get rid of them  
altogether?

- Ralph

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 22 Jan 2009 22:56:48 +0100

> or Mac laptop, but many users would.

What about following scenarios?
1. WAN is down, put nothing into DNS option and make DHCP lease time very short
2. WAN is up, use upstream DNS and make DHCP lease longer.

Ondrej.
-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Jan 2009 17:02:28 -0500

previous  
post...

- Ralph

On Jan 22, 2009, at 4:56 PM 1/22/09, Ondřej Surý wrote:

> 2009/1/21  <[email-masked]>:

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 Jan 2009 12:36:17 +0100

> 2. WAN is up, use upstream DNS and make DHCP lease longer.

+1

But there is a variant:

1. WAN is down, do not reply to DHCP queries, machines on the LAN will
use RFC 3927, 4795 and 4862 and will, I hope, retry DHCP from time to time
2. WAN is up, use upstream DNS and make DHCP lease longer.

The good thing of your proposal is that it does not rely on clients
retrying DHCP "often".

---

From: Ralph Droms <[email-masked]>
Date: Fri, 23 Jan 2009 07:22:07 -0500

However, there may be other information to be delivered to the clients  
via DHCP, and some hosts/applications may not do well with a switch  
from link-local to routable addresses once DHCP actually runs.

- Ralph

On Jan 23, 2009, at 6:36 AM 1/23/09, Stephane Bortzmeyer wrote:

> On Thu, Jan 22, 2009 at 10:56:48PM +0100,
> Ond?ej Surý <[email-masked]> wrote
> a message of 27 lines which said:
>