idnits 2.17.1 draft-pp-dnsop-authinfo-00.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 08, 2020) is 1320 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) ** Downref: Normative reference to an Informational RFC: RFC 7871 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track P. Sood 5 Expires: March 12, 2021 Google 6 September 08, 2020 8 Reporting Information from DNS Authoritative Servers 9 draft-pp-dnsop-authinfo-00 11 Abstract 13 This document defines a new DNS RRtype, AUTHINFO, that is used by 14 authoritative servers to publish information about themselves. This 15 information can be useful because a recursive resolver can determine 16 an authoritative server's capabilities, such as whether an 17 authoritative server supports the EDNS(0) client subnet extension. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 12, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Authoritative Server Information . . . . . . . . . . . . . . 2 56 3. Contents of the Returned I-JSON Object . . . . . . . . . . . 3 57 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Using AUTHINFO Responses for Detecting Client Subnet Support 4 59 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. AUTHINFO RRtype . . . . . . . . . . . . . . . . . . . . . 4 62 5.2. Registry for DNS Authoritative Server Information . . . . 5 63 5.3. Registration for ecs-supported in the IANA DNS 64 Authoritative Server Information Registry . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 It is sometimes useful for a DNS recursive resolver to know the 74 capabilities of an authoritative server before sending queries. 75 Because the record with this information can be signed with DNSSEC, 76 it can be used to help a recursive resolver know whether to expect 77 particular EDNS(0) [RFC6891] options in responses. Other uses for 78 the information may be developed in the future. 80 1.1. Definitions 82 The term "authoritative server" is defined in [RFC8499]. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 2. Authoritative Server Information 92 A recursive resolver that wants to use the DNS to get information 93 about an authoritative server sends a query of /IN/ 94 AUTHINFO to the authoritative server. The name is a 95 placeholder for any zone for which the authoritative server is 96 authoritative. For example, if an authoritative server is 97 authoritative for example.com, the query could be example.com/IN/ 98 AUTHINFO, or the QNAME could be any other name for which the server 99 is authoritative. If the QNAME in the request is for a zone for 100 which the authoritative server is not authoritative, the response 101 MUST be an NXDOMAIN response. 103 The RRtype "AUTHINFO" is defined in this document, and the IANA 104 assignment is given in Section 5.1. The contents of the Rdata in the 105 response to this query is defined in Section 3. If the authoritative 106 server understands the AUTHINFO RRtype, the RRset in the Answer 107 section MUST have exactly one record. 109 Most zone typically have multiple authoritative servers. Thus, the 110 AUTHINFO Rdata returned from different authoritative servers for the 111 same zone might differ. 113 3. Contents of the Returned I-JSON Object 115 The response from a DNS query for the AUTHINFO RRtype is a JSON 116 object. The JSON object MUST use the I-JSON message format defined 117 in [RFC7493]. Note that [RFC7493] was based on RFC 7159, but RFC 118 7159 was replaced by [RFC8259]. Requiring the use of I-JSON instead 119 of more general JSON format greatly increases the likelihood of 120 interoperability. 122 The JSON object MAY contain any name/value pairs. 124 All names in the returned object MUST either be defined in the IANA 125 registry or, if for local use only, begin with the substring "temp-". 126 The IANA registry (Section 5.1) will never register names that begin 127 with "temp-". 129 All names MUST consist only of lower-case ASCII characters, digits, 130 and hyphens (that is, Unicode characters U+0061 through 007A, U+0030 131 through U+0039, and U+002D), and MUST be 63 characters or shorter. 132 As defined in Section 5.1, the IANA registry will not register names 133 that begin with "temp-", so these names can be used freely by any 134 implementer. 136 Note that the message returned by the authoritative server MUST be in 137 I-JSON format. I-JSON requires that the message MUST be encoded in 138 UTF8. 140 3.1. Example 142 The I-JSON object that a authoritative server returns might look like 143 the following: 145 { 146 "temp-field2": 42 147 } 149 As specified in [RFC7493], the I-JSON object is encoded as UTF8. 150 [RFC7493] explicitly allows the returned objects to be in any order. 152 4. Using AUTHINFO Responses for Detecting Client Subnet Support 154 This document defines an entry for the IANA DNS Authoritative Server 155 Information Registry that is defined in Section 5.1. 157 The "ecs-supported" name is used to specify whether the authoritative 158 server supports the EDNS(0) client subnet extension defined in 159 [RFC7871]. The value MUST be a boolean. 161 4.1. Example 163 An authoritative server can be reached at "ns32.example.com" and the 164 IP address 192.0.2.222. It supports EDNS(0) client subnet extension. 165 It's response to the AUTHINFO query might be: 167 { "ecs-supported": true } 169 5. IANA Considerations 171 5.1. AUTHINFO RRtype 173 This document defines a new DNS RR type, AUTHINFO, whose value TBD 174 will be allocated by IANA from the "Resource Record (RR) TYPEs" sub- 175 registry of the "Domain Name System (DNS) Parameters" registry: 177 Type: AUTHINFO 179 Value: TBD 181 Meaning: Information self-published by an authoritative server as an 182 I-JSON (RFC 7493) object 184 Reference: This document 186 5.2. Registry for DNS Authoritative Server Information 188 IANA will create a new registry titled "DNS Authoritative Server 189 Information" that will contain definitions of the names that can be 190 used with the protocols defined in this document. The registration 191 procedure is by Expert Review and Specification Required, as defined 192 in [RFC8126]. 194 The specification that is required for registration can be either an 195 Internet-Draft or an RFC. The reviewer for this registry is 196 instructed to generally be liberal in what they accept into the 197 registry: as long as the specification that comes with the 198 registration request is reasonably understandable, the registration 199 should be accepted. 201 The registry has the following fields for each element: 203 Name: The name to be used in the JSON object. This name MUST NOT 204 begin with "temp-". This name MUST conform to the definition of 205 "string" in I-JSON [RFC7493] message format. 207 Value type: The type of data to be used in the JSON object. 209 Specification: The name of the specification for the registered 210 element. 212 5.3. Registration for ecs-supported in the IANA DNS Authoritative 213 Server Information Registry 215 Name: ecs-supported 217 Value type: Boolean 219 Specification: This document 221 6. Security Considerations 223 The values in the AUTHINFO response will be protected by DNSSEC 224 signature if the zone in which the record resides is signed. 226 7. References 228 7.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 236 DOI 10.17487/RFC7493, March 2015, 237 . 239 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 240 Kumari, "Client Subnet in DNS Queries", RFC 7871, 241 DOI 10.17487/RFC7871, May 2016, 242 . 244 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 245 Writing an IANA Considerations Section in RFCs", BCP 26, 246 RFC 8126, DOI 10.17487/RFC8126, June 2017, 247 . 249 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 250 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 251 May 2017, . 253 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 254 Interchange Format", STD 90, RFC 8259, 255 DOI 10.17487/RFC8259, December 2017, 256 . 258 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 259 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 260 January 2019, . 262 7.2. Informative References 264 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 265 for DNS (EDNS(0))", STD 75, RFC 6891, 266 DOI 10.17487/RFC6891, April 2013, 267 . 269 Authors' Addresses 271 Paul Hoffman 272 ICANN 274 Email: paul.hoffman@icann.org 276 Puneet Sood 277 Google 279 Email: puneets@google.com