idnits 2.17.1 draft-dickson-dprive-adot-auth-04.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 (20 September 2021) is 948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8198' is defined on line 778, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-dickson-dnsop-ds-hack-00 == Outdated reference: A later version (-02) exists of draft-dickson-dnsop-glueless-00 Summary: 1 error (**), 0 flaws (~~), 5 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 20 September 2021 5 Expires: 24 March 2022 7 Authenticated DNS over TLS to Authoritative Servers 8 draft-dickson-dprive-adot-auth-04 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 24 March 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. Prerequisite: New SVCB Binding for DNS and DoT . . . 6 70 6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 7 71 6.2. DANE TLSA Records for ADoT . . . . . . . . . . . . . . . 7 72 6.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.3. Signaling DNS Transport for a Name Server . . . . . . . . 8 74 6.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . 8 75 6.4. Signaling DNS Transport for a Domain . . . . . . . . . . 9 76 6.4.1. Examples . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Validation Using DS Records, DNS Records, TLSA Records, and 78 DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Complete Example . . . . . . . . . . . . . . . . . . . . 10 80 7.1.1. DNS Record Data . . . . . . . . . . . . . . . . . . . 10 81 7.1.2. Discussion Point - Wildcard-like Records . . . . . . 12 82 7.1.3. Resolver Iterative Queries For Final TLS Query . . . 13 83 8. Signaling Resolver Support and Client Desire for ADoT . . . . 16 84 8.1. Server Side Support Signaling . . . . . . . . . . . . . . 16 85 8.2. Client Side Desire Signaling . . . . . . . . . . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 11. Normative References . . . . . . . . . . . . . . . . . . . . 17 89 12. Informative References . . . . . . . . . . . . . . . . . . . 17 90 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 The Domain Name System (DNS) predates any concerns over privacy, 96 including the possibility of pervasive surveillance. The original 97 transports for DNS were UDP and TCP, unencrypted. Additionally, DNS 98 did not originally have any form of data integrity protection, 99 including against active on-path attackers. 101 DNSSEC (DNS Security extensions) added data integrity protection, but 102 did not address privacy concerns. The original DNS over TLS 103 [RFC7858] and DNS over HTTPS [RFC8484] specifications were limited to 104 client-to-resolver traffic. 106 The remaining privacy component is recursive-to-authoritative 107 servers. This Internet Draft is designed to provide a solution to 108 this problem. 110 2. Conventions and Definitions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. Background 120 The result is that the parental side of the zone cut has records 121 needed for DNS resolution which are not signed and not validatable. 123 4. Purpose 125 Authoritative DNS over TLS is intended to provide the following for 126 communications from recursive resolvers to authoritative servers: 128 * Enable discovery of support for ADoT 130 * Validate the name server name 132 * Validate the server's TLS certificate 134 * Provide channel security using TLS 136 4.1. New DNS Elements 138 The following are new protocol components, which are either included 139 in this document, or are in other documents. Some are strictly 140 required, while others are strongly suggested components to allow 141 better scalability and performance. Some of the new elements are 142 aliases to already documented standards, for purposes of these 143 improvements. 145 +=======+============+=======+========+=============================+ 146 |Element| New/Alias/ |Format/|Required|Description | 147 | | OPT |Base | | | 148 +=======+============+=======+========+=============================+ 149 |DNST | Alias |SVCB |Spec: Y |DNS Transport - support for | 150 | | | |DNS: N |DoT | 151 +-------+------------+-------+--------+-----------------------------+ 152 |TLSADOT| Alias |TLSA |Spec: |TLSA without prefixing | 153 | | | |Opt DNS:| | 154 | | | |Yes or | | 155 | | | |TLSA | | 156 +-------+------------+-------+--------+-----------------------------+ 157 |ADOTD | New |OPT RR |N |Signal desire for ADOT | 158 | | | | |(client-resolver) | 159 +-------+------------+-------+--------+-----------------------------+ 160 |ADOTA | New |OPT RR |N |Signal availablity of ADOT | 161 | | | | |(resolver-client) | 162 +-------+------------+-------+--------+-----------------------------+ 163 |NSECD | New |OPT RR |N |Signal desire for NSEC(3) for| 164 | | | | |[RFC8198] | 165 +-------+------------+-------+--------+-----------------------------+ 166 |NSV | New |DNSKEY |Y |Protect NS - see | 167 | | |Alg | |[I-D.dickson-dnsop-ds-hack] | 168 +-------+------------+-------+--------+-----------------------------+ 170 Table 1 172 5. Requirements, and Limitations 174 This protocol depends on correct configuration and operation of the 175 respective components, and that those are maintained according to 176 Best Current Practices: 178 * Use of DS records [I-D.dickson-dnsop-ds-hack] for the protection 179 of the delegation to the authoritative name servers 181 * Use of "glueless" zone(s) for name server names' zone 182 [I-D.dickson-dnsop-glueless] 184 * DNSSEC signing of the zone serving the authoritative name servers' 185 names [@RFC4034;@RFC4035;RFC5155] 187 * Proper management of key signing material for DNSSEC 189 * Ongoing management of RRSIGs on a timely basis (avoiding RRSIG 190 expiry) 192 * Ensuring TLSA records are kept synchronized with the TLS 193 certificates used 195 * Proper management of TLS private keys for TLS certificates used 197 There are external dependencies that impact the system security of 198 any DNSSEC zone, which are inherently unavoidable in establishing 199 this scheme. Specifially, the original DS record enrollment and any 200 updates to the DS records involved in DNSSEC delegations are presumed 201 secure and outside of the scope of the DNS protocol per se. 203 Other risks relate to normal information security practices, 204 including access controls, role based access, audits, multi-factor 205 authentication, multi-party controls, etc. These are out of scope 206 for this protocol itself. 208 6. DNS Records To Publish for ADoT 210 ADoT is a property of DNS servers. The signaling is done at the 211 server level, using a DNS record with the same owner name as the 212 server itself (i.e. where the A and AAAA records for the server are 213 published). 215 6.1. Server DNS Transport Support Signaling 217 In order to support ADoT for a DNS server, it is necessary to publish 218 a record specifyig explicit DoT support. This record also indicates 219 other supported transports for the DNS server, e.g. the standard 220 ports (TCP and UDP port 53). 222 The record type is "DNST" (DNS Transport), which is a specific 223 instance of (aka binding for) SVCB with unique RRTYPE. 225 The zone serving the record MUST be DNSSEC signed. The absence of 226 the DNST RRTYPE is proved by the NSEC(3) record, or else the DNST 227 RRTYPE plus RRSIG is returned in response to a query for this record 228 if it exists. 230 6.1.1. Prerequisite: New SVCB Binding for DNS and DoT 232 (NB: To be separated out into its own draft and expanded fully.) 233 This SVCB binding will be given the RRTYPE value {TBD} with mnemonic 234 name DNST ("DNS Transport"). Like any SVCB binding, there is a 235 mandatory TargetName (which will normally be ".", indicating the 236 target is the same as the record owner name). The default binding is 237 the standard DNS ports, UDP/53 and TCP/53. 239 The SVCB binding includes support for an optional ADoT port, which is 240 the standard DoT port TCP/853. This is signaled by "alpn=dot". The 241 actual port number may be overridden with the "DOTport=N" SvcParam, 242 and the UDP and TCP ports may also be overridden with optional 243 "UDPport=N" and "TCPport=N" SvcParams. 245 Since DNST is a type-specific binding, it does NOT require the 246 underscore prefix naming that the generic SVCB RRTYPE requires. It 247 may occur anywhere, including at the apex of a DNS zone, and may co- 248 exist with any other type that also permits other types.o 250 The DNST binding allows both AliasMode and ServiceMode record types 251 (per the proposed SVCB standard). Both mode types use a TargetName 252 parameter, which supports same-name usage (TargetName = ".") as well 253 as redirected TargetName values. The resolver must follow AliasMode 254 in the same manner as CNAME, i.e. rewriting the QNAME and restarting 255 resolution using the new QNAME. 257 Once the DNST is in ServiceMode, the authoritative server returns 258 both the DNST record(s) and A and AAAA records with the same owner 259 name (TargetName). This reduces the number of queries the resolver 260 would otherwise have to make (i.e. two additional queries for A and 261 AAAA record types). 263 6.1.1.1. Default Ports for DNS 265 This scheme uses an SVCB binding for DNS Transport, DNST. The 266 binding has default ports UDP/53 and TCP/53 as the default-alpn. 267 These are assumed unless "no-default-alpn" is added as an optional 268 SvcParam. 270 6.1.1.2. Optional Port for DoT 272 The DNST binding uses the defined ALPN for DNS-over-TLS with the 273 assigned label "dot". Use of ADoT is signaled if and only if the the 274 SvcParam of "alpn=dot" is present. 276 6.1.2. Examples 278 Suppose the name server ns1.example.net supports only the normal DNS 279 ports, and the name server ns2.example.net supports both the normal 280 ports and ADoT. The zone example.net would include the records: 282 ns1.example.net. IN DNST 1 "." 283 ns2.example.net. IN DNST 1 "." alpn=dot 285 And similarly, if another zone with many name server names wanted to 286 have a policy of all-ADoT support (i.e. every name server supports 287 ADoT), they would each be encoded as: 289 ns1.example2.net DNST 1 "." alpn=dot 290 ns2.example2.net DNST 1 "." alpn=dot 291 ns3.example2.net DNST 1 "." alpn=dot 292 ns4.example2.net DNST 1 "." alpn=dot 294 In each case, the first parameter is the SvcPriority, which must be 295 non-zero (zero indicates AliasMode SVCB record type). 297 Note that it is possible for the resolver to use alter or ignore 298 SvcPriority based on its own local policy. For instance, a resolver 299 to prefer non-DoT over DoT or vice versa. Local policy might be to 300 override SvcPriority ordering, and/or ignore some of the records. 301 For example, a resolver might prefer to support mandatory use of DoT 302 if present on any server in the NS RRset. 304 6.2. DANE TLSA Records for ADoT 306 The presence of ADoT requires additionally that a TLSA [RFC6698] 307 record be provided. A new RRTYPE is to be created for this as an 308 alias of TLSA, with mnemonic of "TLSADOT" (TLS ADOT Certificate). 309 This record will be published at the location NS_NAME, where NS_NAME 310 is the name of the name server. Any valid TLSA RDATA is permitted. 311 The use of Certificate Usage types PKIX-TA and PKIX-EE is NOT 312 RECOMMENDED since PKIX requires web PKI interactions. DANE types 313 only require DNSSEC support. The use of Certificate Usage types 314 DANE-TA records may provide more flexibility in provisioning and 315 validation. Per [RFC7218][RFC7671] the RECOMMENDED Selector and 316 Matching types for this are SPKI and SHA2-256, giving the recommended 317 TLSA record type of DANE-TA SPKI SHA2-256. 319 6.2.1. Example 321 In the above example, ns2.example.net supports DNS over TLS, and thus 322 would need to have a TLSA record. The zone would include: 324 ns2.example.net. IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 326 If there were another zone containing many DNS server names, 327 example2.net, it would be relatively simple to replicate otherwise 328 identical records which use the same signing cert (rather than end- 329 entity cert) in the TLSADOT record. 331 This would look like the following: 333 ns1.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 334 ns2.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 335 ns3.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 336 ns4.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 337 ns1.example2.net IN A IP4_ADDRESS1 338 ns2.example2.net IN A IP4_ADDRESS2 339 ns3.example2.net IN A IP4_ADDRESS3 340 ns4.example2.net IN A IP4_ADDRESS4 341 ns1.example2.net IN AAAA IP6_ADDRESS1 342 ns2.example2.net IN AAAA IP6_ADDRESS2 343 ns3.example2.net IN AAAA IP6_ADDRESS3 344 ns4.example2.net IN AAAA IP6_ADDRESS4 346 6.3. Signaling DNS Transport for a Name Server 348 This transport signaling MUST only be trusted if the name server 349 names for the domain containing the relevant name servers' names are 350 protected with [I-D.dickson-dnsop-ds-hack] and validated. The name 351 servers must also be in a DNSSEC signed zone (i.e. securely delegated 352 where the delegation has been successfully DNSSEC validated). 354 The specific DNS transport that a name server supports is indicated 355 via use of an RRSet of RRTYPE "DNST". This is a SVCB binding, and 356 normally will use the TargetName of "." (meaning the same name). The 357 default ALPN (transport mechanisms) are TCP/53 and UDP/53. The ADoT 358 transport support is signaled by "alpn=dot". There is an existing 359 entry for "dot" in the ALPN table, with port TCP/853. 361 6.3.1. Examples 363 We re-use the same examples from above, indicating whether or not 364 individual authoritative name servers support DoT: 366 ns1.example.net. IN DNST 1 "." 367 ns2.example.net. IN DNST 1 "." alpn=dot 369 And similarly, if another zone with many name server names wanted to 370 have a policy of all-ADoT support (i.e. every name server supports 371 ADoT), this could be encoded as: 373 ns1.example2.net DNST 1 "." alpn=dot 374 ns2.example2.net DNST 1 "." alpn=dot 375 ns3.example2.net DNST 1 "." alpn=dot 376 ns4.example2.net DNST 1 "." alpn=dot 378 6.4. Signaling DNS Transport for a Domain 380 A domain inherits the signaled transport for the name servers serving 381 the domain. 383 This transport signaling MUST only be trusted for use of ADoT if the 384 delegated name server names for the domain are protected with 385 [I-D.dickson-dnsop-ds-hack]. 387 The delegation to NS names "A" and "B", along with the DS record 388 protecting/encoding "A" and "B", results in the DNS transport that is 389 signaled for "A" and "B" being applied to the domain being delegated. 390 This transport will include ADoT IFF the transport for "A" and "B" 391 has included ADoT via DNS records. 393 6.4.1. Examples 395 No additional configuration is needed, beyond use of authority 396 servers which signal DoT support. The following examples assumes the 397 previous DNS records are provisioned: 399 example.com NS ns1.example.net. // does not support ADoT 400 example.com NS ns2.example.net. // supports ADoT 402 example2.com NS ns1.example2.net. // all support ADoT 403 example2.com NS ns2.example2.net. // all support ADoT 405 In this example, ns1 does not have ADoT support (since the DNS record 406 excludes the "alpn=dot" parameter), while ns2 does support ADoT 407 (since it includes "alpn=dot"). 409 7. Validation Using DS Records, DNS Records, TLSA Records, and DNSSEC 410 Validation 412 These records are used to validate corresponding delegation records, 413 DNS records, and TLSA records, as follows: 415 * Initial domain NS records are validated using 416 [I-D.dickson-dnsop-ds-hack] 418 * All DS records implementing [I-D.dickson-dnsop-ds-hack] must be 419 DNSSEC validated prior to use 421 * Once the NS names have been validated, and the delegations to the 422 appropriate name servers are validated, the DNS records for the NS 423 name are obtained to identify the DNS transport methods supported. 425 * If ADoT is among the supported transports, the TLSA record for the 426 name server is obtained, and used for verification of the TLS 427 certificate when making the TLS connection. 429 7.1. Complete Example 431 7.1.1. DNS Record Data 433 Suppose a client requests resolution for the IP address of 434 "sensitive-name.example.com". Suppose the client's resolver has a 435 "cold" cache without any entries beyond the standard Root Zone and 436 relevant TLD name server records. 438 Suppose the following entries are present at their respective TLD 439 authority servers, delegating to the respective authority servers: 441 // (Single NS for brevity only, please use 2 NS minimum ) 442 // Unsigned delegations to various single-operator servers 443 example2.com NS ns1.example2.net. // all support ADoT 444 example3.com NS ns2.example2.net. // all support ADoT 445 example4.com NS ns3.example2.net. // all support ADoT 446 example5.com NS ns4.example2.net. // all support ADoT 448 // Zone serving NS data for single-operator's servers 449 example2.net NS ns1.infra2.example 450 example2.net NS ns2.infra2.example 451 example2.net DS (DS record data) 452 // glueless name servers are used 454 // Special zone serving NS data for previous zone 455 infra2.example NS ns1-glue.infra2.example 456 infra2.example NS ns2-glue.infra2.example 457 infra2.example DS (DS record data) 458 // Note use of glue for only this zone's delegation 459 ns1-glue.infra2.example A (glue A data) 460 ns1-glue.infra2.example AAAA (glue AAAA data) 461 ns2-glue.infra2.example A (glue A data) 462 ns2-glue.infra2.example AAAA (glue AAAA data) 464 Suppose the following additional entries are in the respective 465 authority servers for the ADOT signaling/certs: 467 example2.net SOA ( SOA record data ) 468 // glueless name servers are used 469 example2.net NS ns1.infra2.example 470 example2.net NS ns2.infra2.example 471 // 472 // SVCB records (DNS Transport) for discovery of support 473 ns1.example2.net DNST 1 "." alpn=dot 474 ns2.example2.net DNST 1 "." alpn=dot 475 ns3.example2.net DNST 1 "." alpn=dot 476 ns4.example2.net DNST 1 "." alpn=dot 477 // 478 // ADOT TLSA signing cert 479 ns1.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 480 ns2.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 481 ns3.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 482 ns4.example2.net IN TLSADOT DANE-TA SPKI SHA2-256 (hash data) 483 // 484 // Addresses of name servers serving customer zones 485 // E.g. example2.com to example5.com served on these 486 ns1.example2.net IN A IP4_ADDRESS1 487 ns2.example2.net IN A IP4_ADDRESS2 488 ns3.example2.net IN A IP4_ADDRESS3 489 ns4.example2.net IN A IP4_ADDRESS4 490 ns1.example2.net IN AAAA IP6_ADDRESS1 491 ns2.example2.net IN AAAA IP6_ADDRESS2 492 ns3.example2.net IN AAAA IP6_ADDRESS3 493 ns4.example2.net IN AAAA IP6_ADDRESS4 494 // 495 // plus RRSIGs and NSEC(3) records and their RRSIGs 497 infra2.example SOA ( SOA record data ) 498 infra2.example NS ns1-glue.infra2.example 499 infra2.example NS ns2-glue.infra2.example 500 ns1-glue.infra2.example A (same as glue A data) 501 ns1-glue.infra2.example AAAA (same as glue AAAA data) 502 ns2-glue.infra2.example A (same as glue A data) 503 ns2-glue.infra2.example AAAA (same as glue AAAA data) 504 // 505 // name server info for example2.net zone 506 ns1.infra2.example A (glueless A data) 507 ns1.infra2.example AAAA (glueless AAAA data) 508 ns2.infra2.example A (glueless A data) 509 ns2.infra2.example AAAA (glueless AAAA data) 510 // 511 // plus RRSIGs and NSEC(3) records and their RRSIGs 513 7.1.2. Discussion Point - Wildcard-like Records 515 Wildcards records have RRTYPE(s), but are only instantiated when an 516 owner name does not exist. 518 If wildcards were instantiated whenever the 3-tuple (name, class, 519 type) did not exist, use of wildcard records for DNST and TLSADOT 520 would be a logical choice. 522 The discussion point is as follows: 524 * Would it make sense to support a wildcard-like behavior for 525 covering many owner names which did not have explicit DNST and/or 526 TLSADOT records of their own? 528 * If so, when/how would that be signalled? 530 - It could be explicit, using a separate RRTYPE to flag the need 531 to use the parent name (zone apex) for the required RRTYPE. 533 o This would support use of NSEC(3) records to check for the 534 flag 536 o A resolver could use the flag to optimize cache usage for 537 the parent record. Once the parent is in the cache, the 538 flag in the NSEC(3) for the owner name would trigger use of 539 the cached parent record. 541 - It could be implicit, meaning the absence of the explicit 542 record type results in the need to search for the record type 543 at another name (e.g. zone apex). 545 o The lack of explicit record could be detected from NSEC(3) 546 records 548 o The implicit flag would be handled the same as the explicit 549 flag case above. 551 * The TLSADOT record at the parent zone would only be viable for 552 DANE-TA type. 554 * The DNST record at the parent zone would need to inherit the 555 original owner name for use by TargetName = "." semantics. 557 7.1.3. Resolver Iterative Queries For Final TLS Query 559 (In the following, use of wildcard-type records and semantics is 560 assumed, but not explictly described currently. Literal wildcard 561 record labels ("*") are used as a placeholder, pending the above 562 Discussion Point's resolution.) 564 The following are the necessary queries to various servers necessary 565 to do a private TLS-protected lookup. 567 Several examples are provided in order, from a presumed cold cache 568 state. Root Priming and TLD queries are presumed to already have 569 been complete. 571 1. Query for sensitive-name.example2.com: 573 1. Query for NS for example2.com => get NS ns1.example2.net plus 574 DS => validate the DS and proceed 576 2. Query for NS for example2.net => get NS ns1/ 577 ns2.infra2.example plus DS => validate the DS and proceed 579 3. Query for NS for infra2.example2.net => get NS ns1-glue/ 580 ns2-glue.infra2.example plus DS plus glue A/AAAA => validate 581 the DS and proceed 583 4. Query with NSECD for A for ns1/ns2.infra2.example => get A 584 for ns1/ns2.infra2.example plus RRSIGs plus NSEC(3) plus 585 RRSIG => validate the RRSIGs and proceed 587 5. Query with NSECD for A for ns1.example2.net => get A for 588 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 589 validate the RRSIGs and proceed 591 6. Query with NSECD for DNST for ns1.example2.net => get DNST 592 for *.example2.net plus RRSIG plus special wildcard NSEC(3)s 593 plus RRSIGs => validate the RRSIGs and proceed 595 7. Query with NSECD for TLSADOT for ns1.example2.net => get 596 TLSADOT for *.example2.net plus RRSIG plus special wildcard 597 NSEC(3)s plus RRSIGs => validate the RRSIGs and proceed 599 8. Query over TLS for sensitive-name.example2.com (to 600 ns1.example2.net, match TLS cert chain against DANE-TA cert, 601 only query once TLS established) 603 2. Query for sensitive-name.example3.com: 605 1. Query for NS for example2.com => get NS ns1.example2.net plus 606 DS => validate the DS and proceed 608 2. Query with NSECD for A for ns1.example2.net => get A for 609 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 610 validate the RRSIGs and proceed 612 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 613 proving no non-wildcards exist for ns1.example2.net for those 614 types, synthesize DNST and TLSADOT records) 616 4. Query over TLS for sensitive-name.example2.com (to 617 ns1.example2.net, match TLS cert chain against DANE-TA cert, 618 only query once TLS established) 620 3. Query for sensitive-name.example4.com: 622 1. Query for NS for example2.com => get NS ns1.example2.net plus 623 DS => validate the DS and proceed 625 2. Query with NSECD for A for ns1.example2.net => get A for 626 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 627 validate the RRSIGs and proceed 629 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 630 proving no non-wildcards exist for ns1.example2.net for those 631 types, synthesize DNST and TLSADOT records) 633 4. Query over TLS for sensitive-name.example2.com (to 634 ns1.example2.net, match TLS cert chain against DANE-TA cert, 635 only query once TLS established) 637 4. Query for sensitive-name.example5.com: 639 1. Query for NS for example2.com => get NS ns1.example2.net plus 640 DS => validate the DS and proceed 642 2. Query with NSECD for A for ns1.example2.net => get A for 643 ns1.example2.net plus RRSIG plus NSEC(3) plus RRSIG => 644 validate the RRSIGs and proceed 646 3. NB: already have wildcards for DNST and TLSADOT plus NSEC3 647 proving no non-wildcards exist for ns1.example2.net for those 648 types, synthesize DNST and TLSADOT records) 650 4. Query over TLS for sensitive-name.example2.com (to 651 ns1.example2.net, match TLS cert chain against DANE-TA cert, 652 only query once TLS established) 654 5. Query for sensitive-name2.example2.com: 656 1. (Already have delegation entry for example2.com in cache.) 658 2. (Already have A for ns1.example2.net in cache.) 660 3. (Already have all TLS info in the cache.) 662 4. Query over TLS for sensitive-name.example2.com (to 663 ns1.example2.net, match TLS cert chain against DANE-TA cert, 664 only query once TLS established) 666 Once the initial query or queries for a name server zone has been 667 done, if that zone uses wildcards for DNST and TLSADOT, the only 668 queries needed for a new name server are the A and/or AAAA records. 669 Once the initial query for a name server has been done, all of the 670 address and TLS information is available in the cache, and the DOT 671 query can be made upon receipt of the TLD delegation record. Once 672 the initial query for a second-level domain has been done, the TLD 673 delegation and all of the address and TLS information is available in 674 the cache, and the DOT query can be made immediately. 676 Once a cache is populated with wildcards from the name server domain, 677 additional delegation queries require no more trips than those needed 678 for normal UDP queries: 680 1. Query for delegation from TLD, and validate the response 682 2. Query for the name server's address(es), and validate the 683 response 685 3. Send the query to the authoritative server for the domain with 686 the sensitive name (over TLS or over UDP/TCP, depending on 687 transport supported by the authoritative server) 689 Once a cache is populated with name server addresses and wildcards, 690 additional delegation queries require no more trips than those needed 691 for normal UDP queries: 693 1. Query for delegation from TLD, and validate the response 695 2. Send the query to the authoritative server for the domain with 696 the sensitive name (over TLS or over UDP/TCP, depending on 697 transport supported by the authoritative server) 699 8. Signaling Resolver Support and Client Desire for ADoT 701 The following presume some new OPT sub-types, to be added to the IANA 702 action section or to be split out as separate drafts. The sub-type 703 mnemonics are "ADOTA" (available) and "ADOTD" (desired), each with an 704 enumerated set of values and mnemonic codes. Respectively those are: 705 "Always", "Upon Request", and "Never"; and "Force", "If Available", 706 and "Never". 708 8.1. Server Side Support Signaling 710 A DNS server (e.g. recursive resolver or forwarder) MAY signal to 711 clients that it offers the use of ADoT. The mechanism used is to set 712 the EDNS option "ADOTA". The values for this option are "Always", 713 "Upon Request", and "Never". The value "Always" indicates the server 714 will always attempt to use ADoT without regards to client requests 715 for ADoT. The value "Upon Request" indicates that the server will 716 ONLY use ADoT for upstream queries if the client requests that ADoT 717 be used. These values have no effect on answers served from the 718 resolver's cache. (The "Never" case is unusual, in that it signals 719 the server understands the option, but does not perform ADoT. 720 Generally this would be used to allow a client to track changes in 721 the status, if the client is interested in uses of ADoT.) 723 8.2. Client Side Desire Signaling 725 A DNS client (e.g. stub or forwarder) MAY signal the desire to have 726 the resolver use ADoT. The mechanism used is to set the EDNS option 727 "ADOTD". The values for this option are "Force", "If Available", and 728 "Never". The value "Force" indicates the server should attempt to 729 use ADoT, and return a failure code of XXXX and an EDE value of YYYY 730 if the authoritative server does not offer ADoT, or any other ADoT 731 failure occurs. The value "If Available" indicates that the server 732 should use ADoT for upstream queries if it is availble, but SHOULD 733 NOT allow any downgrades if the authoritative server signals that 734 ADoT is available. These values have no effect on answers served 735 from the resolver's cache. (The "Never" case is unusual, in that it 736 signals the client understands the option, but does not perform ADoT. 737 Generally this would be used to allow a server to track changes in 738 the client base, so the server operator can make informed decisions 739 about enabling ADoT.) 741 9. Security Considerations 743 As outlined above, there could be security issues in various use 744 cases. 746 10. IANA Considerations 748 This document may or many not have any IANA actions. (e.g. if the 749 RRTYPEs, EDNS subtypes, DNSKEY algorithms, etc., are defined in other 750 documents, no IANA actions are needed.) 752 11. Normative References 754 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 755 of Named Entities (DANE) Transport Layer Security (TLS) 756 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 757 2012, . 759 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 760 Conversations about DNS-Based Authentication of Named 761 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 762 2014, . 764 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 765 Authentication of Named Entities (DANE) Protocol: Updates 766 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 767 October 2015, . 769 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 770 and P. Hoffman, "Specification for DNS over Transport 771 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 772 2016, . 774 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 775 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 776 May 2017, . 778 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 779 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 780 July 2017, . 782 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 783 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 784 . 786 12. Informative References 788 [I-D.dickson-dnsop-ds-hack] 789 Dickson, B., "DS Algorithms for Securing NS and Glue", 790 Work in Progress, Internet-Draft, draft-dickson-dnsop-ds- 791 hack-00, 11 August 2021, 792 . 795 [I-D.dickson-dnsop-glueless] 796 Dickson, B., "Operating a Glueless DNS Authority Server", 797 Work in Progress, Internet-Draft, draft-dickson-dnsop- 798 glueless-00, 17 September 2021, 799 . 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 Appendix A. Acknowledgments 809 Thanks to everyone who helped create the tools that let everyone use 810 Markdown to create Internet Drafts, and the RFC Editor for xml2rfc. 812 Thanks to Dan York for his Tutorial on using Markdown (specificially 813 mmark) for writing IETF drafts. 815 Thanks to YOUR NAME HERE for contributions, reviews, etc. 817 Author's Address 819 Brian Dickson 820 GoDaddy 822 Email: brian.peter.dickson@gmail.com