Subject: [Add] draft-stark-add-dns-forwarder-analysis

From: Chris Box <[email-masked]>
Date: Wed, 16 Jun 2021 18:29:10 +0100

All,

As you know the WG's recent progress has been mainly on DDR and DNR.
Barbara has spent some time considering what these drafts would mean for
typical residential deployments. The results can be found in the new I-D
draft-stark-add-dns-forwarder-analysis-00
<https://datatracker.ietf.org/doc/draft-stark-add-dns-forwarder-analysis/>.

   This draft analyzes the behaviors that residential end users and home
   network owners (e.g., parents of young children) might experience
   when operating systems and clients support [I-D.ietf-add-ddr] and/or
   [I-D.ietf-add-dnr] for discovery of encrypted DNS services and the CE
   router of the home network offers itself as the Do53 resolver.  This
   use case is explicitly mentioned in [I-D.ietf-add-requirements]
   Section 3.2 and has several requirements related to it.  This draft
   has two goals: determine if the analysis it provides is accurate and,
   if it is accurate, determine if the behavior is acceptable to the WG
   or if there should be changes to either of the discovery mechanisms.

The main content can be found in these sections:

   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Scenario Analysis . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Scenario 1: No changes to CE router . . . . . . . . . . .   4
     4.2.  Scenario 2: CE router updated to provide DNR in DHCP/
           RA  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Scenario 3: CE router updated to support opportunistic
           encryption to its DNS forwarder . . . . . . . . . . . . .   6
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Questions for the WG  . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7

We *think* the conclusions are valid for both ddr-01, and ddr-01 with PR#11.

But the purpose of writing this draft is to get your opinion. Are we wrong?
If so in which way?

Or if we are not wrong, the final question is to ask you if you are happy
with that end result.

Please have a look and let us know.
Chris

---

From: tirumal reddy <[email-masked]>
Date: Fri, 18 Jun 2021 16:16:27 +0530

Hi Chris,

Other scenarios are also possible like the one discussed in
https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00
to host

a DoH/DoT forwarder on the home router but with a domain-validated
public certificate for authenticated discovery of Encrypted DNS
forwarder.

I don't get the following points in the draft:

Additional results:

* Local name resolution is broken?
Comment> Why is local name resolution broken for domains reserved for
special purposes (like ".home.arpa" or ".local") and private domains
can be resolved using the technique proposed in
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04
?

* Legacy captive portal is now broken?

Comment> What is the need to use captive portals in home networks and
why would the legacy captive portal technique break (my understanding
is OS would continue to use Do53 to detect captive portal) ?

Comment> Assuming captive portals are required in home networks, why
https://datatracker.ietf.org/doc/html/rfc8910 can't be used to allow
the endpoint to know it is behind the captive portal ?

Cheers,

-Tiru

On Wed, 16 Jun 2021 at 22:59, Chris Box <[email-masked]> wrote:

> But the purpose of writing this draft is to get your opinion. Are we
> wrong? If so in which way?
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 18 Jun 2021 13:52:27 +0000

Hi Tiru,
Thanks for your excellent questions. In-line with <bhs>.
Barbara

From: Add <[email-masked]> On Behalf Of tirumal reddy
Sent: Friday, June 18, 2021 5:46 AM
To: Chris Box <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] draft-stark-add-dns-forwarder-analysis

Hi Chris,

Other scenarios are also possible like the one discussed in https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-yDXVHSag$> to host

a DoH/DoT forwarder on the home router but with a domain-validated public certificate for authenticated discovery of Encrypted DNS forwarder.

Additional results:

* Local name resolution is broken?
Comment> Why is local name resolution broken for domains reserved for special purposes (like ".home.arpa" or ".local") and private domains can be resolved using the technique proposed in https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-z2-kLD3Q$> ?

<bhs> Various ISPs and retail router vendors have registered domain names that their CE router will advertise to the LAN and that the CE router can resolve. For example, AT&T's CE router DNS proxy will resolve queries to "attlocal.net". That domain cannot be resolved by any DNS resolver in the Internet. Other (ISP and retail) routers have similar such local domains. There is also a long-standing desire to somehow come up with a way for end users to easily set up their own local domain (properly registered, but only accessible locally). While that's not happened yet, we should avoid closing the door on that idea. The ability to have and use local domains should not be restricted to domains served from managed trust environments. The proposed enterprise-split-dns-04 (I see this was posted yesterday and much of the enterprise-only language was removed) would not be useful for domains served by local routers that do not offer encrypted resolution (if I'm reading it right).

Comment> What is the need to use captive portals in home networks and why would the legacy captive portal technique break (my understanding is OS would continue to use Do53 to detect captive portal) ?

Comment> Assuming captive portals are required in home networks, why https://datatracker.ietf.org/doc/html/rfc8910<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8910__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xFWXVq8w$> can't be used to allow the endpoint to know it is behind the captive portal ?

<bhs> Captive portals are used by some ISPs to set up new CE router authentication and authorization for WAN connectivity. When a new CE router is physically connected to a WAN link, the CE router's identity needs to be associated with this customer (whose link it is connected to).  The user can be taken to a captive portal where they can provide appropriate credentials to indicate this is their new CE router connected to their link. If the captive portal won't break, that will be good. I don't see it in any specification though that clients MUST still detect captive portals. Is this something we can trust to work universally and consistently across all clients? RFC8910 is one component that can be used as part of a new captive portal architecture (such as RFC8952). More than just support for the DHCP option would be needed (e.g., APIs from RFC8908 supported in the CE router and external system changes to make everything work). Supporting changes in a legacy router will require firmware upgrades. Understanding the complexity and risks of the firmware upgrades together with changes to other systems (where complexity + risks => cost) is an assessment that has to be done by these ISPs.

Cheers,

-Tiru

On Wed, 16 Jun 2021 at 22:59, Chris Box <[email-masked]<mailto:[email-masked]>> wrote:
All,

As you know the WG's recent progress has been mainly on DDR and DNR. Barbara has spent some time considering what these drafts would mean for typical residential deployments. The results can be found in the new I-D draft-stark-add-dns-forwarder-analysis-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-stark-add-dns-forwarder-analysis/__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xixxfdCg$>.

   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
We think the conclusions are valid for both ddr-01, and ddr-01 with PR#11.

But the purpose of writing this draft is to get your opinion. Are we wrong? If so in which way?

Or if we are not wrong, the final question is to ask you if you are happy with that end result.

Please have a look and let us know.
Chris
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xv1rOd0w$>

---

From: tirumal reddy <[email-masked]>
Date: Mon, 21 Jun 2021 12:42:22 +0530

Hi Barbara,

Please see inline

On Fri, 18 Jun 2021 at 19:23, STARK, BARBARA H <[email-masked]> wrote:

> *From:* Add <[email-masked]> *On Behalf Of *tirumal reddy
> *Sent:* Friday, June 18, 2021 5:46 AM
> *To:* Chris Box <[email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>
> *Subject:* Re: [Add] draft-stark-add-dns-forwarder-analysis
>
>
>
> Hi Chris,
>
> Other scenarios are also possible like the one discussed in https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-yDXVHSag$> to host
>
> Comment> Why is local name resolution broken for domains reserved for special purposes (like ".home.arpa" or ".local") and private domains can be resolved using the technique proposed in https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-z2-kLD3Q$> ?
>
>
>
> <bhs> Various ISPs and retail router vendors have registered domain names that their CE router will advertise to the LAN and that the CE router can resolve. For example, AT&T’s CE router DNS proxy will resolve queries to “attlocal.net”. That domain cannot be resolved by any DNS resolver in the Internet. Other (ISP and retail) routers have similar such local domains. There is also a long-standing desire to somehow come up with a way for end users to easily set up their own local domain (properly registered, but only accessible locally). While that’s not happened yet, we should avoid closing the door on that idea. The ability to have and use local domains should not be restricted to domains served from managed trust environments. The proposed enterprise-split-dns-04 (I see this was posted yesterday and much of the enterprise-only language was removed) would not be useful for domains served by local routers that do not offer encrypted resolution (if I’m reading it right).
>
>
Split-horizon DNS configuration is not specific to Enterprise networks but
a network-designated encrypted resolver is mandated to prove authority over
the domains (see
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04#section-4.1
for
more details).  Otherwise, an attacker can claim authority of global
domains and adversely impact the privacy of the end-user.

> Comment> Assuming captive portals are required in home networks, why https://datatracker.ietf.org/doc/html/rfc8910 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8910__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xFWXVq8w$> can't be used to allow the endpoint to know it is behind the captive portal ?
>
>
>
> <bhs> Captive portals are used by some ISPs to set up new CE router authentication and authorization for WAN connectivity. When a new CE router is physically connected to a WAN link, the CE router’s identity needs to be associated with this customer (whose link it is connected to).  The user can be taken to a captive portal where they can provide appropriate credentials to indicate this is their new CE router connected to their link. If the captive portal won’t break, that will be good. I don’t see it in any specification though that clients MUST still detect captive portals. Is this something we can trust to work universally and consistently across all clients? RFC8910 is one component that can be used as part of a new captive portal architecture (such as RFC8952). More than just support for the DHCP option would be needed (e.g., APIs from RFC8908 supported in the CE router and external system changes to make everything work). Supporting changes in a legacy router will require firmware upgrades. Understanding the complexity and risks of the firmware upgrades together with changes to other systems (where complexity + risks => cost) is an assessment that has to be done by these ISPs.
>
>
>
> Yes, the work in capport WG is useful for new routers to support captive
portals but not for legacy and un-upgradable routers.

-Tiru

Cheers,
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-stark-add-dns-forwarder-analysis/__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xixxfdCg$>
> .
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!BhdT!2tj-jowO9HELXbWugLX2AP2g8TVLR-9AaSm55ffh-DZ47F2qLj7IR-xv1rOd0w$>
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 21 Jun 2021 14:59:50 +0000

Hi Tiru,
Inline with <bhs2>. Thx, - Barbara

Hi Barbara,

Please see inline

On Fri, 18 Jun 2021 at 19:23, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tiru,
Thanks for your excellent questions. In-line with <bhs>.
Barbara

From: Add <[email-masked]<mailto:[email-masked]>> On Behalf Of tirumal reddy
Sent: Friday, June 18, 2021 5:46 AM
To: Chris Box <[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] draft-stark-add-dns-forwarder-analysis

Hi Chris,

Additional results:

<bhs> Various ISPs and retail router vendors have registered domain names that their CE router will advertise to the LAN and that the CE router can resolve. For example, AT&T's CE router DNS proxy will resolve queries to "attlocal.net<https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!3Fth2H0OPyGg8Jeu6NTDsDlC4ra3fRH4QRiwZD9WT8_-mzalrQLwWghIElXoYQ$>". That domain cannot be resolved by any DNS resolver in the Internet. Other (ISP and retail) routers have similar such local domains. There is also a long-standing desire to somehow come up with a way for end users to easily set up their own local domain (properly registered, but only accessible locally). While that's not happened yet, we should avoid closing the door on that idea. The ability to have and use local domains should not be restricted to domains served from managed trust environments. The proposed enterprise-split-dns-04 (I see this was posted yesterday and much of the enterprise-only language was removed) would not be useful for domains served by local routers that do not offer encrypted resolution (if I'm reading it right).

Split-horizon DNS configuration is not specific to Enterprise networks but a network-designated encrypted resolver is mandated to prove authority over the domains (see https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04#section-4.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04*section-4.1__;Iw!!BhdT!3Fth2H0OPyGg8Jeu6NTDsDlC4ra3fRH4QRiwZD9WT8_-mzalrQLwWggqaO6DeA$> for more details).  Otherwise, an attacker can claim authority of global domains and adversely impact the privacy of the end-user.

<bhs2> 2 points come to mind: (1) Since the current discovery drafts seem prepared to support opportunistic discovery that would allow the local resolver to also be the encrypted resolver, and the local domain is included in a DHCP option (DHCPv4 option 15 Domain Name) sent by this very same device that is both DHCP server and local resolver, I'm struggling to understand why this device can be trusted to be an encrypted resolver and trusted to provide other DHCP options but cannot be trusted to resolve domains it announces in DHCP (which it will resolve anyway if it is the encrypted resolver). (2) Since global resolvers will provide a "Can't find <local domain>: No answer" reply when queried for these local domains (like attlocal.net) I'm really not understanding why clients can't decide to trust that the domain is locally served based both on the local DHCP option being provided AND the encrypted server saying it can't find the domain.

Yes, the work in capport WG is useful for new routers to support captive portals but not for legacy and un-upgradable routers.

-Tiru

Cheers,

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Wed, 23 Jun 2021 11:22:33 +0530

Hi Barbara,

Please see inline [TR]

On Mon, 21 Jun 2021 at 20:30, STARK, BARBARA H <[email-masked]> wrote:

> <bhs> Various ISPs and retail router vendors have registered domain names that their CE router will advertise to the LAN and that the CE router can resolve. For example, AT&T’s CE router DNS proxy will resolve queries to “attlocal.net <https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!3Fth2H0OPyGg8Jeu6NTDsDlC4ra3fRH4QRiwZD9WT8_-mzalrQLwWghIElXoYQ$>”. That domain cannot be resolved by any DNS resolver in the Internet. Other (ISP and retail) routers have similar such local domains. There is also a long-standing desire to somehow come up with a way for end users to easily set up their own local domain (properly registered, but only accessible locally). While that’s not happened yet, we should avoid closing the door on that idea. The ability to have and use local domains should not be restricted to domains served from managed trust environments. The proposed enterprise-split-dns-04 (I see this was posted yesterday and much of the enterprise-only language was removed) would not be useful for domains served by local routers that do not offer encrypted resolution (if I’m reading it right).
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-04*section-4.1__;Iw!!BhdT!3Fth2H0OPyGg8Jeu6NTDsDlC4ra3fRH4QRiwZD9WT8_-mzalrQLwWggqaO6DeA$> for
> <bhs2> 2 points come to mind: (1) Since the current discovery drafts seem
> prepared to support opportunistic discovery that would allow the local
> resolver to also be the encrypted resolver, and the local domain is
> included in a DHCP option (DHCPv4 option 15 Domain Name) sent by this very
> same device that is both DHCP server and local resolver, I’m struggling to
> understand why this device can be trusted to be an encrypted resolver and
> trusted to provide other DHCP options but cannot be trusted to resolve
> domains it announces in DHCP (which it will resolve anyway if it is the
> encrypted resolver).
>

The client needs to learn the DNS zones used for split-horizon DNS only
when it is configured not to use the network-designated resolver to resolve
global domains. For example, if a client is configured to use a public
resolver to resolve global domains and the network-designated resolver to
resolve the split-horizon DNS domains, it needs proof that the
network-designated resolvers are authoritative over the domains in DnsZones.

> (2) Since global resolvers will provide a “Can’t find <local domain>: No
> answer” reply when queried for these local domains (like attlocal.net)
> I’m really not understanding why clients can’t decide to trust that the
> domain is locally served based both on the local DHCP option being provided
> AND the encrypted server saying it can’t find the domain.
>

The proof is required in scenarios where the network runs a different
version of its global domains on its internal network.

Cheers,
-Tiru

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 23 Jun 2021 21:58:18 +0000

In-line with <bhs3>. 😊
Barbara

Hi Barbara,

Please see inline [TR]

On Mon, 21 Jun 2021 at 20:30, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tiru,
Inline with <bhs2>. Thx, - Barbara

Hi Barbara,

Please see inline

Hi Chris,

Additional results:

<bhs> Various ISPs and retail router vendors have registered domain names that their CE router will advertise to the LAN and that the CE router can resolve. For example, AT&T’s CE router DNS proxy will resolve queries to “attlocal.net<https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!3Fth2H0OPyGg8Jeu6NTDsDlC4ra3fRH4QRiwZD9WT8_-mzalrQLwWghIElXoYQ$>”. That domain cannot be resolved by any DNS resolver in the Internet. Other (ISP and retail) routers have similar such local domains. There is also a long-standing desire to somehow come up with a way for end users to easily set up their own local domain (properly registered, but only accessible locally). While that’s not happened yet, we should avoid closing the door on that idea. The ability to have and use local domains should not be restricted to domains served from managed trust environments. The proposed enterprise-split-dns-04 (I see this was posted yesterday and much of the enterprise-only language was removed) would not be useful for domains served by local routers that do not offer encrypted resolution (if I’m reading it right).

<bhs2> 2 points come to mind: (1) Since the current discovery drafts seem prepared to support opportunistic discovery that would allow the local resolver to also be the encrypted resolver, and the local domain is included in a DHCP option (DHCPv4 option 15 Domain Name) sent by this very same device that is both DHCP server and local resolver, I’m struggling to understand why this device can be trusted to be an encrypted resolver and trusted to provide other DHCP options but cannot be trusted to resolve domains it announces in DHCP (which it will resolve anyway if it is the encrypted resolver).

The client needs to learn the DNS zones used for split-horizon DNS only when it is configured not to use the network-designated resolver to resolve global domains. For example, if a client is configured to use a public resolver to resolve global domains and the network-designated resolver to resolve the split-horizon DNS domains, it needs proof that the network-designated resolvers are authoritative over the domains in DnsZones.

<bhs3> When you say “configured”, do you mean “manually configured”? I know of no auto configuration for this for clients in a home network (which is the topic of my draft). Should I understand this comment as saying you agree that under the current discovery drafts there will be no local domain name resolution in home networks, outside of .local and .home.arpa (because we know we can’t expect manual client configuration for this in home networks)? Should we (the WG) consider that to be the way it will and must be and end users will just have to accept that something they used to have will now no longer work?
(2) Since global resolvers will provide a “Can’t find <local domain>: No answer” reply when queried for these local domains (like attlocal.net<https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!wyoGdzkHzB3mEHaPK1v5TizR8B4VnAW6HqNys6msH45DwWHfHZO-6-DAFAJvKQ$>) I’m really not understanding why clients can’t decide to trust that the domain is locally served based both on the local DHCP option being provided AND the encrypted server saying it can’t find the domain.

The proof is required in scenarios where the network runs a different version of its global domains on its internal network.

Cheers,
-Tiru

-Tiru

Cheers,

-Tiru

---

From: Andrew Campling <[email-masked]>
Date: Wed, 23 Jun 2021 22:24:10 +0000

> <bhs3> When you say “configured”, do you mean “manually configured”? I know of no auto configuration for this for clients in a home network (which is the topic of my draft). Should I understand thi…

I hope that we can all agree that we shouldn’t “consider that to be the way it will and must be and end users will just have to accept that something they used to have will now no longer work”.  Bearing in mind RFC8890, we need to find solutions that improve the end user experience and certainly avoid those that make it worse.  This document should help keep us focused on achieving that.

Andrew

---

From: tirumal reddy <[email-masked]>
Date: Thu, 24 Jun 2021 12:36:46 +0530

On Thu, 24 Jun 2021 at 03:28, STARK, BARBARA H <[email-masked]> wrote:

> <bhs3> When you say “configured”, do you mean “manually configured”?
>

I meant the client may not use the network-provided resolver to resolve
global domains for various reasons. For example (1) VPN is enabled on the
endpoint and network-designated resolver is only used to resolve
the split-horizon DNS domains (2) Applications like browsers use a
pre-configured public resolver after user opt-in (3) User has manually
configured the client to use a public resolver but wants to use the
network-designated resolver to resolve the split-horizon DNS domains

> I know of no auto configuration for this for clients in a home network
> (which is the topic of my draft). Should I understand this comment as
> saying you agree that under the current discovery drafts there will be no
> local domain name resolution in home networks, outside of .local and .
> home.arpa (because we know we can’t expect manual client configuration
> for this in home networks)?
>

No. If the home router can be upgraded to host a DoH forwarder and DNR is
used to discover the local encrypted forwarder, private domains can still
be resolved. If the home router cannot be updated to host a DoH forwarder
and the endpoint discovers the ISP encrypted DNS resolver (using DNR or
DDR), the ISP resolver can still resolve the private domains (as it knows
the private domains on the managed router).

-Tiru

> Should we (the WG) consider that to be the way it will and must be and end
> users will just have to accept that something they used to have will now no
> longer work?  (2) Since global resolvers will provide a “Can’t find
> <local domain>: No answer” reply when queried for these local domains (like
> attlocal.net
> <https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!wyoGdzkHzB3mEHaPK1v5TizR8B4VnAW6HqNys6msH45DwWHfHZO-6-DAFAJvKQ$>)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 25 Jun 2021 02:03:20 +0000

Hi Tiru,
In-line with <bhs4>.
Barbara

From: tirumal reddy <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 24, 2021 2:07 AM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: Chris Box <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] draft-stark-add-dns-forwarder-analysis

On Thu, 24 Jun 2021 at 03:28, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
In-line with <bhs3>. 😊
Barbara

Hi Barbara,

Please see inline [TR]

Hi Barbara,

Please see inline

Hi Chris,

Additional results:

I meant the client may not use the network-provided resolver to resolve global domains for various reasons. For example (1) VPN is enabled on the endpoint and network-designated resolver is only used to resolve the split-horizon DNS domains (2) Applications like browsers use a pre-configured public resolver after user opt-in (3) User has manually configured the client to use a public resolver but wants to use the network-designated resolver to resolve the split-horizon DNS domains

<bhs4> I’m really trying to focus on use of the home network not as a means of connecting to a corporate network, but as a network for the people who live in the home to have a private network of devices that can communicate with each other privately (really privately, and not in a manner that is subject to politically-motivated subpoenas). I don’t use a VPN when I’m doing personal stuff in my home. Most people don’t. More and more browsers are doing opt-out, and not opt-in for DoH. Users don’t manually configure clients > 90% of the time. We need to be designing these solutions with a practical understanding and acceptance of the reality of end user behaviors.

I know of no auto configuration for this for clients in a home network (which is the topic of my draft). Should I understand this comment as saying you agree that under the current discovery drafts there will be no local domain name resolution in home networks, outside of .local and .home.arpa (because we know we can’t expect manual client configuration for this in home networks)?

No. If the home router can be upgraded to host a DoH forwarder and DNR is used to discover the local encrypted forwarder, private domains can still be resolved. If the home router cannot be updated to host a DoH forwarder and the endpoint discovers the ISP encrypted DNS resolver (using DNR or DDR), the ISP resolver can still resolve the private domains (as it knows the private domains on the managed router).

<bhs4> The likelihood of upgrading the home router to host a DoH forwarder is slim. Especially now that operating system and browser vendors are more and more stating they intend to use oblivious DoH and are unlikely to ever honor discovered DoH. It makes the considerable investment in upgrading routers a complete waste of money. And since there is a single private domain used for all of the routers it’s not possible to resolve in the ISP resolver. The vast majority of ISPs don’t provide personalized domains that are resolved to home network addresses. There are also domains like Netgear’s routerlogin.net that will be resolved locally by a Netgear router but will resolve to a Netgear web page if not locally resolved (with instructions for troubleshooting why the local Netgear router didn’t resolve it – Netgear should probably include DoH as yet another reason for failure). So, by purposefully not addressing this issue, the WG is accepting this breakage of a capability home networks used to enjoy. If that is the WG decision, then so be it. But we shouldn’t pretend it isn’t just because there exist massively complex work-arounds that ISPs and router vendors could pour lots of resources into to make it work (maybe – if discovery actually ends up being supported and honored). Pouring resources into these workarounds is not going to happen because there’s insufficient benefit to justify it.

-Tiru

Should we (the WG) consider that to be the way it will and must be and end users will just have to accept that something they used to have will now no longer work?  (2) Since global resolvers will provide a “Can’t find <local domain>: No answer” reply when queried for these local domains (like attlocal.net<https://urldefense.com/v3/__http:/attlocal.net__;!!BhdT!wyoGdzkHzB3mEHaPK1v5TizR8B4VnAW6HqNys6msH45DwWHfHZO-6-DAFAJvKQ$>) I’m really not understanding why clients can’t decide to trust that the domain is locally served based both on the local DHCP option being provided AND the encrypted server saying it can’t find the domain.

Cheers,
-Tiru

-Tiru

Cheers,

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Fri, 25 Jun 2021 15:58:25 +0530

On Fri, 25 Jun 2021 at 07:33, STARK, BARBARA H <[email-masked]> wrote:

> Hi Tiru,
>
> In-line with <bhs4>.
>
> Barbara
>
>
>
> *From:* tirumal reddy <[email-masked]>
> *Sent:* Thursday, June 24, 2021 2:07 AM
> *To:* STARK, BARBARA H <[email-masked]>
> *Cc:* Chris Box <[email-masked]>; ADD Mailing list <[email-masked]
> >
> <bhs4> I’m really trying to focus on use of the home network not as a
> means of connecting to a corporate network, but as a network for the people
> who live in the home to have a private network of devices that can
> communicate with each other privately (really privately, and not in a
> manner that is subject to politically-motivated subpoenas). I don’t use a
> VPN when I’m doing personal stuff in my home. Most people don’t. More and
> more browsers are doing opt-out, and not opt-in for DoH. Users don’t
> manually configure clients > 90% of the time. We need to be designing these
> solutions with a practical understanding and acceptance of the reality of
> end user behaviors.
>

The use of the proposed mechanism is not restricted to home networks, it
can be used in untrusted networks (e.g., coffee shops, airports etc. using
public PSK for WiFi authentication or opportunistic wireless encryption) to
use the network-designated resolver only to resolve split-horizon DNS
domains.

> <bhs4> The likelihood of upgrading the home router to host a DoH
> forwarder is slim. Especially now that operating system and browser vendors
> are more and more stating they intend to use oblivious DoH and are
> unlikely to ever honor discovered DoH. It makes the considerable
> investment in upgrading routers a complete waste of money.
>

Oblivious DoH is only relevant for public DoH servers and not for
network-designated DoH servers either hosted in the home/enterprise
networks or in the ISP (Who would host the oblivious proxy and will be
located outside of the ISP network ?).  .

If the home router cannot be upgraded to supported encrypted DNS forwarder
due to resource constraints, endpoints can still discover the ISP provided
encrypted DNS server using the DNR/DDR discovery mechanisms.

I see active participation in the WG from both OS and browser vendors, and
so far no one has claimed the discovered network-designated encrypted
resolver discovery mechanisms will not be implemented and supported. I
don't think oblivious DoH will be enabled by default.

On a side note, DPRIVE WG has not adopted the Oblivious DoH draft; it will
have to wait for the chartering and progress of OHTTP. Further, the
implications of Oblivious DoH with the work happening in this WG needs to
be discussed.

-Tiru

> And since there is a single private domain used for all of the routers
> it’s not possible to resolve in the ISP resolver. The vast majority of ISPs
> don’t provide personalized domains that are resolved to home network
> addresses. There are also domains like Netgear’s routerlogin.net that
> will be resolved locally by a Netgear router but will resolve to a Netgear
> web page if not locally resolved (with instructions for troubleshooting why
> the local Netgear router didn’t resolve it – Netgear should probably
> include DoH as yet another reason for failure). So, by purposefully not
> addressing this issue, the WG is accepting this breakage of a capability
> home networks used to enjoy. If that is the WG decision, then so be it. But
> we shouldn’t pretend it isn’t just because there exist massively complex
> work-arounds that ISPs and router vendors could pour lots of resources into
> to make it work (maybe – if discovery actually ends up being supported and
> honored). Pouring resources into these workarounds is not going to happen
> because there’s insufficient benefit to justify it.
>
>
>
> -Tiru
>
>
>
> longer work?  (2) Since global resolvers will provide a “Can’t find <local
> domain>: No answer” reply when queried for these local domains (like
> attlocal.net

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 25 Jun 2021 14:29:01 +0000

Hi Tiru,
In-line with <bhs5>.
Barbara

From: tirumal reddy <[email-masked]>
Sent: Friday, June 25, 2021 5:28 AM
To: STARK, BARBARA H <[email-masked]>
Cc: Chris Box <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] draft-stark-add-dns-forwarder-analysis

On Fri, 25 Jun 2021 at 07:33, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tiru,
In-line with <bhs4>.
Barbara

Hi Barbara,

Please see inline [TR]

Hi Barbara,

Please see inline

Hi Chris,

Additional results:

The use of the proposed mechanism is not restricted to home networks, it can be used in untrusted networks (e.g., coffee shops, airports etc. using public PSK for WiFi authentication or opportunistic wireless encryption) to use the network-designated resolver only to resolve split-horizon DNS domains.

<bhs5> I’m confused. I never said there was some mechanism restricted to home networks. I said that the draft Chris Box and I published (see subject line) was limited to assessing the proposed discovery mechanisms in the context of home networks. One of the assessment points is that use of private domains will break because the current drafts provide no explicit allowance for split-horizon of private domains in home networks. Ideally, I’d like to get support for private domains (as used in home networks – i.e., using an unencrypted local resolver) explicitly addressed by this WG. The fact that a proposal exists for enterprise networks is not relevant to the specific problem (home networks) that I’m trying to solve. This doesn’t mean that use cases other than home networks aren’t valid. It simply means that I think the home network use case *is* valid and I’d like to see it specifically discussed and addressed. Yes, All Networks Matter. But that doesn’t mean we should be prohibited from discussing how one particular type of network is impacted. I have no problem with your proposal for ensuring the needs of enterprise networks are properly supported. In fact, I fully support this. But please allow me to also ensure the needs of home networks are also addressed.</bhs5>

<bhs4> The likelihood of upgrading the home router to host a DoH forwarder is slim. Especially now that operating system and browser vendors are more and more stating they intend to use oblivious DoH and are unlikely to ever honor discovered DoH. It makes the considerable investment in upgrading routers a complete waste of money.

Oblivious DoH is only relevant for public DoH servers and not for network-designated DoH servers either hosted in the home/enterprise networks or in the ISP (Who would host the oblivious proxy and will be located outside of the ISP network ?).  .

If the home router cannot be upgraded to supported encrypted DNS forwarder due to resource constraints, endpoints can still discover the ISP provided encrypted DNS server using the DNR/DDR discovery mechanisms.

I see active participation in the WG from both OS and browser vendors, and so far no one has claimed the discovered network-designated encrypted resolver discovery mechanisms will not be implemented and supported. I don't think oblivious DoH will be enabled by default.

On a side note, DPRIVE WG has not adopted the Oblivious DoH draft; it will have to wait for the chartering and progress of OHTTP. Further, the implications of Oblivious DoH with the work happening in this WG needs to be discussed.

<bhs5> Please see https://www.cnet.com/news/no-apples-private-relay-is-not-a-vpn/
Some relevant quotes from this article:
“Cloudflare was a primary partner in Apple's push<https://datatracker.ietf.org/doc/html/draft-pauly-dprive-oblivious-doh-00> to standardize the potentially game-changing element of Private Relay --  its in-browser use of something called Oblivious DNS-over-HTTPS (ODoH)."
“In its developer-focused presentation<https://developer.apple.com/videos/play/wwdc2021/10096>, Apple said Private Relay encryption only covers Safari, the DNS-related traffic on your device, and a small subset of traffic from apps."</bhs5>

-Tiru

And since there is a single private domain used for all of the routers it’s not possible to resolve in the ISP resolver. The vast majority of ISPs don’t provide personalized domains that are resolved to home network addresses. There are also domains like Netgear’s routerlogin.net<https://urldefense.com/v3/__http:/routerlogin.net__;!!BhdT!0BG-KJsNKSIsg6Dmy12FLdCSwOSXA6klgTlG1wkUIlfT-MmqXt0eDlUp0hCt2A$> that will be resolved locally by a Netgear router but will resolve to a Netgear web page if not locally resolved (with instructions for troubleshooting why the local Netgear router didn’t resolve it – Netgear should probably include DoH as yet another reason for failure). So, by purposefully not addressing this issue, the WG is accepting this breakage of a capability home networks used to enjoy. If that is the WG decision, then so be it. But we shouldn’t pretend it isn’t just because there exist massively complex work-arounds that ISPs and router vendors could pour lots of resources into to make it work (maybe – if discovery actually ends up being supported and honored). Pouring resources into these workarounds is not going to happen because there’s insufficient benefit to justify it.

-Tiru

Cheers,
-Tiru

-Tiru

Cheers,

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Wed, 30 Jun 2021 11:49:23 +0530

On Fri, 25 Jun 2021 at 19:59, STARK, BARBARA H <[email-masked]> wrote:

> *Sent:* Friday, June 25, 2021 5:28 AM
> can be used in untrusted networks (e.g., coffee shops, airports etc.
> using public PSK for WiFi authentication or opportunistic wireless
> encryption) to use the network-designated resolver only to resolve
> split-horizon DNS domains.
>
>
>
> <bhs5> I’m confused. I never said there was some mechanism restricted to
> home networks. I said that the draft Chris Box and I published (see subject
> line) was limited to assessing the proposed discovery mechanisms in the
> context of home networks. One of the assessment points is that use of
> private domains will break because the current drafts provide no explicit
> allowance for split-horizon of private domains in home networks. Ideally,
> I’d like to get support for private domains (as used in home networks –
> i.e., using an unencrypted local resolver) explicitly addressed by this WG.
> The fact that a proposal exists for enterprise networks is not relevant to
> the specific problem (home networks) that I’m trying to solve. This doesn’t
> mean that use cases other than home networks aren’t valid. It simply means
> that I think the home network use case **is** valid and I’d like to see
> it specifically discussed and addressed. Yes, All Networks Matter. But that
> doesn’t mean we should be prohibited from discussing how one particular
> type of network is impacted. I have no problem with your proposal for
> ensuring the needs of enterprise networks are properly supported. In fact,
> I fully support this. But please allow me to also ensure the needs of home
> networks are also addressed.</bhs5>
>

Yes, I agree with the same problem in home networks where the CPE cannot be
upgraded to support encrypted DNS servers. The challenge is how to solve
the problem without adversely impacting the end-user security and privacy
especially for split-horizon DNS domains (where the home network runs a
different version of the global domain on its internal network). In case of
private domains, the discovered encrypted resolver will return NXDOMAIN
response and the client can possibly fallback to Do53 to resolve the
private domains..

> <bhs5> Please see
> https://www.cnet.com/news/no-apples-private-relay-is-not-a-vpn/
>
> “Cloudflare was a primary partner in Apple's push
> <https://datatracker.ietf.org/doc/html/draft-pauly-dprive-oblivious-doh-00>
> to standardize the potentially game-changing element of Private Relay --
> its in-browser use of something called Oblivious DNS-over-HTTPS (ODoH)."
>
> “In its developer-focused presentation
> <https://developer.apple.com/videos/play/wwdc2021/10096>, Apple said
> Private Relay encryption only covers Safari, the DNS-related traffic on
> your device, and a small subset of traffic from apps."</bhs5>
>

It is good to start a seperate thread to understand how Oblivious DoH will
be deployed and the implication of Oblivious DoH with the work happening in
ADD WG

-Tiru

> addresses. There are also domains like Netgear’s routerlogin.net
> <https://urldefense.com/v3/__http:/routerlogin.net__;!!BhdT!0BG-KJsNKSIsg6Dmy12FLdCSwOSXA6klgTlG1wkUIlfT-MmqXt0eDlUp0hCt2A$>
> that will be resolved locally by a Netgear router but will resolve to a
> Netgear web page if not locally resolved (with instructions for
> troubleshooting why the local Netgear router didn’t resolve it – Netgear
> should probably include DoH as yet another reason for failure). So, by
> purposefully not addressing this issue, the WG is accepting this breakage
> of a capability home networks used to enjoy. If that is the WG decision,
> then so be it. But we shouldn’t pretend it isn’t just because there exist
> massively complex work-arounds that ISPs and router vendors could pour lots
> of resources into to make it work (maybe – if discovery actually ends up
> being supported and honored). Pouring resources into these workarounds is
> not going to happen because there’s insufficient benefit to justify it.
>
>
>
> -Tiru
>
>
>