Network policy to use Network-designated DNS Resolvers

Historically, an endpoint would utilize network-designated DNS servers upon joining a network (e.g., DHCP OFFER, IPv6 Router Advertisement). While it has long been possible to configure endpoints to ignore the network's suggestions and use a (public) DNS server on the Internet, this was seldom used because some networks block UDP/53 (in order to enforce their own DNS policies). Also, there has been an increase in the availability of "public resolvers" which DNS clients may be pre-configured to use instead of the default network resolver for a variety of reasons (e.g., offer a good reachability, support an encrypted transport, provide a claimed privacy policy, (lack of) filtering). With the advent of DoT and DoH, such network blocking is more difficult. The network is unable to express its policy to use network-designated resolvers to the endpoints and the endpoint is unable to identify the reason why the public DNS server is not reachable. DNS resolvers not signaled by the network (e.g., DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) ) will bypass enterprise-specific policies, including security policies for endpoints (e.g., laptops, printers, IoT devices). It is out of the scope of this memo to characterize such policies nor assess whether they achieve the claimed intent. With the advent of DoT and DoH, the network is unable to express any policy to the endpoints to explain why the network is blocking alternative resolvers, and endpoints are unable to identify the reason why their choice of public DNS resolver is not reachable. Although network security services can be configured to block DoT traffic by dropping outgoing packets to destination port number 853, identifying DoH traffic is more challenging: network security services may try to identify the well-known DoH resolvers by their domain name and DoH traffic can be blocked by dropping outgoing packets to these domains. However, DoH traffic can not be fully identified without acting as a TLS proxy, with potenitally many undesired consequences. This results in incompatibilities with the privacy profiles discussed in : If an endpoint has enabled strict privacy profile (Section 5 of ), the endpoint cannot resolve DNS names. If an endpoint has enabled opportunistic privacy profile (Section 5 of ), the endpoint will either fallback to an encrypted connection without authenticating the DNS server signaled by the local network or fallback to clear text DNS, and cannot exchange encrypted DNS messages. The fallback adversely impacts security and privacy as internal attacks are possible within Enterprise networks. For example, an internal attacker can modify the DNS responses to re-direct a client to malicious servers or pervasively monitor the DNS traffic. This document describes a mechanism for informing endpoints of network policy related to network-designated DNS servers, such as those DNS servers signaled using and .

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 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in . The terms "Private DNS", "Global DNS" and "Split DNS" are defined in . 'Encrypted DNS' refers to a DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DoT, DoH, or DoQ). The term "enterprise network" in this document extends to a wide variety of deployment scenarios. For example, an "enterprise" can be a Small Office, Home Office, Corporation, Education facility. The clients that connect to an enterprise network can securely authenticate that network and the client is sure that it has connected to the network it was expecting to.

Provisioning Domains (PvDs) are defined in as sets of network configuration information that clients can use to access networks, including rules for DNS resolution and proxy configuration. defines a mechanism for discovering multiple Explicit PvDs on a single network and their Additional Information by means of an HTTP-over-TLS query using a URI derived from the PvD ID. This set of additional configuration information is referred to as a Web Provisioning Domain (Web PvD). This document defines two PvD Key: which determines if network will block, or attempt to block, DNS queries sent to DNS servers that were not signaled by the network. This key has the value True or False (case insensitive). which contains a extended DNS error code as defined by . This key is only present if NetworkDNSOnly is True. Where enterprise networks require clients to query the network-designated DNS servers, it sets the PvD NetworkDNSOnly key to True, otherwise sets NetworkDNSOnly to False. If NetworkDNSOnly is set to True, it implies the network will block, or attempt to block, DNS queries sent to DNS servers that were not signaled by the network. If NetworkDNSOnly is True, the ErrorNetworkDNSOnly key MUST contain either 15, 16 or 17 Extended DNS error codes as defined by . Note that the extended error code "Blocked" defined in Section 4.16 of identifies indicates that access to domains is blocked due to an policy by the operator of the DNS server, extended error code "Censored" defined in Section 4.17 of identifies access to domains is blocked based on a requirement from an external entity and the extended error code "Filtered" defined in Section 4.18 of identifies access to domains is blocked based on the request from the client to blacklist domains. The ErrorNetworkDNSOnly key is useful when the client does not use DNS resolution by the network-designated DNS server to acquire the IP addresses of alternate DNS servers. For example, the client can be pre-configured with both the domain name and IP addresses of the DNS server not signaled by the network (Section 7.1 in ) or the client can be pre-configured with the IP address of the resolver, and it uses IP address in the certificate as identifier (see ). Further, the ErrorNetworkDNSOnly key is useful when the network security service fails to block access to non-network DNS server but successfully filters traffic from the endpoint to IP addresses not conveyed to the endpoint as part of DNS resolution by the network-designated DNS server. NetworkDNSOnly set to True is an internal security policy expression by the operator of the network but is not a policy prescription to the endpoints to disable its use of its other configured DNS servers; that is, the endpoint can ignore NetworkDNSOnly set to True. If joining an un-trusted network (e.g., coffeeshop, hotel, airport network), a True value of NetworkDNSOnly MUST be ignored. The mechanism the client uses to determine 'trusted network' to assist the user MUST involve authenticated identity of the network (not merely matching SSID in the case of WiFi), such as 802.1X or confirming the network-designated encrypted resolver name is pre-configured in the Operating System and TLS handshake with it succeeds. For example, the client can determine "Open" (unencrypted) wireless networks are untrusted networks, notify the user that using a shared and public Pre-Shared Key (PSK) for wireless authentication is a untrusted network. If the pre-shared-key is the same for all clients that connect to the same WLAN, the shared key will be available to all nodes, including attackers, so it is possible to mount an active on-path attack (e.g., , , ). For example, coffee shops and air ports use PSK and are unwilling to perform complex configuration on their networks. In addition, customers are generally unwilling to do complicated provisioning on their devices just to obtain free Wi-Fi. This type of networks can be tagged as "untrusted networks" with minimal human intervention. In such cases the endpoint MAY choose to use an alternate network (e.g., cellular) to resolve the global domain names.

If a device is managed by an enterprise's IT department, the device can be configured to use a specific encrypted DNS server. This configuration may be manual or rely upon whatever deployed device management tool in an enterprise network. For example, customizing Firefox using Group Policy to use the Enterprise DoH server is discussed in for Windows and MacOS, and setting Chrome policies is discussed in and . If mobile device management (MDM) (e.g., ) secures a device, MDM can configure OS/browser with a specific encrypted DNS server. If an endpoint is on-boarded, for example, using Over-The-Air (OTA) enrollment to provision the device with a certificate and configuration profile, the configuration profile can include the authentication domain name (ADN) of the encrypted DNS server. The OS/Browser can use the configuration profile to use a specific encrypted DNS server. In this case, MDM is not installed on the device. Provisioning IT-managed devices, BYOD devices with MDM or configuration profile with network-designated DNS server is outside the scope of this document. Typically, Enterprise networks do not assume that all devices in their network are managed by the IT team or MDM, especially in the quite common BYOD scenario. The endpoint can use the discovered network-designated DNS server to only access DNS names for which the Enterprise network claims authority and use another public DNS server for global domains or use the discovered network-designated DNS server to access both private domains and global domains. The scope of NetworkDNSOnly key is restricted to unmanaged BYOD devices without a configuration profile on explicitly trusted networks. In this use case, the user has authorized the client to override local DNS settings for a specific network. It is similar to the way users explicitly disable VPN connection in specific networks and VPN connection is enabled by default in other networks for privacy. The unmanaged BYOD devices use mutual authentication of the client and the enterprise network. The client is typically authenticated with their user credentials (e.g., username and password). The network is typically authenticated with a certificate (e.g., PEAP-MSCHAPv2 ) or a mutually-authenticated key exchange which is well-defended from offline attacks (e.g., EAP-pwd , EAP-PSK ). Importantly, WPA-PSK and WPA2-PSK are not well-defended from offline attacks and MUST NOT be used in conjunction with NetworkDNSOnly set to True. Many users have privacy and personal data sovereignty concerns with employers installing MDM on their personal devices; they are concerned that admin can glean personal information and could control how they use their devices. When users do not install MDM on their devices, IT admins do not get visibility into the security posture of those devices. To overcome this problem, a host agent can cryptographically attest the security status associated with device, such as minimum pass code length, biometric login enabled, OS version etc. This approach is fast gaining traction especially with the advent of closed OS like Windows 10 in S mode or Chromebook, where applications are sandboxed (e.g., ransomware attack is not possible) and applications can only be installed via the OS store.

The following example shows how the JSON keys defined in this document can be used:

The JSON keys "identifier", "expires", and "prefixes" are defined in .

The content of NetworkDNSOnly and ErrorSplitDNSBlocked may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly. The security considerations discussed in and need to be considered to restrict the scope of NetworkDNSOnly and ErrorSplitDNSBlocked PvD Keys to explicitly trusted networks. The NetworkDNSOnly and ErrorSplitDNSBlocked PvD Keys assigned by an anonymous or unknown network (e.g., coffee shops) MUST be ignored by the client.

IANA is requested to add NetworkDNSOnly and ErrorSplitDNSBlocked PvD Keys to the Additional Information PvD Keys registry (https://www.iana.org/assignments/pvds/pvds.xhtml).

Thanks to Mohamed Boucadair, Jim Reid, Ben Schwartz, Tommy Pauly, Paul Vixie, Ben Schwartz, and Vinny Parla for the discussion and comments.