]> Nokia

Bangalore Karnataka India kondtir@gmail.com

Orange

Rennes 35000 France mohamed.boucadair@orange.com

Cloud Software Group Holdings, Inc.

danwing@gmail.com

Internet Adaptive DNS Discovery DNS deployment Discovery Typical connectivity service offerings based upon on Customer Premise Equipment (CPEs) involve DNS forwarders on the CPE for various reasons (offer local services, control the scope/content of information in DNS, ensure better dependability for local service, provide control to users, etc.). Upgrading DNS to use encrypted transports introduces deployment complications as to how to sustain current offerings with local services. Solutions are needed to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. This document describes the problem and to what extent existing solutions can or can't be used for these deployments. For example, Star certificates and name constraints extension suffer from the problem of deploying a new feature to CAs, TLS clients, and servers. Discussion Venues Discussion of this document takes place on the Adaptive DNS Discovery Working Group mailing list (add@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 has developed a number of initiatives to promote home router security and hardening. The prplWrt project is an initiative in prpl Foundation that aims to improve the security and performance of open-source router firmware, such as 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) , DNS over TLS (DoT) , and DNS over QUIC (DoQ) ) 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.

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 for such matters. The mechanism for the client to authenticate the local encrypted DNS server is out of scope of this draft (see ). This draft details how such an authenticated local encrypted DNS server would be used.

Conventions and Definitions This document makes use of the terms defined in . 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 .

DDR:

refers to the Discovery of Designated Resolvers procedure defined in .

Encrypted DNS:

refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoH , DoT , and DoQ .

Managed CPE:

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

Proxied DNS In Local Networks shows various network setups where the CPE embeds a caching encrypted DNS forwarder.

Proxied Encrypted DNS Sessions | | |<========DNR========>| | | |<===Encrypted DNS===>|<=Encrypted DNS=>| | | | (b) .--------------. .------------. | | | | 3rd Party Host---| LAN CPE------| ISP |------DNS Resolver | | | | | | | '--------------'| |'------------' | | |<=DNR=>| | |<========DNR========>| | | |<===Encrypted DNS===>|<========Encrypted DNS========>| | | | ]]>

For all the cases shown in , 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., ).
• Supporting advanced services within a local network such as:
  • malware filtering,
  • parental control,
  • Manufacturer Usage Description (MUD) to only allow intended communications to and from an IoT device, and
  • offer multicast DNS proxy service for the ".local" domain .

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.

Deploying Encrypted DNS Forwarder in Local Networks This section discusses some deployment challenges to host an encrypted DNS forwarder within a local network.

Discovery of Designated Resolvers (DDR) DDR requires proving possession of an IP address, as the DDR certificate contains the server's IPv4 and IPv6 addresses and is signed by a Certification Authority (CA). DDR is constrained to public IP addresses because (WebPKI) CAs will not sign special-purpose IP addresses , most notably IPv4 private-use , IPv4 shared address , or IPv6 Unique-Local address space. A tempting solution for enabling an encrypted DNS forwarder with DDR is to use the CPE's WAN IP address for DDR and prove possession of that IP address. However, the CPE's WAN IPv4 address will not be a public IPv4 address if the CPE is behind another layer of NAT (either Carrier Grade NAT (CGN) or another on-premise NAT), reducing the success of this mechanism to CPE's WAN IPv6 address. Also, if the ISP renumbers the subscriber's network suddenly (rather than slow IPv6 renumbering described in ), encrypted DNS service will be delayed until that new certificate is acquired.

Discovery of Network-designated Resolvers (DNR) DNR requires proving possession of a domain name as the encrypted resolver's certificate contains the FQDN. For example, the entity (e.g., ISP or network administrator) managing the CPE would assign a unique FQDN to the CPE. There are two mechanisms for the CPE to obtain the certificate for the FQDN: using one of its WAN IP addresses or requesting its signed certificate from an Internet-facing server used for remote CPE management (e.g., the Auto Configuration Server (ACS) in the CPE WAN Management Protocol ). If the CPE's WAN IP address is used, the CPE needs a public IPv4 or a global unicast IPv6 address together with DNS A or AAAA records pointing to that CPE's WAN address to prove possession of the DNS name to obtain a (WebPKI) CA-signed certificate. That is, the CPE fulfills the DNS or HTTP challenge discussed in Automatic Certificate Management Environment (ACME) . However, a CPE's WAN address will not be a public IPv4 address if the CPE is behind another layer of NAT (either a CGN or another on-premise NAT), reducing the success of this mechanism to a CPE's WAN IPv6 address. If the ISP renumbers the subscriber's network, the DNS record will also need to expire and changed to reflect the new IP address.

Security Considerations DNR-related security considerations are discussed in . Likewise, DDR-related security considerations are discussed in . 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.

IANA Considerations This document has no IANA actions.

References Normative References This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. Informative References OpenWrt Prpl Foundation Prpl Foundation The Broadband Forum This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Nokia Orange Cloud Software Group Holdings, Inc. Obtaining CA-signed certificates for servers within a home network is difficult and causes problems at scale. This document explores requirements to improve this situation and analyzes existing solutions. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market. Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet. This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice. This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries. This memo updates RFC 6890. This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Nokia Orange Citrix Systems, Inc. McAfee An encrypted DNS server is authenticated by a certificate signed by a Certificate Authority (CA). However, for typical encrypted DNS server deployments on Customer Premise Equipment (CPEs), the signature cannot be obtained or requires excessive interactions with a Certificate Authority. This document explores the use of TLS delegated credentials for a DNS server deployed on a CPE. This approach is meant to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities.

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 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 :

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