Application Behavior Considering DNS ==================================== Proposed Working Group Charter ------------------------------ Last revised 2019 November 12. Based on the original proposal at https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#ABCD Edited by Barry Leiba, Dave Lawrence and Ben Schwartz DNS clients, also known as stub resolvers, are the starting point of most DNS queries. When an end user or a networked program requires access to DNS information, the stub resolver is its interface to the DNS. Since the standardization of the Domain Name System in RFCs 1034 and 1035, stub resolvers have been deployed in a variety of architectures, including acting as a core operating system service (as on Windows), a function executed separately by each program (as in POSIX), or a combination of these approaches (e.g. dnsmasq, Android). Each stub resolver must be configured to use one or more specified recursive resolvers. As DNS has been refined and extended (e.g. EDNS, DNSSEC), the number of potential stub configuration options has grown. Operating systems typically offer a default configuration and permit the system administrator to adjust it. By default, most popular operating systems for consumer devices defer the choice of recursive resolver to the network. Similarly, most application software uses the operating system’s DNS configuration by default. Recently, secure transport protocols such as DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC 8094], and DNS over HTTPS (DoH) [RFC 8484] have created a new class of configuration options for stub resolvers. Applications and operating systems, eager to provide confidentiality and tamper-resistance to their DNS queries, have begun enabling these protocols. Some implementations have included changes to how the recursive resolver is selected, such as preferring a recursive resolver that has been approved by the developers. As DNS client behaviors change, assumptions made by other parties may no longer be true. Some network operators have used DNS services for a variety of purposes beyond simple query resolution, and have relied on DNS clients to send queries to their recursive resolver or to transmit queries unencrypted. Maintaining support for those uses, if they are retained, may require new practices and protocols. This working group will consider technical drafts on DNS client configuration, especially with a focus on the following items where technical consensus seems obtainable: - Communicating configuration between the network, operating system, and applications - Discovery of resolvers and their capabilities and behaviors - Query routing in a multi-resolver environment - Multiple non-equivalent query paths, such as split-horizon DNS or geo-sensitive answers - Local DNS caches (e.g. partitioning, use of stale records) - Resilience and fault-tolerance (e.g. single points of failure) - Support for debugging and analysis - DNS Push (accepting responses to queries that have not yet been issued) - Ossification and evolvability The following topics are also relevant, but represent areas that are significantly more challenging for consensus-building: - End-user privacy and pervasive surveillance - Detection and suppression of malware - Use of records from untrusted sources - Policy enforcement and control of the stub resolver configuration - Use and impacts of large recursive resolution services The working group will not attempt to resolve disagreements on these topics, and will require full consensus on any statements regarding these areas. This working group will coordinate with dnsop (OPS Area), capport (ART Area), dprive, dhc, and homenet (INT Area). All last-call announcements will be copied to the relevant working groups to ensure thorough and careful review. The working group will also coordinate with the SEC Area, and will be assigned a security advisor.