idnits 2.17.1 draft-dickson-dprive-adot-auth-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.dickson-dnsop-ds-hack]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 76 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 November 2021) is 892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8198' is defined on line 712, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Dickson 3 Internet-Draft GoDaddy 4 Intended status: Informational 9 November 2021 5 Expires: 13 May 2022 7 Authenticated DNS over TLS to Authoritative Servers 8 draft-dickson-dprive-adot-auth-06 10 Abstract 12 This Internet Draft proposes a mechanism for DNS resolvers to 13 discover support for TLS transport to authoritative DNS servers, to 14 validate this indication of support, and to authenticate the TLS 15 certificates involved. 17 This requires that the name server _names_ are in a DNSSEC signed 18 zone. 20 This also requires that the delegation of the zone served is 21 protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the 22 keys used for discovery of TLS transport support. 24 Additional recommendations relate to use of various techniques for 25 efficiency and scalability, and new EDNS options to minimize round 26 trips and for signaling between clients and resolvers. 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 13 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. New DNS Elements . . . . . . . . . . . . . . . . . . . . 4 66 5. Requirements, and Limitations . . . . . . . . . . . . . . . . 4 67 6. DNS Records To Publish for ADoT . . . . . . . . . . . . . . . 5 68 6.1. Server DNS Transport Support Signaling . . . . . . . . . 5 69 6.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5 70 6.2. DANE TLSA Records for ADoT (TLSADOT) . . . . . . . . . . 6 71 6.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.3. Signaling DNS Transport for a Name Server . . . . . . . . 7 73 6.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7 74 6.4. Signaling DNS Transport for a Domain . . . . . . . . . . 7 75 6.4.1. Examples . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Validation Using DS Records, DNST Records, TLSADOT Records, and 77 DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 8 78 7.1. Complete Example . . . . . . . . . . . . . . . . . . . . 9 79 7.1.1. DNS Record Data . . . . . . . . . . . . . . . . . . . 9 80 7.1.2. Discussion Point - Wildcard-like Records . . . . . . 11 81 7.1.3. Resolver Iterative Queries For Final TLS Query . . . 11 82 8. Signaling Resolver Support and Client Desire for ADoT . . . . 14 83 8.1. Server Side Support Signaling . . . . . . . . . . . . . . 15 84 8.2. Client Side Desire Signaling . . . . . . . . . . . . . . 15 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 88 12. Informative References . . . . . . . . . . . . . . . . . . . 16 89 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 The Domain Name System (DNS) predates any concerns over privacy, 95 including the possibility of pervasive surveillance. The original 96 transports for DNS were UDP and TCP, unencrypted. Additionally, DNS 97 did not originally have any form of data integrity protection, 98 including against active on-path attackers. 100 DNSSEC (DNS Security extensions) added data integrity protection, but 101 did not address privacy concerns. The original DNS over TLS 102 [RFC7858] and DNS over HTTPS [RFC8484] specifications were limited to 103 client-to-resolver traffic. 105 The remaining privacy component is recursive-to-authoritative 106 servers. This Internet Draft is designed to provide a solution to 107 this problem. 109 2. Conventions and Definitions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Background 119 The result is that the parental side of the zone cut has records 120 needed for DNS resolution which are not signed and not validatable. 122 4. Purpose 124 Authoritative DNS over TLS is intended to provide the following for 125 communications from recursive resolvers to authoritative servers: 127 * Enable discovery of support for ADoT 129 * Validate the name server name 131 * Validate the server's TLS certificate 133 * Provide channel security using TLS 135 4.1. New DNS Elements 137 The following are new protocol components, which are either included 138 in this document, or are in other documents. Some are strictly 139 required, while others are strongly suggested components to allow 140 better scalability and performance. Some of the new elements are 141 aliases to already documented standards, for purposes of these 142 improvements. DNST refers to [I-D.dickson-dprive-dnst] 144 +=======+============+=======+========+=============================+ 145 |Element| New/Alias/ |Format/|Required|Description | 146 | | OPT |Base | | | 147 +=======+============+=======+========+=============================+ 148 |DNST | New |Flags |Y |DNS Transport - support for | 149 | | | | |DoT | 150 +-------+------------+-------+--------+-----------------------------+ 151 |TLSADOT| Alias |TLSA |Y |TLSA without prefixing | 152 +-------+------------+-------+--------+-----------------------------+ 153 |ADOTD | New |OPT RR |N |Signal desire for ADOT | 154 | | |(flag) | |(client-resolver) | 155 +-------+------------+-------+--------+-----------------------------+ 156 |ADOTA | New |OPT RR |N |Signal availablity of ADOT | 157 | | |(flag) | |(resolver-client) | 158 +-------+------------+-------+--------+-----------------------------+ 159 |NSECD | New |OPT RR |N |Signal desire for NSEC(3) for| 160 | | |(flag) | |[RFC8198] | 161 +-------+------------+-------+--------+-----------------------------+ 162 |NSV | New |DNSKEY |Y |Protect NS - see | 163 | | |Alg | |[I-D.dickson-dnsop-ds-hack] | 164 +-------+------------+-------+--------+-----------------------------+ 166 Table 1 168 5. Requirements, and Limitations 170 This protocol depends on correct configuration and operation of the 171 respective components, and that those are maintained according to 172 Best Current Practices: 174 * Use of DS records [I-D.dickson-dnsop-ds-hack] for the protection 175 of the delegation to the authoritative name servers 177 * Use of "glueless" zone(s) for name server names' zone 178 [I-D.dickson-dnsop-glueless] 180 * DNSSEC signing of the zone serving the authoritative name servers' 181 names [@RFC4034;@RFC4035;RFC5155] 183 * Proper management of key signing material for DNSSEC 185 * Ongoing management of RRSIGs on a timely basis (avoiding RRSIG 186 expiry) 188 * Ensuring TLSADOT records are kept synchronized with the TLS 189 certificates used 191 * Proper management of TLS private keys for TLS certificates used 193 There are external dependencies that impact the system security of 194 any DNSSEC zone, which are inherently unavoidable in establishing 195 this scheme. Specifially, the original DS record enrollment and any 196 updates to the DS records involved in DNSSEC delegations are presumed 197 secure and outside of the scope of the DNS protocol per se. 199 Other risks relate to normal information security practices, 200 including access controls, role based access, audits, multi-factor 201 authentication, multi-party controls, etc. These are out of scope 202 for this protocol itself. 204 6. DNS Records To Publish for ADoT 206 ADoT is a property of DNS servers. The signaling is done at the 207 server level, using a DNS record with the same owner name as the 208 server itself (i.e. where the A and AAAA records for the server are 209 published). 211 6.1. Server DNS Transport Support Signaling 213 In order to support ADoT for a DNS server, it is necessary to publish 214 a record specifyig explicit DoT support. This record also indicates 215 other supported transports for the DNS server, e.g. the standard 216 ports (TCP and UDP port 53). 218 The record type is "DNST" (DNS Transport), which is a single resource 219 record consisting of flags for different supported transport types. 221 The zone serving the record MUST be DNSSEC signed. The absence of 222 the DNST RRTYPE is proved by the NSEC(3) record, or else the DNST 223 RRTYPE plus RRSIG is returned in response to a query for this record 224 if it exists. 226 6.1.1. Examples 228 Suppose the name server ns1.example.net supports only the normal DNS 229 ports, and the name server ns2.example.net supports both the normal 230 ports and ADoT. The zone example.net would include the records: 232 ns1.example.net. IN DNST UDP TCP 233 ns2.example.net. IN DNST UDP TCP DOT 235 And similarly, if another zone with many name server names wanted to 236 have a policy of all-ADoT support (i.e. every name server supports 237 ADoT), they would each be encoded as: 239 ns1.example2.net DNST UDP TCP DOT 240 ns2.example2.net DNST UDP TCP DOT 241 ns3.example2.net DNST UDP TCP DOT 242 ns4.example2.net DNST UDP TCP DOT 244 6.2. DANE TLSA Records for ADoT (TLSADOT) 246 The presence of ADoT requires additionally that a TLSA [RFC6698] 247 record be provided. A new RRTYPE is to be created for this as an 248 alias of TLSA, with mnemonic of "TLSADOT" (TLS ADOT Certificate). 249 This record will be published at the location NS_NAME, where NS_NAME 250 is the name of the name server. Any valid TLSA RDATA is permitted. 251 The use of Certificate Usage types PKIX-TA and PKIX-EE is NOT 252 RECOMMENDED since PKIX requires web PKI interactions. DANE types 253 only require DNSSEC support. The use of Certificate Usage types 254 DANE-TA records may provide more flexibility in provisioning and 255 validation. On the other hand, DANE-EE is more secure, with fewer 256 consequences for private key loss and certificate revocation. Per 257 [RFC7218][RFC7671] the RECOMMENDED Selector and Matching types for 258 this are SPKI and SHA2-256, giving the recommended TLSADOT record 259 type of DANE-TA SPKI SHA2-256. 261 6.2.1. Example 263 In the above example, ns2.example.net supports DNS over TLS, and thus 264 would need to have a TLSADOT record. The zone would include: 266 ns2.example.net. IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 268 If there were another zone containing many DNS server names, 269 example2.net, it would be relatively simple to replicate otherwise 270 identical records which use the same signing cert (rather than end- 271 entity cert) in the TLSADOT record. 273 This would look like the following: 275 ns1.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 276 ns2.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 277 ns3.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 278 ns4.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 279 ns1.example2.net IN A IP4_ADDRESS1 280 ns2.example2.net IN A IP4_ADDRESS2 281 ns3.example2.net IN A IP4_ADDRESS3 282 ns4.example2.net IN A IP4_ADDRESS4 283 ns1.example2.net IN AAAA IP6_ADDRESS1 284 ns2.example2.net IN AAAA IP6_ADDRESS2 285 ns3.example2.net IN AAAA IP6_ADDRESS3 286 ns4.example2.net IN AAAA IP6_ADDRESS4 288 6.3. Signaling DNS Transport for a Name Server 290 This transport signaling MUST only be trusted if the name server 291 names for the domain containing the relevant name servers' names are 292 protected with [I-D.dickson-dnsop-ds-hack] and validated. The name 293 servers must also be in a DNSSEC signed zone (i.e. securely delegated 294 where the delegation has been successfully DNSSEC validated). 296 The specific DNS transport that a name server supports is indicated 297 via use of an RRSet of RRTYPE "DNST". 299 6.3.1. Examples 301 We re-use the same examples from above, indicating whether or not 302 individual authoritative name servers support DoT: 304 ns1.example.net. IN DNST UDP TCP DOTDNST 305 ns2.example.net. IN DNST UDP TCP DOTDNST 307 And similarly, if another zone with many name server names wanted to 308 have a policy of all-ADoT support (i.e. every name server supports 309 ADoT), this could be encoded as: 311 ns1.example2.net DNST UDP TCP DOT 312 ns2.example2.net DNST UDP TCP DOT 313 ns3.example2.net DNST UDP TCP DOT 314 ns4.example2.net DNST UDP TCP DOT 316 6.4. Signaling DNS Transport for a Domain 318 A domain inherits the signaled transport for the name servers serving 319 the domain. 321 This transport signaling MUST only be trusted for use of ADoT if the 322 delegated name server names for the domain are protected with 323 [I-D.dickson-dnsop-ds-hack]. 325 The delegation to NS names "A" and "B", along with the DS record 326 protecting/encoding "A" and "B", results in the DNS transport that is 327 signaled for "A" and "B" being applied to the domain being delegated. 328 This transport will include ADoT IFF the transport for "A" and "B" 329 has included ADoT via DNS records. 331 6.4.1. Examples 333 No additional configuration is needed, beyond use of authority 334 servers which signal DoT support. The following examples assumes the 335 previous DNS records are provisioned: 337 example.com NS ns1.example.net. // does not support ADoT 338 example.com NS ns2.example.net. // supports ADoT 340 example2.com NS ns1.example2.net. // all support ADoT 341 example2.com NS ns2.example2.net. // all support ADoT 343 In this example, ns1 does not have ADoT support (since the DNST 344 record excludes the DOT flag), while ns2 does support ADoT (since it 345 includes DOT). 347 7. Validation Using DS Records, DNST Records, TLSADOT Records, and 348 DNSSEC Validation 350 These records are used to validate corresponding delegation records, 351 DNST records, and TLSADOT records, as follows: 353 * Initial domain NS records are validated using 354 [I-D.dickson-dnsop-ds-hack] 356 * All DS records implementing [I-D.dickson-dnsop-ds-hack] must be 357 DNSSEC validated prior to use 359 * Once the NS names have been validated, and the delegations to the 360 appropriate name servers are validated, the DNST records for the 361 NS name are obtained to identify the DNS transport methods 362 supported. 364 * If ADoT is among the supported transports, the TLSADOT record for 365 the name server is obtained, and used for verification of the TLS 366 certificate when making the TLS connection. 368 7.1. Complete Example 370 7.1.1. DNS Record Data 372 Suppose a client requests resolution for the IP address of 373 "sensitive-name.example.com". Suppose the client's resolver has a 374 "cold" cache without any entries beyond the standard Root Zone and 375 relevant TLD name server records. 377 Suppose the following entries are present at their respective TLD 378 authority servers, delegating to the respective authority servers: 380 // (Single NS for brevity only, please use 2 NS minimum ) 381 // Unsigned delegations to various single-operator servers 382 example2.com NS ns1.example2.net. // all support ADoT 383 example3.com NS ns2.example2.net. // all support ADoT 384 example4.com NS ns3.example2.net. // all support ADoT 385 example5.com NS ns4.example2.net. // all support ADoT 387 // Zone serving NS data for single-operator's servers 388 example2.net NS ns1.infra2.example 389 example2.net NS ns2.infra2.example 390 example2.net DS (DS record data) 391 // glueless name servers are used 393 // Special zone serving NS data for previous zone 394 infra2.example NS ns1-glue.infra2.example 395 infra2.example NS ns2-glue.infra2.example 396 infra2.example DS (DS record data) 397 // Note use of glue for only this zone's delegation 398 ns1-glue.infra2.example A (glue A data) 399 ns1-glue.infra2.example AAAA (glue AAAA data) 400 ns2-glue.infra2.example A (glue A data) 401 ns2-glue.infra2.example AAAA (glue AAAA data) 403 Suppose the following additional entries are in the respective 404 authority servers for the ADOT signaling/certs: 406 example2.net SOA ( SOA record data ) 407 // glueless name servers are used 408 example2.net NS ns1.infra2.example 409 example2.net NS ns2.infra2.example 410 // 411 // DNS Transport for discovery of support 412 ns1.example2.net DNST UDP TCP DOT 413 ns2.example2.net DNST UDP TCP DOT 414 ns3.example2.net DNST UDP TCP DOT 415 ns4.example2.net DNST UDP TCP DOT 416 // 417 // TLSADOT signing cert 418 ns1.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 419 ns2.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 420 ns3.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 421 ns4.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 422 // 423 // Addresses of name servers serving customer zones 424 // E.g. example2.com to example5.com served on these 425 ns1.example2.net IN A IP4_ADDRESS1 426 ns2.example2.net IN A IP4_ADDRESS2 427 ns3.example2.net IN A IP4_ADDRESS3 428 ns4.example2.net IN A IP4_ADDRESS4 429 ns1.example2.net IN AAAA IP6_ADDRESS1 430 ns2.example2.net IN AAAA IP6_ADDRESS2 431 ns3.example2.net IN AAAA IP6_ADDRESS3 432 ns4.example2.net IN AAAA IP6_ADDRESS4 433 // 434 // plus RRSIGs and NSEC(3) records and their RRSIGs 436 infra2.example SOA ( SOA record data ) 437 infra2.example NS ns1-glue.infra2.example 438 infra2.example NS ns2-glue.infra2.example 439 ns1-glue.infra2.example A (same as glue A data) 440 ns1-glue.infra2.example AAAA (same as glue AAAA data) 441 ns2-glue.infra2.example A (same as glue A data) 442 ns2-glue.infra2.example AAAA (same as glue AAAA data) 443 // 444 // name server info for example2.net zone 445 ns1.infra2.example A (glueless A data) 446 ns1.infra2.example AAAA (glueless AAAA data) 447 ns2.infra2.example A (glueless A data) 448 ns2.infra2.example AAAA (glueless AAAA data) 449 // 450 // plus RRSIGs and NSEC(3) records and their RRSIGs 452 7.1.2. Discussion Point - Wildcard-like Records 454 Wildcards records have RRTYPE(s), but are only instantiated when an 455 owner name does not exist. 457 If wildcards were instantiated whenever the 3-tuple (name, class, 458 type) did not exist, use of wildcard records for DNST and TLSADOT 459 would be a logical choice. 461 The discussion point is as follows: 463 * Would it make sense to support a wildcard-like behavior for 464 covering many owner names which did not have explicit DNST and/or 465 TLSADOT records of their own? 467 * If so, when/how would that be signalled? 469 - It could be explicit, using a separate RRTYPE to flag the need 470 to use the parent name (zone apex) for the required RRTYPE. 472 o This would support use of NSEC(3) records to check for the 473 flag 475 o A resolver could use the flag to optimize cache usage for 476 the parent record. Once the parent is in the cache, the 477 flag in the NSEC(3) for the owner name would trigger use of 478 the cached parent record. 480 - It could be implicit, meaning the absence of the explicit 481 record type results in the need to search for the record type 482 at another name (e.g. zone apex). 484 o The lack of explicit record could be detected from NSEC(3) 485 records 487 o The implicit flag would be handled the same as the explicit 488 flag case above. 490 * The TLSADOT record at the parent zone would only be viable for 491 DANE-TA or PKIX-TA types. 493 7.1.3. Resolver Iterative Queries For Final TLS Query 495 (In the following, use of wildcard-type records and semantics is 496 assumed, but not explictly described currently. Literal wildcard 497 record labels ("*") are used as a placeholder, pending the above 498 Discussion Point's resolution.) 499 The following are the necessary queries to various servers necessary 500 to do a private TLS-protected lookup. 502 Several examples are provided in order, from a presumed cold cache 503 state. Root Priming and TLD queries are presumed to already have 504 been complete. 506 1. Query for sensitive-name.example2.com: 508 1. Query for NS for example2.com => get NS ns1.example2.net plus 509 DS => validate the DS and proceed 511 2. Query for NS for example2.net => get NS ns1/ 512 ns2.infra2.example plus DS => validate the DS and proceed 514 3. Query for NS for infra2.example2.net => get NS ns1-glue/ 515 ns2-glue.infra2.example plus DS plus glue A/AAAA => validate 516 the DS and proceed 518 4. Query with NSECD for A for ns1/ns2.infra2.example => get A 519 for ns1/ns2.infra2.example plus RRSIGs plus NSEC(3) plus 520 RRSIG => validate the RRSIGs and proceed 522 5. Query with NSECD for A for ns1.example2.net => get A for 523 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 524 validate the RRSIGs and proceed 526 6. Query with NSECD for DNST for ns1.example2.net => get DNST 527 for *.example2.net plus RRSIG plus special wildcard NSEC(3)s 528 plus RRSIGs => validate the RRSIGs and proceed 530 7. Query with NSECD for TLSADOT for ns1.example2.net => get 531 TLSADOT for *.example2.net plus RRSIG plus special wildcard 532 NSEC(3)s plus RRSIGs => validate the RRSIGs and proceed 534 8. Query over TLS for sensitive-name.example2.com (to 535 ns1.example2.net, match TLS cert chain against DANE-TA cert, 536 only query once TLS established) 538 2. Query for sensitive-name.example3.com: 540 1. Query for NS for example2.com => get NS ns1.example2.net plus 541 DS => validate the DS and proceed 543 2. Query with NSECD for A for ns1.example2.net => get A for 544 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 545 validate the RRSIGs and proceed 547 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 548 proving no non-wildcards exist for ns1.example2.net for those 549 types, synthesize DNST and TLSADOT records) 551 4. Query over TLS for sensitive-name.example2.com (to 552 ns1.example2.net, match TLS cert chain against DANE-TA cert, 553 only query once TLS established) 555 3. Query for sensitive-name.example4.com: 557 1. Query for NS for example2.com => get NS ns1.example2.net plus 558 DS => validate the DS and proceed 560 2. Query with NSECD for A for ns1.example2.net => get A for 561 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 562 validate the RRSIGs and proceed 564 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 565 proving no non-wildcards exist for ns1.example2.net for those 566 types, synthesize DNST and TLSADOT records) 568 4. Query over TLS for sensitive-name.example2.com (to 569 ns1.example2.net, match TLS cert chain against DANE-TA cert, 570 only query once TLS established) 572 4. Query for sensitive-name.example5.com: 574 1. Query for NS for example2.com => get NS ns1.example2.net plus 575 DS => validate the DS and proceed 577 2. Query with NSECD for A for ns1.example2.net => get A for 578 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 579 validate the RRSIGs and proceed 581 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 582 proving no non-wildcards exist for ns1.example2.net for those 583 types, synthesize DNST and TLSADOT records) 585 4. Query over TLS for sensitive-name.example2.com (to 586 ns1.example2.net, match TLS cert chain against DANE-TA cert, 587 only query once TLS established) 589 5. Query for sensitive-name2.example2.com: 591 1. (Already have delegation entry for example2.com in cache.) 593 2. (Already have A for ns1.example2.net in cache.) 594 3. (Already have all TLS info in the cache.) 596 4. Query over TLS for sensitive-name.example2.com (to 597 ns1.example2.net, match TLS cert chain against DANE-TA cert, 598 only query once TLS established) 600 Once the initial query or queries for a name server zone has been 601 done, if that zone uses wildcards for DNST and TLSADOT, the only 602 queries needed for a new name server are the A and/or AAAA records. 603 Once the initial query for a name server has been done, all of the 604 address and TLS information is available in the cache, and the DOT 605 query can be made upon receipt of the TLD delegation record. Once 606 the initial query for a second-level domain has been done, the TLD 607 delegation and all of the address and TLS information is available in 608 the cache, and the DOT query can be made immediately. 610 Once a cache is populated with wildcards from the name server domain, 611 additional delegation queries require no more trips than those needed 612 for normal UDP queries: 614 1. Query for delegation from TLD, and validate the response 616 2. Query for the name server's address(es), and validate the 617 response 619 3. Send the query to the authoritative server for the domain with 620 the sensitive name (over TLS or over UDP/TCP, depending on 621 transport supported by the authoritative server) 623 Once a cache is populated with name server addresses and wildcards, 624 additional delegation queries require no more trips than those needed 625 for normal UDP queries: 627 1. Query for delegation from TLD, and validate the response 629 2. Send the query to the authoritative server for the domain with 630 the sensitive name (over TLS or over UDP/TCP, depending on 631 transport supported by the authoritative server) 633 8. Signaling Resolver Support and Client Desire for ADoT 635 The following presume some new OPT sub-types, to be added to the IANA 636 action section or to be split out as separate drafts. The sub-type 637 mnemonics are "ADOTA" (available) and "ADOTD" (desired), each with an 638 enumerated set of values and mnemonic codes. Respectively those are: 639 "Always", "Upon Request", and "Never"; and "Force", "If Available", 640 and "Never". 642 8.1. Server Side Support Signaling 644 A DNS server (e.g. recursive resolver or forwarder) MAY signal to 645 clients that it offers the use of ADoT. The mechanism used is to set 646 the EDNS option "ADOTA". The values for this option are "Always", 647 "Upon Request", and "Never". The value "Always" indicates the server 648 will always attempt to use ADoT without regards to client requests 649 for ADoT. The value "Upon Request" indicates that the server will 650 ONLY use ADoT for upstream queries if the client requests that ADoT 651 be used. These values have no effect on answers served from the 652 resolver's cache. (The "Never" case is unusual, in that it signals 653 the server understands the option, but does not perform ADoT. 654 Generally this would be used to allow a client to track changes in 655 the status, if the client is interested in uses of ADoT.) 657 8.2. Client Side Desire Signaling 659 A DNS client (e.g. stub or forwarder) MAY signal the desire to have 660 the resolver use ADoT. The mechanism used is to set the EDNS option 661 "ADOTD". The values for this option are "Force", "If Available", and 662 "Never". The value "Force" indicates the server should attempt to 663 use ADoT, and return a failure code of XXXX and an EDE value of YYYY 664 if the authoritative server does not offer ADoT, or any other ADoT 665 failure occurs. The value "If Available" indicates that the server 666 should use ADoT for upstream queries if it is availble, but SHOULD 667 NOT allow any downgrades if the authoritative server signals that 668 ADoT is available. These values have no effect on answers served 669 from the resolver's cache. (The "Never" case is unusual, in that it 670 signals the client understands the option, but does not perform ADoT. 671 Generally this would be used to allow a server to track changes in 672 the client base, so the server operator can make informed decisions 673 about enabling ADoT.) 675 9. Security Considerations 677 As outlined above, there could be security issues in various use 678 cases. 680 10. IANA Considerations 682 This document may or many not have any IANA actions. (e.g. if the 683 RRTYPEs, EDNS subtypes, DNSKEY algorithms, etc., are defined in other 684 documents, no IANA actions are needed.) 686 11. Normative References 688 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 689 of Named Entities (DANE) Transport Layer Security (TLS) 690 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 691 2012, . 693 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 694 Conversations about DNS-Based Authentication of Named 695 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 696 2014, . 698 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 699 Authentication of Named Entities (DANE) Protocol: Updates 700 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 701 October 2015, . 703 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 704 and P. Hoffman, "Specification for DNS over Transport 705 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 706 2016, . 708 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 709 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 710 May 2017, . 712 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 713 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 714 July 2017, . 716 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 717 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 718 . 720 12. Informative References 722 [I-D.dickson-dnsop-ds-hack] 723 Dickson, B., "DS Algorithms for Securing NS and Glue", 724 Work in Progress, Internet-Draft, draft-dickson-dnsop-ds- 725 hack-02, 19 September 2021, 726 . 729 [I-D.dickson-dnsop-glueless] 730 Dickson, B., "Operating a Glueless DNS Authority Server", 731 Work in Progress, Internet-Draft, draft-dickson-dnsop- 732 glueless-02, 22 September 2021, 733 . 736 [I-D.dickson-dprive-dnst] 737 Dickson, B., "Resource Record for Signaling Transport for 738 DNS to Authority Servers", Work in Progress, Internet- 739 Draft, draft-dickson-dprive-dnst-00, 24 October 2021, 740 . 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, 745 DOI 10.17487/RFC2119, March 1997, 746 . 748 Appendix A. Acknowledgments 750 Thanks to everyone who helped create the tools that let everyone use 751 Markdown to create Internet Drafts, and the RFC Editor for xml2rfc. 753 Thanks to Dan York for his Tutorial on using Markdown (specificially 754 mmark) for writing IETF drafts. 756 Thanks to YOUR NAME HERE for contributions, reviews, etc. 758 Author's Address 760 Brian Dickson 761 GoDaddy 763 Email: brian.peter.dickson@gmail.com