From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9606.txt | 494 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 494 insertions(+) create mode 100644 doc/rfc/rfc9606.txt (limited to 'doc/rfc/rfc9606.txt') diff --git a/doc/rfc/rfc9606.txt b/doc/rfc/rfc9606.txt new file mode 100644 index 0000000..80d95d3 --- /dev/null +++ b/doc/rfc/rfc9606.txt @@ -0,0 +1,494 @@ + + + + +Internet Engineering Task Force (IETF) T. Reddy.K +Request for Comments: 9606 Nokia +Category: Standards Track M. Boucadair +ISSN: 2070-1721 Orange + June 2024 + + + DNS Resolver Information + +Abstract + + This document specifies a method for DNS resolvers to publish + information about themselves. DNS clients can use the resolver + information to identify the capabilities of DNS resolvers. How DNS + clients use such information is beyond the scope of this document. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9606. + +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 + 2. Terminology + 3. Retrieving Resolver Information + 4. Format of the Resolver Information + 5. Resolver Information Keys/Values + 6. An Example + 7. Security Considerations + 8. IANA Considerations + 8.1. RESINFO RR Type + 8.2. DNS Resolver Information Keys Registration + 8.3. Guidelines for the Designated Experts + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + Historically, DNS clients communicated with recursive resolvers + without needing to know anything about the features supported by + these resolvers. However, more and more recursive resolvers expose + different features that may impact delivered DNS services (privacy + preservation, filtering, transparent behavior, etc.). DNS clients + can discover and authenticate encrypted DNS resolvers provided by a + local network, for example, using the Discovery of Network-designated + Resolvers (DNR) [RFC9463] and the Discovery of Designated Resolvers + (DDR) [RFC9462]. However, these DNS clients can't retrieve + information from the discovered recursive resolvers about their + capabilities to feed the resolver selection process. Instead of + depending on opportunistic approaches, DNS clients need a more + reliable mechanism to discover the features that are configured on + these resolvers. + + This document fills that void by specifying a mechanism that allows + communication of DNS resolver information to DNS clients for use in + resolver selection decisions. For example, the resolver selection + procedure may use the retrieved resolver information to prioritize + privacy-preserving resolvers over those that don't enable QNAME + minimisation [RFC9156]. Another example is when a DNS client selects + a resolver based on its filtering capability. For instance, a DNS + client can choose a resolver that filters domains according to a + security policy using the Blocked (15) Extended DNS Error (EDE) + [RFC8914]. Alternatively, the client may have a policy not to select + a resolver that forges responses using the Forged Answer (4) EDE. + However, it is out of the scope of this document to define the + selection procedure and policies. Once a resolver is selected by a + DNS client, and unless explicitly mentioned, this document does not + interfere with that resolver's DNS operations. + + Specifically, this document defines a new resource record (RR) type + for DNS clients to query the recursive resolvers. The initial + information that a resolver might want to expose is defined in + Section 5. That information is scoped to cover properties that are + used to infer privacy and transparency policies of a resolver. Other + information can be registered in the future per the guidance in + Section 8.2. The information is not intended for end-user + consumption. + +2. Terminology + + 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. + + This document makes use of the terms defined in [RFC9499]. The + following additional terms are used: + + Encrypted DNS: Refers to a DNS scheme where DNS exchanges are + transported over an encrypted channel between a DNS client and + server (e.g., DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) + [RFC7858], or DNS over QUIC (DoQ) [RFC9250]). + + Encrypted DNS resolver: Refers to a DNS resolver that supports any + encrypted DNS scheme. + + Reputation: Defined as "the estimation in which an identifiable + actor is held, especially by the community or the Internet public + generally" per Section 1 of [RFC7070]. + +3. Retrieving Resolver Information + + A DNS client that wants to retrieve the resolver information may use + the RR type "RESINFO" defined in this document. The content of the + RDATA in a response to a query for RESINFO RR QTYPE is defined in + Section 5. If the resolver understands the RESINFO RR type, the + RRset MUST have exactly one record. Invalid records MUST be silently + ignored by DNS clients. RESINFO is a property of the resolver and is + not subject to recursive resolution. + + A DNS client can retrieve the resolver information using the RESINFO + RR type and the QNAME of the domain name that is used to authenticate + the DNS resolver (referred to as the Authentication Domain Name (ADN) + in DNR [RFC9463]). + + If the Special-Use Domain Name "resolver.arpa", defined in [RFC9462], + is used to discover an encrypted DNS resolver, the client can + retrieve the resolver information using the RESINFO RR type and QNAME + of "resolver.arpa". In this case, a client has to contend with the + risk that a resolver does not support RESINFO. The resolver might + pass the query upstream, and then the client can receive a positive + RESINFO response from either a legitimate DNS resolver or an + attacker. + + The DNS client MUST set the Recursion Desired (RD) bit of the query + to 0. The DNS client MUST discard the response if the AA flag in the + response is set to 0, indicating that the DNS resolver is not + authoritative for the response. + + If a group of resolvers is sharing the same ADN and/or anycast + address, then these instances SHOULD expose a consistent RESINFO. + +4. Format of the Resolver Information + + The resolver information record uses the same format as DNS TXT + records. The format rules for TXT records are defined in the base + DNS specification (Section 3.3.14 of [RFC1035]) and are further + elaborated in the DNS-based Service Discovery (DNS-SD) specification + (Section 6.1 of [RFC6763]). The recommendations to limit the TXT + record size are discussed in Section 6.1 of [RFC6763]. + + Similar to DNS-SD, the RESINFO RR type uses "key/value" pairs to + convey the resolver information. Each key/value pair is encoded + using the format rules defined in Section 6.3 of [RFC6763]. Using + standardized key/value syntax within the RESINFO RR type makes it + easier for future keys to be defined. If a DNS client sees unknown + keys in a RESINFO RR type, it MUST silently ignore them. The same + rules for the keys, as defined in Section 6.4 of [RFC6763], MUST be + followed for RESINFO. + + Resolver information keys MUST either be defined in the IANA registry + (Section 8.2) or begin with the substring "temp-" for names defined + for local use only. + +5. Resolver Information Keys/Values + + The following resolver information keys are defined: + + qnamemin: The presence of this key indicates that the DNS resolver + supports QNAME minimisation [RFC9156] to improve DNS privacy. + Note that, per the rules for the keys defined in Section 6.4 of + [RFC6763], if there is no '=' in a key, then it is a boolean + attribute, simply identified as being present, with no value. + + The presence of this key indicates that the DNS resolver is + configured to minimise the amount of privacy-sensitive data sent + to an authoritative name server. + + This is an optional attribute. + + exterr: If the DNS resolver supports the EDE option defined in + [RFC8914] to return additional information about the cause of DNS + errors, the value of this key lists the possible EDE codes that + can be returned by this DNS resolver. A value can be an + individual EDE or a range of EDEs. Range values MUST be + identified by "-". When multiple non-contiguous values are + present, these values MUST be comma-separated. + + Returned EDEs (e.g., Blocked (15), Censored (16), and Filtered + (17)) indicate whether the DNS resolver is configured to reveal + the reason why a query was filtered/blocked when such an event + happens. If the resolver's capabilities are updated to include + new similar error codes, the resolver can terminate the TLS + session, prompting the client to initiate a new TLS connection and + retrieve the resolver information again. This allows the client + to become aware of the resolver's updated capabilities. + Alternatively, if the client receives an EDE for a DNS request, + but that EDE was not listed in the "exterr", the client can query + the resolver again to learn about the updated resolver's + capabilities to return new error codes. If a mismatch still + exists, the client can identify that the resolver information is + inaccurate and discard it. + + This is an optional attribute. + + infourl: A URL that points to the generic unstructured resolver + information (e.g., DoH APIs supported, possible HTTP status codes + returned by the DoH server, or how to report a problem) for + troubleshooting purposes. The server that exposes such + information is called "resolver information server". + + The resolver information server MUST support only the content-type + "text/html" for the resolver information. The DNS client MUST + reject the URL as invalid if the scheme is not "https". Invalid + URLs MUST be ignored. The URL MUST be treated only as diagnostic + information for IT staff. It is not intended for end-user + consumption as the URL can possibly provide misleading + information. + + This key can be used by IT staff to retrieve other useful + information about the resolver and also the procedure to report + problems (e.g., invalid filtering). + + This is an optional attribute. + + New keys can be defined as per the procedure defined in Section 8.2. + +6. An Example + + Figure 1 shows an example of a published resolver information record. + + resolver.example.net. 7200 IN RESINFO qnamemin exterr=15-17 + infourl=https://resolver.example.com/guide + + Figure 1: An Example of a Resolver Information Record + + As mentioned in Section 3, a DNS client that discovers the ADN + "resolver.example.net" of its resolver using DNR will issue a query + for RESINFO RR QTYPE for that ADN and will learn that: + + * the resolver enables QNAME minimisation, + + * the resolver can return Blocked (15), Censored (16), and Filtered + (17) EDEs, and + + * more information can be retrieved from + "https://resolver.example.com/guide". + +7. Security Considerations + + DNS clients communicating with discovered DNS resolvers MUST use one + of the following measures to prevent DNS response forgery attacks: + + 1. Establish an authenticated secure connection to the DNS resolver. + + 2. Implement local DNSSEC validation (Section 10 of [RFC9499]) to + verify the authenticity of the resolver information. + + It is important to note that, of these two measures, only the first + one can apply to queries for "resolver.arpa". + + An encrypted resolver may return incorrect information in RESINFO. + If the client cannot validate the attributes received from the + resolver, which will be used for resolver selection or displayed to + the end user, the client should process those attributes only if the + encrypted resolver has sufficient reputation according to local + policy (e.g., user configuration, administrative configuration, or a + built-in list of reputable resolvers). This approach limits the + ability of a malicious encrypted resolver to cause harm with false + claims. + +8. IANA Considerations + +8.1. RESINFO RR Type + + IANA has updated the "Resource Record (RR) TYPEs" registry under the + "Domain Name System (DNS) Parameters" registry group [RRTYPE] as + follows: + + Type: RESINFO + Value: 261 + Meaning: Resolver Information as Key/Value Pairs + Reference: RFC 9606 + +8.2. DNS Resolver Information Keys Registration + + IANA has created a new registry called "DNS Resolver Information + Keys" under the "Domain Name System (DNS) Parameters" registry group + [IANA-DNS]. This new registry contains definitions of the keys that + can be used to provide the resolver information. + + The registration procedure is Specification Required (Section 4.6 of + [RFC8126]). Designated experts should carefully consider the + security implications of allowing a resolver to include new keys in + this registry. Additional considerations are provided in + Section 8.3. + + The structure of the registry is as follows: + + Name: The key name. The name MUST conform to the definition in + Section 4 of this document. The IANA registry MUST NOT register + names that begin with "temp-" so that these names can be used + freely by any implementer. + + Description: A description of the registered key. + + Reference: The reference specification for the registered element. + + The initial contents of this registry are provided in Table 1. + + +==========+=====================================+===========+ + | Name | Description | Reference | + +==========+=====================================+===========+ + | qnamemin | The presence of the key name | RFC 9606 | + | | indicates that QNAME minimisation | | + | | is enabled. | | + +----------+-------------------------------------+-----------+ + | exterr | Lists the set of enabled extended | RFC 9606 | + | | DNS errors. It must be an INFO- | | + | | CODE decimal value in the "Extended | | + | | DNS Error Codes" registry | | + | | . | | + +----------+-------------------------------------+-----------+ + | infourl | Provides a URL that points to | RFC 9606 | + | | unstructured resolver information | | + | | that is used for troubleshooting. | | + +----------+-------------------------------------+-----------+ + + Table 1: Initial Contents of the DNS Resolver Information + Keys Registry + +8.3. Guidelines for the Designated Experts + + It is suggested that multiple designated experts be appointed for + registry change requests. + + Criteria that should be applied by the designated experts include + determining whether the proposed registration duplicates existing + entries and whether the registration description is clear and fits + the purpose of this registry. + + Registration requests are evaluated within a two-week review period + on the advice of one or more designated experts. Within the review + period, the designated experts will either approve or deny the + registration request, communicating this decision to IANA. Denials + should include an explanation and, if applicable, suggestions as to + how to make the request successful. + +9. References + +9.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. + Lawrence, "Extended DNS Errors", RFC 8914, + DOI 10.17487/RFC8914, October 2020, + . + + [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query + Name Minimisation to Improve Privacy", RFC 9156, + DOI 10.17487/RFC9156, November 2021, + . + + [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. + Jensen, "Discovery of Designated Resolvers", RFC 9462, + DOI 10.17487/RFC9462, November 2023, + . + + [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., + and T. Jensen, "DHCP and Router Advertisement Options for + the Discovery of Network-designated Resolvers (DNR)", + RFC 9463, DOI 10.17487/RFC9463, November 2023, + . + +9.2. Informative References + + [IANA-DNS] IANA, "Domain Name System (DNS) Parameters", + . + + [RESINFO] Sood, P. and P. Hoffman, "DNS Resolver Information Self- + publication", Work in Progress, Internet-Draft, draft-pp- + add-resinfo-02, 27 June 2020, + . + + [RFC7070] Borenstein, N. and M. Kucherawy, "An Architecture for + Reputation Reporting", RFC 7070, DOI 10.17487/RFC7070, + November 2013, . + + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over Transport + Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May + 2016, . + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + . + + [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over + Dedicated QUIC Connections", RFC 9250, + DOI 10.17487/RFC9250, May 2022, + . + + [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, + RFC 9499, DOI 10.17487/RFC9499, March 2024, + . + + [RRTYPE] IANA, "Resource Record (RR) TYPEs", + . + +Acknowledgments + + This specification leverages the work that has been documented in + [RESINFO]. + + Thanks to Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben + Schwartz, Tony Finch, Daniel Kahn Gillmor, Eric Rescorla, Shashank + Jain, Florian Obser, Richard Baldry, and Martin Thomson for the + discussion and comments. + + Thanks to Mark Andrews, Joe Abley, Paul Wouters, and Tim Wicinski for + the discussion on RR formatting rules. + + Special thanks to Tommy Jensen for the careful and thoughtful + Shepherd review. + + Thanks to Johan Stenstam and Jim Reid for the dns-dir reviews, Ray + Bellis for the RRTYPE allocation review, Arnt Gulbrandsen for the ART + review, and Mallory Knodel for the gen-art review. + + Thanks to Éric Vyncke for the AD review. + + Thanks to Gunter Van de Velde, Erik Kline, Paul Wouters, Orie Steele, + Warren Kumari, Roman Danyliw, and Murray Kucherawy for the IESG + review. + +Authors' Addresses + + Tirumaleswar Reddy.K + Nokia + India + Email: kondtir@gmail.com + + + Mohamed Boucadair + Orange + 35000 Rennes + France + Email: mohamed.boucadair@orange.com -- cgit v1.2.3