Internet-Draft | Analysis of DNS Forwarder Scenario | June 2021 |
Stark & Box | Expires 17 December 2021 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/.¶
Source for this draft and an issue tracker can be found at https://github.com/bhstark2/dns-forwarder-analysis.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 December 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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:¶
Becoming a WG draft is not a goal of this draft. There is and will be no request for adoption by any WG.¶
While DNS forwarders / proxies may exist in environments other than home networks (e.g., hotspots, small businesses), this draft does not attempt to examine those usages. This draft is focused on home networks.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Having a DNS forwarder in the CE router that is advertised to the LAN using DHCP and RDNSS options is a common deployment model for many ISPs and is also the default in many retail consumer routers (e.g., Netgear).¶
[I-D.ietf-add-requirements] contains the following text related to this use case:¶
"Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g. [RFC1918], link-local or unique local addresses. To support the discovery of encrypted DNS in these environments, a means is needed for the discovery process to work from a locally-addressed Do53 resolver to an encrypted DNS resolver that is accessible either at the same (local) address, or at a different global address. Both options need to be supported."¶
"R4.1 If the local network resolver is a forwarder that does not offer encrypted DNS service, an upstream encrypted resolver SHOULD be retrievable via queries sent to that forwarder."¶
"R4.2 Achieving requirement 4.1 SHOULD NOT require any changes to DNS forwarders hosted on non-upgradable legacy network devices."¶
In the context of a home network, there are several reasons why this deployment model is used. Some reasons are:¶
The following sections will analyze what behavior a user is expected to see when certain conditions exist. In all cases, it's assumed the CE router is advertising itself as the Do53 server (using DHCP and/or RA). The clients and OSs that are of interest in these scenarios are using whatever Do53 server is advertised to them by DHCP/RA. There may be clients and devices that use other Do53 servers; those are out of scope of this analysis. Analyzing the behavior of clients that do not support either DoH or DoT, or do not support any mechanism to discover encrypted servers are also out of scope.¶
Assumptions common to all scenarios are:¶
Assumptions:¶
Expected behaviors:¶
The end result is that no Encrypted Resolver will be used by an OS or app that uses DDR or DNR to discover an Encrypted Resolver, unless the OS or app subsequently uses some non-standard mechanism to select an Encrypted Resolver. Note that this suggests that the DDR and DNR proposals in their current form do not satisfy the requirement "R4.2 Achieving requirement 4.1 SHOULD NOT require any changes to DNS forwarders hosted on non-upgradable legacy network devices."¶
Also note that non-upgraded legacy routers will not satisfy the [I-D.ietf-add-ddr] requirement that a "DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream." If the CE router were updated to not forward queries for "resolver.arpa" upstream, the end result would not change. Since this scenario provides the same end result, it isn't broken out separately.¶
Assumptions:¶
Expected behaviors:¶
Additional results:¶
Assumptions:¶
dns://resolver.arpa
; SVCB record points to the CE router with a self-signed certificate¶
Note that the effort do do these upgrades is considered to be rather large.¶
Expected behaviors:¶
Since Scenario 3 is considered a large effort and the resulting behavior is unpredictable, it is unlikely to be pursued.¶
Since Scenario 2 will break some of the functionality that a significant number of home network owners have purposefully enabled (e.g., router-based DNS-based parental controls), will break existing captive portal implementations used to simplify setup of broadband connections, and may break local name resolution (?) it is unlikely to be pursued.¶
This leaves Scenario 1 (do nothing in routers that provide DNS forwarder).¶
Are these the results we want to achieve with Encrypted Resolver discovery mechanisms?¶
Breaking the security mechanisms that many users currently have enabled in their home network routers (e.g., DNS filtering) will worsen the security of those users. While these mehanisms are not perfect, and can easily be bypassed by client applications that run DoH, this does not make them completely useless.¶
This document has no IANA actions.¶
Thanks to ...¶