idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 729 has weird spacing: '...e be ff db 5b...' == Line 737 has weird spacing: '...0 5b fd da 80...' == Line 770 has weird spacing: '...4 5b fd da 80...' == Line 783 has weird spacing: '...4 2f bb b9 f9...' == Line 808 has weird spacing: '...c 82 cf df ac...' -- The document date (March 21, 2018) is 2228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7120' is defined on line 551, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSIANA' Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Shore 3 Internet-Draft Fastly 4 Intended status: Standards Track R. Barnes 5 Expires: September 22, 2018 Mozilla 6 S. Huque 7 Salesforce 8 W. Toorop 9 NLnet Labs 10 March 21, 2018 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-07 15 Abstract 17 This draft describes a new TLS extension for transport of a DNS 18 record set serialized with the DNSSEC signatures needed to 19 authenticate that record set. The intent of this proposal is to 20 allow TLS clients to perform DANE authentication of a TLS server 21 without needing to perform additional DNS record lookups. It is not 22 intended to be used to validate the TLS server's address records. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 61 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4 64 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 65 4. Construction of Serialized Authentication Chains . . . . . . 7 66 5. Caching and Regeneration of the Authentication Chain . . . . 8 67 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 69 8. Mandating use of this extension . . . . . . . . . . . . . . . 9 70 9. DANE and Traditional PKIX Interoperation . . . . . . . . . . 10 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 13.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 14 78 A.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 15 79 A.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 18 80 A.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 20 81 A.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 21 83 1. Requirements Notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 2. Introduction 93 This draft describes a new TLS [RFC5246] [TLS13] extension for 94 transport of a DNS record set serialized with the DNSSEC signatures 95 [RFC4034] needed to authenticate that record set. The intent of this 96 proposal is to allow TLS clients to perform DANE Authentication 98 [RFC6698] [RFC7671] of a TLS server without performing additional DNS 99 record lookups and incurring the associated latency penalty. It also 100 provides the ability to avoid potential problems with TLS clients 101 being unable to look up DANE records because of an interfering or 102 broken middlebox on the path between the client and a DNS server 103 [HAMPERING]. And lastly, it allows a TLS client to validate the 104 server's DANE (TLSA) records itself without needing access to a 105 validating DNS resolver to which it has a secure connection. 107 This mechanism is useful for TLS applications that need to address 108 the problems described above, typically web browsers or SIP/VoIP 109 [RFC3261] and XMPP [RFC7590]. It may not be relevant for many other 110 applications. For example, SMTP MTAs are usually located in data 111 centers, may tolerate extra DNS lookup latency, are on servers where 112 it is easier to provision a validating resolver, or are less likely 113 to experience traffic interference from misconfigured middleboxes. 114 Furthermore, SMTP MTAs usually employ Opportunistic Security 115 [RFC7672], in which the presence of the DNS TLSA records is used to 116 determine whether to enforce an authenticated TLS connection. Hence 117 DANE authentication of SMTP MTAs will typically not use this 118 mechanism. 120 The extension described here allows a TLS client to request that the 121 TLS server return the DNSSEC authentication chain corresponding to 122 its DANE record. If the server is configured for DANE 123 authentication, then it performs the appropriate DNS queries, builds 124 the authentication chain, and returns it to the client. The server 125 will usually use a previously cached authentication chain, but it 126 will need to rebuild it periodically as described in Section 5. The 127 client then authenticates the chain using a pre-configured trust 128 anchor. 130 This specification is based on Adam Langley's original proposal for 131 serializing DNSSEC authentication chains and delivering them in an 132 X.509 certificate extension [I-D.agl-dane-serializechain]. It 133 modifies the approach by using wire format DNS records in the 134 serialized data (assuming that the data will be prepared and consumed 135 by a DNS-specific library), and by using a TLS extension to deliver 136 the data. 138 As described in the DANE specification [RFC6698] [RFC7671], this 139 procedure applies to the DANE authentication of X.509 certificates or 140 raw public keys [RFC7250]. 142 3. DNSSEC Authentication Chain Extension 144 3.1. Protocol, TLS 1.2 145 A client MAY include an extension of type "dnssec_chain" in the 146 (extended) ClientHello. The "extension_data" field of this extension 147 MUST be empty. 149 Servers receiving a "dnssec_chain" extension in the ClientHello and 150 which are capable of being authenticated via DANE, return a 151 serialized authentication chain in the extended ServerHello message 152 using the format described below. If a server is unable to return an 153 authentication chain, or does not wish to return an authentication 154 chain, it does not include a dnssec_chain extension. As with all TLS 155 extensions, if the server does not support this extension it will not 156 return any authentication chain. 158 3.2. Protocol, TLS 1.3 160 A client MAY include an extension of type "dnssec_chain" in the 161 ClientHello. The "extension_data" field of this extension MUST be 162 empty. 164 Servers receiving a "dnssec_chain" extension in the ClientHello, and 165 which are capable of being authenticated via DANE, return a 166 serialized authentication chain in the extension block of the 167 Certificate message containing the end entity certificate being 168 validated, using the format described below. 170 The extension protocol behavior otherwise follows that specified for 171 TLS version 1.2. 173 3.3. Raw Public Keys 175 [RFC7250] specifies the use of raw public keys for both server and 176 client authentication in TLS 1.2. It points out that in cases where 177 raw public keys are being used, code for certificate path validation 178 is not required. However, DANE, when used in conjunction with the 179 dnssec_chain extension, provides a mechanism for securely binding a 180 raw public key to a named entity in the DNS, and when using DANE for 181 authentication a raw key may be validated using a path chaining back 182 to a DNSSEC trust root. This has the added benefit of mitigating an 183 unknown key share attack, as described in [I-D.barnes-dane-uks], 184 since it effectively augments the raw public key with the server's 185 name and provides a means to commit both the server and the client to 186 using that binding. 188 The UKS attack is possible in situations in which the association 189 between a domain name and a public key is not tightly bound, as in 190 the case in DANE in which a client either ignores the name in the 191 certificate (as specified in [RFC7671]) or there is no attestation of 192 trust outside of the DNS. The vulnerability arises in the following 193 situations: 195 o If the client does not verify the identity in the server's 196 certificate (as recommended in Section 5.1 of [RFC7671]), then an 197 attacker can induce the client to accept an unintended identity 198 for the server, 200 o If the client allows the use of raw public keys in TLS, then it 201 will not receive any indication of the server's identity in the 202 TLS channel, and is thus unable to check that the server's 203 identity is as intended. 205 The mechanism for conveying DNSSEC validation chains described in 206 this document results in a commitment by both parties, via the TLS 207 handshake, to a validated domain name and EE key. 209 The mechanism for encoding DNSSEC authentication chains in a TLS 210 extension, as described in this document, is not limited to public 211 keys encapsulated in X.509 containers but MAY be applied to raw 212 public keys and other representations, as well. 214 3.4. DNSSEC Authentication Chain Data 216 The "extension_data" field of the "dnssec_chain" extension MUST 217 contain a DNSSEC Authentication Chain encoded in the following form: 219 opaque AuthenticationChain<1..2^16-1> 221 The AuthenticationChain structure is composed of a sequence of 222 uncompressed wire format DNS resource record sets (RRset) and 223 corresponding signatures (RRSIG) record sets. 225 This sequence of native DNS wire format records enables easier 226 generation of the data structure on the server and easier 227 verification of the data on client by means of existing DNS library 228 functions. 230 Each RRset in the chain is composed of a sequence of wire format DNS 231 resource records. The format of the resource record is described in 232 RFC 1035 [RFC1035], Section 3.2.1. 234 RR(i) = owner | type | class | TTL | RDATA length | RDATA 236 where RR(i) denotes the ith RR. 238 The resource records that make up a RRset all have the same owner, 239 type and class, but different RDATA as specified RFC 2181 [RFC2181], 240 Section 5. Each RRset in the sequence is followed by its associated 241 RRsig record set. This RRset has the same owner and class as the 242 preceding RRset, but has type RRSIG. The Type Covered field in the 243 RDATA of the RRsigs identifies the type of the preceding RRset as 244 described in RFC 4034 [RFC4034], Section 3. The RRsig record wire 245 format is described in RFC 4034 [RFC4034], Section 3.1. The 246 signature portion of the RDATA, as described in the same section, is 247 the following: 249 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 251 where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 252 the Signer's Name field in canonical form and the signature field 253 excluded. 255 The first RRset in the chain MUST contain the TLSA record set being 256 presented. However, if the owner name of the TLSA record set is an 257 alias (CNAME or DNAME), then it MUST be preceded by the chain of 258 alias records needed to resolve it. DNAME chains SHOULD omit 259 unsigned CNAME records that may have been synthesized in the response 260 from a DNS resolver. (If unsigned synthetic CNAMES are present, then 261 the TLS client will just ignore them, as they are not necessary to 262 validate the chain.) 264 The subsequent RRsets MUST contain the full set of DNS records needed 265 to authenticate the TLSA record set from the server's trust anchor. 266 Typically this means a set of DNSKEY and DS RRsets that cover all 267 zones from the target zone containing the TLSA record set to the 268 trust anchor zone. The TLS client should be prepared to receive this 269 set of RRsets in any order. 271 Names that are aliased via CNAME and/or DNAME records may involve 272 multiple branches of the DNS tree. In this case, the authentication 273 chain structure needs to include DS and DNSKEY record sets that cover 274 all the necessary branches. 276 If the TLSA record set was synthesized by a DNS wildcard, the chain 277 MUST include the signed NSEC or NSEC3 [RFC5155] records that prove 278 that there was no explicit match of the TLSA record name and no 279 closer wildcard match. 281 The final DNSKEY RRset in the authentication chain corresponds to the 282 trust anchor (typically the DNS root). This trust anchor is also 283 preconfigured in the TLS client, but including it in the response 284 from the server permits TLS clients to use the automated trust anchor 285 rollover mechanism defined in RFC 5011 [RFC5011] to update their 286 configured trust anchor. 288 The following is an example of the records in the AuthenticationChain 289 structure for the HTTPS server at www.example.com, where there are 290 zone cuts at "com." and "example.com." (record data are omitted here 291 for brevity): 293 _443._tcp.www.example.com. TLSA 294 RRSIG(_443._tcp.www.example.com. TLSA) 295 example.com. DNSKEY 296 RRSIG(example.com. DNSKEY) 297 example.com. DS 298 RRSIG(example.com. DS) 299 com. DNSKEY 300 RRSIG(com. DNSKEY) 301 com. DS 302 RRSIG(com. DS) 303 . DNSKEY 304 RRSIG(. DNSKEY) 306 4. Construction of Serialized Authentication Chains 308 This section describes a possible procedure for the server to use to 309 build the serialized DNSSEC chain. 311 When the goal is to perform DANE authentication [RFC6698] [RFC7671] 312 of the server, the DNS record set to be serialized is a TLSA record 313 set corresponding to the server's domain name, protocol, and port 314 number. 316 The domain name of the server MUST be that included in the TLS 317 server_name extension [RFC6066] when present. If the server_name 318 extension is not present, or if the server does not recognize the 319 provided name and wishes to proceed with the handshake rather than to 320 abort the connection, the server picks one of its configured domain 321 names associated with the server IP address to which the connection 322 has been established. 324 The TLSA record to be queried is constructed by prepending the _port 325 and _transport labels to the domain name as described in [RFC6698], 326 where "port" is the port number associated with the TLS server. The 327 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 328 port number label is the left-most label, followed by the transport, 329 followed by the base domain name. 331 The components of the authentication chain are typically built by 332 starting at the target record set and its corresponding RRSIG. Then 333 traversing the DNS tree upwards towards the trust anchor zone 334 (normally the DNS root), for each zone cut, the DNSKEY and DS RRsets 335 and their signatures are added. However, see Section 3.4 for 336 specific processing needed for aliases and wildcards. If DNS 337 response messages contain any domain names utilizing name compression 338 [RFC1035], then they MUST be uncompressed. 340 Newer DNS protocol enhancements, such as the EDNS Chain Query 341 extension [RFC7901] if supported, may offer easier ways to obtain all 342 of the chain data in one transaction with an upstream DNSSEC aware 343 recursive server. 345 5. Caching and Regeneration of the Authentication Chain 347 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 348 have validity periods (specifically signature expiration times). 349 After the TLS server constructs the serialized authentication chain, 350 it SHOULD cache and reuse it in multiple TLS connection handshakes. 351 However, it MUST refresh and rebuild the chain as TTLs and signature 352 validity periods dictate. A server implementation could carefully 353 track these parameters and requery component records in the chain 354 correspondingly. Alternatively, it could be configured to rebuild 355 the entire chain at some predefined periodic interval that does not 356 exceed the DNS TTLs or signature validity periods of the component 357 records in the chain. 359 6. Verification 361 A TLS client making use of this specification, and which receives a 362 DNSSEC authentication chain extension from a server, MUST use this 363 information to perform DANE authentication of the server. In order 364 to do this, it uses the mechanism specified by the DNSSEC protocol 365 [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a 366 DNSSEC validation engine or library. 368 If the authentication chain is correctly verified, the client then 369 performs DANE authentication of the server according to the DANE TLS 370 protocol [RFC6698] [RFC7671]. 372 Clients MAY cache the server's validated TLSA RRset or other 373 validated portions of the chain as an optimization to save signature 374 verification work for future connections. The period of such caching 375 MUST NOT exceed the TTL associated with those records. A client that 376 possesses a validated and unexpired TLSA RRset or the full chain in 377 its cache does not need to send the dnssec_chain extension for 378 subsequent connections to the same TLS server. It can use the cached 379 information to perform DANE authentication. 381 7. Trust Anchor Maintenance 383 The trust anchor may change periodically, e.g. when the operator of 384 the trust anchor zone performs a DNSSEC key rollover. TLS clients 385 using this specification MUST implement a mechanism to keep their 386 trust anchors up to date. They could use the method defined in 387 [RFC5011] to perform trust anchor updates inband in TLS, by tracking 388 the introduction of new keys seen in the trust anchor DNSKEY RRset. 389 However, alternative mechanisms external to TLS may also be utilized. 390 Some operating systems may have a system-wide service to maintain and 391 keep the root trust anchor up to date. In such cases, the TLS client 392 application could simply reference that as its trust anchor, 393 periodically checking whether it has changed. Some applications may 394 prefer to implement trust anchor updates as part of their automated 395 software updates. 397 8. Mandating use of this extension 399 Green field applications that are designed to always employ this 400 extension, could of course unconditionally mandate its use. 402 If TLS applications want to mandate the use of this extension for 403 specific servers, clients could maintain a whitelist of sites where 404 the use of this extension is forced. The client would refuse to 405 authenticate such servers if they failed to deliver this extension. 406 Client applications could also employ a Trust on First Use (TOFU) 407 like strategy, whereby they would record the fact that a server 408 offered the extension and use that knowledge to require it for 409 subsequent connections. 411 This protocol currently provides no way for a server to prove that it 412 doesn't have a TLSA record. Hence absent whitelists, a client 413 misdirected to a server that has fraudulently acquired a public CA 414 issued certificate for the real server's name, could be induced to 415 establish a PKIX verified connection to the rogue server that 416 precluded DANE authentication. This could be solved by enhancing 417 this protocol to require that servers without TLSA records need to 418 provide a DNSSEC authentication chain that proves this (i.e. the 419 chain includes NSEC or NSEC3 records that demonstrate either the 420 absence of the TLSA record, or the absence of a secure delegation to 421 the associated zone). Such an enhancement would be impossible to 422 deploy incrementally though since it requires all TLS servers to 423 support this protocol. 425 One possible way to address the threat of attackers that have 426 fraudulently obtained valid PKIX credentials, is to use current PKIX 427 defense mechanisms, such as checking Certificate Transparency logs to 428 detect certificate misissuance. This may be necessary anyway, as TLS 429 servers may support both DANE and PKIX authentication. Even TLS 430 servers that support only DANE may be interested in detecting PKIX 431 adversaries impersonating their service to DANE unaware TLS clients. 433 9. DANE and Traditional PKIX Interoperation 435 When DANE is being introduced incrementally into an existing PKIX 436 environment, there may be scenarios in which DANE authentication for 437 a server fails but PKIX succeeds, or vice versa. What happens here 438 depends on TLS client policy. If DANE authentication fails, the 439 client may decide to fallback to traditional PKIX authentication. In 440 order to do so efficiently within the same TLS handshake, the TLS 441 server needs to have provided the full X.509 certificate chain. When 442 TLS servers only support DANE-EE or DANE-TA modes, they have the 443 option to send a much smaller certificate chain: just the EE 444 certificate for the former, and a short certificate chain from the 445 DANE trust anchor to the EE certificate for the latter. If the TLS 446 server supports both DANE and traditional PKIX, and wants to allow 447 efficient PKIX fallback within the same handshake, they should always 448 provide the full X.509 certificate chain. 450 10. Security Considerations 452 The security considerations of the normatively referenced RFCs all 453 pertain to this extension. Since the server is delivering a chain of 454 DNS records and signatures to the client, it MUST rebuild the chain 455 in accordance with TTL and signature expiration of the chain 456 components as described in Section 5. TLS clients need roughly 457 accurate time in order to properly authenticate these signatures. 458 This could be achieved by running a time synchronization protocol 459 like NTP [RFC5905] or SNTP [RFC5905], which are already widely used 460 today. TLS clients MUST support a mechanism to track and rollover 461 the trust anchor key, or be able to avail themselves of a service 462 that does this, as described in Section 7. Security considerations 463 related to mandating the use of this extension are described in 464 Section 8. 466 11. IANA Considerations 468 This extension requires the registration of a new value in the TLS 469 ExtensionsType registry. The value requested from IANA is 53, and 470 the extension should be marked "Recommended" in accordance with "IANA 471 Registry Updates for TLS and DTLS" [TLSIANA]. 473 12. Acknowledgments 475 Many thanks to Adam Langley for laying the groundwork for this 476 extension. The original idea is his but our acknowledgment in no way 477 implies his endorsement. This document also benefited from 478 discussions with and review from the following people: Viktor 479 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 480 McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri 481 Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. 483 13. References 485 13.1. Normative References 487 [RFC1035] Mockapetris, P., "Domain names - implementation and 488 specification", STD 13, RFC 1035, November 1987. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 494 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 495 . 497 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 498 Rose, "Resource Records for the DNS Security Extensions", 499 RFC 4034, March 2005. 501 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 502 Rose, "Protocol Modifications for the DNS Security 503 Extensions", RFC 4035, March 2005. 505 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 506 Security (DNSSEC) Hashed Authenticated Denial of 507 Existence", RFC 5155, March 2008. 509 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 510 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 512 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 513 Extension Definitions", RFC 6066, January 2011. 515 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 516 of Named Entities (DANE) Transport Layer Security (TLS) 517 Protocol: TLSA", RFC 6698, August 2012. 519 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 520 Authentication of Named Entities (DANE) Protocol: Updates 521 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 522 October 2015, . 524 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 525 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 526 May 2017, . 528 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 529 Version 1.3", March 2018, . 532 [TLSIANA] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 533 and DTLS", , . 536 13.2. Informative References 538 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 539 A., Peterson, J., Sparks, R., Handley, M., and E. 540 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 541 DOI 10.17487/RFC3261, June 2002, . 544 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 545 Trust Anchors", STD 74, RFC 5011, September 2007. 547 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 548 Time Protocol Version 4: Protocol and Algorithms 549 Specification", RFC 5905, June 2010. 551 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 552 Points", BCP 100, RFC 7120, January 2014. 554 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 555 T. Kivinen, "Using Raw Public Keys in Transport Layer 556 Security (TLS) and Datagram Transport Layer Security 557 (DTLS)", RFC 7250, June 2014. 559 [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer 560 Security (TLS) in the Extensible Messaging and Presence 561 Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 562 2015, . 564 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 565 Opportunistic DNS-Based Authentication of Named Entities 566 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 567 10.17487/RFC7672, October 2015, 568 . 570 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 571 10.17487/RFC7901, June 2016, 572 . 574 [I-D.agl-dane-serializechain] 575 Langley, A., "Serializing DNS Records with DNSSEC 576 Authentication", draft-agl-dane-serializechain-01 (work in 577 progress), July 2011. 579 [I-D.barnes-dane-uks] 580 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 581 Share Attacks on DNS-based Authentications of Named 582 Entities (DANE)", draft-barnes-dane-uks-00 (work in 583 progress), October 2016. 585 [HAMPERING] 586 Gorjon, X. and W. Toorop, "Discovery method for a DNSSEC 587 validating stub resolver", July 2015, . 591 Appendix A. Test vectors 593 The provided test vectors will authenticate the certificate used with 594 https://example.com/, https://example.net/ and https://example.org/ 595 at the time of writing: 597 -----BEGIN CERTIFICATE----- 598 MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw 599 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 600 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz 601 dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa 602 MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML 603 TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB 604 c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY 605 MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A 606 MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u 607 Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo 608 D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V 609 RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3 610 jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a 611 z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw 612 FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW 613 5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t 614 ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh 615 bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud 616 DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f 617 BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy 618 dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt 619 aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG 620 AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB 621 gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy 622 dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E 623 aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC 624 MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q 625 6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP 626 PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy 627 ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI 628 l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS 629 wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII= 630 -----END CERTIFICATE----- 632 For brevity and reproducability all DNS zones involved with the test 633 vectors are signed using keys with algorithm 13: ECDSA Curve P-256 634 with SHA-256. 636 To reflect operational practice, different zones in the examples are 637 in different phases of rolling their signing keys: 639 All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), 640 except for the example.com and example.net zones which use a 641 Combined Signing Key (CSK). 643 The root and org zones are rolling their ZSK's. 645 The com and org zones are rolling their KSK's. 647 The test vectors are DNSSEC valid in the same period as the 648 certificate is valid, which is in between November 3 2015 and 649 November 28 2018, with the following root trust anchor: 651 . IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 652 641bb568746f2ffc4d4 ) 654 A.1. _443._tcp.www.example.com 656 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 657 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 658 ada ) 659 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 660 20181128000000 20151103000000 1870 example.com. 661 uml1DUjp5RfrXn9WtuMxEQV+ygzrONcuzsnyfOGSszwaDdkSOJ0Kndcfbb2Il 662 LUV04Z+V488+Sd1jr7/21tsKA== ) 663 example.com. 3600 IN DNSKEY ( 257 3 13 664 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 665 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 666 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 667 20181128000000 20151103000000 1870 example.com. 668 HujA9vQTbCxMeaYjDOCF0fYyHhajTl5xPztrp5u6P2vYV8naYQLG3zUF1gaer 669 WBOagXXblaSSbYwB96LU3uSdg== ) 670 example.com. 900 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd25a 671 986e8a44f319ac3cd302bafc08f5b81e16 ) 672 example.com. 900 IN RRSIG ( DS 13 2 900 20181128000000 673 20151103000000 34327 com. 674 1tua9ntAqZvOnK5UztzIjN38Bqs6mJ8KAT7L4+AxevDL+z0Jft7RC1/g6Qrfa 675 In1wqF4U7TvC8PYOD0U/HYtwQ== ) 676 com. 900 IN DNSKEY ( 256 3 13 677 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 678 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 679 com. 900 IN DNSKEY ( 257 3 13 680 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 681 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 682 com. 900 IN DNSKEY ( 257 3 13 683 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 684 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 685 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 686 20151103000000 18931 com. 687 lZmTBrfcRgVbqHJIfCVr6c3HUDgy3MlNSCSnrVV2S5/NmB3ZiFcvIDn0iqXPm 688 7YQfvfWi6utyxBu/fSD6S1ARw== ) 689 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 690 20151103000000 28809 com. 691 8qZOVM4X8wGt5XPWhG2HO4FAD6Kvs5eIhZUz+7DVCrZ/XMEVrMIHcm1Q+sq0s 692 hm4cSivK2BxOO24PHJXoZN2Lw== ) 693 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 694 f9eabb94487e658c188e7bcb52115 ) 695 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 696 70643bbde681db342a9e5cf2bb380 ) 697 com. 86400 IN RRSIG ( DS 13 1 86400 20181128000000 698 20151103000000 31918 . 699 5KQVa0NP+6k7VEGMmeky2/Y3wIGM70Fkm0vp5NmQ6KPk8L1XMJPltcJDWGGjc 700 EU3Uc4z2DUxzZyWgEDdrSOcdw== ) 701 . 86400 IN DNSKEY ( 256 3 13 702 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 703 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 704 . 86400 IN DNSKEY ( 256 3 13 705 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 706 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 707 . 86400 IN DNSKEY ( 257 3 13 708 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 709 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 710 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20181128000000 711 20151103000000 47005 . 712 ehAzuZD3yT0pShXkKavrMdz+DKvvFvbZ+sGRZ5iQTni+ulMzZxHQ5+kSha65B 713 Y2AIUphjyWcGr6VwP3Ne74iZA== ) 715 A hex dump of the wire format data of this content is: 717 0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65 718 0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00 719 0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78 720 0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a 721 0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74 722 0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 723 0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d 724 0070: 05 00 00 0e 10 5b fd da 80 56 37 f9 00 07 4e 07 725 0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ba 69 75 0d 726 0090: 48 e9 e5 17 eb 5e 7f 56 b6 e3 31 11 05 7e ca 0c 727 00a0: eb 38 d7 2e ce c9 f2 7c e1 92 b3 3c 1a 0d d9 12 728 00b0: 38 9d 0a 9d d7 1f 6d bd 88 94 b5 15 d3 86 7e 57 729 00c0: 8f 3c f9 27 75 8e be ff db 5b 6c 28 07 65 78 61 730 00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e 731 00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe 732 00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8 733 0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9 734 0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e 735 0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03 736 0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30 737 0140: 0d 02 00 00 0e 10 5b fd da 80 56 37 f9 00 07 4e 738 0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 1e e8 c0 739 0160: f6 f4 13 6c 2c 4c 79 a6 23 0c e0 85 d1 f6 32 1e 740 0170: 16 a3 4e 5e 71 3f 3b 6b a7 9b ba 3f 6b d8 57 c9 741 0180: da 61 02 c6 df 35 05 d6 06 9e ad 60 4e 6a 05 d7 742 0190: 6e 56 92 49 b6 30 07 de 8b 53 7b 92 76 07 65 78 743 01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00 744 01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90 745 01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3 746 01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65 747 01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00 748 01f0: 2b 0d 02 00 00 03 84 5b fd da 80 56 37 f9 00 86 749 0200: 17 03 63 6f 6d 00 d6 db 9a f6 7b 40 a9 9b ce 9c 750 0210: ae 54 ce dc c8 8c dd fc 06 ab 3a 98 9f 0a 01 3e 751 0220: cb e3 e0 31 7a f0 cb fb 3d 09 7e de d1 0b 5f e0 752 0230: e9 0a df 68 89 f5 c2 a1 78 53 b4 ef 0b c3 d8 38 753 0240: 3d 14 fc 76 2d c1 03 63 6f 6d 00 00 30 00 01 00 754 0250: 00 03 84 00 44 01 00 03 0d ec 82 04 e4 3a 25 f2 755 0260: 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d c2 a4 756 0270: 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca f2 e9 757 0280: cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 56 b6 80 758 0290: 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 00 00 30 759 02a0: 00 01 00 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b 760 02b0: ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77 761 02c0: a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7 762 02d0: 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64 763 02e0: 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d 764 02f0: 00 00 30 00 01 00 00 03 84 00 44 01 01 03 0d b3 765 0300: 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d9 ac 5e 766 0310: 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 95 8f 71 767 0320: c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 38 95 93 768 0330: 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 93 90 03 769 0340: 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00 30 770 0350: 0d 01 00 00 03 84 5b fd da 80 56 37 f9 00 49 f3 771 0360: 03 63 6f 6d 00 95 99 93 06 b7 dc 46 05 5b a8 72 772 0370: 48 7c 25 6b e9 cd c7 50 38 32 dc c9 4d 48 24 a7 773 0380: ad 55 76 4b 9f cd 98 1d d9 88 57 2f 20 39 f4 8a 774 0390: a5 cf 9b b6 10 7e f7 d6 8b ab ad cb 10 6e fd f4 775 03a0: 83 e9 2d 40 47 03 63 6f 6d 00 00 2e 00 01 00 00 776 03b0: 03 84 00 57 00 30 0d 01 00 00 03 84 5b fd da 80 777 03c0: 56 37 f9 00 70 89 03 63 6f 6d 00 f2 a6 4e 54 ce 778 03d0: 17 f3 01 ad e5 73 d6 84 6d 87 3b 81 40 0f a2 af 779 03e0: b3 97 88 85 95 33 fb b0 d5 0a b6 7f 5c c1 15 ac 780 03f0: c2 07 72 6d 50 fa ca b4 b2 19 b8 71 28 af 2b 60 781 0400: 71 38 ed b8 3c 72 57 a1 93 76 2f 03 63 6f 6d 00 782 0410: 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 02 20 f7 783 0420: a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 41 20 2f 784 0430: 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 15 03 63 785 0440: 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 70 89 0d 786 0450: 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 73 e9 2c 787 0460: 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf 2b b3 788 0470: 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00 53 789 0480: 00 2b 0d 01 00 01 51 80 5b fd da 80 56 37 f9 00 790 0490: 7c ae 00 e4 a4 15 6b 43 4f fb a9 3b 54 41 8c 99 791 04a0: e9 32 db f6 37 c0 81 8c ef 41 64 9b 4b e9 e4 d9 792 04b0: 90 e8 a3 e4 f0 bd 57 30 93 e5 b5 c2 43 58 61 a3 793 04c0: 70 45 37 51 ce 33 d8 35 31 cd 9c 96 80 40 dd ad 794 04d0: 23 9c 77 00 00 30 00 01 00 01 51 80 00 44 01 00 795 04e0: 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a2 54 f7 796 04f0: 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca 8c e3 797 0500: f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 68 e3 58 798 0510: ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d4 ce 8d 799 0520: fe 14 00 00 30 00 01 00 01 51 80 00 44 01 00 03 800 0530: 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f2 4c ac 801 0540: fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b3 21 c1 802 0550: d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 91 5b 16 803 0560: d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d1 1d 17 804 0570: 11 00 00 30 00 01 00 01 51 80 00 44 01 01 03 0d 805 0580: ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad 21 55 806 0590: ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 17 36 807 05a0: d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd 0f a0 808 05b0: 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 ad 46 809 05c0: 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d 00 00 810 05d0: 01 51 80 5b fd da 80 56 37 f9 00 b7 9d 00 7a 10 811 05e0: 33 b9 90 f7 c9 3d 29 4a 15 e4 29 ab eb 31 dc fe 812 05f0: 0c ab ef 16 f6 d9 fa c1 91 67 98 90 4e 78 be ba 813 0600: 53 33 67 11 d0 e7 e9 12 85 ae b9 05 8d 80 21 4a 814 0610: 61 8f 25 9c 1a be 95 c0 fd cd 7b be 22 64 816 A.2. _25._tcp.example.com wildcard 818 _25._tcp.example.com. 3600 IN TLSA ( 3 1 1 819 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 820 ada ) 821 _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 822 20181128000000 20151103000000 1870 example.com. 823 e7Q5L2x7Ca3SkSY6pRjqgtRxkEN1uYUcgyMlPp6GQ4zxAZxoO1Y1vGqxN4eNA 824 +yBnlUSIJQ46KKVS5PC79Qipg== ) 825 *._tcp.example.com. 3600 IN NSEC ( 826 _443._tcp.www.example.com. RRSIG NSEC TLSA ) 827 *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 828 20181128000000 20151103000000 1870 example.com. 829 FlTtPqEPUPAQozlbt7bD9s2XIxdVPJ3nb+jK94Fxa2JsaZChH1n/DsYb5KS7J 830 G5GyubhMFTLeIqwTngx6JCktg== ) 831 example.com. 3600 IN DNSKEY ( 257 3 13 832 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 833 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 834 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 835 20181128000000 20151103000000 1870 example.com. 836 HujA9vQTbCxMeaYjDOCF0fYyHhajTl5xPztrp5u6P2vYV8naYQLG3zUF1gaer 837 WBOagXXblaSSbYwB96LU3uSdg== ) 838 example.com. 900 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd25a 839 986e8a44f319ac3cd302bafc08f5b81e16 ) 840 example.com. 900 IN RRSIG ( DS 13 2 900 20181128000000 841 20151103000000 34327 com. 842 1tua9ntAqZvOnK5UztzIjN38Bqs6mJ8KAT7L4+AxevDL+z0Jft7RC1/g6Qrfa 843 In1wqF4U7TvC8PYOD0U/HYtwQ== ) 844 com. 900 IN DNSKEY ( 256 3 13 845 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 846 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 847 com. 900 IN DNSKEY ( 257 3 13 848 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 849 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 850 com. 900 IN DNSKEY ( 257 3 13 851 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 852 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 853 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 854 20151103000000 18931 com. 855 lZmTBrfcRgVbqHJIfCVr6c3HUDgy3MlNSCSnrVV2S5/NmB3ZiFcvIDn0iqXPm 856 7YQfvfWi6utyxBu/fSD6S1ARw== ) 857 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 858 20151103000000 28809 com. 859 8qZOVM4X8wGt5XPWhG2HO4FAD6Kvs5eIhZUz+7DVCrZ/XMEVrMIHcm1Q+sq0s 860 hm4cSivK2BxOO24PHJXoZN2Lw== ) 861 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 862 f9eabb94487e658c188e7bcb52115 ) 863 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 864 70643bbde681db342a9e5cf2bb380 ) 865 com. 86400 IN RRSIG ( DS 13 1 86400 20181128000000 866 20151103000000 31918 . 867 5KQVa0NP+6k7VEGMmeky2/Y3wIGM70Fkm0vp5NmQ6KPk8L1XMJPltcJDWGGjc 868 EU3Uc4z2DUxzZyWgEDdrSOcdw== ) 869 . 86400 IN DNSKEY ( 256 3 13 870 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 871 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 872 . 86400 IN DNSKEY ( 256 3 13 873 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 874 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 875 . 86400 IN DNSKEY ( 257 3 13 876 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 877 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 878 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20181128000000 879 20151103000000 47005 . 880 ehAzuZD3yT0pShXkKavrMdz+DKvvFvbZ+sGRZ5iQTni+ulMzZxHQ5+kSha65B 881 Y2AIUphjyWcGr6VwP3Ne74iZA== ) 883 A.3. _443._tcp.www.example.org CNAME 885 _443._tcp.www.example.org. 3600 IN CNAME ( 886 dane311.example.org. ) 887 _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 888 20181128000000 20151103000000 56566 example.org. 889 wLQYbRNMqrXCD65GZJqwwsD0TDF2VQTklBYdYCMo+JTjqvZw1UFYmcJXmwJsL 890 KezLIzSdKW6jK0LMJ3YUw3Bmw== ) 891 dane311.example.org. 3600 IN TLSA ( 3 1 1 892 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 893 ada ) 894 dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 895 20181128000000 20151103000000 56566 example.org. 896 AllKVcpLz/9vG/xJQFwWEK0cHbjO6lI65ELWSoWxPvYJ5o8QnSbRkzfCM4lTs 897 g94s5VvzMLYIbSZ1TWo2hcCdg== ) 898 example.org. 3600 IN DNSKEY ( 256 3 13 899 NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N 900 UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566 901 example.org. 3600 IN DNSKEY ( 257 3 13 902 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 903 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 904 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 905 20181128000000 20151103000000 44384 example.org. 906 ZsQ5wl2ZvofwDq7uYlvoqEeq9byHbl59Ap4EPXdB4PpnWy2dJkIElgXCfILrU 907 EUCD1aKb2SoRZe18EJ8LMVJuw== ) 908 example.org. 900 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a513c 909 8003e1d9121f1ff11a08b4cdd348d090aa6 ) 910 example.org. 900 IN RRSIG ( DS 13 2 900 20181128000000 911 20151103000000 9523 org. 912 15KUWAaNkJehAUdqm46TdeGg6mVm6bVKeaWLr34FTJlfMWWij+kmA6SM/bZbq 913 kZBjtMWT55XersA+llFQNQI/Q== ) 914 org. 900 IN DNSKEY ( 256 3 13 915 fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e 916 HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417 917 org. 900 IN DNSKEY ( 256 3 13 918 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy 919 mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523 920 org. 900 IN DNSKEY ( 257 3 13 921 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 922 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352 924 org. 900 IN DNSKEY ( 257 3 13 925 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 926 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 927 org. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 928 20151103000000 12651 org. 929 G9I7dIh5Zn2hBu8jhgnLDTXZUpnPRkOMHjl1RcyHNbvJGLIiaPRVtcJXW0Vr+ 930 arygWmsHrDgWz0vw2IXZr3qKw== ) 931 org. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 932 20151103000000 49352 org. 933 iQmYWqUdU07Syw1Fqwx+8+hSk0w06tCGmkwdppyxUSFESumEhkOXgOv6NuIEn 934 eKjwMIaLj5HFB+9WnOkzgGE5Q== ) 935 org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 936 9db5c24a75743eb1e704b97a9fabc ) 937 org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe 938 f4a2f18920db5f58710dd767c293b ) 939 org. 86400 IN RRSIG ( DS 13 1 86400 20181128000000 940 20151103000000 31918 . 941 JGPMvEbfLoWNUELn/5cjjdRZx2CmdikbHuH6N/1BrxACWrGy05NuPvBPTEVOr 942 mPFfm5SIMLLTWgxf0K0FsNHoQ== ) 943 . 86400 IN DNSKEY ( 256 3 13 944 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 945 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 946 . 86400 IN DNSKEY ( 256 3 13 947 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 948 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 949 . 86400 IN DNSKEY ( 257 3 13 950 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 951 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 952 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20181128000000 953 20151103000000 47005 . 954 ehAzuZD3yT0pShXkKavrMdz+DKvvFvbZ+sGRZ5iQTni+ulMzZxHQ5+kSha65B 955 Y2AIUphjyWcGr6VwP3Ne74iZA== ) 957 A.4. _443._tcp.www.example.net DNAME 959 example.net. 3600 IN DNAME example.com. 960 example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20181128000000 961 20151103000000 48085 example.net. 962 +MJa5ZEmYh/kHYOhabF3ibfJ5xhJDJAA76Sugc/LFyTDJbmYW/nlYf3XLdcDh 963 7lv6NfCkPuv6eCkSFGnVVvriA== ) 964 _443._tcp.www.example.net. 3600 IN CNAME ( 965 _443._tcp.www.example.com. ) 966 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 967 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 968 ada ) 969 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 970 20181128000000 20151103000000 1870 example.com. 972 uml1DUjp5RfrXn9WtuMxEQV+ygzrONcuzsnyfOGSszwaDdkSOJ0Kndcfbb2Il 973 LUV04Z+V488+Sd1jr7/21tsKA== ) 974 example.net. 3600 IN DNSKEY ( 257 3 13 975 X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d 976 9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085 977 example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600 978 20181128000000 20151103000000 48085 example.net. 979 Qu7q2IheqxAKGnchYSvQeJuXdnBj/+wJoEmv67wemOUI6qvWWIo535w+hguUV 980 mZm/W5rp3qWBGChLxxfqIK13g== ) 981 example.net. 900 IN DS ( 48085 13 2 7c1998ce683df60e2fa41460c453f 982 88f463dac8cd5d074277b4a7c04502921be ) 983 example.net. 900 IN RRSIG ( DS 13 2 900 20181128000000 984 20151103000000 10713 net. 985 xxSlIJlpOSmrUgwR++os2SHTpRf53SO95G6FQyH5lEslnTnbZoq0p/AVrlB8q 986 Qw3qmSXjRwGW3VFbkV60/tWCg== ) 987 net. 900 IN DNSKEY ( 256 3 13 988 061EoQs4sBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimi4/lw/vtyfqALuLF 989 JiFjtCK3HMPi8HQ1jbGEwbGCA== ) ; Key ID = 10713 990 net. 900 IN DNSKEY ( 257 3 13 991 LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5 992 oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485 993 net. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 994 20151103000000 485 net. 995 CC494bZrtBHXImEZpe6E3h6NL0R5fRR/MEuC1f2sfC6/dlCjRwFjCy9eOKnFL 996 ar4Rxbpf7dvEwqGHNTawEo6jw== ) 997 net. 86400 IN DS ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c 998 d8c247769b23adb13ca234d1c05 ) 999 net. 86400 IN RRSIG ( DS 13 1 86400 20181128000000 1000 20151103000000 31918 . 1001 q+G4l97pYbFgAUhzzOW5+YoFiJc5omUbe20H28AwMHOrx19BdGp/2XhKDQ5F3 1002 tUTNerRmklzYm+7J/XtLpGXAw== ) 1003 . 86400 IN DNSKEY ( 256 3 13 1004 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1005 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1006 . 86400 IN DNSKEY ( 256 3 13 1007 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1008 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1009 . 86400 IN DNSKEY ( 257 3 13 1010 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1011 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1012 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20181128000000 1013 20151103000000 47005 . 1014 ehAzuZD3yT0pShXkKavrMdz+DKvvFvbZ+sGRZ5iQTni+ulMzZxHQ5+kSha65B 1015 Y2AIUphjyWcGr6VwP3Ne74iZA== ) 1016 example.com. 3600 IN DNSKEY ( 257 3 13 1017 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 1018 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 1019 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 1020 20181128000000 20151103000000 1870 example.com. 1021 HujA9vQTbCxMeaYjDOCF0fYyHhajTl5xPztrp5u6P2vYV8naYQLG3zUF1gaer 1022 WBOagXXblaSSbYwB96LU3uSdg== ) 1023 example.com. 900 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd25a 1024 986e8a44f319ac3cd302bafc08f5b81e16 ) 1025 example.com. 900 IN RRSIG ( DS 13 2 900 20181128000000 1026 20151103000000 34327 com. 1027 1tua9ntAqZvOnK5UztzIjN38Bqs6mJ8KAT7L4+AxevDL+z0Jft7RC1/g6Qrfa 1028 In1wqF4U7TvC8PYOD0U/HYtwQ== ) 1029 com. 900 IN DNSKEY ( 256 3 13 1030 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 1031 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 1032 com. 900 IN DNSKEY ( 257 3 13 1033 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 1034 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 1035 com. 900 IN DNSKEY ( 257 3 13 1036 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 1037 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 1038 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 1039 20151103000000 18931 com. 1040 lZmTBrfcRgVbqHJIfCVr6c3HUDgy3MlNSCSnrVV2S5/NmB3ZiFcvIDn0iqXPm 1041 7YQfvfWi6utyxBu/fSD6S1ARw== ) 1042 com. 900 IN RRSIG ( DNSKEY 13 1 900 20181128000000 1043 20151103000000 28809 com. 1044 8qZOVM4X8wGt5XPWhG2HO4FAD6Kvs5eIhZUz+7DVCrZ/XMEVrMIHcm1Q+sq0s 1045 hm4cSivK2BxOO24PHJXoZN2Lw== ) 1046 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 1047 f9eabb94487e658c188e7bcb52115 ) 1048 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 1049 70643bbde681db342a9e5cf2bb380 ) 1050 com. 86400 IN RRSIG ( DS 13 1 86400 20181128000000 1051 20151103000000 31918 . 1052 5KQVa0NP+6k7VEGMmeky2/Y3wIGM70Fkm0vp5NmQ6KPk8L1XMJPltcJDWGGjc 1053 EU3Uc4z2DUxzZyWgEDdrSOcdw== ) 1055 Authors' Addresses 1057 Melinda Shore 1058 Fastly 1060 EMail: mshore@fastly.com 1062 Richard Barnes 1063 Mozilla 1065 EMail: rlb@ipv.sx 1066 Shumon Huque 1067 Salesforce 1069 EMail: shuque@gmail.com 1071 Willem Toorop 1072 NLnet Labs 1074 EMail: willem@nlnetlabs.nl