Subject: [v6ops] 7084-bis DNS proxy requirement

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Jun 2017 14:33:18 +0000

I don't think this is the right recommendation:  
 L-12:  The IPv6-only CE router SHOULD implement a DNS proxy as
          described in [RFC5625].

There are many CE routers that pass to LAN devices the address of WAN-based DNS servers (of ISP or Google, etc.) and do not implement a DNS server as a forwarding proxy. This "SHOULD" requirement in the context of a CE Router that does not implement a forwarding proxy is meaningless, and not implementing a forwarding proxy is very valid and does not need to be discouraged. On the other hand, if a forwarding proxy is implemented, doing so according to RFC 5625 needs to be required. Forwarding proxies that aren't compliant with RFC 5625 have no business being deployed to mass market consumers.

Note that BBF TR-124 has a requirement for RFC 5625 worded as:
"If the RG's DNS server is implemented as a forwarding proxy, it MUST be done according to the recommendations in RFC 5625."

Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 14:12:30 -0400

> There are many CE routers that pass to LAN devices the address of WAN-based DNS servers (of ISP or Google, etc.) and do not implement a DNS server as a forwarding proxy. This "SHOULD" requirement i…

The reason this is here is that naming has to work when the northbound interface of the CE router is not connected.   This is not to say that there is any local name service, but simply that the CE router has to have an IP address for the resolver that it can give out at that time, and may not have an IP address for an _external_ resolver that can be assumed will be functional when the northbound interface reconnects.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 15:39:26 -0400

Why is that device a router at all, and not a bridge?  Does it have a DHCP
server?

On Jun 15, 2017 3:29 PM, "STARK, BARBARA H" <[email-masked]> wrote:

There are many CE routers that pass to LAN devices the address of WAN-based
DNS servers (of ISP or Google, etc.) and do not implement a DNS server as a
forwarding proxy. This "SHOULD" requirement in the context of a CE Router
that does not implement a forwarding proxy is meaningless, and not
implementing a forwarding proxy is very valid and does not need to be
discouraged. On the other hand, if a forwarding proxy is implemented, doing
so according to RFC 5625 needs to be required. Forwarding proxies that
aren't compliant with RFC 5625 have no business being deployed to mass
market consumers.

The reason this is here is that naming has to work when the northbound
interface of the CE router is not connected.   This is not to say that
there is any local name service, but simply that the CE router has to have
an IP address for the resolver that it can give out at that time, and may
not have an IP address for an _external_ resolver that can be assumed will
be functional when the northbound interface reconnects.

<BHS> Having an IP address of a resolver to hand out is very different than
requiring all CE Routers to be the resolver. I very much disagree that all
CE Routers be required to be the resolver of a local name service or be
capable of being the resolver. The scenario where the ISP provides a very
low-end single-LAN-port router with DSL/DOCSIS/etc modem, and the user is
then expected to supply a more functional router (if the user wants to
enable a home network) is not uncommon. Those low-end router/modems should
never be expected to provide a resolver function for a local name service.
That should be done by the more functional router the user supplies. These
low-end routers were specifically intended to be covered by RFC 7084. The
word “Basic” in the title was very intentional.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Jun 2017 19:29:01 +0000

<BHS> Having an IP address of a resolver to hand out is very different than requiring all CE Routers to be the resolver. I very much disagree that all CE Routers be required to be the resolver of a local name service or be capable of being the resolver. The scenario where the ISP provides a very low-end single-LAN-port router with DSL/DOCSIS/etc modem, and the user is then expected to supply a more functional router (if the user wants to enable a home network) is not uncommon. Those low-end router/modems should never be expected to provide a resolver function for a local name service. That should be done by the more functional router the user supplies. These low-end routers were specifically intended to be covered by RFC 7084. The word "Basic" in the title was very intentional.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Jun 2017 21:37:15 +0000

> Why is that device a router at all, and not a bridge?  

Because by making it a router, help desk calls (quantity and  duration) were reduced significantly. All the stuff for dealing with PPPoE configuration, 6rd configuration, and being able to troubleshoot at an IP layer with a single type of router, and that router is managed, is so-o-o much easier. And with the ability to decrease help desk calls and reduce call time for help desk calls and increase the precision of help desk diagnostics, customer satisfaction, on average, is increased. 

> Does it have a DHCP server?
Yes. In order to be able to put any sort of IP device (single PC or "more functional router") behind it and have everything "just work" with little more than "plug in the Ethernet cable" for instructions, DHCPv4 has to be there. Because all good IPv6-capable CE routers support DHCPv6 IA_PD client requests to the WAN, DHCPv6 for IA_PD is also there. 

Barbara

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Jun 2017 14:39:48 -0700

So - you are suggesting that L-12 be worded similarly to TR-124: "*IF* ... *THEN* ...". Right?

> On Jun 15, 2017, at 7:33 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 17:53:31 -0400

> Yes. In order to be able to put any sort of IP device (single PC or "more functional router") behind it and have everything "just work" with little more than "plug in the Ethernet cable" for instru…

If it's got a DHCP server, it's hard to see why it can't have a DNS proxy.   I wrote a pretty fancy one that adds edns0 options one way and drops them the other (meaning it's remembering outstanding transactions).  It's about 32k of code, compiled, with packet dump code for debugging still in.   I suspect if you took out all the stuff that's not needed for a bare DNS proxy, it would be more like 16k.   I realize that cheap CE routers have limited space, but it's hard to believe that their space is _that_ limited.

That said, if you want to remove this requirement, you need to solve the problem the requirement solves some other way.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Jun 2017 17:56:34 -0400

On Thu, Jun 15, 2017 at 3:29 PM, STARK, BARBARA H <[email-masked]> wrote:
> interface of the CE router is not connected.   This is not to say that there
> is any local name service, but simply that the CE router has to have an IP
> address for the resolver that it can give out at that time, and may not have
> an IP address for an _external_ resolver that can be assumed will be
> functional when the northbound interface reconnects.
>
>
>
> capable of being the resolver.

<no hats>
I agree -- there is a huge amount of DNS breakage caused by CE trying
to be "clever" with DNS. Suggesting that vendors SHOULD implement some
sort of DNS thingie that they a: don't really want to and b: have
little skill in is likely to end in yet more pain.
</no hats>

I'd really suggest that the DNSOP WG be consulted on this particular
point -- I think that they will have some useful input.

W

> The scenario where the ISP provides a very

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 18:28:22 -0400

> little skill in is likely to end in yet more pain.

Warren, that's all very well and good, but it's important to understand _why_ this is a requirement, and not just say "oh, this is a bad idea, let's get rid of it."

It's definitely true that badly-implemented proxies are a problem.   So if the problem the proxies are meant to be solved can be solved in some easier way, it's a great idea to do that.   But what is that easier way?   Alternatively, perhaps it's okay if, when my internet connection comes up, I don't necessarily have actually connectivity for some period of time.   That's definitely easier to implement.   We can even jigger the amount of time by, for example, requiring that when the upstream resolvers' IP addresses are not known, we give out short leases, or require that when the connection comes back, a new RA be sent immediately (depending on whether we're talking IPv4 or IPv6).

I don't think that bringing this to DNSOP actually tells us anything.   The problem of bad DNS proxies is already well-understood in the DNSOP working group, and indeed there's an excellent RFC that explains how to make good (or less bad, depending on your prejudices) proxies.   This is really a host configuration problem, not a DNS problem.   So what is the value in bringing that screaming horde of lunatics^H^H^H^H^H^H^H^H^H^H^Hwise and knowledgable bunch of IETF greybeards into this conversation?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 18:33:23 -0400

On Jun 15, 2017, at 6:26 PM, STARK, BARBARA H <[email-masked]> wrote:
> <bhs> It’s not just about limited space. It’s about needing to support the code in documentation, help desk training, fully test the code, etc. And it’s about a complete lack of customer demand for this functionality in these devices.

Customers don't want their DNS to work if they power on their home router before they power on their cheap CE router that it's plugged into?
 
> <bhs> Hmm. I appreciate your goal of wanting the home network to have a name server. I even think it’s a really good idea for there to be a name server in the home network. I just think a 7074-bis is the wrong medium. It’s not something that’s needed for basic IPv6 connectivity. Perhaps homenet could create a homenet router profile for more functional homenet routers.

I am _not talking about_ homenet naming here.   The reason that CE routers have DNS Proxies is that when the uplink isn't available and the end-user device asks a question, the CE router has to be able to give it an answer that will work once the uplink _is_ present.   Or, the network has to not work until the uplink is present.   Either way, this violates the principle of least surprise for the end user and generates support desk calls, and that's why so many CE routers _do_ have DNS proxies.

If there's a way around this for CE routers you send out to end users, that's great, but you haven't explained what it is.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Jun 2017 22:13:08 +0000

> So - you are suggesting that L-12 be worded similarly to TR-124: "*IF* ...

Yes. 
But...
I phrased it obtusely in case others had different goals in mind. I wasn't sure whether the goal was to recommend implementing a forwarding proxy, or recommending that a forwarding proxy be implemented according to RFC 5625.
Per Ted's response, it appears the goal was to recommend implementing a forwarding proxy to support a name server. My proposed words wouldn't address that.
Barbara

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Jun 2017 10:02:00 +1000

DNS proxies are a cop out by router manufactures.  Routers need
full blown DNS VALIDATING RECURSIVE SERVERS which also are authoritative
for the local zones of the home as well as for locally served dns
zones [1].

If you do to do a proxy there SHOULD be seperate addresses advertised
for each upstream server so that the properties of the upstream
servers are not mixed and so that extensions like DNS COOKIE (RFC
7873) work.  If the proxy talks to multiple upstream servers that
support DNS COOKIE the unnecessary BADCOOKIE due to the proxy mixing
transaction streams will result in unnecessary TCP fallback.

   If the reply to a retried request with a fresh Server Cookie is
   BADCOOKIE, the client SHOULD retry using TCP as the transport, since
   the server will likely process the request normally based on the
   security provided by TCP (see Section 5.2.3).

Mark

[1] https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml.

In message <[email-masked]>, "STARK, BARBARA H" writes:
> I phrased it obtusely in case others had different goals in mind. I wasn't sure whether the goal was to recommend implem
> enting a forwarding proxy, or recommending that a forwarding proxy be implemented according to RFC 5625.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Hooton <[email-masked]>
Date: Fri, 16 Jun 2017 00:44:26 +0000

On 16/6/17, 10:02 am, "v6ops on behalf of Mark Andrews" <[email-masked] on behalf of [email-masked]> wrote:
    DNS proxies are a cop out by router manufactures.  Routers need
    full blown DNS VALIDATING RECURSIVE SERVERS which also are authoritative
    for the local zones of the home as well as for locally served dns
    zones [1].
    
Mark this is completely crazy and if we were to do it the world would end. How many CPE’s have you ever seen that en-masse run current, secure and patched versions of the daemons they use? If the standard becomes every CPE running a full blown DNS resolver, I predict it will take ~6 weeks before we see the first in a long and agonising list of DNS based denial of services and mass CPE compromises. Further to this it will take approximately 10 years before the problem is resolved by the CPE in question failing/being taken out of service.

As an operator, I would be far more comfortable with the CPE being as light as humanly possible with as few running processes as possible using a mechanism that refers all subscriber requests on my network to my centralised, secure and properly maintained resolver/ntp/whatever infrastructure. Instead of making things more complicated or expecting that upstream servers support something special, I would suggest that the user get what they should when a service isn’t working – a failure with a short TTL. Once the link comes up their service should start working. 

Having a full blown resolver on the CPE isn’t going to give the user a different outcome in a link down situation – the lookup is going to fail regardless so if you want DNS proxies gone why not get rid of DNS resolution on the CPE all together?

Short TTL leases aren’t a terrible way of doing this, you would just need to be careful that it doesn’t spiral into a denial of service on the CPE so lease times would need to back off incrementally after say 15 minutes.

Kind Regards,

David Hooton
Founder | Ordnance
Cloud Scale, Carrier Grade
P: +61415850000 T: @dave_hooton W: ordnance.co

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Jun 2017 22:26:47 +0000

<bhs> It's not just about limited space. It's about needing to support the code in documentation, help desk training, fully test the code, etc. And it's about a complete lack of customer demand for this functionality in these devices.

<bhs> Hmm. I appreciate your goal of wanting the home network to have a name server. I even think it's a really good idea for there to be a name server in the home network. I just think a 7074-bis is the wrong medium. It's not something that's needed for basic IPv6 connectivity. Perhaps homenet could create a homenet router profile for more functional homenet routers.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 21:27:19 -0400

> Per Ted's response, it appears the goal was to recommend implementing a forwarding proxy to support a name server. My proposed words wouldn't address that.

As has been pointed out to me off-list, one way to solve this problem is to simply eliminate any mention of DHCPv6 on the home LAN.   If the only way to get a DNS configuration is RDNSS, then the need for the proxy goes away.

Unfortunately, the problem remains if the device supports any of the IPv4 transition mechanism that provide IPv4 on the LAN.   A good reason to just use NAT64, but of course I'm sure that's a can of worms nobody wants to open. :)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Jun 2017 11:48:15 +1000

In message <[email-masked].
outlook.com>, David Hooton writes:
> On 16/6/17, 10:02 am, "v6ops on behalf of Mark Andrews"
> <[email-masked] on behalf of [email-masked]> wrote:
> Mark this is completely crazy and if we were to do it the world would
> end. How many CPE's have you ever seen that en-masse run current, secure
> and patched versions of the daemons they use? If the standard becomes
> every CPE running a full blown DNS resolver, I predict it will take ~6
> weeks before we see the first in a long and agonising list of DNS based
> denial of services and mass CPE compromises. Further to this it will take
> approximately 10 years before the problem is resolved by the CPE in
> question failing/being taken out of service.

All I see here is FUD.  DNS servers are not like you portray them
to be and yes I am acutely aware of how many CVE notices we (ISC)
have issued and what they are for [1].  I'm also aware that they
are almost always for the server choosing to shut itself down rather
than continuing to run in a known bad state.  I also know that
running the nameserver from launchd or as a Windows service with
restart enabled mitigates the issue.  ISC however can't assume that
that is the case so we issue CVE notices.

[1] https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html

> As an operator, I would be far more comfortable with the CPE being as
> light as humanly possible with as few running processes as possible using
> a mechanism that refers all subscriber requests on my network to my
> centralised, secure and properly maintained resolver/ntp/whatever
> infrastructure. Instead of making things more complicated or expecting
> that upstream servers support something special, I would suggest that the
> user get what they should when a service isn't working, a failure with a
> short TTL. Once the link comes up their service should start working.

So basically stuff the home user when the link is down rather than keep
what is reachable working.

> Having a full blown resolver on the CPE isn't going to give the user a
> different outcome in a link down situation , the lookup is going to fail
> regardless so if you want DNS proxies gone why not get rid of DNS
> resolution on the CPE all together?

So you don't think internal services should continue to work when
the link is down.  That customer privacy shouldn't be preserved.
DNS proxies leak like a sieve when it comes to customer privacy.

> Short TTL leases aren't a terrible way of doing this, you would just need
> to be careful that it doesn't spiral into a denial of service on the CPE
> so lease times would need to back off incrementally after say 15 minutes.
>
> Kind Regards,
>
> David Hooton
> Founder | Ordnance

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Jun 2017 22:09:25 -0400

> DNS proxies leak like a sieve when it comes to customer privacy.

Mark, this is the IPv6 router requirements document, not the Homenet router requirements document. Even in the latter case, getting a full DNS server into the router is a bit of a sticky wicket, but it can't be required in 7084-bis, because that's not the target use case.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Jun 2017 13:15:43 +1000

In message <[email-masked]>, Ted Lemon writes:
> > Per Ted's response, it appears the goal was to recommend implementing a
> > forwarding proxy to support a name server. My proposed words wouldn't
> > address that.
>
> As has been pointed out to me off-list, one way to solve this problem is
> to simply eliminate any mention of DHCPv6 on the home LAN.   If the only
> way to get a DNS configuration is RDNSS, then the need for the proxy goes
> away.

How the DNS recursive service is implemented (local recursive,
proxy, remote recursive) is independent of the mechanism to discover
it (DHCPv6, RDNSS).

> Unfortunately, the problem remains if the device supports any of the IPv4
> transition mechanism that provide IPv4 on the LAN.   A good reason to
> just use NAT64, but of course I'm sure that's a can of worms nobody wants
> to open. :)

---

From: David Hooton <[email-masked]>
Date: Fri, 16 Jun 2017 06:58:38 +0000

All I see here is FUD.  DNS servers are not like you portray them
    to be and yes I am acutely aware of how many CVE notices we (ISC)
    have issued and what they are for [1].  

I used drama to communicate a point and I apologise if it made the message less clear. My point wasn’t that the guys writing DNS daemons don’t know what they are doing because we all know you guys are excellent at what you do. 

My point was - why would you want, by default to install code that can, will and absolutely should require updating more often than once every 10 years onto some of most poorly maintained and patched infrastructure on the internet? There are far better maintained places for this kind of network function to exist that ARE well maintained, often automatically by OS and application vendors. 

    
Yes 100% absolutely when the device is configured in its default state. 

The abstract of the RFC we are discussing says that it is specifically talking about: “the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it”. To me this means provide the most simple possible service that when connected to a working internet connection allocates client hosts a routable IPv6 address(es) and advertises whatever other services are required for the host to configure itself in order to make the address if has been allocated useful, in this case DNS.

If the vendor chooses to offer a full blown locally installed resolver as a configurable option and the user/service provider chooses to activate it there should be nothing preventing them from doing so. This doesn’t mean that full blown resolvers should be an RFC defined default because it is not required for the basic connection to work, it is a nice to have.

There are plenty of application/OS level options available for local name resolution that don’t require the CPE to be the local network resolver or even to be online. DNS proxies only leak what the applications using them request, networks are meant to deliver packets as efficiently as possible to their destinations not fix/prevent errors further up the stack.

This problem might be resolved by network functions that sit on the CPE, but are definitely don’t fall within basic provisioning of an IPv6 CE or the hosts attached to it.

Kind Regards,

David Hooton
Founder | Ordnance

---

From: Erik Kline <[email-masked]>
Date: Fri, 16 Jun 2017 16:24:00 +0900

> proxy, remote recursive) is independent of the mechanism to discover

Except in so much as it's entangled with which nameserver IP address the
CPE hands out if it does run a proxy.

If the CPE is announcing a non-stable DNS server IP (i.e. one formed from
the address space PD'd to it and assuming that prefix can change in future)
it will want to be able to deprecate that nameserver and replace it with a
new one.  Only one of these two protocols supports doing this nicely.

---

From: <[email-masked]>
Date: Fri, 16 Jun 2017 08:54:35 +0000

Hi Barbara, 

I would agree with your comment if the requirement was a MUST, but given this is a SHOULD + the behavior is widely deployed + a provider may decide to provision DNS servers with IPv6 addresses only while internal requests may be placed over IPv4 (think about DS-Lite, MAP & Co), I do support the current wording in the draft. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de STARK, BARBARA H
> Envoyé : jeudi 15 juin 2017 16:33
> À : [email-masked]
> Objet : [v6ops] 7084-bis DNS proxy requirement
> 
> There are many CE routers that pass to LAN devices the address of WAN-
> based DNS servers (of ISP or Google, etc.) and do not implement a DNS
> server as a forwarding proxy. This "SHOULD" requirement in the context of
> a CE Router that does not implement a forwarding proxy is meaningless, and
> not implementing a forwarding proxy is very valid and does not need to be
> discouraged. On the other hand, if a forwarding proxy is implemented,
> doing so according to RFC 5625 needs to be required. Forwarding proxies
> that aren't compliant with RFC 5625 have no business being deployed to
> mass market consumers.
> 
> "If the RG's DNS server is implemented as a forwarding proxy, it MUST be
> done according to the recommendations in RFC 5625."
> 
> Barbara
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Jun 2017 12:51:50 +0000

> I would agree with your comment if the requirement was a MUST, but given
> this is a SHOULD + the behavior is widely deployed + a provider may decide
> to provision DNS servers with IPv6 addresses only while internal requests
> may be placed over IPv4 (think about DS-Lite, MAP & Co), I do support the
> current wording in the draft.

The use case you describe is not necessary to support basic IPv6 connectivity, and does not provide a significantly better user experience in the context of IPv6 connectivity. Many IPv6-capable CE Routers are deployed and working very well today without this. 

Requirements in RFC 7084 should be restricted to those that are absolutely necessary (MUST) or very highly desirable because they will provide a significantly better user experience (SHOULD) in the context of IPv6 connectivity.

There are many widely deployed not-necessary-for-IPv6 features in CE routers that RFC 7084 is properly silent on.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Fri, 16 Jun 2017 11:05:39 -0700

On Jun 16, 2017, at 05:51, STARK, BARBARA H <[email-masked]> wrote:
> 
> The use case you describe is not necessary to support basic IPv6 connectivity, and does not provide a significantly better user experience in the context of IPv6 connectivity.

Providing hosts on home LANs with a) native IPv6 connectivity using provider delegated address space, which is subject to change without prior approval by the subscriber, and b) automatic configuration of DNS server IPv6 addresses, can be done with a decent user experience using RDNSS, but not for hosts that only implement DHCPv6, which last we checked is a significant fraction of the installed base under support. For them, using a DNS proxy absolutely provides a better user experience, although I do recognize the desire to downplay the significance of the improvement.

I suppose it’s not actually important to expand the requirements of what constitutes “basic IPv6 connectivity” to include a decent user experience when providers change delegated prefixes. After all, in many contexts, a decent user experience is a luxury class of service sold at premium prices. Maybe it would make a lot of sense to write two RFCs: one for the CE routers sold to the peasants, and another for the CE routers sold to people whose user experiences are significant.

--james woodyatt <[email-masked] <mailto:[email-masked]>>