idnits 2.17.1 draft-ietf-tls-dnssec-chain-extension-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 687 has weird spacing: '...a 66 ac a4 a7...' == Line 692 has weird spacing: '...e c7 ef a4 e6...' == Line 698 has weird spacing: '...2 76 fd a5 82...' == Line 712 has weird spacing: '...7 d1 fa ad 5b...' == Line 717 has weird spacing: '...e 8d bd e6 e1...' -- The document date (January 23, 2018) is 2285 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: July 27, 2018 Mozilla 6 S. Huque 7 Salesforce 8 W. Toorop 9 NLnet Labs 10 January 23, 2018 12 A DANE Record and DNSSEC Authentication Chain Extension for TLS 13 draft-ietf-tls-dnssec-chain-extension-06 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 will 22 typically not be used for general DNSSEC validation of TLS endpoint 23 names. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 27, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 4 62 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4 65 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 66 4. Construction of Serialized Authentication Chains . . . . . . 7 67 5. Caching and Regeneration of the Authentication Chain . . . . 8 68 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 70 8. Mandating use of this extension . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 12.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 12 78 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 12 79 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 12 80 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13 81 D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 14 82 D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 16 83 D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 17 84 D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 18 86 1. Requirements Notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 This draft describes a new TLS [RFC5246] extension for transport of a 95 DNS record set serialized with the DNSSEC signatures [RFC4034] needed 96 to authenticate that record set. The intent of this proposal is to 97 allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] 98 of a TLS server without performing additional DNS record lookups and 99 incurring the associated latency penalty. It also provides the 100 ability to avoid potential problems with TLS clients being unable to 101 look up DANE records because of an interfering or broken middlebox on 102 the path between the client and a DNS server. And lastly, it allows 103 a TLS client to validate DANE records itself without necessarily 104 needing access to a validating DNS resolver to which it has a secure 105 connection. It will typically not be used for general DNSSEC 106 validation of endpoint names, but is more appropriate for validation 107 of DANE TLSA records. 109 This mechanism is useful for TLS applications that need to address 110 the problems described above, typically web browsers or VoIP and XMPP 111 applications. It may not be relevant for many other applications. 112 For example, SMTP MTAs are usually located in data centers, may 113 tolerate extra DNS lookup latency, are on servers where it is easier 114 to provision a validating resolver, or are less likely to experience 115 traffic interference from misconfigured middleboxes. Furthermore, 116 SMTP MTAs usually employ Opportunistic Security [RFC7672], in which 117 the presence of the DNS TLSA records is used to determine whether to 118 enforce an authenticated TLS connection. Hence DANE authentication 119 of SMTP MTAs will typically not use this mechanism. 121 The extension described here allows a TLS client to request in the 122 ClientHello message that the DNS authentication chain be returned in 123 the (extended) ServerHello message. If the server is configured for 124 DANE authentication, then it performs the appropriate DNS queries, 125 builds the authentication chain, and returns it to the client. The 126 server will usually use a previously cached authentication chain, but 127 it will need to rebuild it periodically as described in Section 5. 128 The client then authenticates the chain using a pre-configured trust 129 anchor. 131 This specification is based on Adam Langley's original proposal for 132 serializing DNSSEC authentication chains and delivering them in an 133 X.509 certificate extension [I-D.agl-dane-serializechain]. It 134 modifies the approach by using wire format DNS records in the 135 serialized data (assuming that the data will be prepared and consumed 136 by a DNS-specific library), and by using a TLS extension to deliver 137 the data. 139 As described in the DANE specification [RFC6698] [RFC7671], this 140 procedure applies to the DANE authentication of X.509 certificates or 141 raw public keys [RFC7250]. 143 3. DNSSEC Authentication Chain Extension 145 3.1. Protocol, TLS 1.2 147 A client MAY include an extension of type "dnssec_chain" in the 148 (extended) ClientHello. The "extension_data" field of this extension 149 MUST be empty. 151 Servers receiving a "dnssec_chain" extension in the ClientHello, and 152 which are capable of being authenticated via DANE, MAY return a 153 serialized authentication chain in the extended ServerHello message, 154 using the format described below. If a server is unable to return an 155 authentication chain, or does not wish to return an authentication 156 chain, it does not include a dnssec_chain extension. As with all TLS 157 extensions, if the server does not support this extension it will not 158 return any authentication chain. 160 A client must not be able to force a server to perform lookups on 161 arbitrary domain names using this mechanism. Therefore, a server 162 MUST NOT construct chains for domain names other than its own. 164 3.2. Protocol, TLS 1.3 166 A client MAY include an extension of type "dnssec_chain" in the 167 ClientHello. The "extension_data" field of this extension MUST be 168 empty. 170 Servers receiving a "dnssec_chain" extension in the ClientHello, and 171 which are capable of being authenticated via DANE, SHOULD return a 172 serialized authentication chain in the extension block of the 173 Certificate message containing the end entity certificate being 174 validated, using the format described below. 176 The extension protocol behavior otherwise follows that specified for 177 TLS version 1.2. 179 3.3. Raw Public Keys 181 [RFC7250] specifies the use of raw public keys for both server and 182 client authentication in TLS 1.2. It points out that in cases where 183 raw public keys are being used, code for certificate path validation 184 is not required. However, DANE, when used in conjunction with the 185 dnssec_chain extension, provides a mechanism for securely binding a 186 raw public key to a named entity in the DNS, and when using DANE for 187 authentication a raw key may be validated using a path chaining back 188 to a DNSSEC trust root. This has the added benefit of mitigating an 189 unknown key share attack, as described in [I-D.barnes-dane-uks], 190 since it effectively augments the raw public key with the server's 191 name and provides a means to commit both the server and the client to 192 using that binding. 194 The UKS attack is possible in situations in which the association 195 between a domain name and a public key is not tightly bound, as in 196 the case in DANE in which a client either ignores the name in 197 certificate (as specified in [RFC7671] or there is no attestation of 198 trust outside of the DNS. The vulnerability arises in the following 199 situations: 201 o If the client does not verify the identity in the server's 202 certificate (as recommended in Section 5.1 of [RFC7671]), then an 203 attacker can induce the client to accept an unintended identity 204 for the server, 206 o If the client allows the use of raw public keys in TLS, then it 207 will not receive any indication of the server's identity in the 208 TLS channel, and is thus unable to check that the server's 209 identity is as intended. 211 The mechanism for conveying DNSSEC validation chains described in 212 this document results in a commitment by both parties, via the TLS 213 handshake, to a domain name which has been validated as belonging to 214 the owner name. 216 The mechanism for encoding DNSSEC authentication chains in a TLS 217 extension, as described in this document, is not limited to public 218 keys encapsulated in X.509 containers but MAY be applied to raw 219 public keys and other representations, as well. 221 3.4. DNSSEC Authentication Chain Data 223 The "extension_data" field of the "dnssec_chain" extension MUST 224 contain a DNSSEC Authentication Chain encoded in the following form: 226 opaque AuthenticationChain<0..2^16-1> 228 The AuthenticationChain structure is composed of a sequence of 229 uncompressed wire format DNS resource record sets (RRset) and 230 corresponding signatures (RRSIG) record sets. 232 This sequence of native DNS wire format records enables easier 233 generation of the data structure on the server and easier 234 verification of the data on client by means of existing DNS library 235 functions. However this document describes the data structure in 236 sufficient detail that implementers if they desire can write their 237 own code to do this. 239 Each RRset in the chain is composed of a sequence of wire format DNS 240 resource records. The format of the resource record is described in 241 RFC 1035 [RFC1035], Section 3.2.1. 243 RR(i) = owner | type | class | TTL | RDATA length | RDATA 245 Each RRset in the sequence is followed by its associated RRsig record 246 set. The RRsig record wire format is described in RFC 4034 247 [RFC4034], Section 3.1. The signature portion of the RDATA, as 248 described in the same section, is the following: 250 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 252 where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 253 the Signer's Name field in canonical form and the signature field 254 excluded. 256 The first RRset in the chain MUST contain the TLSA record set being 257 presented. However, if the owner name of the TLSA record set is an 258 alias (CNAME or DNAME), then it MUST be preceded by the chain of 259 alias records needed to resolve it. DNAME chains should omit 260 unsigned CNAME records that may have been synthesized in the response 261 from a DNS resolver. 263 The subsequent RRsets MUST contain the full set of DNS records needed 264 to authenticate the TLSA record set from the server's trust anchor. 265 Typically this means a set of DNSKEY and DS RRsets that cover all 266 zones from the target zone containing the TLSA record set to the 267 trust anchor zone. The TLS client should be prepared to receive this 268 set of RRsets in any order. 270 Names that are aliased via CNAME and/or DNAME records may involve 271 multiple branches of the DNS tree. In this case, the authentication 272 chain structure needs to include DS and DNSKEY record sets that cover 273 all the necessary branches. 275 If the TLSA record set was synthesized by a DNS wildcard, the chain 276 must include the signed NSEC or NSEC3 records that prove that there 277 was no explicit match of the TLSA record name and no closer wildcard 278 match. 280 The final DNSKEY RRset in the authentication chain corresponds to the 281 trust anchor (typically the DNS root). This trust anchor is also 282 preconfigured in the TLS client, but including it in the response 283 from the server permits TLS clients to use the automated trust anchor 284 rollover mechanism defined in RFC 5011 [RFC5011] to update their 285 configured trust anchor. 287 The following is an example of the records in the AuthenticationChain 288 structure for the HTTPS server at www.example.com, where there are 289 zone cuts at "com." and "example.com." (record data are omitted here 290 for brevity): 292 _443._tcp.www.example.com. TLSA 293 RRSIG(_443._tcp.www.example.com. TLSA) 294 example.com. DNSKEY 295 RRSIG(example.com. DNSKEY) 296 example.com. DS 297 RRSIG(example.com. DS) 298 com. DNSKEY 299 RRSIG(com. DNSKEY) 300 com. DS 301 RRSIG(com. DS) 302 . DNSKEY 303 RRSIG(. DNSKEY) 305 4. Construction of Serialized Authentication Chains 307 This section describes a possible procedure for the server to use to 308 build the serialized DNSSEC chain. 310 When the goal is to perform DANE authentication [RFC6698] [RFC7671] 311 of the server, the DNS record set to be serialized is a TLSA record 312 set corresponding to the server's domain name, protocol, and port 313 number. 315 The domain name of the server MUST be that included in the TLS 316 server_name extension [RFC6066] when present. If the server_name 317 extension is not present, or if the server does not recognize the 318 provided name and wishes to proceed with the handshake rather than to 319 abort the connection, the server uses the domain name associated with 320 the server IP address to which the connection has been established. 322 The TLSA record to be queried is constructed by prepending the _port 323 and _transport labels to the domain name as described in [RFC6698], 324 where "port" is the port number associated with the TLS server. The 325 transport is "tcp" for TLS servers, and "udp" for DTLS servers. The 326 port number label is the left-most label, followed by the transport, 327 followed by the base domain name. 329 The components of the authentication chain are typically built by 330 starting at the target record set and its corresponding RRSIG. Then 331 traversing the DNS tree upwards towards the trust anchor zone 332 (normally the DNS root), for each zone cut, the DNSKEY and DS RRsets 333 and their signatures are added. However, see Section 3.4 for 334 specific processing needed for aliases and wildcards. If DNS 335 responses messages contain any domain names utilizing name 336 compression [RFC1035], then they must be uncompressed. 338 Newer DNS protocol enhancements, such as the EDNS Chain Query 339 extension [RFC7901] if supported, may offer easier ways to obtain all 340 of the chain data in one transaction with an upstream DNSSEC aware 341 recursive server. 343 5. Caching and Regeneration of the Authentication Chain 345 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 346 have validity periods (specifically signature expiration times). 347 After the TLS server constructs the serialized authentication chain, 348 it SHOULD cache and reuse it in multiple TLS connection handshakes. 349 However, it MUST refresh and rebuild the chain as TTLs and signature 350 validity periods dictate. A server implementation could carefully 351 track these parameters and requery component records in the chain 352 correspondingly. Alternatively, it could be configured to rebuild 353 the entire chain at some predefined periodic interval that does not 354 exceed the DNS TTLs or signature validity periods of the component 355 records in the chain. 357 6. Verification 359 A TLS client making use of this specification, and which receives a 360 DNSSEC authentication chain extension from a server, SHOULD use this 361 information to perform DANE authentication of the server. In order 362 to do this, it uses the mechanism specified by the DNSSEC protocol 363 [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a 364 DNSSEC validation engine or library. 366 If the authentication chain is correctly verified, the client then 367 performs DANE authentication of the server according to the DANE TLS 368 protocol [RFC6698] [RFC7671]. 370 Clients MAY cache the server's validated TLS RRset or other validated 371 portions of the chain as an optimization to save signature 372 verification work for future connections. The period of such caching 373 MUST NOT exceed the TTL associated with those records. 375 7. Trust Anchor Maintenance 377 The trust anchor may change periodically, e.g. when the operator of 378 the trust anchor zone performs a DNSSEC key rollover. TLS clients 379 using this specification MUST implement a mechanism to keep their 380 trust anchors up to date. They could use the method defined in 381 [RFC5011] to perform trust anchor updates inband in TLS, by tracking 382 the introduction of new keys seen in the trust anchor DNSKEY RRset. 383 However, alternative mechanisms external to TLS may also be utilized. 384 Some operating systems may have a system-wide service to maintain and 385 keep the root trust anchor up to date. In such cases, the TLS client 386 application could simply reference that as its trust anchor, 387 periodically checking whether it has changed. Some applications may 388 prefer to implement trust anchor updates as part of their automated 389 software updates. 391 8. Mandating use of this extension 393 Green field applications that are designed to always employ this 394 extension, could of course unconditionally mandate its use. 396 If TLS applications want to mandate the use of this extension for 397 specific servers, clients could maintain a whitelist of sites where 398 the use of this extension is forced. The client would refuse to 399 authenticate such servers if they failed to deliver this extension. 400 Client applications could also employ a Trust on First Use (TOFU) 401 like strategy, whereby they would record the fact that a server 402 offered the extension and use that knowledge to require it for 403 subsequent connections. 405 This protocol currently provides no way for a server to prove that it 406 doesn't have a TLSA record. Hence absent whitelists, a client 407 misdirected to a server that has fraudulently acquired a public CA 408 issued certificate for the real server's name, could be induced to 409 establish a PKIX verified connection to the rogue server that 410 precluded DANE authentication. This could be solved by enhancing 411 this protocol to require that servers without TLSA records need to 412 provide a DNSSEC authentication chain that proves this (i.e. the 413 chain includes NSEC or NSEC3 records that demonstrate either the 414 absence of the TLSA record, or the absence of a secure delegation to 415 the associated zone). Such an enhancement would be impossible to 416 deploy incrementally though since it requires all TLS servers to 417 support this protocol. 419 9. Security Considerations 421 The security considerations of the normatively referenced RFCs all 422 pertain to this extension. Since the server is delivering a chain of 423 DNS records and signatures to the client, it MUST rebuild the chain 424 in accordance with TTL and signature expiration of the chain 425 components as described in Section 5. TLS clients need roughly 426 accurate time in order to properly authenticate these signatures. 427 This could be achieved by running a time synchronization protocol 428 like NTP [RFC5905] or SNTP [RFC5905], which are already widely used 429 today. TLS clients MUST support a mechanism to track and rollover 430 the trust anchor key, or be able to avail themselves of a service 431 that does this, as described in Section 7. Security considerations 432 related to mandating the use of this extension are described in 433 Section 8. 435 10. IANA Considerations 437 This extension requires the registration of a new value in the TLS 438 ExtensionsType registry. The value requested from IANA is 53. If 439 the draft is adopted by the WG, the authors expect to make an early 440 allocation request as specified in [RFC7120]. 442 11. Acknowledgments 444 Many thanks to Adam Langley for laying the groundwork for this 445 extension. The original idea is his but our acknowledgment in no way 446 implies his endorsement. This document also benefited from 447 discussions with and review from the following people: Viktor 448 Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick 449 McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane 450 Wessels, Nico Williams, and Paul Wouters. 452 12. References 454 12.1. Normative References 456 [RFC1035] Mockapetris, P., "Domain names - implementation and 457 specification", STD 13, RFC 1035, November 1987. 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 463 Rose, "Resource Records for the DNS Security Extensions", 464 RFC 4034, March 2005. 466 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 467 Rose, "Protocol Modifications for the DNS Security 468 Extensions", RFC 4035, March 2005. 470 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 471 Security (DNSSEC) Hashed Authenticated Denial of 472 Existence", RFC 5155, March 2008. 474 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 475 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 477 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 478 Extension Definitions", RFC 6066, January 2011. 480 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 481 of Named Entities (DANE) Transport Layer Security (TLS) 482 Protocol: TLSA", RFC 6698, August 2012. 484 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 485 Authentication of Named Entities (DANE) Protocol: Updates 486 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 487 October 2015, . 489 12.2. Informative References 491 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 492 Trust Anchors", STD 74, RFC 5011, September 2007. 494 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 495 Time Protocol Version 4: Protocol and Algorithms 496 Specification", RFC 5905, June 2010. 498 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 499 Points", BCP 100, RFC 7120, January 2014. 501 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 502 T. Kivinen, "Using Raw Public Keys in Transport Layer 503 Security (TLS) and Datagram Transport Layer Security 504 (DTLS)", RFC 7250, June 2014. 506 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 507 Opportunistic DNS-Based Authentication of Named Entities 508 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 509 10.17487/RFC7672, October 2015, 510 . 512 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 513 10.17487/RFC7901, June 2016, 514 . 516 [I-D.agl-dane-serializechain] 517 Langley, A., "Serializing DNS Records with DNSSEC 518 Authentication", draft-agl-dane-serializechain-01 (work in 519 progress), July 2011. 521 [I-D.barnes-dane-uks] 522 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 523 Share Attacks on DNS-based Authentications of Named 524 Entities (DANE)", draft-barnes-dane-uks-00 (work in 525 progress), October 2016. 527 Appendix A. Updates from -01 and -02 529 o Editorial updates for style and consistency 531 o Updated discussion of UKS attack 533 Appendix B. Updates from -01 535 o Added TLS 1.3 support 537 o Added section describing applicability to raw public keys 539 o Softened language about record order 541 Appendix C. Updates from -00 543 o Edits based on comments from Rick van Rein 545 o Warning about not overloading X.509 wildcards on DNSSEC wildcards 546 (from V. Dukhovny) 548 o Added MUST include negative proof on wildcards (from V. Dukhovny) 550 o Removed "TODO" on allowing the server to deliver only one 551 signature per RRset 553 o Added additional minor edits suggested by Viktor Dukhovny 555 Appendix D. Test vectors 557 The provided test vectors will authenticate the certificate used with 558 https://example.com/, https://example.net/ and https://example.org/ 559 at the time of writing: 561 -----BEGIN CERTIFICATE----- 562 MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw 563 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 564 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz 565 dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa 566 MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML 567 TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB 568 c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY 569 MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A 570 MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u 571 Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo 572 D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V 573 RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3 574 jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a 575 z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw 576 FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW 577 5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t 578 ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh 579 bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud 580 DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f 581 BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy 582 dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt 583 aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG 584 AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB 585 gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy 586 dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E 587 aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC 588 MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q 589 6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP 590 PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy 591 ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI 592 l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS 593 wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII= 594 -----END CERTIFICATE----- 596 For brevity and reproducability all DNS zones involved with the test 597 vectors are signed using a single key with algorithm 13: ECDSA Curve 598 P-256 with SHA-256. 600 The test vectors are DNSSEC valid at June 1 2017, with the following 601 root trust anchor: 603 . IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 604 641bb568746f2ffc4d4 ) 606 D.1. _443._tcp.www.example.com 608 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 609 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 610 ada ) 611 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 612 20170616000000 20170526000000 1870 example.com. 613 GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft 614 Kd8NsZJAikRr4CpaXITYQMx1w== ) 615 example.com. 3600 IN DNSKEY ( 257 3 13 616 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 617 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 618 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 619 20170616000000 20170526000000 1870 example.com. 620 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 621 8q6DBlCdlRQvzD90UKZDIAqbA== ) 622 example.com. 900 IN DS ( 1870 13 2 623 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 624 e16 ) 625 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 626 20170529000000 18931 com. 627 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 628 5XxvbOdLIJAcxhRS1c2VITfMA== ) 629 com. 900 IN DNSKEY ( 257 3 13 630 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 631 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 632 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 633 20170529000000 18931 com. 634 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 635 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 636 com. 86400 IN DS ( 18931 13 2 637 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 638 115 ) 639 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 640 20170530000000 47005 . 641 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 642 jGGQccnLkQnUf7zednetSWalg== ) 643 . 86400 IN DNSKEY ( 257 3 13 644 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 645 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 646 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 647 20170530000000 47005 . 648 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 649 8y3m+LZSLDSBHEocXIiRHWdFg== ) 651 A hex dump of the wire format data of this content is: 653 0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65 654 0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00 655 0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78 656 0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a 657 0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74 658 0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 659 0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d 660 0070: 05 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 07 661 0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 7b be 85 af 662 0090: 63 08 fd be 6e eb 68 df 85 c2 58 e6 41 37 2f 68 663 00a0: 34 4f 4f ce 91 9c 4c b0 54 bb e5 31 cd 57 0c 57 664 00b0: cf 10 ce 33 13 29 7a b4 81 d9 10 d0 cf f3 32 c8 665 00c0: 24 e8 06 12 59 8c 58 c5 15 6e ae e1 07 65 78 61 666 00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e 667 00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe 668 00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8 669 0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9 670 0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e 671 0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03 672 0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30 673 0140: 0d 02 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 674 0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 db ce bb 675 0160: 5f 1c 4b f0 4e de 1e 36 f0 00 75 ae 79 f1 4e 7b 676 0170: 42 3b ff dc c0 04 b8 3c 5f 3a e7 ac a7 0c 47 0a 677 0180: a5 3d 70 95 28 d5 c9 65 5c 6f 7c ad 25 1e d2 77 678 0190: 00 2c 0a 9f f7 e9 19 a6 04 e9 cb 09 60 07 65 78 679 01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00 680 01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90 681 01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3 682 01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65 683 01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00 684 01f0: 2b 0d 02 00 00 03 84 59 34 9f 00 59 2b 64 80 49 685 0200: f3 03 63 6f 6d 00 18 f3 6d 66 92 89 48 73 26 3a 686 0210: cd 1e 35 38 a3 97 07 1b ed de d6 14 db 16 f0 f5 687 0220: 62 27 20 c5 eb fa 66 ac a4 a7 8e 93 33 ca 62 42 688 0230: 91 7a 51 b5 15 3a 83 14 3a 80 a5 f2 b6 80 00 e5 689 0240: 6b 92 ba 37 ec 2d 03 63 6f 6d 00 00 30 00 01 00 690 0250: 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b ef 7a 5d 691 0260: 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77 a0 42 34 692 0270: a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7 3c d3 d4 693 0280: c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64 33 70 f1 694 0290: 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d 00 00 2e 695 02a0: 00 01 00 00 03 84 00 57 00 30 0d 01 00 00 03 84 696 02b0: 59 34 9f 00 59 2b 64 80 49 f3 03 63 6f 6d 00 8d 697 02c0: 21 46 95 a5 17 ab 10 0a 49 dd 25 d3 6b 7d 88 ab 698 02d0: 2b 18 c9 53 da f2 76 fd a5 82 b8 ea 14 cb 7c 25 699 02e0: 4a 36 4a f0 48 9b e6 a3 0d aa 5b 98 15 8e 64 12 700 02f0: bb 1b 6e 45 3f 03 00 88 3d 48 b7 0f 78 53 2b 03 701 0300: 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 702 0310: 0d 02 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 703 0320: 59 41 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 704 0330: 21 15 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00 705 0340: 53 00 2b 0d 01 00 01 51 80 59 3d d9 80 59 2c b6 706 0350: 00 b7 9d 00 33 56 6b d8 e2 80 50 7a e6 cf 68 27 707 0360: bb 22 5c a7 aa 41 f1 36 94 1c ae 94 9c 3f da 98 708 0370: c5 0f 56 b8 26 c7 57 44 05 a3 a5 11 ef d9 77 b3 709 0380: 49 a9 50 8d 99 76 98 78 8e 4b 30 a8 70 51 63 09 710 0390: a2 b6 14 05 00 00 30 00 01 00 01 51 80 00 44 01 711 03a0: 01 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 712 03b0: ad 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 713 03c0: 42 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 714 03d0: bd 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 715 03e0: 63 ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 716 03f0: 0d 00 00 01 51 80 59 3d d9 80 59 2c b6 00 b7 9d 717 0400: 00 2b 43 e5 99 de 8d bd e6 e1 f0 05 2d 16 a1 7a 718 0410: 79 15 42 da 47 da 2f 63 0e 46 ab 7d e3 7e 9b 8a 719 0420: 7d 25 e2 3f 18 bf 85 4c 17 b7 d5 3c 06 c8 18 bb 720 0430: bd 98 44 11 72 e3 18 bc 9d 99 88 e5 00 91 58 c8 721 0440: 47 723 D.2. _25._tcp.example.com wildcard 725 _25._tcp.example.com. 3600 IN TLSA ( 3 1 1 726 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 727 ada ) 728 _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 729 20170616000000 20170526000000 1870 example.com. 730 dVxm88Spko03MB4pLo+zijMup2nr1Ii65yPqB/cAR/1Zg41iXer7I2sGh9KfT 731 ExLJC6dUMDVFUfm+1rwb+ax8Q== ) 732 *._tcp.example.com. 3600 IN NSEC ( 733 _443._tcp.www.example.com. RRSIG NSEC TLSA ) 734 *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 735 20170616000000 20170526000000 1870 example.com. 736 1lNaYYQ+FAG8YBVEx/026OGhVw5DjAyqBGrrLN9D12IZuLHtTQ4C9QPORP4na 737 GWNPgASvLyNR8MoN0oXV7tbnQ== ) 738 example.com. 3600 IN DNSKEY ( 257 3 13 739 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 740 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 741 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 742 20170616000000 20170526000000 1870 example.com. 743 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 744 8q6DBlCdlRQvzD90UKZDIAqbA== ) 745 example.com. 900 IN DS ( 1870 13 2 746 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 747 e16 ) 748 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 749 20170529000000 18931 com. 750 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 751 5XxvbOdLIJAcxhRS1c2VITfMA== ) 752 com. 900 IN DNSKEY ( 257 3 13 753 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 754 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 755 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 756 20170529000000 18931 com. 757 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 758 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 759 com. 86400 IN DS ( 18931 13 2 760 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 761 115 ) 762 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 763 20170530000000 47005 . 764 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 765 jGGQccnLkQnUf7zednetSWalg== ) 766 . 86400 IN DNSKEY ( 257 3 13 767 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 768 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 769 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 770 20170530000000 47005 . 771 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 772 8y3m+LZSLDSBHEocXIiRHWdFg== ) 774 D.3. _443._tcp.www.example.org CNAME 776 _443._tcp.www.example.org. 3600 IN CNAME ( 777 dane311.example.org. ) 778 _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 779 20170616000000 20170526000000 44384 example.org. 780 DN+UMxh5TWL1u6Mc6ScWMU5R9C+qqIOSH4hqQmiPWhvSg0lFd71g43UqtdmBT 781 VRUbhk/f9WC8Fy5D0gE5lUcyA== ) 782 dane311.example.org. 3600 IN TLSA ( 3 1 1 783 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 784 ada ) 785 dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 786 20170616000000 20170526000000 44384 example.org. 787 HJx59dAMQgvJSYBYtixzfodup5KRUzJ1SlRUrFJkGZz6PkpfuFdtpZwPN1vw9 788 SyvXq7WqRD46aaCMwR4ApUJ+w== ) 789 example.org. 3600 IN DNSKEY ( 257 3 13 790 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 791 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 792 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 793 20170616000000 20170526000000 44384 example.org. 794 MPTpfbVvPBXmh2Z4fgjy2GMgcJ8RYpXeOBOBidJDglLh4XQAiFOT6YpGRR5ig 795 tQGINd6gKVYdRSsEtXe1K8zxg== ) 796 example.org. 900 IN DS ( 44384 13 2 797 ec307e2efc8f0117ed96ab48a513c8003e1d9121f1ff11a08b4cdd348d090 798 aa6 ) 799 example.org. 900 IN RRSIG ( DS 13 2 900 20170615000000 800 20170525000000 12651 org. 801 MA3pxiap702Hvc81diwZDcRzLrkKssVzzTqCiJJoZFeNq40GuCOVGgEc+w6aq 802 SVgkgFJrhJISei/kvIZTx8ftw== ) 803 org. 900 IN DNSKEY ( 257 3 13 804 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 805 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 806 org. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000 807 20170525000000 12651 org. 808 o4L9nBQo8KXF0a7D5268U+Bq8SuW/aePtyuSfvQvP79nN/mzh9P11CsT/opmW 809 kg0u6pqaG9KE1T37jloes8J8w== ) 810 org. 86400 IN DS ( 12651 13 2 811 3979a51f98bbf219fcaf4a4176e766dfa8f9db5c24a75743eb1e704b97a9f 812 abc ) 813 org. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 814 20170530000000 47005 . 815 Mi1c7QrpHnl1MSLJTrq/WM0V0DQKwFPGaMFmHHwm8Yb/b934CUHMXU0dR+cLT 816 hakZNz37edtwPxKKOzZQ6pYUw== ) 817 . 86400 IN DNSKEY ( 257 3 13 818 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 819 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 820 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 821 20170530000000 47005 . 822 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 823 8y3m+LZSLDSBHEocXIiRHWdFg== ) 825 D.4. _443._tcp.www.example.net DNAME 827 example.net. 3600 IN DNAME example.com. 828 example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20170616000000 829 20170526000000 48085 example.net. 830 sTl9oxvpd7KxOZ9e5suevha7Fr+zPc3a0pWEUfjFE5v9Umu5js/vcp1i6hdqy 831 tQ2WXEQDsHeEjw9stupvMJkkg== ) 832 _443._tcp.www.example.net. 3600 IN CNAME ( 833 _443._tcp.www.example.com. ) 834 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 835 c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165 836 ada ) 837 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 838 20170616000000 20170526000000 1870 example.com. 839 GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft 840 Kd8NsZJAikRr4CpaXITYQMx1w== ) 841 example.net. 3600 IN DNSKEY ( 257 3 13 842 X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d 843 9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085 844 example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600 845 20170616000000 20170526000000 48085 example.net. 846 8jSs5O3AypurKs8JFoAYj30qlmQ9QS29IBoqbyv2ggxtdDZoKWZE0kOuQcRxx 847 q1pP707qRjp98THQSTVh+C0iQ== ) 848 example.net. 900 IN DS ( 48085 13 2 849 7c1998ce683df60e2fa41460c453f88f463dac8cd5d074277b4a7c0450292 850 1be ) 851 example.net. 900 IN RRSIG ( DS 13 2 900 20170615000000 852 20170525000000 485 net. 853 xqN9gHO5HXB+GH2x3DvjpMl6f+CdsVvON2K7G0FDVIL5iFMNLPqCAITlFofWF 854 Ty6VXFKPoy9TZresE/JCL/PFA== ) 855 net. 900 IN DNSKEY ( 257 3 13 856 LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5 857 oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485 858 net. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000 859 20170525000000 485 net. 860 jEI8WucG9EzJ1Euv0Pq3aNFhoYbvQeLUs19r9YImkWi8QlmH76ZJuLTCGHTDh 861 /Il5cZWukKc3ScptxVA57uRyQ== ) 862 net. 86400 IN DS ( 485 13 2 863 ab25a2941aa7f1eb8688bb783b25587515a0cd8c247769b23adb13ca234d1 864 c05 ) 865 net. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 866 20170530000000 47005 . 867 ZR/UTP2OrYwJQhsCAWsKoIs9OSiUDdBFXzFqYSrV41G1oQsKVSi/NU1tT1UZW 868 CENddWt90XLXZAlSYnv6s8Ceg== ) 869 . 86400 IN DNSKEY ( 257 3 13 870 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 871 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 872 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000 873 20170530000000 47005 . 874 tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK 875 8y3m+LZSLDSBHEocXIiRHWdFg== ) 876 example.com. 3600 IN DNSKEY ( 257 3 13 877 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 878 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 879 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 880 20170616000000 20170526000000 1870 example.com. 881 sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r 882 8q6DBlCdlRQvzD90UKZDIAqbA== ) 883 example.com. 900 IN DS ( 1870 13 2 884 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81 885 e16 ) 886 example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000 887 20170529000000 18931 com. 889 rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3 890 5XxvbOdLIJAcxhRS1c2VITfMA== ) 891 com. 900 IN DNSKEY ( 257 3 13 892 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 893 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 894 com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000 895 20170529000000 18931 com. 896 wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk 897 c6Nx3HLmhidf6dmt/Hi0ePBsQ== ) 898 com. 86400 IN DS ( 18931 13 2 899 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52 900 115 ) 901 com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000 902 20170530000000 47005 . 903 jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+ 904 jGGQccnLkQnUf7zednetSWalg== ) 906 Authors' Addresses 908 Melinda Shore 909 Fastly 911 EMail: mshore@fastly.com 913 Richard Barnes 914 Mozilla 916 EMail: rlb@ipv.sx 918 Shumon Huque 919 Salesforce 921 EMail: shuque@gmail.com 923 Willem Toorop 924 NLnet Labs 926 EMail: willem@nlnetlabs.nl