idnits 2.17.1 draft-tapril-ns2-01.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 (13 July 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-00 == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-svcb-httpssvc-00 == Outdated reference: A later version (-02) exists of draft-ghedini-dprive-early-data-01 -- Duplicate reference: draft-huitema-quic-dnsoquic, mentioned in 'DOQ-I-D', was also mentioned in 'I-D.draft-huitema-quic-dnsoquic-07'. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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 13 July 2020 5 Expires: 14 January 2021 7 Parameterized Nameserver Delegation with NS2 and NS2T 8 draft-tapril-ns2-01 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, transport 15 signaling would be required to negotiate how authoritative servers 16 would be contacted by resolvers. This document provides two new 17 Resource Record Types, NS2 and NS2T, to facilitate this negotiation 18 by allowing zone owners to signal how the authoritative nameserver(s) 19 for their zone(s) may accept queries. 21 Discussion Venues 23 This note is to be removed before publishing as an RFC. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/timapril/ns2 (https://github.com/timapril/ns2). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 14 January 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Introductory Examples . . . . . . . . . . . . . . . . . . 3 63 1.2. Goal of the NS2 and NS2T Records . . . . . . . . . . . . 4 64 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. NS2 and NS2T Record Types . . . . . . . . . . . . . . . . . . 5 66 2.1. Difference between the records . . . . . . . . . . . . . 5 67 2.2. AliasForm Record Type . . . . . . . . . . . . . . . . . . 6 68 2.2.1. Multiple Service Providers . . . . . . . . . . . . . 6 69 2.2.2. Loop Prevention . . . . . . . . . . . . . . . . . . . 7 70 2.3. ServiceForm Record Type . . . . . . . . . . . . . . . . . 7 71 2.3.1. SvcFieldPriority . . . . . . . . . . . . . . . . . . 7 72 2.3.2. SvcDomainName . . . . . . . . . . . . . . . . . . . . 7 73 2.3.3. SvcParamKeys . . . . . . . . . . . . . . . . . . . . 8 74 2.4. Deployment Considerations . . . . . . . . . . . . . . . . 10 75 2.4.1. AliasForm and ServiceForm in the Parent . . . . . . . 10 76 2.4.2. Rollout . . . . . . . . . . . . . . . . . . . . . . . 11 77 2.4.3. Availability . . . . . . . . . . . . . . . . . . . . 11 78 2.4.4. Multiple ServiceForm records for the same host or IP 79 address . . . . . . . . . . . . . . . . . . . . . . . 11 80 3. Responses with NS2 . . . . . . . . . . . . . . . . . . . . . 12 81 3.1. Response Size Considerations . . . . . . . . . . . . . . 12 82 3.2. When to include glue . . . . . . . . . . . . . . . . . . 13 83 4. DNSSEC and NS2 . . . . . . . . . . . . . . . . . . . . . . . 13 84 5. Privact Considerations . . . . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 6.1. Availability of zones without NS . . . . . . . . . . . . 13 87 6.2. Reflection Attacks . . . . . . . . . . . . . . . . . . . 13 88 6.3. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.4. Availability . . . . . . . . . . . . . . . . . . . . . . 14 90 6.5. Connetion Failures . . . . . . . . . . . . . . . . . . . 14 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 7.1. New registry for NS2 transports . . . . . . . . . . . . . 14 93 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 14 94 7.1.2. Initial Contents . . . . . . . . . . . . . . . . . . 14 95 7.2. New SvcParamKey Values . . . . . . . . . . . . . . . . . 15 96 8. Informative References . . . . . . . . . . . . . . . . . . . 16 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 98 Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 17 99 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 18 100 Appendix D. Discussions . . . . . . . . . . . . . . . . . . . . 19 101 D.1. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 19 102 D.2. CNS2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 D.3. Second Record Name . . . . . . . . . . . . . . . . . . . 20 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 Resolvers currently rely on the NS records in the parent and child 109 zones to provide and confirm the nameservers that are authoritative 110 for each zone. The Nameserver version 2 (NS2) record extends the 111 functionality of the NS record to include additional information 112 about how authoritative zone information can be queried, whether that 113 be over alternate protocols or by using alternate protocol 114 parameters. The NS2 record may be present at zone cuts but can also 115 redirect resolvers to other nameservers for further redirection via 116 the Nameserver Version 2 Target (NS2T) record, which does not 117 indicate a zone cut. 119 The NS2 and NS2T records uses the SVCB record format defined in 120 [I-D.draft-ietf-dnsop-svcb-https-00], using a subset of the already 121 defined service parameters as well as new parameters described in 122 this document. Some, but not all, of the existing service parameters 123 will also be available for NS2 and NS2T records. This document will 124 outline the available parameters and their usage. 126 1.1. Introductory Examples 128 To introduce the NS2 and NS2T records, this example shows a possible 129 response from an authoritative in the authority section of the DNS 130 response when delegating to another nameserver. 132 example.com. 86400 IN NS2 2 ns2.example.com. ( transports=dot, 133 dnsTlsFingerprints=["MIIS987SSLKJ...123===", 134 "MII3SODKSLKJ...456==="] ) 135 example.com. 86400 IN NS2 3 ns3.example.com. ( transports=doh, 136 dnsDohURITemplate="https://ns.example.net/q/{?dns}" ) 137 example.com. 86400 IN NS ns1.example.com. 138 ns1.example.com. 86400 IN NS 192.0.2.1 139 ns2.example.com. 86400 IN NS 192.0.2.2 140 ns3.example.com. 86400 IN NS 192.0.2.3 141 In this example, the authoritative nameserver is delegating to both a 142 DNS-over-TLS and DNS-over-HTTPS service running on ns2.example.net 143 and ns3.example.com respectively, for resolvers that support NS2, and 144 also delegating to ns1.example.com which will serve unencrypted DNS 145 over port 53 for those that do not. 147 Like in SVCB, NS2 and NS2T also offer the ability to use the Alias 148 form delegation. The example below shows an example where 149 example.com is being delegated with a NS2 AliasForm record which can 150 then be further resolved to locate the authroitative nameserver(s). 152 example.com. 86400 IN NS2 0 ns2.example.net. 153 example.com. 86400 IN NS ns1.example.com. 154 ns1.example.com. 86400 IN NS 192.0.2.1 156 The example.net authoritative server may return the following NS2T 157 records in response to a query as deirected by the above records. 159 ns2.example.net 3600 IN NS2T ns2.example.org. ( transports=dot, 160 dnsTlsFingerprints=["MIIS987SSLKJ...123==="] ) 161 ns2.example.net 3600 IN NS2T ns3.example.org. ( transports=doh, 162 ddnsDohURITemplate="https://ns.example.net/q/{?dns}") 164 The avbove records indicate to the client that the authoritative 165 nameservers for zones that Alias to ns2.example.net are 166 ns1.example.org and ns2.example.rg with the configuration provided. 168 Later sections of this document will go into more detail on the 169 resolution process using these records. 171 1.2. Goal of the NS2 and NS2T Records 173 The primary goal of the NS2 and NS2T records is to provide zone 174 owners a way to signal to clients how they may receive queries for 175 the records for which they are authoritative. The NS2 and NS2T 176 records are machine readable, can coexist with NS records in the same 177 zone, and do not break software that does not support them. 179 NS2 and NS2T are designed to allow child zones to publish NS2 and 180 NS2T records, even without support in the parent zone. Lack of 181 parent zone support for NS2 records may arise for technical or policy 182 reasons. 184 1.3. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119] [RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 2. NS2 and NS2T Record Types 194 The SVCB record allows for two types of records, the AliasForm and 195 the ServiceForm. The NS2 record takes advantage of both and each 196 will be described below in depth. 198 2.1. Difference between the records 200 This document introduces two different resource record types. Both 201 records have the same functionality, with the difference between them 202 being that the NS2 record MUST only be used at a delegation point 203 while the NS2T, is NS2 Target, record does not indicate that the 204 label is being delegated. For example, take the following NS2 205 record: 207 example.com. 86400 IN NS2 1 ns2.example.net. ( transports=dot ) 209 When a client receives the above record, the resolver should send 210 queries for any name under example.com to the nameserver at 211 ns2.example.com unless further delegated. By contrast, when 212 presented with the records below: 214 example.com. 86400 IN NS2 0 customer.example.org. 215 customer.example.org. 86400 IN NS2T 1 ns2.example.net. ( transports=dot ) 217 A resolver trying to resolve a name under example.com would get the 218 first record above from the parent authoritative server, .COM, 219 indicating that the NS2T records found at customer.example.org should 220 be used to locate the authoritative nameservers of example.com. The 221 second record above dictates that the authoritative nameserver from 222 records that have aliased to customer.example.org is ns2.example.net, 223 which only accepts queries over DNS-over-TLS. The primary difference 224 between the two records is that the NS2 record means that anything 225 under the record label should be queried at the delegated server 226 while the NS2T record is just for redirection purposes, and any names 227 under the record's label should still be resolved using the same 228 server unless otherwise delegated. 230 It should be noted that both NS2 and NS2T records may exist for the 231 same label. Below is an example of this: 233 example.com. 86400 IN NS2 0 c1.example.org. 234 c1.example.org. 86400 IN NS2T 1 ns2.example.net. ( transports=dot ) 235 c1.example.org. 86400 IN NS2 1 ns3.example.net. ( transports=dot ) 236 test.c1.example.org. 600 IN A 192.0.2.1 238 In the above case, the NS2 record for c1.example.org would only be 239 used when trying to resolve names below c1.example.org. This reason 240 is why when an AliasForm NS2 or NS2T record is encountered, the 241 resolver MUST query for the NS2T record associated with the given 242 name. 244 Since the NS2 record is indicative of a zone cut while NS2T is not, 245 names MUST NOT have but NS2 and NS2T records at the same time. 247 2.2. AliasForm Record Type 249 In order to take full advantage of the AliasForm of NS2 and NS2T, the 250 parent, child and resolver must support these records. When 251 supported, the use of the AliasForm will allow zone owners to 252 delegate their zones to another operator with a single record in the 253 parent. AliasForm NS2 records SHOULD appear in the child zone when 254 used in the parent. If a resolver were to encounter an AliasForm NS2 255 or NS2T record, it would then resolve the name in the SvcDomainName 256 of the original record using NS2T RR type to receive the either 257 another AliasForm record or a ServiceForm NS2T record. 259 For example, if the name www.example.com was being resolved, the .com 260 zone may issue a referral by returning the following record: 262 example.com. 86400 IN NS2 0 customer1.example.net. 264 The above record would indicate to the resolver that in order to 265 obtain the authoritative nameserver records for example.com, the 266 resolver should resolve the RR type NS2T for the name 267 customer1.example.net. 269 2.2.1. Multiple Service Providers 271 Some zone owners may wish to use multiple providers to serve their 272 zone, in which case multiple NS2 AliasForm records can be used. In 273 the event that multiple NS2 AliasForm records are encountered, the 274 resolver SHOULD pick one of the records at random. For example, to 275 split traffic between two providers, the zone owner for example.com 276 could have the following NS2 records: 278 example.com. 86400 IN NS2 0 customer1.example.net. 279 example.com. 86400 IN NS2 0 customer1.example.org. 281 DRAFT NOTE: SVCB says that there "SHOULD only have a single RR". 282 This ignores that but keep the randomization part. Section 2.5p1 of 283 SVCB 285 2.2.2. Loop Prevention 287 Special care should be taken by both the zone owner and the delegated 288 zone operator to ensure that a lookup loop is not created by having 289 two AliasForm records rely on each other to serve the zone. Doing so 290 may result in a resolution loop, and likely a denial of service. Any 291 clients implementing NS2 and NS2T SHOULD implement a per-resolution 292 limit of how many AliasForm records may be traversed when looking up 293 a delegation to prevent infinite looping. When a loop is detected, 294 like with the handling of CNAME or NS, the server should respond to 295 the client with SERVFAIL. 297 2.3. ServiceForm Record Type 299 The ServiceForm of the NS2 and NS2T records are likely to be the more 300 popular of the two. They work the same way as the SVCB or HTTPSSVC 301 records do by providing a priority and list of parameters associated 302 with the SvcDomainName. In addition to being able to identify which 303 protocols are supported by the authoriatative server, the ServiceForm 304 record will also allow providers to operate different protocols on 305 different addresses. 307 2.3.1. SvcFieldPriority 309 As defined in the DNS SVCB document 310 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcFieldPriority values 311 SHOULD be used to dictate the priority when multiple NS2 or NS2T 312 records are returned. 314 2.3.2. SvcDomainName 316 As defined in the SVCB document 317 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], the SvcDomainName provides 318 the hostname to which the NS2 or NS2T record refers. The wire format 319 must be the a-label format of the name. When presented, the u-label 320 may be presented, but the the a-label should also be displayed 321 displaying the u-label. The SvcDomainName field MUST be set and MUST 322 NOT be "." for NS2 records. Records with a SvcDomainName of "." 323 SHOULD be discarded. 325 DRAFT NOTE: Should u-label and a-label be expanded? I'm leaning 326 towards not expanding. 328 2.3.3. SvcParamKeys 330 The following DNS SVCB parameters are defined for the NS2 and NS2T 331 ServiceForms. 333 2.3.3.1. "transports" 335 The "transports" SvcParamKey defines the list of transports offered 336 by the nameserver named in the SvcDomainName. 338 The existing "alpn" SvcParamKey was not reused for NS2 and NS2T due 339 to the restriction that the "alpn" SvcParamValues are limited to 340 those defined in the TLS Application-Layer Protocol Negotiation 341 (ALPN) Protocol IDs registry. Plaintext DNS traffic is not, and 342 should not be listed in that registry, but is required to support the 343 transition to encrypted transport in NS2 and NS2T records. 345 Below is a list of the transport values defined in this document: 347 * "do53": indicates that a server supports plaintext, unencrypted 348 DNS traffic over UDP or UDP as defined in [RFC1035] and [RFC1034] 349 and the updates to those RFCs. 351 * "dot": indicates that the server supports encrypted DNS traffic 352 over DNS-over-TLS as defined in [RFC7858]. 354 * "doh": indicates that the server supports encrypted DNS traffic 355 over DNS-over-HTTPS as defined in [RFC8484]. Records that use the 356 DoH service form may be further redirected with HTTPSSVC records 357 in the delegated zone. 359 * "doq": indicates that the server supports encrypted DNS traffic 360 over DNS over Dedicated QUIC Connections 361 [I-D.draft-huitema-quic-dnsoquic-07] 363 The order of the keys in the list dictate the order which the 364 nameserver SHOULD be contacted in. The client SHOULD compare the 365 order of available transports with the set of transports it supports 366 to determine how to contact the selected nameserver. 368 The presentation format of the SvcParamValue is a comma delimited 369 quoted string of the available transport names. The wire format for 370 the SvcParamValue is a string of 16-bit integers representing the 371 TransportKey values as described in the "NS2/NS2T Transport Parameter 372 Registry". 374 2.3.3.2. "dnsDotEarlyData" 376 The "dnsDotEarlyData" SvcParamKey indicates if the server will accept 377 requests with TLS 1.3 Early Data as described in 378 [I-D.draft-ghedini-dprive-early-data-01]. If the "dot" transport is 379 enabled on the record but this value is not present, the default 380 value is that the server will not accept early data. 382 The presentation format of the SvcParamValue is the string "true" or 383 "false". The wire format of the SvcParamValue is to not have the key 384 present or a single octet with the value of 0x00 when early data is 385 not allowed and a 0x01 value when early data is allowed. All other 386 values should be treated as an error and revert the value to the 387 default of not supported. 389 DRAFT NOTE: Should this be "ns2flags" and just have a 16 bit field 390 for boolean values? 392 2.3.3.3. "dnsDohURITemplate" 394 The "dnsDohURITemplate" SvcParamKey defines the URI template to be 395 used for issuing DNS-over-HTTPS queries to the nameserver defined in 396 the record. The host portion of the "dnsDohURITemplate" value SHOULD 397 match the SvcDomainName field. 399 In the event that the host portion of the "dnsDohURITemplate" 400 SvcParamValues and SvcDomainName field do not match, the 401 SvcDomainName value SHOULD be used for resolving the host and provide 402 host portion of the "dnsDohURITemplate" template SvcParamValue for 403 the TLS ServerNameIndication header and the HTTP Host header. For 404 example, in the below NS2 delegation, the client SHOULD resolve the 405 name ns.example.net and provide the host header and TLS 406 ServerNameIndication header of doh.example.org: 408 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 409 dnsDohURITemplate="https://doh.example.org/q/{?dns}" ) 411 The presentation format of the SvcParamValue is a quoted string. The 412 wire form of the SvcParamValue is an octet string of the URI template 413 as defined in [RFC8484]. 415 2.3.3.4. "esniconfig" 417 The "esnikeys" SvcParamKey is defined in 418 [I-D.draft-ietf-dnsop-svcb-httpssvc-00]. It can be used to provide 419 the ESNI key for DoT, DoH and/or future protocols which may make use 420 of ESNI for session establishment. See 421 [I-D.draft-ietf-dnsop-svcb-httpssvc-00] for the usage, wire, and 422 display formatting for this SvcParamKey. 424 2.3.3.5. "dnsTlsFingerprints" 426 The "dnsTlsFingerprints" SvcParamKey is a list of fingerprints for 427 the TLS certificates that may be presented by the nameserver. This 428 record SHOULD match the TLSA record as described in [RFC6698]. Due 429 to bootstrapping concerns, this SvcParamKey has been added to the NS2 430 record as the TLSA records would only be resolveable after the 431 initial connetion to the delegated nameserver was established. When 432 this field is not present, certificate validation should be performed 433 by either DANE or by traditional TLS certification validation using 434 trusted root certification authorities. 436 The presentation and wire format of the SvcParamValue is the same as 437 the presentation and wire format described for the TLSA record as 438 defined in [RFC6698], sections 2.1 and 2.2 respectively. 440 2.4. Deployment Considerations 442 The NS2 and NS2T records intends to replace the NS record while also 443 adding additional functionality in order to support additional 444 transports for the DNS. Below are discussions of considerations for 445 deployment. 447 2.4.1. AliasForm and ServiceForm in the Parent 449 Both the AliasForm and ServiceForm records MUST NOT be returned for 450 the same record when not in delegated zone. In the case where both 451 are present, the ServiceForm MUST be used and the AliasForm ignored. 453 DRAFT NOTE: This is in direct conflict with SVCB. I'm currently of 454 the opinion that it should stay as it is for reliability reasons. If 455 it is decided that this should contradict SVCB, maybe we should try 456 to change SVCB. 458 2.4.2. Rollout 460 When introduced, the NS2 and NS2T record will likely not be supported 461 by the Root or second level operators, and may not be for some time. 462 In the interim, zone owners may place these records into their zones, 463 both for their own zone and any of their child zones. If a resolver 464 supports alternative transports, it MAY, when delegated to another 465 server, issue a query for NS2 or NS2T records and potentially use 466 those records for further query processing. 468 DRAFT NOTE: Should we include something here that an authoritative 469 MAY include NS2 records in the additionals section of responses to 470 encourage resolvers to upgrade? What about an ECS option from the 471 authority to signal that it is capable of alternat transports? 473 2.4.3. Availability 475 If a zone operator removes all NS records before NS2 and NS2T records 476 are implemented by all clients, the availability of their zones will 477 be impacted for the clients that are using non-supporting resolvers. 478 In some cases, this may be a desired quality, but should be noted by 479 zone owners and operators. 481 2.4.4. Multiple ServiceForm records for the same host or IP address 483 As described in the "transport" SvcParamKey section above, a host or 484 IP address may support multiple different transport methods. This 485 can be represented in two ways. The first is to list all supported 486 transports in the order of diminishing desire in the same record. 487 The second is to use multiple NS2 or NS2T records. 489 When those records have different SvcFieldPriority values, as in 490 [I-D.draft-ietf-dnsop-svcb-httpssvc-00], lower-numbered priorities 491 express a higher preference for that record. 493 NS2 and NS2T records may have multiple values for the 494 "dnsTlsFingerprints" SvcParamKey. Records that are identical other 495 than the "dnsTlsFingerprints" SvcParamValues may be joined together 496 including multiple "dnsTlsFingerprints" as seen in this example: 498 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 499 dnsTlsFingerprints="MIIS987SSLKJ...123===" ) 500 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 501 dnsTlsFingerprints="MII3SODKSLKJ...456===" ) 502 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 503 dnsDohURITemplate="https://dns.example.org/q/{?dns}" ) 505 are the same as: 507 example.com. 86400 IN NS2 2 ns.example.net. ( transports=dot, 508 dnsTlsFingerprints=["MIIS987SSLKJ...123===", 509 "MII3SODKSLKJ...456==="] ) 510 example.com. 86400 IN NS2 3 ns.example.net. ( transports=doh, 511 dnsDohURITemplate="https://dns.example.org/q/{?dns}" ) 513 3. Responses with NS2 515 The NS2 and NS2T records are intended to supersede the NS record. As 516 such, the NS2 records should be included in the response in the 517 following situations, assuming the records exist in the servers zone: 519 1) If the qtype is for NS2 or NS2T, the server should respond with 520 NS2 or NS2T respectively in the authority section of the response. 522 2) For queries over unencrypted TCP port 53, any of the NS2 and NS2T 523 records SHOULD be included in the additional section of the response. 525 3) For queries over unencrypted UDP port 53, any of the NS2 and NS2T 526 records SHOULD be included in the additional section of the response 527 unless doing so would result in a truncated response. For responses 528 that would require truncation, the resolver operator and/or 529 implementor may decide to truncate the response or exclude the 530 records from the response. 532 4) If encrypted transports are supported on the authority, the any 533 NS2 and NS2T records should be included in the authority section of 534 the respose. 536 DRAFT NOTE: It is unknown how resolvers will handle multiple 537 authoritative RRTypes in the authority section of the response, 538 leaving 2 and 3 as the additional section until either testing is 539 done or a consensus is determined in DNSOP/DPRIVE. 541 DRAFT NOTE: Suggesting authority for encrypted transport since it 542 would more closely align with the NS record. 544 3.1. Response Size Considerations 546 For latency-conscious zones, the overall packet size of the 547 delegation records from a parent zone to child zone should be taken 548 into account when configuring the NS, NS2 and NS2T records. 549 Resolvers that wish to receive NS2 and NS2T records in response 550 SHOULD advertise and support a buffer size that is as large as 551 possible, ideally 4096 bytes, to allow the authoritative server to 552 respond without truncating whenever possible. 554 3.2. When to include glue 556 Like with NS, when a parent is delegating to a child that is in 557 bailiwick, glue records should be included with responses to enable 558 the client to continue to resolve the names. 560 The ServiceForm version of NS2 returnes sufficent information to the 561 client communicate with the delegated nameserver over a transport 562 other than Do53, but the AliasForm does not. For this reason, the 563 most common use of the AliasForm record would be to alias to a name 564 that is out of bailiwick to the requested zone, which SHOULD be 565 resolveable without relying on the originally queried zone. In the 566 event of an in-bailiwick AliasForm record, the client must either 567 have a pre-agreed upon configuration for the server or attempt 568 opprotunisitic upgrade of the connection to use non-Do53 for the 569 initial setup. 571 4. DNSSEC and NS2 573 Like with NS records, the NS2 records in the child zone SHOULD be 574 signed when the zone is DNSSEC signed. The NS2 records that appear 575 in the parent zone are glue and would not be signed, as is the case 576 with NS records. 578 NS2T records, SHOULD be signed in a zone which is signed by DNSSEC. 580 5. Privact Considerations 582 All of the information handled or transmitted by this protocol is 583 public information published in the DNS. 585 While the records are transmitting public infomration, resolvers 586 which are making use of records may be attemping to keep the 587 information they are querying private from on-path observers. 588 Privacy consious resolvers should query for this record at the apex 589 of a zone when delegated from the parent to help establish an 590 encrypted channel to the authority. 592 6. Security Considerations 594 TODO: Fill this section out 596 6.1. Availability of zones without NS 598 6.2. Reflection Attacks 600 6.3. Parsing 601 6.4. Availability 603 6.5. Connetion Failures 605 When a resolver attempts to access nameserver delegated by a NS2 or 606 NST2 record, if a connection error occurs, such as a certificate 607 mismatch or unreachable server, the resolver SHOULD attempt to 608 connect to the other nameservers delegated to until either exhausting 609 the list or the resolver's policy indicates that they should treat 610 the resoltion as failed. 612 The failure action when failing to resolve a name with NS2/NS2T due 613 to connection erros is dependant on the resolver operators policies. 614 For resolvers which strongly favor privacy, the operators may wish to 615 return a SERVFAIL when the NS2/NS2T resoltion process completes 616 without successfully contacting a delegated nameserver(s) while 617 opportunisitic privacy resolvers may wish to attempt resolution using 618 any NS records that may be present. 620 7. IANA Considerations 622 7.1. New registry for NS2 transports 624 The "NS2/NS2T Transport Parameter Registry" defines the namespace for 625 parameters, including string representations and numeric values. 626 This registry applies to the "transports" DNS SVCB format, currently 627 impacting the NS2 RR Type. 629 ACTION: create and include a reference to this registry. 631 7.1.1. Procedure 633 A registration MUST include the following fields: 635 * Name: The transport type key name 637 * TransportKey: A numeric identifier (range 0-65535) 639 * Meaning: a short description 641 * Protocol Specification 643 * Pointer to specification text 645 7.1.2. Initial Contents 647 The "NS2/NS2T Transport Parameter Registry" shall initially be 648 populated with the registrations below: 650 +==============+========+================+===============+==========+ 651 | TransportKey | Name | Meaning | Protocol |Reference | 652 | | | | Specification | | 653 +==============+========+================+===============+==========+ 654 | 0 | key0 | Reserved | Reserved | (This | 655 | | | | |Document) | 656 +--------------+--------+----------------+---------------+----------+ 657 | 1 | do53 | Unencrypted, | RFC1035 | (This | 658 | | | Plaintext DNS | |Document) | 659 | | |over UDP or TCP | | | 660 +--------------+--------+----------------+---------------+----------+ 661 | 2 | dot | DNS-over-TLS | RFC7858 | (This | 662 | | | | |Document) | 663 +--------------+--------+----------------+---------------+----------+ 664 | 3 | doh | DNS-over-HTTPS | RFC8484 | (This | 665 | | | | |Document) | 666 +--------------+--------+----------------+---------------+----------+ 667 | 4 | doq | DNS over | [DOQ-I-D] | | 668 | | | Dedicated QUIC | | | 669 | | | Connections | | | 670 +--------------+--------+----------------+---------------+----------+ 671 | 65280-65534 |keyNNNNN| Private Use | Private Use | (This | 672 | | | | |Document) | 673 +--------------+--------+----------------+---------------+----------+ 674 | 65535 |key65535| Reserved | Reserved | (This | 675 | | | | |Document) | 676 +--------------+--------+----------------+---------------+----------+ 678 Table 1 680 7.2. New SvcParamKey Values 682 This document defines new SvcParamKey values in the "Service Binding 683 (SVCB) Parameter Registry". 685 +=============+====================+=========+=================+ 686 | SvcParamKey | NAME | Meaning | Reference | 687 +=============+====================+=========+=================+ 688 | TBD1 | transports | | (This Document) | 689 +-------------+--------------------+---------+-----------------+ 690 | TBD2 | dnsDotEarlyData | | (This Document) | 691 +-------------+--------------------+---------+-----------------+ 692 | TBD3 | dnsDohURITemplate | | (This Document) | 693 +-------------+--------------------+---------+-----------------+ 694 | TBD4 | dnsTlsFingerprints | | (This Document) | 695 +-------------+--------------------+---------+-----------------+ 697 Table 2 699 8. Informative References 701 [I-D.draft-ietf-dnsop-svcb-https-00] 702 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 703 and parameter specification via the DNS (DNS SVCB and 704 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 705 dnsop-svcb-https-00, 12 June 2020, . 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 714 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 715 May 2017, . 717 [I-D.draft-ietf-dnsop-svcb-httpssvc-00] 718 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 719 and parameter specification via the DNS (DNS SVCB and 720 HTTPSSVC)", Work in Progress, Internet-Draft, draft-ietf- 721 dnsop-svcb-httpssvc-00, 31 October 2019, 722 . 725 [RFC1035] Mockapetris, P.V., "Domain names - implementation and 726 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 727 November 1987, . 729 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 730 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 731 November 1987, . 733 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 734 and P. Hoffman, "Specification for DNS over Transport 735 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 736 2016, . 738 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 739 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 740 . 742 [I-D.draft-huitema-quic-dnsoquic-07] 743 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 744 Iyengar, "Specification of DNS over Dedicated QUIC 745 Connections", Work in Progress, Internet-Draft, draft- 746 huitema-quic-dnsoquic-07, 7 September 2019, 747 . 750 [I-D.draft-ghedini-dprive-early-data-01] 751 Ghedini, A., "Using Early Data in DNS over TLS", Work in 752 Progress, Internet-Draft, draft-ghedini-dprive-early-data- 753 01, 6 July 2019, . 756 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 757 of Named Entities (DANE) Transport Layer Security (TLS) 758 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 759 2012, . 761 [DOQ-I-D] Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 762 Iyengar, "Specification of DNS over Dedicated QUIC 763 Connections", Work in Progress, Internet-Draft, draft- 764 huitema-quic-dnsoquic-07, 7 September 2019, 765 . 768 Appendix A. Acknowledgements 770 Thank you to John Levine, Erik Nygren, Ralf Weber, Jon Reed, Ben 771 Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, 772 Gordon Marx and Brian Wellington for their comments and suggestions 773 on this draft. 775 Appendix B. TODO 777 RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION. 779 * Discussion about TTLs and what they should be and how that might 780 impact performance 782 * Discuss the cacheability of the Alias form records. 784 * Remove all "DRAFT NOTES:" in the document. 786 * Write a security considerations section 788 * add prohibition of AliasForm referring to AliasForm 789 * add out-of-bailiwick requirement for AliasForm 791 * worked out resolution example including alias form delegation 793 * DoH URI teamplte does not include post 795 * If NS2 is authoritative in the parent, does that mean that it will 796 not be a referral anymore? Probably a question for the working 797 group 799 Appendix C. Change Log 801 RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION. 803 pre-00 805 * Initial draft. 807 * Wire and Presentation formats for all new SvcParamKeys and 808 SvcParamValues 810 * IANA considerations first pass 812 * Added a section about SvcFieldPriority 814 * Added the "ds" and "dnskey" SvcParamKey options to support the 815 deprecation of the DS in the parent. 817 * Added notes on DNSSEC signing of NS2 819 * Removed multi-provider sharding example, with performance 820 measurements the distribution probably wouldn't work 822 * Reworked the introduction to try and make it easier to parse 824 * Removed the port fields for each transport option 826 * Added a discussion about when to include NS2 records. 828 * Add an example early in the draft. Introduction area 830 * Add section about port numbers discussion 832 * collapse udp and tcp to the do53 834 * added a second record (NS2 and NS2T) 836 -01 837 * Removed DS and DNSKEY SvcParamFields. Avoids issues with DNSSEC 838 signing in the parent. 840 * Removed IPv{4,6}Hints SvcParamFields. There was a discussion on 841 DNSOP about how glue is required 843 * Updating when to sign the NS2 / NS2T records (removed signing in 844 the parent) 846 * Attempting to clean up the introduction, goals and motivations of 847 the document 849 * Adding a privacy considerations section 851 * Adding more clairty around when to include/expect the NS2/NS2T 852 records 854 * Adding this note that CNS2 will not be included in this draft 856 * Prohibiting NS2 and NS2T from existing at the same name 858 * Making the statement about the parent records being glue and 859 should not be signed 861 Appendix D. Discussions 863 Editor Note: Remove this full section before publication. 865 D.1. Port Numbers 867 Originally, I had added SvcParamKeys for port numbers for each of the 868 protocols. There was a discussion that resulted in removing the port 869 numbers, since it was added complexity that had little perceived use 870 in the wild. These can be added back if there is a desire to have 871 them. The original author included them as a way to provide the 872 nameserver operator a way to differentiate incoming traffic when 873 using the aliasform with lower TTLs and intelligent responses based 874 on the client IP. 876 D.2. CNS2 878 Client NS2, similar to CDS might be a way to provide support for 879 getting NS2 records into the parent zone before going through the 880 registrars, but that might be a tough thing to agree on at this 881 point. 883 D.3. Second Record Name 885 Selected NS2T for Nameserver 2 Target since the record defines the 886 target authoritative servers. 888 ~~~ 01234567890123456789012345678901234567890123456789012345678901234 889 567891 891 Author's Address 893 Tim April 894 Akamai Technologies 896 Email: ietf@tapril.net