Hosting Encrypted DNS Forwarders on CPEs

Status of This Memo

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 8 May 2025.¶

Copyright Notice

Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Customer Premises Equipment (CPEs, also called Home Routers) are a critical component of the home network, and their security is essential to protecting the devices and data that are connected to them. For example, the prpl Foundation [prpl] has developed a number of initiatives to promote home router security and hardening. The prplWrt project [prplwrt] is an initiative in prpl Foundation that aims to improve the security and performance of open-source router firmware, such as OpenWrt [openwrt]. OpenWrt is an open-source operating system that is designed to run on a wide range of routers and embedded devices. It now includes support for containerization technology such as Docker, making it possible to run containerized applications on a home router. Further, DNS providers have optimized the encrypted DNS forwarder to run in a container in home routers.¶

However, upgrading DNS to use encrypted transports (e.g., DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], and DNS over QUIC (DoQ) [RFC9250]) introduces deployment complications as to how to sustain current offerings with local services.¶

This document describes the problem encountered to host encrypted DNS resolvers in managed CPEs. It also identifies a set of requirements and discusses to what extent existing solutions can (or can't) meet these requirements.¶

2. Scope

This document describes the current state of the art for deploying encrypted DNS on customer premise equipment. New mechanisms should be described in separate documents.¶

The document does not focus on generic considerations related to deploying DNS proxies. The reader may refer to [RFC5625] for such matters.¶

The mechanism for the client to authenticate the local encrypted DNS server is out of scope of this draft (see [I-D.rbw-home-servers]). This draft details how such an authenticated local encrypted DNS server would be used.¶

3. Conventions and Definitions

This document makes use of the terms defined in [RFC9499].¶

The following additional terms are used:¶

DHCP:

refers to both DHCPv4 and DHCPv6.¶

Do53:

refers to unencrypted DNS.¶

DNR:

refers to the Discovery of Network-designated Resolvers procedure defined in [RFC9463].¶

DDR:

refers to the Discovery of Designated Resolvers procedure defined in [RFC9462].¶

Encrypted DNS:

refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoH [RFC8484], DoT [RFC7858], and DoQ [RFC9250].¶

Managed CPE:

refers to a CPE that is managed by an ISP or CPE vendor or Security Service Provider.¶

4. Proxied DNS In Local Networks

Figure 1 shows various network setups where the CPE embeds a caching encrypted DNS forwarder.¶

For all the cases shown in Figure 1, the CPE advertises itself as the default DNS server to the hosts it serves in the LAN. The CPE relies upon DHCP or RA to advertise itself to internal hosts as the default encrypted DNS forwarder using DNR. When receiving a DNS request that a CPE cannot handle locally, the CPE forwards the request to an upstream encrypted DNS. The upstream encrypted DNS can be hosted by the ISP or provided by a third party.¶

Such a forwarder presence is required for (but not limuted to):¶

• IPv4 service continuity purposes (e.g., Section 3.1 of [RFC8585]).¶

• Supporting advanced services within a local network such as:¶

  • malware filtering,¶

  • parental control,¶

  • Manufacturer Usage Description (MUD) [RFC8520] to only allow intended communications to and from an IoT device, and¶

  • offer multicast DNS proxy service for the ".local" domain [RFC6762].¶

When the CPE behaves as a DNS forwarder, DNS communications can be decomposed into two legs to resolve queries:¶

• The leg between an internal host and the CPE.¶

• The leg between the CPE and an upstream DNS resolver.¶

5. Deploying Encrypted DNS Forwarder in Local Networks

This section discusses some deployment challenges to host an encrypted DNS forwarder within a local network.¶

6. Security Considerations

DNR-related security considerations are discussed in Section 7 of [RFC9463]. Likewise, DDR-related security considerations are discussed in Section 7 of [RFC9462].¶

The communication between the CPE and endpoints is encrypted using mechanisms such as WPA2/3, and any communication with the DNS server co-located on the CPE is also protected. However, the client does not know whether the DNS server is co-located on the CPE or not. If the client uses clear text DNS (i.e., Do53), it will assume that the DNS messages are susceptible to pervasive monitoring. For instance, in an Enterprise deployment, multiple network devices could exist between an endpoint and the CPE; hosting an encrypted DNS server on the CPE minimizes the impact of a breach, which is an essential zero trust principle. Furthermore, the client and user would be able to identify the entity hosting the encrypted DNS server using the ADN assigned to it.¶

7. IANA Considerations

This document has no IANA actions.¶

8. References

Appendix A. Example of Delegated Certificate Issuance

Let's consider that the encrypted DNS forwarder is hosted on a CPE and provisioned by a service (e.g., ACS) in the operator's network. Also, let's assume that each CPE is assigned a unique FQDN (e.g., "cpe-12345.example.com" where 12345 is a unique number).¶

• It is best to ensure that such an FQDN does not carry any Personally Identifiable Information (PII) or device identification details like the customer number or device's serial number.¶

The CPE generates a public and private key-pair, builds a certificate signing request (CSR), and sends the CSR to a service in the operator managing the CPE. Upon receipt of the CSR, the operator's service can utilize certificate management protocols like ACME [RFC8555] to automate certificate management functions such as domain validation procedure, certificate issuance, and certificate revocation.¶

The challenge with this technique is that the service will have to communicate with the CA to issue certificates for millions of CPEs. If an external CA is unable to issue a certificate in time or replace an expired certificate, the service would no longer be able to present a valid certificate to a CPE. When the service requests certificate issuance for a large number of subdomains (e.g., millions of CPEs), it may be treated as an attacker by the CA to overwhelm it. Furthermore, the short-lived certificates (e.g., certificates that expire after 90 days) issued by the CA will have to be renewed frequently. With short-lived certificates, there is a smaller time window to renew a certificate and, therefore, a higher risk that a CA outage will negatively affect the uptime of the encrypted DNS forwarders on CPEs (and the services offered via these CPEs).¶

These challenges can be addressed by using protocols like ACME to automate the certificate renewal process, ensuring certificates are renewed well before expiration. Additionally, incorporating another CA as a backup can provide redundancy and further mitigate the risk of outages. By having a secondary CA, the service can switch to the backup CA in case the primary CA is unavailable, thus maintaining continuous service availability and reducing the risk of service disruption.¶

It offers the additional advantage of improving the security of Browser and CPE interactions. This ensures that HTTPS access to the CPE is possible, allowing the device administrator to securely communicate with and manage the CPE.¶

Acknowledgments

This draft is triggered by the discussion that occured at IETF#119 (Brisbane) about the need to frame the problem to be solved. Thanks to all the participants to that discussion.¶

Acknowledgements from [I-D.reddy-add-delegated-credentials]:

Thanks to Neil Cook, Martin Thomson, Tommy Pauly, Benjamin Schwartz, and Michael Richardson for the discussion and comments.¶

Authors' Addresses