idnits 2.17.1 draft-reddy-add-resolver-info-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 April 2022) is 744 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 252, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) == Outdated reference: A later version (-10) exists of draft-ietf-add-ddr-06 == Outdated reference: A later version (-16) exists of draft-ietf-add-dnr-06 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD WG T. Reddy 3 Internet-Draft Akamai 4 Intended status: Standards Track M. Boucadair 5 Expires: 15 October 2022 Orange 6 13 April 2022 8 DNS Resolver Information 9 draft-reddy-add-resolver-info-05 11 Abstract 13 This document specifies a method for DNS resolvers to publish 14 information about themselves. Clients can use the resolver 15 information to identify the capabilities of DNS resolvers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 15 October 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Retrieving Resolver Information . . . . . . . . . . . . . . . 3 53 4. Format of the Resolver Information . . . . . . . . . . . . . 3 54 5. Resolver Information . . . . . . . . . . . . . . . . . . . . 3 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. RESINFO RRtype . . . . . . . . . . . . . . . . . . . . . 5 58 7.2. DNS Resolver Information Registration . . . . . . . . . . 5 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 9.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 Historically, DNS stub resolvers communicated with recursive 68 resolvers without needing to know anything about the features 69 supported by these recursive resolvers. As more and more recursive 70 resolvers expose different features that may impact the delivered DNS 71 service, means to help stub resolvers to identify the capabilities of 72 the resolver are valuable. Typically, stub resolvers can discover 73 and authenticate encrypted DNS servers provided by a local network, 74 for example, using the techniques specified in [I-D.ietf-add-dnr] and 75 [I-D.ietf-add-ddr]. However, these stub resolvers need a means to 76 retrieve information from the discovered recursive resolvers about 77 their capabilities. 79 This document fills that void by specifying a method for stub 80 resolvers to retrieve such information. To that aim, a new RRtype is 81 defined for stub resolvers to query the recursive resolvers. The 82 information that a resolver might want to give is defined in 83 Section 5. 85 Retrieved information can be used to feed the server selection 86 procedure. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119][RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 This document makes use of the terms defined in [RFC8499]. 98 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 99 channel between a DNS client and server (e.g., DoT, DoH, or DoQ). 101 3. Retrieving Resolver Information 103 A stub resolver that wants to retrieve the resolver information may 104 use the RRtype "RESINFO" defined in this document (see Section 7.1). 106 The content of the RDATA in a response to RRtype query is defined in 107 Section 5. If the resolver understands the RESINFO RRtype, the RRset 108 in the Answer section MUST have exactly one record. 110 The client can retrieve the resolver information using the RESINFO 111 RRtype and QNAME of the domain name that is used to authenticate the 112 DNS server (referred to as ADN in [I-D.ietf-add-dnr]). 114 If the special use domain name "resolver.arpa" defined in 115 [I-D.ietf-add-ddr] is used to discover the Encrypted DNS server, the 116 client can retrieve the resolver information using the RESINFO RRtype 117 and QNAME of the designated resolver. 119 4. Format of the Resolver Information 121 The resolver information is returned as a JSON object. Precisely, 122 the JSON object MUST use the I-JSON message format [RFC7493]. 124 Note that [RFC7493] was based on [RFC7159], but [RFC7159] was 125 replaced by [RFC8259]. Requiring the use of I-JSON instead of 126 more general JSON format greatly increases the likelihood of 127 interoperability. 129 The JSON object returned by a DNS query may contain any name/value 130 pairs. All names MUST consist only of lower-case ASCII characters, 131 digits, and hyphens (that is, Unicode characters U+0061 through 007A, 132 U+0030 through U+0039, and U+002D). These names MUST be 63 133 characters or shorter. 135 All names in the returned object MUST either be defined in the IANA 136 registry Section 7.2 or begin with the substring "temp-" for names 137 defined for local use only. 139 5. Resolver Information 141 The resolver information includes the following attributes: 143 qnameminimization: If the DNS server supports QNAME minimisation 145 [RFC7816] to improve DNS privacy, the parameter value is set to 146 true. This is a mandatory attribute. 148 extendeddnserror: If the DNS server supports extended DNS error 149 (EDE) [RFC8914] to return additional information about the cause 150 of DNS errors, the parameter lists the possible extended DNS error 151 codes that can be returned by the DNS server. This is an optional 152 attribute. 154 resinfourl: An URL that points to the generic unstructured resolver 155 information (e.g., DoH APIs supported, possible HTTP status codes 156 returned by the DoH server, how to report a problem) for 157 troubleshooting purpose. The server MUST support the content-type 158 'text/html'. The DNS client MUST reject the URL if the scheme is 159 not "https". The client MUST validate that both the encrypted DNS 160 server and the resolver information server are owned and managed 161 by the same entity by establishing a TLS connection to the domain 162 name in the URL and checking if the subjectAltName entry in the 163 server certificate includes the name of the encrypted DNS server. 164 If this match fails, the client MUST ignore the resolver 165 information. As such, the URL should be treated only as 166 diagnostic information for IT staff. This is a mandatory 167 attribute. 169 New attributes can be defined as per the procedure defined in 170 Section 7.2. 172 As specified in [RFC7493], the I-JSON object is encoded as UTF8. 173 [RFC7493] explicitly allows the returned objects to be in any order. 175 Figure 1 shows an example of resolver information. 177 { 178 "qnameminimization": true, 179 "extendeddnserror": [ 180 15, 181 16, 182 17 183 ], 184 "resinfourl": "https://resolver.example.com/guide", 185 } 187 Figure 1: An Example of Resolver Information 189 6. Security Considerations 191 Unless a DNS request to retrieve the resolver information is 192 encrypted (e.g., sent over DNS-over-TLS (DoT) [RFC7858] or DNS-over- 193 HTTPS (DoH)) [RFC8484], the response is susceptible to forgery. The 194 DNS resolver information can be retrieved after the encrypted 195 connection is established to the DNS server or retrieved before the 196 encrypted connection is established to the DNS server by using local 197 DNSSEC validation. 199 7. IANA Considerations 201 Note to the RFC Editor: Please update [RFCXXXX] with the RFC 202 number to be assigned to this document. 204 7.1. RESINFO RRtype 206 This document requests IANA to register a new value from the 207 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 208 (DNS) Parameters" registry available at [RRTYPE]: 210 Type: RESINFO 211 Value: TBD 212 Meaning: Resolver Information as an I-JSON 213 Reference: [RFCXXXX] 215 7.2. DNS Resolver Information Registration 217 This document requests IANA to create a new registry entitled "DNS 218 Resolver Information". This registry contains definitions of the 219 names that can be used to provide the resolver information. 221 The registration procedure is Specification Required (Section 4.6 of 222 [RFC8126]). 224 The structure of the registry is as follows: 226 Name: The name to be used in the JSON object. The name MUST conform 227 to the definition of "string" in I-JSON message format. The IANA 228 registry MUST NOT register names that begin with "temp-", so these 229 names can be used freely by any implementer. 231 Value Type: The type of data to be used in the JSON object. 233 Description: Provides a description of the attribute 235 Specification: The reference specification for the registered 236 element. 238 The initial content of this registry is provided in Table 1. 240 +===================+=========+===================+===============+ 241 | Name | Value | Specification | Specification | 242 | | Type | | | 243 +===================+=========+===================+===============+ 244 | qnameminimization | boolean | Indicates whether | [RFCXXXX] | 245 | | | qnameminimization | | 246 | | | is enabled or not | | 247 +-------------------+---------+-------------------+---------------+ 248 | extendeddnserror | number | Lists the set of | [RFCXXXX] | 249 | | | extended DNS | | 250 | | | errors | | 251 +-------------------+---------+-------------------+---------------+ 252 | resinfourl | string | Provides an | [RFCXXXX] | 253 | | | unstructured | | 254 | | | resolver | | 255 | | | information that | | 256 | | | is used for | | 257 | | | troubleshooting | | 258 +-------------------+---------+-------------------+---------------+ 260 Table 1: Initial RESINFO Registry 262 8. Acknowledgments 264 This specification leverages the work that has been documented in 265 [I-D.pp-add-resinfo]. 267 Thanks to Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben 268 Schwartz, Tony Finch, Daniel Kahn Gillmor, Eric Rescorla and Shashank 269 Jain for the discussion and comments. 271 9. References 273 9.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 281 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 282 2014, . 284 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 285 DOI 10.17487/RFC7493, March 2015, 286 . 288 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 289 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 290 . 292 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 293 Writing an IANA Considerations Section in RFCs", BCP 26, 294 RFC 8126, DOI 10.17487/RFC8126, June 2017, 295 . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 302 Lawrence, "Extended DNS Errors", RFC 8914, 303 DOI 10.17487/RFC8914, October 2020, 304 . 306 9.2. Informative References 308 [I-D.ietf-add-ddr] 309 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 310 Jensen, "Discovery of Designated Resolvers", Work in 311 Progress, Internet-Draft, draft-ietf-add-ddr-06, 4 April 312 2022, . 315 [I-D.ietf-add-dnr] 316 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 317 Jensen, "DHCP and Router Advertisement Options for the 318 Discovery of Network-designated Resolvers (DNR)", Work in 319 Progress, Internet-Draft, draft-ietf-add-dnr-06, 22 March 320 2022, . 323 [I-D.pp-add-resinfo] 324 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 325 publication", Work in Progress, Internet-Draft, draft-pp- 326 add-resinfo-02, 30 June 2020, 327 . 330 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 331 and P. Hoffman, "Specification for DNS over Transport 332 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 333 2016, . 335 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 336 Interchange Format", STD 90, RFC 8259, 337 DOI 10.17487/RFC8259, December 2017, 338 . 340 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 341 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 342 . 344 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 345 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 346 January 2019, . 348 [RRTYPE] IANA, "Resource Record (RR) TYPEs", 349 . 352 Authors' Addresses 354 Tirumaleswar Reddy 355 Akamai 356 Embassy Golf Link Business Park 357 Bangalore 560071 358 Karnataka 359 India 360 Email: kondtir@gmail.com 362 Mohamed Boucadair 363 Orange 364 35000 Rennes 365 France 366 Email: mohamed.boucadair@orange.com