idnits 2.17.1 draft-edmonds-dnsop-capabilities-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 : ---------------------------------------------------------------------------- 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 (July 2, 2017) is 2488 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Edmonds 3 Internet-Draft Fastly 4 Intended status: Standards Track July 2, 2017 5 Expires: January 3, 2018 7 Signaling DNS Capabilities 8 draft-edmonds-dnsop-capabilities-00 10 Abstract 12 This document defines an Extension Mechanisms for DNS (EDNS0) option 13 that allows DNS clients and servers to signal support for DNS 14 protocol capabilities. Clients and servers that support this option 15 can take advantage of new DNS protocol features when completing a 16 transaction, and by caching the set of capabilities advertised by a 17 DNS server, a DNS client can utilize any mutually supported DNS 18 protocol capability in subsequent queries. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 3, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. The "DNS Features" Capability . . . . . . . . . . . . . . 5 59 4.2. The "EDNS0 Option Codes" Capability . . . . . . . . . . . 6 60 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Originating the Option . . . . . . . . . . . . . . . . . 7 62 5.2. Generating a Response . . . . . . . . . . . . . . . . . . 7 63 5.3. Caching the Option . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 10. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 11.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The lack of explicit capability signaling in the DNS protocol 77 [RFC1035] makes it hard to deploy new functionality. For instance, 78 Client Subnet in DNS Queries [RFC7871] defines an EDNS option to be 79 used with a subset of specialized zones on the Internet capable of 80 producing "tailored responses". It describes two strategies for 81 deciding when to originate the Client Subnet option: the use of 82 periodic probes by the resolver, and the use of a safelist of 83 nameservers permitted by the resolver operator to use the option. In 84 practice, few EDNS options have been defined, and EDNS options have 85 not been originated routinely by general purpose resolvers on the 86 Internet. If many EDNS options were to be widely used, it would be 87 unreasonable to expect resolver implementations to perform option- 88 specific probing or resolver operators to perform option-specific 89 safelisting for each newly introduced EDNS option. 91 EDNS options are not the only aspect of the DNS protocol that can 92 benefit from explicit capability signaling. Extension Mechanisms for 93 DNS (EDNS(0)) [RFC6891] includes a VERSION field in the OPT Pseudo- 94 RR, but encourages clients to set this field to the "lowest 95 implemented level capable of expressing a transaction, to minimize 96 the responder and network load of discovering the greatest common 97 implementation level between requestor and responder". If new EDNS 98 VERSIONs were to be introduced, capability signaling would permit a 99 DNS transaction initiated with a lower implementation level to be 100 completed with the highest mutually supported implementation level. 102 Similarly, Q and Meta-TYPEs [RFC6895] (Section 3.1) have been 103 allocated sparingly. Introducing a new general purpose QTYPE is 104 problematic, because by definition the existing installed base of 105 nameservers will not support the new QTYPE. 107 This document defines an EDNS0 option that allows DNS clients and 108 servers to exchange lists of supported "DNS Capabilities". This new 109 option includes explicit client-side caching semantics that allow 110 future queries to be initiated that take advantage of mutually 111 supported functionality. It also defines two DNS Capabilities. The 112 first, "DNS Features", encodes an array of feature flags that future 113 DNS protocol features may take advantage of. The second, "EDNS0 114 Option Codes", encodes the set of EDNS0 options supported by the 115 client or server. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Overview 125 A DNS client that implements this protocol will include the "DNS 126 Capabilities" EDNS0 option described in Section 4 in queries that it 127 initiates (Section 5.1). If a DNS server that implements this 128 protocol receives a query that includes this option, it will generate 129 a corresponding response (Section 5.2) indicating which DNS 130 Capabilities it supports and the length of time that the client may 131 cache the server's capabilities for (Section 5.3). 133 4. Option Format 135 This protocol uses an EDNS0 [RFC6891] option to encode the 136 capabilities supported by the client or server. For each capability, 137 the option contains a TLV element . Multiple Capability TLVs may be 139 concatenated together, and the ordering of Capability TLVs within the 140 option is not significant. The option is structured as follows: 142 +0 (MSB) +1 (LSB) 143 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 144 0: | OPTION-CODE | 145 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 146 2: | OPTION-LENGTH | 147 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 148 4: | OPTION-TTL-MINUTES | 149 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 150 6: | CAPABILITY TYPE | CAPABILITY LENGTH | 151 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 152 8: | | 153 / CAPABILITY VALUE... / 154 / / 155 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 156 / / 157 / (Additional Capability TLVs...) / 158 / / 159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 161 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for the DNS 162 Capabilities option is TBD-DNS-CAPABILITIES-OPT. 164 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the 165 length of the payload (everything after OPTION-LENGTH) in octets. 167 o OPTION-TTL-MINUTES, 2 octets, unsigned, indicates the number of 168 minutes clients may cache this DNS Capabilities option. 170 o CAPABILITY TYPE, 1 octet, identifies the Capability encoded in the 171 Capability TLV, using codes as assigned in TBD-DNS-CAPABILITIES- 172 TYPE-REGISTRY. 174 o CAPABILITY LENGTH, 1 octet, unsigned, encodes the number of octets 175 in the CAPABILITY VALUE field. 177 o CAPABILITY VALUE, variable number of octets, contains capability- 178 specific data. 180 The format of the CAPABILITY VALUE field depends on the value of the 181 CAPABILITY TYPE field. This document defines the following 182 CAPABILITY TYPE values: 184 +---------+-------------------------------+-----------+-------------+ 185 | Value | Name | Singleton | Reference | 186 +---------+-------------------------------+-----------+-------------+ 187 | 0 | Reserved | | This | 188 | | | | document | 189 | 1 | DNS Features | Y | Section 4.1 | 190 | 2 | EDNS0 Option Codes | Y | Section 4.2 | 191 | 3-249 | Unassigned | | | 192 | 250-254 | Reserved for | | This | 193 | | Local/Experimental Use | | document | 194 | 255 | Reserved | | This | 195 | | | | document | 196 +---------+-------------------------------+-----------+-------------+ 198 CAPABILITY TYPE values. 200 The "DNS Features" and "EDNS0 Option Codes" capabilities are further 201 described below. 203 4.1. The "DNS Features" Capability 205 The "DNS Features" capability is a variable length array of feature 206 flags encoded as a bitmap with trailing zero octets omitted. 208 New DNS protocol functionality that requires upgraded semantics may 209 register a flag in this capability. DNS clients and servers that 210 support a new protocol feature with a feature flag in this capability 211 MUST set the corresponding bit in this capability in queries and 212 responses when those messages include a DNS Capabilities option. 214 Each feature flag is assigned an individual bit in the "DNS Features" 215 bitmap. For example, the first feature flag corresponds to the Most 216 Significant Bit (MSB) of the first octet of the array, the ninth 217 feature flag corresponds to the MSB of the second octet of the array, 218 and the 256th feature flag corresponds to the Least Significant Bit 219 (LSB) of the 32nd octet of the array. 221 If no "DNS Features" flags are supported by the DNS client or server, 222 this capability MUST be omitted from the DNS Capabilities option. 223 Trailing zero octets in the "DNS Features" bitmap MUST be omitted. 224 The minimum CAPABILITY LENGTH value for this capability is 1, and the 225 maximum CAPABILITY LENGTH value for this capability is 32. 227 +---------+------+----------------------------------+---------------+ 228 | Bit | Flag | Description | Reference | 229 +---------+------+----------------------------------+---------------+ 230 | 0-249 | | Unassigned | | 231 | 250-254 | | Reserved for Local/Experimental | This document | 232 | | | Use | | 233 | 255 | | Reserved | This document | 234 +---------+------+----------------------------------+---------------+ 236 "DNS Features" flags. 238 The "DNS Features" capability is a singleton capability. It MUST NOT 239 appear more than once in a DNS Capabilities option. 241 4.2. The "EDNS0 Option Codes" Capability 243 [RFC4034] (Section 4.1.2) defines the Type Bit Maps field of the NSEC 244 RR using a sparse encoding of the 16-bit code points in the DNS 245 Resource Record (RR) TYPEs registry. This document reuses that 246 "window block" bitmap encoding for the "DNS EDNS0 Option Codes (OPT)" 247 registry, which is also a 16-bit code space. 249 The "EDNS0 Option Codes" capability is a window block encoded bitmap 250 indicating which EDNS0 Option Codes are supported by the DNS client 251 or server. If the "EDNS0 Option Codes" capability is included in the 252 DNS Capability option in a DNS message, the EDNS0 Option Codes 253 supported by the DNS client or server SHOULD be indicated using this 254 capability. 256 The EDNS0 Option Codes space is split into 256 window blocks, each 257 representing the low-order 8 bits of the 16-bit code space. Each 258 block that has at least one indicated EDNS0 Option Code is encoded 259 using a single octet window number (from 0 to 255), a single octet 260 bitmap length (from 1 to 32) indicating the number of octets used for 261 the window block's bitmap, and up to 32 octets (256 bits) of bitmap. 263 Window blocks are present in the "EDNS0 Option Codes" capability in 264 increasing numerical order. 266 Each bitmap encodes the low-order 8 bits of EDNS0 Option Codes within 267 the window block. The first bit is bit 0. For window block 0, bit 3 268 corresponds to NSID [RFC5001], bit 8 corresponds to EDNS Client 269 Subnet [RFC7871], and so forth. If a bit is set, it indicates that 270 the corresponding EDNS0 Option Code is supported by the DNS protocol 271 implementation that sent the message containing the "EDNS0 Option 272 Codes" capability. 274 Window blocks with no EDNS0 Option Codes present MUST NOT be 275 included. Trailing zero octets in the bitmap MUST be omitted. The 276 length of each block's bitmap is determined by the option code with 277 the largest numerical value, within that block, among the set of 278 option codes indicated as supported. Trailing zero octets not 279 specified MUST be interpreted as zero octets. 281 The "EDNS0 Option Codes" capability is a singleton capability. It 282 MUST NOT appear more than once in a DNS Capabilities option. 284 5. Protocol Description 286 5.1. Originating the Option 288 A DNS client that implements this protocol SHOULD include the DNS 289 Capabilities option in each EDNS(0) enabled query it sends. If the 290 DNS client supports any DNS Features (Section 4.1), it MUST include a 291 DNS Features capability in the DNS Capabilities option advertising 292 the supported features. If the DNS client supports any EDNS0 Option 293 Codes, it MAY include an EDNS0 Option Codes capability in the DNS 294 Capabilities option advertising the supported option codes. 296 DNS clients MUST set the OPTION-TTL-MINUTES field to zero. 298 5.2. Generating a Response 300 When a query containing the DNS Capabilities option is received, a 301 DNS server supporting DNS Capabilities MAY use the information 302 contained in the client's option to generate a response that utilizes 303 the functionality that the client has advertised as supported. 305 A DNS server that implements this protocol and receives a DNS 306 Capabilities option MUST include a DNS Capabilities option in its 307 response. If the DNS server implements any DNS Features 308 (Section 4.1), it MUST include a DNS Features capability in the DNS 309 Capabilities option advertising the supported features. If the DNS 310 server supports any EDNS0 Option Codes, it MUST include an EDNS0 311 Option Codes capability in the DNS Capabilities option advertising 312 the supported option codes. 314 If the DNS Capabilities option was not included in a query, a DNS 315 server MUST NOT include one when generating a response. 317 5.3. Caching the Option 319 When a DNS client originates a query containing the DNS Capabilities 320 option and receives a response containing the DNS Capabilities 321 option, the data contained in the option SHOULD be cached so that 322 future queries sent to the same DNS server can utilize functionality 323 that the server has advertised as supported. A query sent to "the 324 same DNS server" means a query sent to a server identified by the 325 same network address as a previous query. 327 The amount of time that the DNS Capabilities option may be cached for 328 is indicated in the OPTION-TTL-MINUTES field. This allows a maximum 329 cache entry lifetime of 45.5 days. If a DNS Capabilities option for 330 a given DNS server is already cached when a subsequent response 331 containing a DNS Capabilities option is received, the cached option 332 MAY be overwritten with the newer data, and the cache entry's 333 lifetime MAY be extended or reduced. 335 If a DNS client receives a response containing the DNS Capabilities 336 option where the OPTION-TTL-MINUTES field is zero, the data contained 337 in the option MUST be discarded, and the response MUST be treated as 338 if it did not contain a DNS Capabilities option. 340 6. IANA Considerations 342 To be written. 344 7. Implementation Status 346 To be written. 348 8. Security Considerations 350 To be written. 352 9. Acknowledgements 354 To be written. 356 10. TODO 358 1. There is a limited amount of space available in a UDP DNS query 359 message (512 octets), and a query message with a maximum size 360 query name (255 octets) and a plausible set of other EDNS0 361 options could be as much as ~300 octets, leaving ~200 octets for 362 the DNS Capabilities option. What should happen if all of the 363 desired DNS Capabilities data can't be serialized into a <= 512 364 octet query message? 366 11. References 368 11.1. Normative References 370 [RFC1035] Mockapetris, P., "Domain names - implementation and 371 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 372 November 1987, . 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 380 Rose, "Resource Records for the DNS Security Extensions", 381 RFC 4034, DOI 10.17487/RFC4034, March 2005, 382 . 384 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 385 for DNS (EDNS(0))", STD 75, RFC 6891, 386 DOI 10.17487/RFC6891, April 2013, 387 . 389 11.2. Informative References 391 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 392 RFC 5001, DOI 10.17487/RFC5001, August 2007, 393 . 395 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 396 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 397 April 2013, . 399 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 400 Kumari, "Client Subnet in DNS Queries", RFC 7871, 401 DOI 10.17487/RFC7871, May 2016, 402 . 404 Author's Address 406 Robert Edmonds 407 Fastly 408 Atlanta, Georgia 409 United States of America 411 Email: edmonds@mycre.ws