idnits 2.17.1 draft-reddy-add-resolver-info-03.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 (April 13, 2021) is 1108 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 274, 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-00 == Outdated reference: A later version (-16) exists of draft-ietf-add-dnr-00 -- 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 McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: October 15, 2021 Orange 6 April 13, 2021 8 DNS Resolver Information 9 draft-reddy-add-resolver-info-03 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 October 15, 2021. 34 Copyright Notice 36 Copyright (c) 2021 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Retrieving Resolver Information . . . . . . . . . . . . . . . 3 54 4. Format of the Resolver Information . . . . . . . . . . . . . 3 55 5. Resolver Information . . . . . . . . . . . . . . . . . . . . 3 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. RESINFO RRtype . . . . . . . . . . . . . . . . . . . . . 5 59 7.2. DNS Resolver Information Registration . . . . . . . . . . 5 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 9.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 Historically, DNS stub resolvers communicated with recursive 69 resolvers without needing to know anything about the features 70 supported by these recursive resolvers. As more and more recursive 71 resolvers expose different features that may impact the delivered DNS 72 service, means to help stub resolvers to identify the capabilities of 73 the resolver are valuable. Typically, stub resolvers can discover 74 and authenticate encrypted DNS servers provided by a local network, 75 for example, using the techniques specified in [I-D.ietf-add-dnr] and 76 [I-D.ietf-add-ddr]. However, these stub resolvers need a means to 77 retrieve information from the discovered recursive resolvers about 78 their capabilities. 80 This document fills that void by specifying a method for stub 81 resolvers to retrieve such information. To that aim, a new RRtype is 82 defined for stub resolvers to query the recursive resolvers. The 83 information that a resolver might want to give is defined in 84 Section 5. 86 Retrieved information can be used to feed the server selection 87 procedure. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119][RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 This document makes use of the terms defined in [RFC8499]. 99 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 100 channel between a DNS client and server (e.g., DoT, DoH, or DoQ). 102 3. Retrieving Resolver Information 104 A stub resolver that wants to retrieve the resolver information may 105 use the RRtype "RESINFO" defined in this document (see Section 7.1). 107 The content of the RDATA in a response to RRtype query is defined in 108 Section 5. If the resolver understands the RESINFO RRtype, the RRset 109 in the Answer section MUST have exactly one record. 111 The client can retrieve the resolver information using the RESINFO 112 RRtype and QNAME of the domain name that is used to authenticate the 113 DNS server (referred to as ADN in [I-D.ietf-add-dnr]). 115 If the special use domain name "resolver.arpa" defined in 116 [I-D.ietf-add-ddr] is used to discover the Encrypted DNS server, the 117 client can retrieve the resolver information using the RESINFO RRtype 118 and a QNAME of "resolver.arpa". 120 4. Format of the Resolver Information 122 The resolver information is returned as a JSON object. Precisely, 123 the JSON object MUST use the I-JSON message format [RFC7493]. 125 Note that [RFC7493] was based on [RFC7159], but [RFC7159] was 126 replaced by [RFC8259]. Requiring the use of I-JSON instead of 127 more general JSON format greatly increases the likelihood of 128 interoperability. 130 The JSON object returned by a DNS query may contain any name/value 131 pairs. All names MUST consist only of lower-case ASCII characters, 132 digits, and hyphens (that is, Unicode characters U+0061 through 007A, 133 U+0030 through U+0039, and U+002D). These names MUST be 63 134 characters or shorter. 136 All names in the returned object MUST either be defined in the IANA 137 registry Section 7.2 or begin with the substring "temp-" for names 138 defined for local use only. 140 5. Resolver Information 142 The resolver information includes the following attributes: 144 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 Note that the extended error code "Blocked" defined in 155 Section 4.16 of [RFC8914] identifies access to domains is 156 blocked due to an policy by the operator of the DNS server, 157 extended error code "Censored" defined in Section 4.17 of 158 [RFC8914] identifies access to domains is blocked based on a 159 requirement from an external entity and the extended error code 160 "Filtered" defined in Section 4.18 of [RFC8914] identifies 161 access to domains is blocked based on the request from the 162 client to blacklist domains. 164 clientauth: If the DNS server requires client authentication, the 165 parameter value is set to true. For example, when not on the 166 enterprise network (e.g., coffee shop) yet needing to access the 167 enterprise Encrypted DNS server, roaming users can use client 168 authentication to access the Enterprise-provided Encrypted DNS 169 server. This is an optional attribute. 171 resinfourl: An URL that points to the generic unstructured resolver 172 information (e.g., DoH APIs supported, possible HTTP status codes 173 returned by the DoH server, how to report a problem) for 174 troubleshooting purpose. The server MUST support the content-type 175 'text/html'. This is a mandatory attribute. 177 identityurl: An URL that points to a human-friendly description of 178 the resolver identity to display to the end-user. The server MUST 179 support the content-type 'text/plain'. This is a mandatory 180 attribute. 182 New attributes can be defined as per the procedure defined in 183 Section 7.2. 185 As specified in [RFC7493], the I-JSON object is encoded as UTF8. 186 [RFC7493] explicitly allows the returned objects to be in any order. 188 Figure 1 shows an example of resolver information. 190 { 191 "qnameminimization": true, 192 "extendeddnserror": [ 193 15, 194 16, 195 17 196 ], 197 "clientauth": false, 198 "resinfourl": "https://resolver.example.com/guide", 199 "identityurl": "https://resolver.example.com/user-friendly-name" 200 } 202 Figure 1: An Example of Resolver Information 204 6. Security Considerations 206 Unless a DNS request to retrieve the resolver information is 207 encrypted (e.g., sent over DNS-over-TLS (DoT) [RFC7858] or DNS-over- 208 HTTPS (DoH)) [RFC8484], the response is susceptible to forgery. The 209 DNS resolver information can be retrieved after the encrypted 210 connection is established to the DNS server or retrieved before the 211 encrypted connection is established to the DNS server by using local 212 DNSSEC validation. 214 7. IANA Considerations 216 Note to the RFC Editor: Please update [RFCXXXX] with the RFC 217 number to be assigned to this document. 219 7.1. RESINFO RRtype 221 This document requests IANA to register a new value from the 222 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 223 (DNS) Parameters" registry available at [RRTYPE]: 225 Type: RESINFO 226 Value: TBD 227 Meaning: Resolver Information as an I-JSON 228 Reference: [RFCXXXX] 230 7.2. DNS Resolver Information Registration 232 This document requests IANA to create a new registry entitled "DNS 233 Resolver Information". This registry contains definitions of the 234 names that can be used to provide the resolver information. 236 The registration procedure is Specification Required (Section 4.6 of 237 [RFC8126]). 239 The structure of the registry is as follows: 241 Name: The name to be used in the JSON object. The name MUST conform 242 to the definition of "string" in I-JSON message format. The IANA 243 registry MUST NOT register names that begin with "temp-", so these 244 names can be used freely by any implementer. 246 Value Type: The type of data to be used in the JSON object. 248 Description: Provides a description of the attribute 250 Specification: The reference specification for the registered 251 element. 253 The initial content of this registry is provided in Table 1. 255 +-------------------+---------+---------------------+---------------+ 256 | Name | Value | Specification | Specification | 257 | | Type | | | 258 +-------------------+---------+---------------------+---------------+ 259 | qnameminimization | boolean | Indicates whether | [RFCXXXX] | 260 | | | qnameminimization | | 261 | | | is enabled or not | | 262 | extendeddnserror | number | Lists the set of | [RFCXXXX] | 263 | | | extended DNS errors | | 264 | clientauth | boolean | Indicates whether | [RFCXXXX] | 265 | | | client | | 266 | | | authentication is | | 267 | | | required or not | | 268 | resinfourl | string | Provides an | [RFCXXXX] | 269 | | | unstructured | | 270 | | | resolver | | 271 | | | information that is | | 272 | | | used for | | 273 | | | troubleshooting | | 274 | identityurl | string | Points to a human- | [RFCXXXX] | 275 | | | friendly | | 276 | | | description of the | | 277 | | | resolver identity | | 278 | | | to display to the | | 279 | | | end-user | | 280 +-------------------+---------+---------------------+---------------+ 282 Table 1: Initial RESINFO Registry 284 8. Acknowledgments 286 This specification leverages the work that has been documented in 287 [I-D.pp-add-resinfo]. 289 Thanks to Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben 290 Schwartz, Tony Finch, and Shashank Jain for the discussion and 291 comments. 293 9. References 295 9.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 303 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 304 2014, . 306 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 307 DOI 10.17487/RFC7493, March 2015, 308 . 310 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 311 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 312 . 314 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 315 Writing an IANA Considerations Section in RFCs", BCP 26, 316 RFC 8126, DOI 10.17487/RFC8126, June 2017, 317 . 319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 321 May 2017, . 323 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 324 Lawrence, "Extended DNS Errors", RFC 8914, 325 DOI 10.17487/RFC8914, October 2020, 326 . 328 9.2. Informative References 330 [I-D.ietf-add-ddr] 331 Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 332 Jensen, "Discovery of Designated Resolvers", draft-ietf- 333 add-ddr-00 (work in progress), February 2021. 335 [I-D.ietf-add-dnr] 336 Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 337 Jensen, "DHCP and Router Advertisement Options for the 338 Discovery of Network-designated Resolvers (DNR)", draft- 339 ietf-add-dnr-00 (work in progress), February 2021. 341 [I-D.pp-add-resinfo] 342 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 343 publication", draft-pp-add-resinfo-02 (work in progress), 344 June 2020. 346 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 347 and P. Hoffman, "Specification for DNS over Transport 348 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 349 2016, . 351 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 352 Interchange Format", STD 90, RFC 8259, 353 DOI 10.17487/RFC8259, December 2017, 354 . 356 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 357 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 358 . 360 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 361 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 362 January 2019, . 364 [RRTYPE] IANA, "Resource Record (RR) TYPEs", 365 . 368 Authors' Addresses 369 Tirumaleswar Reddy 370 McAfee, Inc. 371 Embassy Golf Link Business Park 372 Bangalore, Karnataka 560071 373 India 375 Email: kondtir@gmail.com 377 Mohamed Boucadair 378 Orange 379 Rennes 35000 380 France 382 Email: mohamed.boucadair@orange.com