idnits 2.17.1 draft-tapril-ns2-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. -- 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 (March 9, 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ghedini-dprive-early-data-01 == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-svcb-httpssvc-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop T. April 3 Internet-Draft Akamai Technologies 4 Intended status: Informational March 9, 2020 5 Expires: September 10, 2020 7 Parameterized Nameserver Delegation with NS2 and NS2T 8 draft-tapril-ns2-00 10 Abstract 12 Within the DNS, there is no mechanism for authoritative servers to 13 advertise which transport methods they are capable of. If secure 14 transport methods are adopted by authoritative operators, protocol 15 negotiation would be required. This document provides two new 16 Resource Record Types, NS2 and NS2T, to facilitate that negotiation 17 by allowing zone owners to signal how the authoritative nameserver(s) 18 for their zone(s) may accept 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 https://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 September 10, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Introductory Examples . . . . . . . . . . . . . . . . . . 3 56 1.2. Goal of the NS2 and NS2T Records . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. NS2 and NS2T Record Types . . . . . . . . . . . . . . . . . . 4 59 2.1. Difference between the records . . . . . . . . . . . . . 5 60 2.2. AliasForm Record Type . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Multiple Service Providers . . . . . . . . . . . . . 6 62 2.2.2. Loop Prevention . . . . . . . . . . . . . . . . . . . 6 63 2.3. ServiceForm . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3.1. SvcFieldPriority . . . . . . . . . . . . . . . . . . 7 65 2.3.2. SvcDomainName . . . . . . . . . . . . . . . . . . . . 7 66 2.3.3. SvcParamKeys . . . . . . . . . . . . . . . . . . . . 7 67 2.4. Deployment Considerations . . . . . . . . . . . . . . . . 11 68 2.4.1. AliasForm and ServiceForm in the Parent . . . . . . . 11 69 2.4.2. Rollout . . . . . . . . . . . . . . . . . . . . . . . 11 70 2.4.3. Availability . . . . . . . . . . . . . . . . . . . . 11 71 2.4.4. Multiple ServiceForm records for the same host or IP 72 address . . . . . . . . . . . . . . . . . . . . . . . 11 73 3. Responses with NS2 . . . . . . . . . . . . . . . . . . . . . 12 74 3.1. Response Size Considerations . . . . . . . . . . . . . . 12 75 3.2. When to include glue . . . . . . . . . . . . . . . . . . 12 76 4. DNSSEC and NS2 . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 5.1. Availability of zones without NS . . . . . . . . . . . . 13 79 5.2. Reflection Attacks . . . . . . . . . . . . . . . . . . . 13 80 5.3. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.4. Availability . . . . . . . . . . . . . . . . . . . . . . 13 82 5.5. Connetion Failures . . . . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. New registry for NS2 transports . . . . . . . . . . . . . 14 85 6.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 14 86 6.1.2. Initial Contents . . . . . . . . . . . . . . . . . . 14 87 6.2. New SvcParamKey Values . . . . . . . . . . . . . . . . . 15 88 7. Informative References . . . . . . . . . . . . . . . . . . . 16 89 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 90 Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 17 91 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 18 92 Appendix D. Discussions . . . . . . . . . . . . . . . . . . . . 18 93 D.1. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 19 94 D.2. Second Record Name . . . . . . . . . . . . . . . . . . . 19 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 Resolvers currently rely on the NS records in the parent and child 100 zones to provide and confirm the nameservers that are authoritative 101 for each zone. The Nameserver version 2 (NS2) record extends the 102 functionality of the NS record to include additional information 103 about how authoritative zone information can be queried, whether that 104 be over alternate protocols or by using alternate protocol 105 parameters. The NS2 record may be present at zone cuts but can also 106 redirect resolvers to other nameservers for further redirection via 107 the Nameserver Version 2 Target (NS2T) record, which does not 108 indicate a zone cut. 110 The NS2 and NS2T records uses the SVCB record format defined in 111 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], using a subset of the 112 already defined service parameters as well as new parameters 113 described in this document. Some, but not all, of the existing 114 service parameters will also be available for NS2 and NS2T records. 115 This document will outline the available parameters and their usage. 117 1.1. Introductory Examples 119 To introduce the NS2 and NS2T records, this example shows a possible 120 response from an authoritative in the authority section of the DNS 121 response when delegating to another nameserver. 123 example.com. 86400 IN NS2 2 ns2.example.com. ( transports=dot, 124 dnsTlsFingerprints=["MIIS987SSLKJ...123===", 125 "MII3SODKSLKJ...456==="] ) 126 example.com. 86400 IN NS2 3 ns3.example.com. ( transports=doh, 127 dnsDohURITemplate="https://ns.example.net/q/{?dns}" ) 128 example.com. 86400 IN NS ns1.example.com. 129 ns1.example.com. 86400 IN NS 192.0.2.1 130 ns2.example.com. 86400 IN NS 192.0.2.2 131 ns3.example.com. 86400 IN NS 192.0.2.3 133 In this example, the authoritative nameserver is delegating to both a 134 DNS-over-TLS and DNS-over-HTTPS service running on ns.example.net for 135 resolvers that support NS2, and also delegating to a nameserver that 136 will serve unencrypted DNS over port 53 for those that do not. 138 Like in SVCB, NS2 and NS2T also offer the ability to use the Alias 139 form delegation. The example below shows an example where 140 example.com is being delegated with NS2 to an AliasForm which can 141 then be further resolved. 143 example.com. 86400 IN NS2 0 ns2.example.net. 144 example.com. 86400 IN NS ns1.example.com. 145 ns1.example.com. 86400 IN NS 192.0.2.1 147 The example.net authoritative server may return the following NS2T 148 records in response to a query as deirected by the above records. 150 ns2.example.net 3600 IN NS2T ns1.example.org. ( transports=dot, 151 dnsTlsFingerprints=["MIIS987SSLKJ...123==="] ) 152 ns2.example.net 3600 IN NS2T ns2.example.org. ( transports=doh, 153 ddnsDohURITemplate="https://ns.example.net/q/{?dns}") 155 The avbove records indicate to the client that the authoritative 156 nameservers for zones that Alias to ns2.example.net are 157 ns1.example.org and ns2.example.rg with the configuration provided. 159 Later sections of this document will go into more detail on the 160 resolution process using these records. 162 1.2. Goal of the NS2 and NS2T Records 164 The primary goal of the NS2 and NS2T records is to provide zone 165 owners a way to signal to clients how they may receive queries for 166 the records for which they are authoritative. The NS2 and NS2T 167 records are machine readable, can coexist with NS records in the same 168 zone, and do not break software that does not support them. 170 NS2 and NS2T are designed to allow child zones to publish NS2 and 171 NS2T records, even when parent zones only publish NS records. Lack 172 of parent zone support for NS2 records may arise for technical or 173 policy reasons. 175 1.3. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in 180 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 2. NS2 and NS2T Record Types 185 The SVCB record allows for two types of records, the AliasForm and 186 the ServiceForm. The NS2 record takes advantage of both and each 187 will be described below in depth. 189 2.1. Difference between the records 191 This document introduces two different resource record types. Both 192 records have the same functionality, with the difference between them 193 being that the NS2 record MUST only be used at a delegation point 194 while the NS2T, is NS2 Target, record does not indicate that the 195 label is being delegated. For example, take the following NS2 196 record: 198 example.com. 86400 IN NS2 1 ns2.example.net. ( transports=dot ) 200 When a client receives the above record, the resolver should send 201 queries for any name under example.com to the nameserver at 202 ns2.example.com unless further delegated. By contrast, when 203 presented with the records below: 205 example.com. 86400 IN NS2 0 customer.example.org. 206 customer.example.org. 86400 IN NS2T 1 ns2.example.net. ( transports=dot ) 208 A resolver trying to resolve a name under example.com would get the 209 first record above from the parent authoritative server, .COM, 210 indicating that the NS2T records found at customer.example.org should 211 be used to locate the authoritative nameservers of example.com. The 212 second record above dictates that the authoritative nameserver from 213 records that have aliased to customer.example.org is ns2.example.net, 214 which only accepts queries over DNS-over-TLS. The primary difference 215 between the two records is that the NS2 record means that anything 216 under the record label should be queried at the delegated server 217 while the NS2T record is just for redirection purposes, and any names 218 under the record's label should still be resolved using the same 219 server unless otherwise delegated. 221 It should be noted that both NS2 and NS2T records may exist for the 222 same label. Below is an example of this: 224 example.com. 86400 IN NS2 0 c1.example.org. 225 c1.example.org. 86400 IN NS2T 1 ns2.example.net. ( transports=dot ) 226 c1.example.org. 86400 IN NS2 1 ns3.example.net. ( transports=dot ) 227 test.c1.example.org. 600 IN A 192.0.2.1 229 In the above case, the NS2 record for c1.example.org would only be 230 used when trying to resolve names below c1.example.org. This reason 231 is why when an AliasForm NS2 or NS2T record is encountered, the 232 resolver MUST query for the NS2T record associated with the given 233 name. 235 2.2. AliasForm Record Type 237 In order to take full advantage of the AliasForm of NS2 and NS2T, the 238 parent, child and resolver must support these records. When 239 supported, the use of the AliasForm will allow zone owners to 240 delegate their zones to another operator with a single record in the 241 parent. AliasForm NS2 records SHOULD appear in the child zone when 242 used in the parent. If a resolver were to encounter an AliasForm NS2 243 or NS2T record, it would then resolve the name in the SvcDomainName 244 of the original record using NS2T RR type to receive the either 245 another AliasForm record or a ServiceForm NS2T record. 247 For example, if the name www.example.com was being resolved, the .com 248 zone may issue a referral by returning the following record: 250 example.com. 86400 IN NS2 0 customer1.example.net. 252 The above record would indicate to the resolver that in order to 253 obtain the authoritative nameserver records for example.com, the 254 resolver should resolve the RR type NS2T for the name 255 customer1.example.net. 257 2.2.1. Multiple Service Providers 259 Some zone owners may wish to use multiple providers to serve their 260 zone, in which case multiple NS2 AliasForm records can be used. In 261 the event that multiple NS2 AliasForm records are encountered, the 262 resolver SHOULD pick one of the records at random. For example, to 263 split traffic between two providers, the zone owner for example.com 264 could have the following NS2 records: 266 example.com. 86400 IN NS2 0 customer1.example.net. 267 example.com. 86400 IN NS2 0 customer1.example.org. 269 DRAFT NOTE: SVCB says that there "SHOULD only have a single RR". 270 This ignores that but keep the randomization part. Section 2.5p1 of 271 SVCB 273 2.2.2. Loop Prevention 275 Special care should be taken by both the zone owner and the delegated 276 zone operator to ensure that a lookup loop is not created by having 277 two AliasForm records rely on each other to serve the zone. Doing so 278 may result in a resolution loop, and likely a denial of service. Any 279 clients implementing NS2 and NS2T SHOULD implement a per-resolution 280 limit of how many AliasForm records may be traversed when looking up 281 a delegation to prevent infinite looping. When a loop is detected, 282 like with the handling of CNAME or NS, the server should respond to 283 the client with SERVFAIL. 285 2.3. ServiceForm 287 The ServiceForm of the NS2 and NS2T records are likely to be the more 288 popular of the two. They work the same way as the SVCB or HTTPSSVC 289 records do by providing a priority and list of parameters associated 290 with the SvcDomainName. In addition to being able to identify which 291 protocols are supported by the authoriatative server, the ServiceForm 292 record will also allow providers to operate different protocols on 293 different addresses. 295 2.3.1. SvcFieldPriority 297 As defined in the DNS SVCB document 298 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcFieldPriority values 299 SHOULD be used to dictate the priority when multiple NS2 or NS2T 300 records are returned. 302 2.3.2. SvcDomainName 304 As defined in the SVCB document 305 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcDomainName provides 306 the hostname to which the NS2 or NS2T record refers. The wire format 307 must be the a-label format of the name. When presented, the u-label 308 may be presented, but the the a-label should also be displayed 309 displaying the u-label. The SvcDomainName field MUST be set and MUST 310 NOT be "." for NS2 records. Records with a SvcDomainName of "." 311 SHOULD be discarded. 313 DRAFT NOTE: Should u-label and a-label be expanded? I'm leaning 314 towards not expanding. 316 2.3.3. SvcParamKeys 318 The following DNS SVCB parameters are defined for the NS2 and NS2T 319 ServiceForms. 321 2.3.3.1. "ipv4hint" and "ipv6hint" 323 The "ipv4hint" and "ipv6hint" SvcParamKeys are defined in 324 [I-D.draft-ietf-dnsop-svcb-httpssvc-00]. The NS2 and NS2T records 325 can makes use of the same keys to indicate the IP address(es) of the 326 server referenced in the SvcDomainname field. "ipv4hint" and 327 "ipv6hint" supersede existing glue records for a name but not A or 328 AAAA records in the child. When not present, glue records MAY be 329 used to locate the delegated nameserver. 331 See [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire and 332 display formatting for this SvcParamKey. 334 2.3.3.2. "transports" 336 The "transports" SvcParamKey defines the list of transports offered 337 by the nameserver named in the SvcDomainName. 339 The existing "alpn" SvcParamKey was not reused for NS2 and NS2T due 340 to the restriction that the "alpn" SvcParamValues are limited to 341 those defined in the TLS Application-Layer Protocol Negotiation 342 (ALPN) Protocol IDs registry. Plaintext DNS traffic is not, and 343 should not be listed in that registry, but is required to support the 344 transition to encrypted transport in NS2 and NS2T records. 346 Below is a list of the transport values defined in this document: 348 o "do53": indicates that a server supports plaintext, unencrypted 349 DNS traffic over UDP or UDP as defined in [RFC1035] and [RFC1034] 350 and the updates to those RFCs. 352 o "dot": indicates that the server supports encrypted DNS traffic 353 over DNS-over-TLS as defined in [RFC7858]. 355 o "doh": indicates that the server supports encrypted DNS traffic 356 over DNS-over-HTTPS as defined in [RFC8484]. Records that use the 357 DoH service form may be further redirected with HTTPSSVC records 358 in the delegated zone. 360 o "doq": indicates that the server supports encrypted DNS traffic 361 over DNS over Dedicated QUIC Connections 362 [I-D.draft-huitema-quic-dnsoquic-07] 364 The order of the keys in the list dictate the order which the 365 nameserver SHOULD be contacted in. The client SHOULD compare the 366 order of available transports with the set of transports it supports 367 to determine how to contact the selected nameserver. 369 The presentation format of the SvcParamValue is a comma delimited 370 quoted string of the available transport names. The wire format for 371 the SvcParamValue is a string of 16-bit integers representing the 372 TransportKey values as described in the "NS2/NS2T Transport Parameter 373 Registry". 375 2.3.3.3. "dnsDotEarlyData" 377 The "dnsDotEarlyData" SvcParamKey indicates if the server will accept 378 requests with TLS 1.3 Early Data as described in 379 [I-D.draft-ghedini-dprive-early-data-01]. If the "dot" transport is 380 enabled on the record but this value is not present, the default 381 value is that the server will not accept early data. 383 The presentation format of the SvcParamValue is the string "true" or 384 "false". The wire format of the SvcParamValue is to not have the key 385 present or a single octet with the value of 0x00 when early data is 386 not allowed and a 0x01 value when early data is allowed. All other 387 values should be treated as an error and revert the value to the 388 default of not supported. 390 DRAFT NOTE: Should this be "ns2flags" and just have a 16 bit field 391 for boolean values? 393 2.3.3.4. "dnsDohURITemplate" 395 The "dnsDohURITemplate" SvcParamKey defines the URI template to be 396 used for issuing DNS-over-HTTPS queries to the nameserver defined in 397 the record. The host portion of the "dnsDohURITemplate" value SHOULD 398 match the SvcDomainName field. 400 In the event that the host portion of the "dnsDohURITemplate" 401 SvcParamValues and SvcDomainName field do not match, the 402 SvcDomainName value SHOULD be used for resolving the host and provide 403 host portion of the "dnsDohURITemplate" template SvcParamValue for 404 the TLS ServerNameIndication header and the HTTP Host header. For 405 example, in the below NS2 delegation, the client SHOULD resolve the 406 name ns.example.net and provide the host header and TLS 407 ServerNameIndication header of doh.example.org: 409 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 410 dnsDohURITemplate="https://doh.example.org/q/{?dns}" ) 412 The presentation format of the SvcParamValue is a quoted string. The 413 wire form of the SvcParamValue is an octet string of the URI template 414 as defined in [RFC8484]. 416 2.3.3.5. "esniconfig" 418 The "esnikeys" SvcParamKey is defined in 419 [I-D.draft-ietf-dnsop-svcb-httpssvc-00]. It can be used to provide 420 the ESNI key for DoT, DoH and/or future protocols which may make use 421 of ESNI for session establishment. See 423 [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire, and 424 display formatting for this SvcParamKey. 426 2.3.3.6. "dnsTlsFingerprints" 428 The "dnsTlsFingerprints" SvcParamKey is a list of fingerprints for 429 the TLS certificates that may be presented by the nameserver. This 430 record SHOULD match the TLSA record as described in [RFC6698]. Due 431 to bootstrapping concerns, this SvcParamKey has been added to the NS2 432 record as the TLSA records would only be resolveable after the 433 initial connetion to the delegated nameserver was established. When 434 this field is not present, certificate validation should be performed 435 by either DANE or by traditional TLS certification validation using 436 trusted root certification authorities. 438 The presentation and wire format of the SvcParamValue is the same as 439 the presentation and wire format described for the TLSA record as 440 defined in [RFC6698], sections 2.1 and 2.2 respectively. 442 2.3.3.7. "ds" or "dnskey" 444 The "ds" and "dnskey" SvcParamKey contain a list of hashes of the 445 public key(s) used to sign the zone and the public key(s) for the 446 zone respectively. Unline the DS and DNSKEY RRTypes, the "ds" and 447 "dnskey" SvcParamKey values apply to the referenced resolver only, 448 but the same values may be advertised for all records. For secure 449 delegation, only one of these SvcParamKey is required in the NS2 or 450 NS2T record, but both may be provided. The "ds" and "dnskey" 451 SvcParamKey will supersede any DS or DNSKEY records available in the 452 parent zone, but in the absence of these SvcParamKeys in the NS2 453 record, clients should defer to the DS or DNSKEY records if present. 454 Having these keys in the NS2 record may reduce the number of queries 455 that are required to delegate to the child nameserver, but can result 456 in larger packet sizes. These larger packets could result in UDP 457 fragmentation, forcing clients to upgrade the connection to 458 unencrypted DNS over TCP. 460 Multiple "ds" or "dnskey" SvcParamKeys MAY exist to provide multiple 461 valid public keys for key rollovers or when using multiple signing 462 methods. 464 The wire format of the SvcParamValues is a list of values defined in 465 [RFC4034] for both the SvcParamValue for the "ds" SvcParamKey 466 matching the DS RRType and the SvcParamValue for the "dnskey" 467 SvcParamKey matching the DNSKEY RRType. The presentation format for 468 both records is a quoted string list using the same presentation 469 format defined in [RFC4034] for both records. 471 2.4. Deployment Considerations 473 The NS2 and NS2T records intends to replace the NS record while also 474 adding additional functionality in order to support additional 475 transports for the DNS. Below are discussions of considerations for 476 deployment. 478 2.4.1. AliasForm and ServiceForm in the Parent 480 Both the AliasForm and ServiceForm records MUST NOT be returned for 481 the same record when not in delegated zone. In the case where both 482 are present, the ServiceForm MUST be used and the AliasForm ignored. 484 DRAFT NOTE: This is in direct conflict with SVCB. I'm currently of 485 the opinion that it should stay as it is for reliability reasons. If 486 it is decided that this should contradict SVCB, maybe we should try 487 to change SVCB. 489 2.4.2. Rollout 491 When introduced, the NS2 and NS2T record will likely not be supported 492 by the Root or second level operators, and may not be for some time. 493 In the interim, zone owners may place these records into their zones, 494 both for their own zone and any of their child zones. If a resolver 495 supports alternative transports, it MAY, when delegated to another 496 server, issue a query for NS2 or NS2T records and potentially use 497 those records for further query processing. 499 DRAFT NOTE: Should we include something here that an authoritative 500 MAY include NS2 records in the additionals section of responses to 501 encourage resolvers to upgrade? What about an ECS option from the 502 authority to signal that it is capable of alternat transports? 504 2.4.3. Availability 506 If a zone operator removes all NS records before NS2 and NS2T records 507 are implemented by all clients, the availability of their zones will 508 be impacted for the clients that are using non-supporting resolvers. 509 In some cases, this may be a desired quality, but should be noted by 510 zone owners and operators. 512 2.4.4. Multiple ServiceForm records for the same host or IP address 514 As described in the "transport" SvcParamKey section above, a host or 515 IP address may support multiple different transport methods. This 516 can be represented in two ways. The first is to list all supported 517 transports in the order of diminishing desire in the same record. 518 The second is to use multiple NS2 or NS2T records. 520 When those records have different SvcFieldPriority values, as in 521 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], lower-numbered priorities 522 express a higher preference for that record. 524 In the case where there are identical records other than the "ds" or 525 "dnskey" fields, the records can be combined. In the below example, 526 there are two records that have the same SvcDomainName, 527 SvcFieldPriority, and SvcParamValues (other than "ds"). As a result, 528 the NS2 records here: 530 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 531 dnsTlsFingerprints="MIIS987SSLKJ...123===" ) 532 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 533 dnsTlsFingerprints="MII3SODKSLKJ...456===" ) 534 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 535 dnsDohURITemplate="https://dns.example.org/q/{?dns}" ) 537 are the same as: 539 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 540 dnsTlsFingerprints=["MIIS987SSLKJ...123===", 541 "MII3SODKSLKJ...456==="] ) 542 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 543 dnsDohURITemplate="https://dns.example.org/q/{?dns}" ) 545 3. Responses with NS2 547 NS2 and NS2T are intended to supersede the NS record. When an 548 authoritative nameserver receives a query for a name that it intendes 549 to refer to another server, the nameserver SHOULD be provided NS2 550 records in addition to NS records in the delegation. 552 3.1. Response Size Considerations 554 For latency-conscious zones, the overall packet size of the 555 delegation records from a parent zone to child zone should be taken 556 into account when configuring the NS, NS2 and NS2T records. 557 Resolvers that wish to receive NS2 and NS2T records in response 558 SHOULD advertise and support a buffer size that is as large as 559 possible, ideally 4096 bytes, to allow the authoritative server to 560 respond without truncating whenever possible. 562 3.2. When to include glue 564 Like with NS, when a parent is delegating to a child that is in 565 bailiwick, glue records should be included with responses to enable 566 the client to continue to resolve the names. 568 The ServiceForm version of NS2 returnes sufficent information to the 569 client communicate with the delegated nameserver over a transport 570 other than Do53, but the AliasForm does not. For this reason, the 571 most common use of the AliasForm record would be to alias to a name 572 that is out of bailiwick to the requested zone, which SHOULD be 573 resolveable without relying on the originally queried zone. In the 574 event of an in-bailiwick AliasForm record, the client must either 575 have a pre-agreed upon configuration for the server or attempt 576 opprotunisitic upgrade of the connection to use non-Do53 for the 577 initial setup. 579 4. DNSSEC and NS2 581 When NS2 and NS2T records exist in a zone (parent, child or 582 unrelated) and the zone is signed, the records SHOULD be included in 583 the DNSSEC signing. NS2 and NS2T records for the same label may have 584 different SvcParamValues for the "ds" or "dnskey" SvcParamKeys. 585 Validating resolvers need to carefully track which keying information 586 corresponds to which (zones, resolver) tuple. 588 5. Security Considerations 590 TODO: Fill this section out 592 5.1. Availability of zones without NS 594 5.2. Reflection Attacks 596 5.3. Parsing 598 5.4. Availability 600 5.5. Connetion Failures 602 When a resolver attempts to access nameserver delegated by a NS2 or 603 NST2 record, if a connection error occurs, such as a certificate 604 mismatch or unreachable server, the resolver SHOULD attempt to 605 connect to the other nameservers delegated to until either exhausting 606 the list or the resolver's policy indicates that they should treat 607 the resoltion as failed. 609 The failure action when failing to resolve a name with NS2/NS2T due 610 to connection erros is dependant on the resolver operators policies. 611 For resolvers which strongly favor privacy, the operators may wish to 612 return a SERVFAIL when the NS2/NS2T resoltion process completes 613 without successfully contacting a delegated nameserver(s) while 614 opportunisitic privacy resolvers may wish to attempt resolution using 615 any NS records that may be present. 617 6. IANA Considerations 619 6.1. New registry for NS2 transports 621 The "NS2/NS2T Transport Parameter Registry" defines the namespace for 622 parameters, including string representations and numeric values. 623 This registry applies to the "transports" DNS SVCB format, currently 624 impacting the NS2 RR Type. 626 ACTION: create and include a reference to this registry. 628 6.1.1. Procedure 630 A registration MUST include the following fields: 632 o Name: The transport type key name 634 o TransportKey: A numeric identifier (range 0-65535) 636 o Meaning: a short description 638 o Protocol Specification 640 o Pointer to specification text 642 6.1.2. Initial Contents 644 The "NS2/NS2T Transport Parameter Registry" shall initially be 645 populated with the registrations below: 647 +----------+-------+-----------+--------------------------+---------+ 648 | Transpor | Name | Meaning | Protocol Specification | Referen | 649 | tKey | | | | ce | 650 +----------+-------+-----------+--------------------------+---------+ 651 | 0 | key0 | Reserved | Reserved | (This D | 652 | | | | | ocument | 653 | | | | | ) | 654 | | | | | | 655 | 1 | do53 | Unencrypt | RFC1035 | (This D | 656 | | | ed, | | ocument | 657 | | | Plaintext | | ) | 658 | | | DNS over | | | 659 | | | UDP or | | | 660 | | | TCP | | | 661 | | | | | | 662 | 2 | dot | DNS-over- | RFC7858 | (This D | 663 | | | TLS | | ocument | 664 | | | | | ) | 665 | | | | | | 666 | 3 | doh | DNS-over- | RFC8484 | (This D | 667 | | | HTTPS | | ocument | 668 | | | | | ) | 669 | | | | | | 670 | 4 | doq | DNS over | [I-D.draft-huitema-quic- | | 671 | | | Dedicated | dnsoquic-07] | | 672 | | | QUIC Conn | | | 673 | | | ections | | | 674 | | | | | | 675 | 65280-65 | keyNN | Private | Private Use | (This D | 676 | 534 | NNN | Use | | ocument | 677 | | | | | ) | 678 | | | | | | 679 | 65535 | key65 | Reserved | Reserved | (This D | 680 | | 535 | | | ocument | 681 | | | | | ) | 682 +----------+-------+-----------+--------------------------+---------+ 684 6.2. New SvcParamKey Values 686 This document defines new SvcParamKey values in the "Service Binding 687 (SVCB) Parameter Registry". 689 +-------------+--------------------+---------+-----------------+ 690 | SvcParamKey | NAME | Meaning | Reference | 691 +-------------+--------------------+---------+-----------------+ 692 | TBD1 | transports | | (This Document) | 693 | | | | | 694 | TBD2 | dnsDotEarlyData | | (This Document) | 695 | | | | | 696 | TBD3 | dnsDohURITemplate | | (This Document) | 697 | | | | | 698 | TBD4 | dnsTlsFingerprints | | (This Document) | 699 | | | | | 700 | TBD5 | ds | | (This Document) | 701 | | | | | 702 | TBD6 | dnskey | | (This Document) | 703 +-------------+--------------------+---------+-----------------+ 705 7. Informative References 707 [I-D.draft-ghedini-dprive-early-data-01] 708 Ghedini, A., "Using Early Data in DNS over TLS", draft- 709 ghedini-dprive-early-data-01 (work in progress), July 710 2019. 712 [I-D.draft-huitema-quic-dnsoquic-07] 713 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 714 Iyengar, "Specification of DNS over Dedicated QUIC 715 Connections", draft-huitema-quic-dnsoquic-07 (work in 716 progress), September 2019. 718 [I-D.draft-ietf-dnsop-svcb-httpssvc-00] 719 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 720 and parameter specification via the DNS (DNS SVCB and 721 HTTPSSVC)", draft-ietf-dnsop-svcb-httpssvc-00 (work in 722 progress), October 2019. 724 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 725 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 726 . 728 [RFC1035] Mockapetris, P., "Domain names - implementation and 729 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 730 November 1987, . 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, 734 DOI 10.17487/RFC2119, March 1997, 735 . 737 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 738 Rose, "Resource Records for the DNS Security Extensions", 739 RFC 4034, DOI 10.17487/RFC4034, March 2005, 740 . 742 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 743 of Named Entities (DANE) Transport Layer Security (TLS) 744 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 745 2012, . 747 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 748 and P. Hoffman, "Specification for DNS over Transport 749 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 750 2016, . 752 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 753 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 754 May 2017, . 756 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 757 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 758 . 760 Appendix A. Acknowledgements 762 Thank you to Erik Nygren, Ralf Weber, Jon Reed, Ben Kaduk, Mashooq 763 Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, Gordon Marx 764 and Brian Wellington for their comments and suggestions on this 765 draft. 767 Appendix B. TODO 769 RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION. 771 o Discussion about TTLs and what they should be and how that might 772 impact performance 774 o Discuss the cacheability of the Alias form records. 776 o Remove all "DRAFT NOTES:" in the document. 778 o Write a security considerations section 780 o add prohibition of AliasForm referring to AliasForm 782 o add out-of-bailiwick requirement for AliasForm 784 o worked out resolution example including alias form delegation 785 o DoH URI teamplte does not include post 787 o If NS2 is authoritative in the parent, does that mean that it will 788 not be a referral anymore? Probably a question for the working 789 group 791 Appendix C. Change Log 793 RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION. 795 pre-00 797 o Initial draft. 799 o Wire and Presentation formats for all new SvcParamKeys and 800 SvcParamValues 802 o IANA considerations first pass 804 o Added a section about SvcFieldPriority 806 o Added the "ds" and "dnskey" SvcParamKey options to support the 807 deprecation of the DS in the parent. 809 o Added notes on DNSSEC signing of NS2 811 o Removed multi-provider sharding example, with performance 812 measurements the distribution probably wouldn't work 814 o Reworked the introduction to try and make it easier to parse 816 o Removed the port fields for each transport option 818 o Added a discussion about when to include NS2 records. 820 o Add an example early in the draft. Introduction area 822 o Add section about port numbers discussion 824 o collapse udp and tcp to the do53 826 o added a second record (NS2 and NS2T) 828 Appendix D. Discussions 830 Editor Note: Remove this full section before publication. 832 D.1. Port Numbers 834 Originally, I had added SvcParamKeys for port numbers for each of the 835 protocols. There was a discussion that resulted in removing the port 836 numbers, since it was added complexity that had little perceived use 837 in the wild. These can be added back if there is a desire to have 838 them. The original author included them as a way to provide the 839 nameserver operator a way to differentiate incoming traffic when 840 using the aliasform with lower TTLs and intelligent responses based 841 on the client IP. 843 D.2. Second Record Name 845 Selected NS2T for Nameserver 2 Target since the record defines the 846 target authoritative servers. 848 ~~~ 01234567890123456789012345678901234567890123456789012345678901234 849 5678912 851 Author's Address 853 Tim April 854 Akamai Technologies 856 Email: ietf@tapril.net