idnits 2.17.1 draft-reddy-add-resolver-info-02.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 5, 2021) is 1117 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: 'I-D.ietf-add-dnr' is mentioned on line 113, but not defined == Missing Reference: 'I-D.ietf-add-ddr' is mentioned on line 76, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 276, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) -- 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 7, 2021 Orange 6 April 5, 2021 8 DNS Resolver Information 9 draft-reddy-add-resolver-info-02 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 7, 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 7 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 [I-D.ietf- 116 add-ddr] is used to discover the Encrypted DNS server, the client can 117 first retrieve a CNAME that aliases `_dns.resolver.arpa` to 118 `_dns.$HOSTNAME` and then retrieve the resolver information using the 119 RESINFO RRtype and QNAME of the `$HOSTNAME`. 121 4. Format of the Resolver Information 123 The resolver information is returned as a JSON object. Precisely, 124 the JSON object MUST use the I-JSON message format [RFC7493]. 126 Note that [RFC7493] was based on [RFC7159], but [RFC7159] was 127 replaced by [RFC8259]. Requiring the use of I-JSON instead of 128 more general JSON format greatly increases the likelihood of 129 interoperability. 131 The JSON object returned by a DNS query may contain any name/value 132 pairs. All names MUST consist only of lower-case ASCII characters, 133 digits, and hyphens (that is, Unicode characters U+0061 through 007A, 134 U+0030 through U+0039, and U+002D). These names MUST be 63 135 characters or shorter. 137 All names in the returned object MUST either be defined in the IANA 138 registry Section 7.2 or begin with the substring "temp-" for names 139 defined for local use only. 141 5. Resolver Information 143 The resolver information includes the following attributes: 145 qnameminimization: If the DNS server supports QNAME minimisation 146 [RFC7816] to improve DNS privacy, the parameter value is set to 147 true. This is a mandatory attribute. 149 extendeddnserror: If the DNS server supports extended DNS error 150 (EDE) [RFC8914] to return additional information about the cause 151 of DNS errors, the parameter lists the possible extended DNS error 152 codes that can be returned by the DNS server. This is an optional 153 attribute. 155 Note that the extended error code "Blocked" defined in 156 Section 4.16 of [RFC8914] identifies access to domains is 157 blocked due to an policy by the operator of the DNS server, 158 extended error code "Censored" defined in Section 4.17 of 159 [RFC8914] identifies access to domains is blocked based on a 160 requirement from an external entity and the extended error code 161 "Filtered" defined in Section 4.18 of [RFC8914] identifies 162 access to domains is blocked based on the request from the 163 client to blacklist domains. 165 clientauth: If the DNS server requires client authentication, the 166 parameter value is set to true. For example, when not on the 167 enterprise network (e.g., coffee shop) yet needing to access the 168 enterprise Encrypted DNS server, roaming users can use client 169 authentication to access the Enterprise-provided Encrypted DNS 170 server. This is an optional attribute. 172 resinfourl: An URL that points to the generic unstructured resolver 173 information (e.g., DoH APIs supported, possible HTTP status codes 174 returned by the DoH server, how to report a problem) for 175 troubleshooting purpose. The server MUST support the content-type 176 'text/html'. This is a mandatory attribute. 178 identityurl: An URL that points to a human-friendly description of 179 the resolver identity to display to the end-user. The server MUST 180 support the content-type 'text/plain'. This is a mandatory 181 attribute. 183 New attributes can be defined as per the procedure defined in 184 Section 7.2. 186 As specified in [RFC7493], the I-JSON object is encoded as UTF8. 187 [RFC7493] explicitly allows the returned objects to be in any order. 189 Figure 1 shows an example of resolver information. 191 { 192 "qnameminimization": true, 193 "extendeddnserror": [ 194 15, 195 16, 196 17 197 ], 198 "clientauth": false, 199 "resinfourl": "https://resolver.example.com/guide", 200 "identityurl": "https://resolver.example.com/user-friendly-name" 201 } 203 Figure 1: An Example of Resolver Information 205 6. Security Considerations 207 Unless a DNS request to retrieve the resolver information is 208 encrypted (e.g., sent over DNS-over-TLS (DoT) [RFC7858] or DNS-over- 209 HTTPS (DoH)) [RFC8484], the response is susceptible to forgery. The 210 DNS resolver information can be retrieved after the encrypted 211 connection is established to the DNS server. If the client wishes to 212 retrieve the resolver information before the encryption connection is 213 established to the DNS resolver, the client MUST use local DNSSEC 214 validation. 216 7. IANA Considerations 218 Note to the RFC Editor: Please update [RFCXXXX] with the RFC 219 number to be assigned to this document. 221 7.1. RESINFO RRtype 223 This document requests IANA to register a new value from the 224 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 225 (DNS) Parameters" registry available at [RRTYPE]: 227 Type: RESINFO 228 Value: TBD 229 Meaning: Resolver Information as an I-JSON 230 Reference: [RFCXXXX] 232 7.2. DNS Resolver Information Registration 234 This document requests IANA to create a new registry entitled "DNS 235 Resolver Information". This registry contains definitions of the 236 names that can be used to provide the resolver information. 238 The registration procedure is Specification Required (Section 4.6 of 239 [RFC8126]). 241 The structure of the registry is as follows: 243 Name: The name to be used in the JSON object. The name MUST conform 244 to the definition of "string" in I-JSON message format. The IANA 245 registry MUST NOT register names that begin with "temp-", so these 246 names can be used freely by any implementer. 248 Value Type: The type of data to be used in the JSON object. 250 Description: Provides a description of the attribute 252 Specification: The reference specification for the registered 253 element. 255 The initial content of this registry is provided in Table 1. 257 +-------------------+---------+---------------------+---------------+ 258 | Name | Value | Specification | Specification | 259 | | Type | | | 260 +-------------------+---------+---------------------+---------------+ 261 | qnameminimization | boolean | Indicates whether | [RFCXXXX] | 262 | | | qnameminimization | | 263 | | | is enabled or not | | 264 | extendeddnserror | number | Lists the set of | [RFCXXXX] | 265 | | | extended DNS errors | | 266 | clientauth | boolean | Indicates whether | [RFCXXXX] | 267 | | | client | | 268 | | | authentication is | | 269 | | | required or not | | 270 | resinfourl | string | Provides an | [RFCXXXX] | 271 | | | unstructured | | 272 | | | resolver | | 273 | | | information that is | | 274 | | | used for | | 275 | | | troubleshooting | | 276 | identityurl | string | Points to a human- | [RFCXXXX] | 277 | | | friendly | | 278 | | | description of the | | 279 | | | resolver identity | | 280 | | | to display to the | | 281 | | | end-user | | 282 +-------------------+---------+---------------------+---------------+ 284 Table 1: Initial RESINFO Registry 286 8. Acknowledgments 288 This specification leverages the work that has been documented in 289 [I-D.pp-add-resinfo]. 291 Thanks to Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben 292 Schwartz, and Shashank Jain for the discussion and comments. 294 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 304 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 305 2014, . 307 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 308 DOI 10.17487/RFC7493, March 2015, 309 . 311 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 312 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 313 . 315 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 316 Writing an IANA Considerations Section in RFCs", BCP 26, 317 RFC 8126, DOI 10.17487/RFC8126, June 2017, 318 . 320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 322 May 2017, . 324 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 325 Lawrence, "Extended DNS Errors", RFC 8914, 326 DOI 10.17487/RFC8914, October 2020, 327 . 329 9.2. Informative References 331 [I-D.pp-add-resinfo] 332 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 333 publication", draft-pp-add-resinfo-02 (work in progress), 334 June 2020. 336 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 337 and P. Hoffman, "Specification for DNS over Transport 338 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 339 2016, . 341 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 342 Interchange Format", STD 90, RFC 8259, 343 DOI 10.17487/RFC8259, December 2017, 344 . 346 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 347 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 348 . 350 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 351 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 352 January 2019, . 354 [RRTYPE] IANA, "Resource Record (RR) TYPEs", 355 . 358 Authors' Addresses 360 Tirumaleswar Reddy 361 McAfee, Inc. 362 Embassy Golf Link Business Park 363 Bangalore, Karnataka 560071 364 India 366 Email: kondtir@gmail.com 368 Mohamed Boucadair 369 Orange 370 Rennes 35000 371 France 373 Email: mohamed.boucadair@orange.com