idnits 2.17.1 draft-dukhovni-tls-dnssec-chain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 992 has weird spacing: '...1 d3 bc e3 a2...' == Line 1018 has weird spacing: '...3 fb cc d4 d8...' == Line 1024 has weird spacing: '...6 43 bb de 68...' == Line 1040 has weird spacing: '...5 b4 ea e5 14...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: When a server that implements (and is configured to enable the use of) this extension receives a "dnssec_chain" extension in the ClientHello, it MUST first check whether the requested TLSA RRset (based on the port number in this extension and hostname in the SNI extension) is associated with the server. If the extension, the SNI hostname or the port number is unsupported, the server's extended ServerHello message SHALL not include the dnssec_chain extension. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unsigned CNAMEs that are implied by associated DNAME records MUST not be included, they can be inferred from the DNAME records. Any NSEC or NSEC3 denial of existence records must be accompanied by the associated SOA record. -- The document date (November 4, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) 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 V. Dukhovni 3 Internet-Draft Two Sigma 4 Intended status: Experimental S. Huque 5 Expires: May 7, 2020 Salesforce 6 W. Toorop 7 NLnet Labs 8 P. Wouters 9 Red Hat 10 M. Shore 11 Fastly 12 November 4, 2019 14 The DANE Authentication Chain Extension for TLS 15 draft-dukhovni-tls-dnssec-chain-00 17 Abstract 19 This draft describes a new TLS extension for transport of a DNS 20 record set serialized with the DNSSEC signatures needed to 21 authenticate that record set. This allows TLS clients to perform 22 DANE authentication of a TLS server without the need to perform 23 additional DNS record lookups. 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 May 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 65 3.3.1. Authenticated Denial of Existence . . . . . . . . . . 9 66 4. Construction of Serialized Authentication Chains . . . . . . 9 67 5. Caching and Regeneration of the Authentication Chain . . . . 10 68 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Extension pinning . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 13 71 9. Virtual Hosting . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. Operational Considerations . . . . . . . . . . . . . . . . . 14 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 14.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 19 80 A.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 20 81 A.2. _25._tcp.example.com NSEC wildcard . . . . . . . . . . . 24 82 A.3. _25._tcp.example.org NSEC3 wildcard . . . . . . . . . . . 25 83 A.4. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 27 84 A.5. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 28 85 A.6. _25._tcp.smtp.example.com NSEC Denial of Existence . . . 30 86 A.7. _25._tcp.smtp.example.org NSEC3 Denial of Existence . . . 32 87 A.8. _443._tcp.www.insecure.example NSEC3 opt-out insecure 88 delegation . . . . . . . . . . . . . . . . . . . . . . . 34 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 91 1. Requirements Notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 2. Introduction 101 This document describes a new TLS [RFC5246] [RFC8446] extension for 102 transport of DNSSEC [RFC4034] signed DNS Resource Records (RRs). 103 This allows TLS clients to perform DANE Authentication [RFC6698] 104 [RFC7671] of a TLS server without the need to perform additional DNS 105 record lookups. Retrieval of the required DNS records may be 106 unavailable to the client ([HAMPERING]), or may incur undesirable 107 additional latency. It further allows a TLS client to validate the 108 server's DANE (TLSA) records itself without requiring access to a 109 validating DNS resolver to which it must have a secure connection. 111 The extension described here allows a TLS client to request that the 112 TLS server return the DNSSEC authentication chain corresponding to 113 its DNSSEC-validated DANE TLSA Resource Record set (RRset), or 114 authenticated denial of existence of such an RRset (as described in 115 Section 3.3.1). If the server supports this extension it performs 116 the appropriate DNS queries, builds the authentication chain, and 117 returns it to the client. The server will typically use a previously 118 cached authentication chain, but it will need to rebuild it 119 periodically as described in Section 5. The client then 120 authenticates the chain using a pre-configured DNSSEC trust anchor. 122 In the absense of TLSA records, this extension conveys the required 123 authenticated denial of existence. Such proofs are needed to 124 securely signal that specified TLSA records are not available so that 125 TLS clients can safely fall back to WebPKI based authentication if 126 allowed by local policy. These proofs are also needed to avoid 127 downgrade from opportunistic authenticated TLS (when DANE TLSA 128 records are present) to unauthenticated opportunistic TLS (in the 129 absence of DANE). Denial of existence records are also used by the 130 TLS client to clear no longer relevant extension pins, as described 131 in Section 7. 133 As described in the DANE specification [RFC6698] [RFC7671], this 134 procedure applies to the DANE authentication of X.509 certificates or 135 raw public keys [RFC7250]. 137 This extension also mitigates againts an unknown key share (UKS) 138 attack [I-D.barnes-dane-uks] when using raw public keys, since the 139 server commits to its DNS name (normally found in its certificate) 140 via the content of the returned TLSA RRset. 142 3. DNSSEC Authentication Chain Extension 144 3.1. Protocol, TLS 1.2 146 A client MAY include an extension of type "dnssec_chain" in the 147 (extended) ClientHello. The "extension_data" field of this extension 148 consists of the server's 16-bit TCP port number in network (big- 149 endian) byte order. Clients sending this extension MUST also send 150 the Server Name Identification (SNI, [RFC6066]) extension. Together, 151 these make it possible for the server to determine which 152 authenticated TLSA RRset chain needs to be used for the 153 "dnssec_chain" extension. 155 When a server that implements (and is configured to enable the use 156 of) this extension receives a "dnssec_chain" extension in the 157 ClientHello, it MUST first check whether the requested TLSA RRset 158 (based on the port number in this extension and hostname in the SNI 159 extension) is associated with the server. If the extension, the SNI 160 hostname or the port number is unsupported, the server's extended 161 ServerHello message SHALL not include the dnssec_chain extension. 163 Otherwise, the server's extended ServerHello message MUST contain a 164 serialized authentication chain using the format described below. If 165 the server does not have access to the requested DNS chain - for 166 example due to a misconfiguration or expired chain - the server MUST 167 omit the extension rather than send an incomplete chain. Clients 168 that are expecting this extension MUST interpret this as a downgrade 169 attack and MUST abort the TLS session. Therefore, servers MUST send 170 denial of existence proofs, unless for the particular application 171 protocol or service clients are expected to continue even in the 172 absence of such a proof. As with all TLS extensions, if the server 173 does not support this extension it will not return any authentication 174 chain. 176 3.2. Protocol, TLS 1.3 178 In TLS 1.3, the server adds its dnssec_chain extension in the 179 extension block of the Certificate message containing the end entity 180 certificate being validated, rather than to the extended ServerHello 181 message. 183 The extension protocol behavior otherwise follows that specified for 184 TLS version 1.2. 186 3.3. DNSSEC Authentication Chain Data 188 The "extension_data" field of the client's "dnssec_chain" extension 189 MUST contain the server's 16-bit TCP port number in network (big- 190 endian) byte order: 192 struct { 193 uint16 PortNumber; 194 } DnssecChainExtension; 196 The "extension_data" field of the server's "dnssec_chain" extension 197 MUST contain a DNSSEC Authentication Chain encoded in the following 198 form: 200 struct { 201 uint16 ExtSupportLifetime; 202 opaque AuthenticationChain<1..2^16-1> 203 } DnssecChainExtension; 205 The ExtSupportLifetime value is the number of hours for which the TLS 206 server has committed itself to serving this extension. A value of 207 zero prohibits the client from unilaterally requiring ongoing use of 208 the extension based on prior observation of its use (extension 209 pinning). This is further described in Section 7. 211 The AuthenticationChain is composed of a sequence of uncompressed 212 wire format DNS Resource Record sets (RRsets) and corresponding 213 Resource Record signatures (RRSIGs). 215 This sequence of native DNS wire format records enables easier 216 generation of the data structure on the server and easier 217 verification of the data on client by means of existing DNS library 218 functions. 220 Each RRset in the chain is composed of a sequence of wire format DNS 221 Resource Records. The format of the Resource Record is described in 222 [RFC1035], Section 3.2.1. 224 RR(i) = owner | type | class | TTL | RDATA length | RDATA 226 where RR(i) denotes the ith RR. 228 The Resource Records that make up a RRset all have the same owner, 229 type, class and TTL, but different RDATA as specified in [RFC2181], 230 Section 5. 232 Each signed RRset in the sequence is followed by its associated RRsig 233 record set. This RRset has the same owner and class as the preceding 234 RRset, but has type RRSIG. The Type Covered field in the RDATA of 235 the RRsigs identifies the type of the preceding RRset as described in 236 [RFC4034]>, Section 3. 238 The RRsig record wire format is described in [RFC4034], Section 3.1. 239 The signature portion of the RDATA, as described in the same section, 240 is the following: 242 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) 244 where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with 245 the Signer's Name field in canonical form and the signature field 246 excluded. 248 The order of returned RRsets is unspecified and a TLS client MUST NOT 249 assume any ordering of RRsets. 251 Unsigned CNAMEs that are implied by associated DNAME records MUST not 252 be included, they can be inferred from the DNAME records. Any NSEC 253 or NSEC3 denial of existence records must be accompanied by the 254 associated SOA record. 256 The returned RRsets MUST contain either the requested TLSA RRset, 257 perhaps or the associated denial of existence proof. In either case, 258 the chain of RRsets MUST be accompanied with the full set of DNS 259 records needed to authenticate the TLSA record set or its denial of 260 existence up the DNS hierarchy up to either the Root Zone or another 261 trust anchor mutually configured by the TLS server and client. 263 The chain will contain a unique class 1 (IN) RRset whose owner is 264 equal to or is the closest ancestore of the requested TLSA RRset, and 265 whose record type is one of TLSA, SOA, CNAME or DNAME. These four 266 cases correspond to either: 268 1. A signed TLSA RRset at the requested domain name. 270 2. An signed SOA record and signed NSEC or NSEC3 records from the 271 associated zone, which together authenticate the non-existence of 272 the requested TLSA RRset. 274 3. A signed CNAME from the requested name to another domain name, 275 ultimately leading to a TLSA RRset, or denial of existence. 277 4. A signed ancestor DNAME record that specifies a new subtree in 278 DNS at which the chain continues (by prepending the labels 279 intermediate betwen the requested name the owner of the DNAME 280 record). 282 The first two cases determine whether the TLSA RRset does or does not 283 exist. The last two just redirect the requested name to the target 284 of the alias (actual with CNAME, or implied with DNAME), with the 285 status determined there or after further alias indirection. Clients 286 MUST be prepared to encounter alias loops, and then conclude that the 287 requested TLSA RRset therefore does not exist. In the presence of a 288 CNAME loop or other server-side DNS problem, servers may be unable to 289 construct the authentication chain and would then have no choice but 290 to omit the extension. 292 In the case of a denial of existence response, the response chain 293 should include all DNSSEC signed records from the root zone to the 294 proof of non-existence of a validable entry in the chain that 295 disproves the existence of a a secure delegation to - or of - the 296 TLSA record. 298 Names that are aliased via CNAME and/or DNAME records may involve 299 multiple branches of the DNS tree. In this case, the authentication 300 chain structure needs to include DS and DNSKEY record sets that cover 301 all the necessary branches. 303 If the TLSA record set was synthesized by a DNS wildcard, the chain 304 MUST include the signed NSEC or NSEC3 [RFC5155] records that prove 305 that there was no explicit match of the TLSA record name and no 306 closer wildcard match. 308 The topmost DNSKEY RRset in the authentication chain corresponds to 309 the trust anchor (typically the DNS root). This trust anchor is also 310 preconfigured in the TLS client, but including it in the response 311 from the server permits TLS clients to use the automated trust anchor 312 rollover mechanism defined in RFC 5011 [RFC5011] to update their 313 configured trust anchor. 315 The following is an example of the records in the AuthenticationChain 316 structure for the HTTPS server at www.example.com, where there are 317 zone cuts at "com." and "example.com." (record data are omitted here 318 for brevity): 320 _443._tcp.www.example.com. TLSA 321 RRSIG(_443._tcp.www.example.com. TLSA) 322 example.com. DNSKEY 323 RRSIG(example.com. DNSKEY) 324 example.com. DS 325 RRSIG(example.com. DS) 326 com. DNSKEY 327 RRSIG(com. DNSKEY) 328 com. DS 329 RRSIG(com. DS) 330 . DNSKEY 331 RRSIG(. DNSKEY) 333 The following is an example of denial of existence for a TLSA RRset 334 at "_443._tcp.www.example.com". The NSEC record in this example 335 asserts the non-existence of both the requested RRset and any 336 potentially relevant wildcard records. 338 www.example.com. IN NSEC (example.com. DNSKEY SOA NS NSEC RRSIG) 339 RRSIG(www.example.com. NSEC) 340 example.com. DNSKEY 341 RRSIG(example.com. DNSKEY) 342 example.com. DS 343 RRSIG(example.com. DS) 344 com. DNSKEY 345 RRSIG(com. DNSKEY) 346 com. DS 347 RRSIG(com. DS) 348 . DNSKEY 349 RRSIG(. DNSKEY) 351 The following is an example of (hypothetical) insecure delegation of 352 "example.com" from the ".com" zone. This example shows NSEC3 records 353 with opt-out. 355 ; covers example.com 356 onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - 357 onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) 358 RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3) 359 ; covers *.com 360 3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 - 361 3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG) 362 RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3) 363 ; closest-encloser "com" 364 ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - 365 ck0pojmg874ljref7efn8430qvit8bsm.com 366 NS SOA RRSIG DNSKEY NSEC3PARAM) 367 RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3) 368 com. DNSKEY 369 RRSIG(com. DNSKEY) 370 com. DS 371 RRSIG(com. DS) 372 . DNSKEY 373 RRSIG(. DNSKEY) 375 3.3.1. Authenticated Denial of Existence 377 TLS servers supporting this extension that do not have a signed TLSA 378 record MUST instead return a DNSSEC chain that provides authenticated 379 denial of existence. A TLS client receiving proof of authenticated 380 denial of existence MUST use an alternative method to verify the TLS 381 server identity or close the connection. Such an alternative could 382 be the classic WebPKI model of preinstalled root CA's. 384 Authenticated denial chains include NSEC or NSEC3 records that 385 demonstrate one of the following facts: 387 o The TLSA record does not exist. 389 o There is no signed delegation to a DNS zone which is either an 390 ancestor of, or the same as, the TLSA record name. 392 4. Construction of Serialized Authentication Chains 394 This section describes a possible procedure for the server to use to 395 build the serialized DNSSEC chain. 397 When the goal is to perform DANE authentication [RFC6698] [RFC7671] 398 of the server, the DNS record set to be serialized is a TLSA record 399 set corresponding to the server's domain name, protocol, and port 400 number. 402 The domain name of the server MUST be that included in the TLS 403 server_name (SNI) extension [RFC6066]. If the server does not 404 recognize the SNI name as one if its own names, but wishes to proceed 405 with the handshake rather than to abort the connection, the server 406 MUST NOT send a dnssec_chain extension to the client. 408 The name in client's SNI extension MUST NOT be CNAME-expanded by the 409 server. The TLSA base domain (Section 3 of [RFC6698]) SHALL be the 410 hostname from the client's SNI extension and the guidance in 411 Section 7 of [RFC7671] does not apply. See Section 9 for further 412 discussion. 414 The TLSA record to be queried is constructed by prepending the _port 415 and _transport labels to the domain name as described in [RFC6698], 416 where "port" is the port number taken from the client's dnssec_chain 417 extension. The transport is "tcp" for TLS servers, and "udp" for 418 DTLS servers. The port number label is the left-most label, followed 419 by the transport, followed by the server domain name (from SNI). 421 The components of the authentication chain are typically built by 422 starting at the target record set and its corresponding RRSIG. Then 423 traversing the DNS tree upwards towards the trust anchor zone 424 (normally the DNS root). For each zone cut, the DNSKEY and DS RRsets 425 and their signatures are added. However, see Section 3.3 for 426 specific processing needed for aliases and wildcards. If DNS 427 response messages contain any domain names utilizing name compression 428 [RFC1035], then they MUST be uncompressed prior to inclusion in the 429 chain. 431 Implementations of EDNS Chain Query Requests as specified in 432 [RFC7901] may offer an easier way to obtain all of the chain data in 433 one transaction with an upstream DNSSEC aware recursive server. 435 5. Caching and Regeneration of the Authentication Chain 437 DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 438 have validity periods (specifically signature expiration times). 439 After the TLS server constructs the serialized authentication chain, 440 it SHOULD cache and reuse it in multiple TLS connection handshakes. 441 However, it MUST refresh and rebuild the chain as TTLs and signature 442 validity periods dictate. A server implementation could carefully 443 track these parameters and requery component records in the chain 444 correspondingly. Alternatively, it could be configured to rebuild 445 the entire chain at some predefined periodic interval that does not 446 exceed the DNS TTLs or signature validity periods of the component 447 records in the chain. 449 6. Verification 451 A TLS client performing DANE based verification might not need to use 452 this extension. For example, the TLS client could perform native DNS 453 lookups and perform DANE verification without this extension. Or it 454 could fetch authentication chains via another protocol. If the TLS 455 client already possesses a valid TLSA record, it MAY omit using this 456 extension. However, if it includes this extension, it MUST use the 457 TLS server reply to update the extension pinning status of the TLS 458 server's extension lifetime. See Section 7. 460 A TLS client making use of this specification, and which receives a 461 valid DNSSEC authentication chain extension from a server, MUST use 462 this information to perform DANE authentication of the server. In 463 order to perform the validation, it uses the mechanism specified by 464 the DNSSEC protocol [RFC4035] [RFC5155]. This mechanism is sometimes 465 implemented in a DNSSEC validation engine or library. 467 If the authentication chain validates, the client then performs DANE 468 authentication of the server according to the DANE TLS protocol 469 [RFC6698] [RFC7671]. 471 Clients MAY cache the server's validated TLSA RRset to ammortize the 472 cost of receiving and validating the chain over multiple connections. 473 The period of such caching MUST NOT exceed the TTL associated with 474 those records. A client that possesses a validated and unexpired 475 TLSA RRset or the full chain in its cache does not need to send the 476 dnssec_chain extension for subsequent connections to the same TLS 477 server. It can use the cached information to perform DANE 478 authentication. 480 Note that when a client and server perform TLS session resumption the 481 server sends no "dnssec_chain". This is particularly clear with TLS 482 1.3, where the certificate message to which the chain might be 483 attached is also not sent on resumption. 485 7. Extension pinning 487 TLS applications can be designed to unconditionally mandate this 488 extension. Such TLS clients requesting this extension would abort a 489 connection to a TLS server that does not respond with a validatable 490 extension reply. 492 However, in a mixed use deployment of WebPKI and DANE, there is the 493 possibility that the security of a TLS client is downgraded from DANE 494 to WebPKI. This can happen when a TLS client connection is 495 intercepted and redirected to a rogue TLS server presenting a TLS 496 certificate that is considered valid from a WebPKI point of view, but 497 one that does not match the legitimate server's TLSA records. By 498 omitting this extension, such a rogue TLS server could downgrade the 499 TLS client to validate the mis-issued certificate using only the 500 WebPKI and not via DANE, provided the TLS client is also not able to 501 fetch the TLSA records directly from DNS. 503 The ExtSupportLifetime element of the extension provides a counter- 504 measure against such downgrade attacks. It's value represents the 505 number of hours that the TLS server (or cluster of servers serving 506 the same Server Name) commit to serving this extension in the future. 507 This is referred to as the "pinning time" or "extension pin" of the 508 extension. A non-zero extenion pin value received MUST ONLY be used 509 if the extention also contains a valid TLSA authentication chain that 510 matches the server's certificate chain (the server passes DANE 511 authentication based on the enclosed TLSA RRset). 513 Any existing extension pin for the server instance (name and port) 514 MUST be cleared on receipt of a valid denial of existence for the 515 associated TLSA RRset. The same also applies if the client obtained 516 the denial of existence proof via another method, such as through 517 direct DNS queries. Based on the TLS client's local policy, it MAY 518 then terminate the connection or MAY continue using WebPKI based 519 server authentication. 521 Extension pins MUST also be cleared upon the completion of a DANE 522 authenticated handshake with a server that returns a dnssec_chain 523 extension with a zero ExtSupportLifetime. 525 Upon completion of a full validated hanshake with a server that 526 returns a dnssec_chain extension with a non-zero ExtSupport lifetime, 527 the client MUST update any existing pin lifetime for the service 528 (name and port) to a value that is no longer than that indicated by 529 the server. The client MAY, subject to local policy, create a 530 previously non-existent pin, again for a lifetime that is not longer 531 than that indicated by the server. The extension support lifetime is 532 not constrained by any DNS TTLs or RRSIG expirations in the returned 533 chain. 535 Clients MAY implement support for a subset of DANE certificate 536 usages. For example, clients may support only DANE-EE(3) and DANE- 537 TA(2) ([RFC7218]), only PKIX-EE(1) and PKIX-TA(0) or all four. 538 Clients that implement DANE-EE(3) and DANE-TA(2) MUST implement the 539 relevant updates in [RFC7671]. 541 For a non-zero saved value of the ExtSupportLifetime element of the 542 extension, TLS clients MUST mandate ("pin") the use of this extension 543 by the corresponding TLS servers for the time period specified by the 544 pinning value. If during this time, the TLS client does not have a 545 valid TLSA record and connects to a TLS server using this extension 546 for the associated name and port, and it does not obtain a valid 547 authentication chain in this extension, it MUST either abort the 548 connection or delay communication with the server via the TLS session 549 until it is able to obtain valid TLSA records (or non-existence 550 proof) out of band, such as via direct DNS lookups. If attempts to 551 obtain the TLSA RRset out of band fail, the client MUST abort the TLS 552 session. 554 Note that requiring the extension is NOT the same as requiring the 555 use of DANE TLSA records or even DNSSEC. A DNS zone operator may at 556 any time delete the TLSA records, or even remove the DS records to 557 disable the secure delegation of the server's DNS zone. The TLS 558 server will, when it updates its cached TLSA authentication chain, 559 replace the chain with the corresponding denial of existence chain. 560 The server's only obligation is continued support for this extension. 562 8. Trust Anchor Maintenance 564 The trust anchor may change periodically, e.g. when the operator of 565 the trust anchor zone performs a DNSSEC key rollover. TLS clients 566 using this specification MUST implement a mechanism to keep their 567 trust anchors up to date. They could use the method defined in 568 [RFC5011] to perform trust anchor updates inband in TLS, by tracking 569 the introduction of new keys seen in the trust anchor DNSKEY RRset. 570 However, alternative mechanisms external to TLS may also be utilized. 571 Some operating systems may have a system-wide service to maintain and 572 keep the root trust anchor up to date. In such cases, the TLS client 573 application could simply reference that as its trust anchor, 574 periodically checking whether it has changed. Some applications may 575 prefer to implement trust anchor updates as part of their automated 576 software updates. 578 9. Virtual Hosting 580 Delivery of application services is often provided by a third party 581 on behalf of the domain owner (hosting customer). Since the domain 582 owner may want to be able to move the service between providers, non- 583 zero support lifetimes for this extension should only be enabled by 584 mutual agreement between the provider and domain owner. 586 When CNAME records are employed to redirect network connections to 587 the provider's network, as mentioned in Section 4 the server uses the 588 client's SNI hostname as the TLSA base domain without CNAME 589 expansion. When the certificate chain for the service is managed by 590 the provider, it is impractical to coordinate certificate changes by 591 the provider with updates in the hosting customer's DNS. Therefore, 592 the TLSA RRset for the hosted domain is best configured as a CNAME 593 from the customer's domain to a TLSA RRset that is managed by the 594 provider as part of delivering the hosted service. For example: 596 ; Customer DNS 597 www.example.com. IN CNAME node1.provider.example. 598 _443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example. 599 ; Provider DNS 600 node1.provider.example. IN A 192.0.2.1 601 _dane443.node1.provider.example. IN TLSA 1 1 1 ... 603 Clients that obtain TLSA records directly from DNS, bypassing this 604 extension, may however perform CNAME-expansion as in Section 7 of 605 [RFC7671], and if TLSA records are associated with the fully-expanded 606 name, may use that name as the TLSA base domain and SNI name for the 607 TLS handshake. 609 To avoid confusion, it is RECOMMENDED that server operators not 610 publish TLSA RRs (_port._tcp. + base domain) based on the expanded 611 CNAMEs used to locate their network addresses. Instead, the server 612 operator SHOULD publish TLSA RRs at an alternative DNS node (as in 613 the example above), to which the hosting customer will publish a 614 CNAME alias. This results in all clients (whether they obtain TLSA 615 records from DNS directly, or employ this extension) seeing the same 616 TLSA records and sending the same SNI name. 618 10. Operational Considerations 620 When DANE is being introduced incrementally into an existing PKIX 621 environment, there may be scenarios in which DANE authentication for 622 a server fails but PKIX succeeds, or vice versa. What happens here 623 depends on TLS client policy. If DANE authentication fails, the 624 client may decide to fall back to traditional PKIX authentication. 625 In order to do so efficiently within the same TLS handshake, the TLS 626 server needs to have provided the full X.509 certificate chain. When 627 TLS servers only support DANE-EE or DANE-TA modes, they have the 628 option to send a much smaller certificate chain: just the EE 629 certificate for the former, and a short certificate chain from the 630 DANE trust anchor to the EE certificate for the latter. If the TLS 631 server supports both DANE and traditional PKIX, and wants to allow 632 efficient PKIX fallback within the same handshake, they should always 633 provide the full X.509 certificate chain. 635 When a TLS server operator wishes to no longer deploy this extension, 636 it must properly decommission its use. If a non-zero pin lifetim is 637 presently advertised, it must first be changed to 0. The extension 638 can be disabled once all previously advertised pin lifetimes have 639 expired. Removal of TLSA records or even DNSSEC signing of the zone 640 can be done at any time, but the server MUST still be able to return 641 the associated denial of existence proofs to any clients that have 642 unexpired pins. 644 TLS clients MAY reduce the received extension pin value to a maximum 645 set by local policy. This can mitigate a theoretical yet unlikely 646 attack where a compromised TLS server is modified to advertise a pin 647 value set to the maximum of 7 years. Care should be taken not to set 648 a local maximum that is too short as that would reduce the downgrade 649 attack protection that the extension pin offers. 651 If the hosting provider intends to use end-entity TLSA records 652 (certificate usage PKIX-EE(1) or DANE-EE(3)) then the simplest 653 approach is to use the same key-pair for all the certificates at a 654 given hosting node, and publish "1 1 1" or "3 1 1" RRs matching the 655 common public key. Since key rollover cannot be simultaneous across 656 multiple certificate updates, there will be times when multiple "1 1 657 1" (or "3 1 1") records will be required to match all the extant 658 certificates. Multiple TLSA records are in any case needed a few 659 TTLs before certificate updates as explained in Section 8 of 660 [RFC7671]. 662 If the hosting provider intends to use trust-anchor TLSA records 663 (certificate usage PKIX-TA(0) or DANE-TA(2)) then the same TLSA 664 record can match all end-entity certificates issues by the 665 certification authority in question, and continues to work across 666 end-entity certificate updates, so long as the issuer certificate or 667 public keys remains unchanged. This can be easier to implement, at 668 the cost of greater reliance on the security of the selected 669 provider. 671 The provider can of course publish separate TLSA records for each 672 customer, which increases the number of such RRsets that need to be 673 managed, but makes each one independent of the rest. 675 11. Security Considerations 677 The security considerations of the normatively referenced RFCs all 678 pertain to this extension. Since the server is delivering a chain of 679 DNS records and signatures to the client, it MUST rebuild the chain 680 in accordance with TTL and signature expiration of the chain 681 components as described in Section 5. TLS clients need roughly 682 accurate time in order to properly authenticate these signatures. 683 This could be achieved by running a time synchronization protocol 684 like NTP [RFC5905] or SNTP [RFC5905], which are already widely used 685 today. TLS clients MUST support a mechanism to track and roll over 686 the trust anchor key, or be able to avail themselves of a service 687 that does this, as described in Section 8. Security considerations 688 related to mandating the use of this extension are described in 689 Section 7. 691 12. IANA Considerations 693 This document defines one new entry in the TLS ExtensionsType Values 694 registry: 696 Value Extension Name TLS 1.3 Recommended Reference 697 ----- -------------- ------- ----------- --------------- 698 TBD dnssec_chain CH No [this document] 700 Figure 1 702 13. Acknowledgments 704 Many thanks to Adam Langley for laying the groundwork for this 705 extension in [I-D.agl-dane-serializechain]. The original idea is his 706 but our acknowledgment in no way implies his endorsement. This 707 document also benefited from discussions with and review from the 708 following people: Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, 709 Patrick McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri 710 Visweswaran, Duane Wessels, Nico Williams, and Richard Barnes. 712 14. References 714 14.1. Normative References 716 [RFC1035] Mockapetris, P., "Domain names - implementation and 717 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 718 November 1987, . 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, . 725 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 726 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 727 . 729 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 730 Rose, "Resource Records for the DNS Security Extensions", 731 RFC 4034, DOI 10.17487/RFC4034, March 2005, 732 . 734 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 735 Rose, "Protocol Modifications for the DNS Security 736 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 737 . 739 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 740 Security (DNSSEC) Hashed Authenticated Denial of 741 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 742 . 744 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 745 (TLS) Protocol Version 1.2", RFC 5246, 746 DOI 10.17487/RFC5246, August 2008, . 749 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 750 Extensions: Extension Definitions", RFC 6066, 751 DOI 10.17487/RFC6066, January 2011, . 754 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 755 of Named Entities (DANE) Transport Layer Security (TLS) 756 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 757 2012, . 759 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 760 Conversations about DNS-Based Authentication of Named 761 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 762 2014, . 764 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 765 Authentication of Named Entities (DANE) Protocol: Updates 766 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 767 October 2015, . 769 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 770 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 771 May 2017, . 773 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 774 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 775 . 777 14.2. Informative References 779 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 780 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 781 September 2007, . 783 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 784 "Network Time Protocol Version 4: Protocol and Algorithms 785 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 786 . 788 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 789 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 790 Transport Layer Security (TLS) and Datagram Transport 791 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 792 June 2014, . 794 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 795 DOI 10.17487/RFC7901, June 2016, . 798 [I-D.barnes-dane-uks] 799 Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- 800 Share Attacks on DNS-based Authentications of Named 801 Entities (DANE)", draft-barnes-dane-uks-00 (work in 802 progress), October 2016. 804 [I-D.agl-dane-serializechain] 805 Langley, A., "Serializing DNS Records with DNSSEC 806 Authentication", draft-agl-dane-serializechain-01 (work in 807 progress), July 2011. 809 [HAMPERING] 810 Gorjon, X. and W. Toorop, "Discovery method for a DNSSEC 811 validating stub resolver", July 2015, 812 . 815 Appendix A. Test vectors 817 The test vectors in this appendix are representations of the content 818 of the "opaque AuthenticationChain" field in DNS presentation format. 819 And except for the "extention_data" in Figure 2, do not contain the 820 "uint16 ExtSupportLifetime" field. 822 For brevity and reproducibility all DNS zones involved with the test 823 vectors are signed using keys with algorithm 13: ECDSA Curve P-256 824 with SHA-256. 826 To reflect operational practice, different zones in the examples are 827 in different phases of rolling their signing keys: 829 All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), 830 except for the example.com and example.net zones which use a 831 Combined Signing Key (CSK). 833 The root and org zones are rolling their ZSK's. 835 The com and org zones are rolling their KSK's. 837 The test vectors are DNSSEC valid in the same period as the 838 certificate is valid, which is in between November 28 2018 and 839 December 2 2020, with the following root trust anchor: 841 . IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 842 641bb568746f2ffc4d4 ) 844 The test vectors will authenticate the certificate used with 845 https://example.com/, https://example.net/ and https://example.org/ 846 at the time of writing: 848 -----BEGIN CERTIFICATE----- 849 MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN 850 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E 851 aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN 852 MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju 853 aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw 854 b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT 855 ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI 856 hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV 857 rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g 858 rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80 859 eyRJRqzy8I0LSPTTkhr3okXuzOXXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9jF3pJ 860 QnucP9vTBejMh374qvyd0QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvt 861 hcNtBfhkp8kO64/hxLHrLWgOFT/l4tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8Ew 862 ggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLyjnjUY4tCzhxtniMB0GA1UdDgQWBBRm 863 mGIC4AmRp9njNvt2xrC/oW2nvjCBgQYDVR0RBHoweIIPd3d3LmV4YW1wbGUub3Jn 864 ggtleGFtcGxlLmNvbYILZXhhbXBsZS5lZHWCC2V4YW1wbGUubmV0ggtleGFtcGxl 865 Lm9yZ4IPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS5lZHWCD3d3dy5leGFt 866 cGxlLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG 867 AQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNv 868 bS9zc2NhLXNoYTItZzYuY3JsMC+gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5j 869 b20vc3NjYS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgG 870 CCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAEC 871 AjB8BggrBgEFBQcBAQRwMG4wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj 872 ZXJ0LmNvbTBGBggrBgEFBQcwAoY6aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29t 873 L0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB 874 fwYKKwYBBAHWeQIEAgSCAW8EggFrAWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb 875 37jjd80OyA3cEAAAAWdcMZVGAAAEAwBIMEYCIQCEZIG3IR36Gkj1dq5L6EaGVycX 876 sHvpO7dKV0JsooTEbAIhALuTtf4wxGTkFkx8blhTV+7sf6pFT78ORo7+cP39jkJC 877 AHYAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMA 878 RzBFAiBvqnfSHKeUwGMtLrOG3UGLQIoaL3+uZsGTX3MfSJNQEQIhANL5nUiGBR6g 879 l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC 880 wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z 881 RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM 882 MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R 883 8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM 884 v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu 885 N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa 886 X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I 887 0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN 888 -----END CERTIFICATE----- 890 A.1. _443._tcp.www.example.com 892 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 893 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 894 922 ) 895 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 896 20201202000000 20181128000000 1870 example.com. 897 rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S 898 z2BhaswpGLVVuoijuVdzxYjmw== ) 899 example.com. 3600 IN DNSKEY ( 257 3 13 900 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 901 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 902 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 903 20201202000000 20181128000000 1870 example.com. 904 nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt 905 QHPGSpvRxTUC4tZi62z1UgGDw== ) 906 example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd 907 25a986e8a44f319ac3cd302bafc08f5b81e16) 908 example.com. 172800 IN RRSIG ( DS 13 2 172800 909 20201202000000 20181128000000 34327 com. 910 sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO 911 J1hhWSB6jgubEVl17rGNOA/YQ== ) 912 com. 172800 IN DNSKEY ( 256 3 13 913 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 914 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 915 com. 172800 IN DNSKEY ( 257 3 13 916 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 917 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 918 com. 172800 IN DNSKEY ( 257 3 13 919 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 920 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 921 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 922 20181128000000 18931 com. 923 LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5 924 7LFdPKpcvb8BvhM+GqKWGBEsg== ) 925 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 926 20181128000000 28809 com. 927 sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev 928 mDXqz6KEhhQjT+aQWDt6WFHlA== ) 929 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 930 f9eabb94487e658c188e7bcb52115 ) 931 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 932 70643bbde681db342a9e5cf2bb380 ) 933 com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 934 20181128000000 31918 . 935 nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb 936 vBKTf6pk8JRCqnfzlo2QY+WXA== ) 937 . 86400 IN DNSKEY ( 256 3 13 938 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 939 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 940 . 86400 IN DNSKEY ( 256 3 13 941 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 942 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 943 . 86400 IN DNSKEY ( 257 3 13 944 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 945 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 946 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 947 20181128000000 47005 . 948 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 949 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 951 A hex dump of the "extension_data" of the server's "dnssec_chain" 952 extension represention this with an ExtSupportLifetime value of 0 is: 954 0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 955 0010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 956 0020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f 957 0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b3 958 0040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 04 959 0050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 960 0060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 961 0070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 07 962 0080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d 963 0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c 964 00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35 965 00b0: 5f ba af 75 3c 19 28 32 fa 62 1f a7 3a 8b 85 ed 966 00c0: 79 d3 74 11 73 87 59 8f cc 81 2e 1e f3 fb 07 65 967 00d0: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 968 00e0: 00 0e 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 969 00f0: 9c fe a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 970 0100: 12 d8 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 971 0110: ce b9 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 972 0120: 5b 2e 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 973 0130: 65 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 974 0140: 00 30 0d 02 00 00 0e 10 5f c6 d9 00 5b fd da 80 975 0150: 07 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 46 976 0160: 28 38 30 75 b8 e3 4b 74 3a 20 9b 27 ae 14 8d 11 977 0170: 0d 4e 1a 24 61 38 a9 10 83 24 9c b4 a1 2a 2d 9b 978 0180: c4 c2 d7 ab 5e b3 af b9 f5 d1 03 7e 4d 5d a8 33 979 0190: 9c 16 2a 92 98 e9 be 18 07 41 a8 ca 74 ac cc 07 980 01a0: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 981 01b0: 00 02 a3 00 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 982 01c0: 8e 90 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 983 01d0: 3c d3 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 984 01e0: 6c 65 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 985 01f0: 57 00 2b 0d 02 00 02 a3 00 5f c6 d9 00 5b fd da 986 0200: 80 86 17 03 63 6f 6d 00 a2 03 e7 04 a6 fa cb eb 987 0210: 13 fc 93 84 fd d6 de 6b 50 de 56 59 27 1f 38 ce 988 0220: 81 49 86 84 e6 36 31 72 d4 7e 23 19 fd b4 a2 2a 989 0230: 58 a2 31 ed c2 f1 ff 4f b2 81 1a 18 07 be 72 cb 990 0240: 52 41 aa 26 fd ae e0 39 03 63 6f 6d 00 00 30 00 991 0250: 01 00 02 a3 00 00 44 01 00 03 0d ec 82 04 e4 3a 992 0260: 25 f2 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d 993 0270: c2 a4 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca 994 0280: f2 e9 cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 56 995 0290: b6 80 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 00 996 02a0: 00 30 00 01 00 02 a3 00 00 44 01 01 03 0d 45 b9 997 02b0: 1c 3b ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 80 998 02c0: a7 77 a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d1 999 02d0: 12 c7 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc 1000 02e0: 5f 64 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 63 1001 02f0: 6f 6d 00 00 30 00 01 00 02 a3 00 00 44 01 01 03 1002 0300: 0d b3 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d9 1003 0310: ac 5e 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 95 1004 0320: 8f 71 c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 38 1005 0330: 95 93 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 93 1006 0340: 90 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 57 1007 0350: 00 30 0d 01 00 02 a3 00 5f c6 d9 00 5b fd da 80 1008 0360: 49 f3 03 63 6f 6d 00 18 a9 48 eb 23 d4 4f 80 ab 1009 0370: c9 92 38 fc b4 3c 5a 18 de be 57 00 4f 73 43 59 1010 0380: 3f 6d eb 6e d7 1e 04 65 4a 43 3f 7a a1 97 21 30 1011 0390: d9 bd 92 1c 73 dc f6 3f cf 66 5f 2f 05 a0 aa eb 1012 03a0: af b0 59 dc 12 c9 65 03 63 6f 6d 00 00 2e 00 01 1013 03b0: 00 02 a3 00 00 57 00 30 0d 01 00 02 a3 00 5f c6 1014 03c0: d9 00 5b fd da 80 70 89 03 63 6f 6d 00 61 70 e6 1015 03d0: 95 9b d9 ed 6e 57 58 37 b6 f5 80 bd 99 db d2 4a 1016 03e0: 44 68 2b 0a 35 96 26 a2 46 b1 81 2f 5f 90 96 b7 1017 03f0: 5e 15 7e 77 84 8f 06 8a e0 08 5e 1a 60 9f c1 92 1018 0400: 98 c3 3b 73 68 63 fb cc d4 d8 1f 5e b2 03 63 6f 1019 0410: 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 02 1020 0420: 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 41 1021 0430: 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 15 1022 0440: 03 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 70 1023 0450: 89 0d 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 73 1024 0460: e9 2c 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf 1025 0470: 2b b3 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 1026 0480: 00 53 00 2b 0d 01 00 01 51 80 5f c6 d9 00 5b fd 1027 0490: da 80 7c ae 00 12 2e 27 6d 45 d9 e9 81 6f 79 22 1028 04a0: ad 6e a2 e7 3e 82 d2 6f ce 0a 4b 71 86 25 f3 14 1029 04b0: 53 1a c9 2f 8a e8 24 18 df 9b 89 8f 98 9d 32 e8 1030 04c0: 0b c4 de ab a7 c4 a7 c8 f1 72 ad b5 7c ed 7f b5 1031 04d0: e7 7a 78 4b 07 00 00 30 00 01 00 01 51 80 00 44 1032 04e0: 01 00 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a2 1033 04f0: 54 f7 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca 1034 0500: 8c e3 f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 68 1035 0510: e3 58 ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d4 1036 0520: ce 8d fe 14 00 00 30 00 01 00 01 51 80 00 44 01 1037 0530: 00 03 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f2 1038 0540: 4c ac fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b3 1039 0550: 21 c1 d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 91 1040 0560: 5b 16 d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d1 1041 0570: 1d 17 11 00 00 30 00 01 00 01 51 80 00 44 01 01 1042 0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad 1043 0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 1044 05a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd 1045 05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 1046 05c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d 1047 05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 00 1048 05e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c 1049 05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 72 1050 0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f 1051 0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be 1053 Figure 2 1055 A.2. _25._tcp.example.com NSEC wildcard 1057 _25._tcp.example.com. 3600 IN TLSA ( 3 1 1 1058 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 1059 922 ) 1060 _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 1061 20201202000000 20181128000000 1870 example.com. 1062 BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2 1063 rfL4DFP8rO3VMgI0v+ogrox0w== ) 1064 *._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG 1065 NSEC TLSA ) 1066 *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 1067 20201202000000 20181128000000 1870 example.com. 1068 K6u8KrR8ca5bjtbce3w8yjMXr9vw12225lAwyIHpxptY43OMLCUCenwpYW5qd 1069 mpFvAacqj4+tSkKiN279SI9pA== ) 1070 example.com. 3600 IN DNSKEY ( 257 3 13 1071 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 1072 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 1073 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 1074 20201202000000 20181128000000 1870 example.com. 1075 nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt 1076 QHPGSpvRxTUC4tZi62z1UgGDw== ) 1077 example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd 1078 25a986e8a44f319ac3cd302bafc08f5b81e16 ) 1079 example.com. 172800 IN RRSIG ( DS 13 2 172800 1080 20201202000000 20181128000000 34327 com. 1081 sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO 1082 J1hhWSB6jgubEVl17rGNOA/YQ== ) 1083 com. 172800 IN DNSKEY ( 256 3 13 1084 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 1085 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 1086 com. 172800 IN DNSKEY ( 257 3 13 1087 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 1088 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 1089 com. 172800 IN DNSKEY ( 257 3 13 1090 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 1091 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 1092 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1093 20181128000000 18931 com. 1094 LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5 1095 7LFdPKpcvb8BvhM+GqKWGBEsg== ) 1096 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1097 20181128000000 28809 com. 1098 sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev 1099 mDXqz6KEhhQjT+aQWDt6WFHlA== ) 1100 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 1101 f9eabb94487e658c188e7bcb52115 ) 1102 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 1103 70643bbde681db342a9e5cf2bb380 ) 1104 com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1105 20181128000000 31918 . 1106 nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb 1107 vBKTf6pk8JRCqnfzlo2QY+WXA== ) 1108 . 86400 IN DNSKEY ( 256 3 13 1109 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1110 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1111 . 86400 IN DNSKEY ( 256 3 13 1112 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1113 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1114 . 86400 IN DNSKEY ( 257 3 13 1115 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1116 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1117 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1118 20181128000000 47005 . 1119 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1120 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1122 A.3. _25._tcp.example.org NSEC3 wildcard 1124 _25._tcp.example.org. 3600 IN TLSA ( 3 1 1 1125 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 1126 922 ) 1127 _25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 1128 20201202000000 20181128000000 56566 example.org. 1129 lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL 1130 cYzJ7vCvqb9gFCiCJjK2gAamw== ) 1131 dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( 1132 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) 1133 dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( 1134 NSEC3 13 3 3600 20201202000000 20181128000000 56566 1135 example.org. 1137 guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE 1138 X38cWzEQOpreJu3t4WAfPsxdg== ) 1139 example.org. 3600 IN DNSKEY ( 256 3 13 1140 NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N 1141 UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566 1142 example.org. 3600 IN DNSKEY ( 257 3 13 1143 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 1144 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 1145 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 1146 20201202000000 20181128000000 44384 example.org. 1147 ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk 1148 6OPPvyHjVXMAsvk0tqV0B+/ag== ) 1149 example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 1150 3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 1151 example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000 1152 20181128000000 9523 org. 1153 m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 1154 clpAfvZHx59Ackst4X+zXYpUA== ) 1155 org. 86400 IN DNSKEY ( 256 3 13 1156 fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e 1157 HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417 1158 org. 86400 IN DNSKEY ( 256 3 13 1159 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy 1160 mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523 1161 org. 86400 IN DNSKEY ( 257 3 13 1162 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 1163 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352 1164 org. 86400 IN DNSKEY ( 257 3 13 1165 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 1166 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 1167 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1168 20181128000000 12651 org. 1169 Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt 1170 us0pUgWngbT/OWXskdMYXZU4A== ) 1171 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1172 20181128000000 49352 org. 1173 VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p 1174 vZEMj1YXD+dIqb2nUK9PGBAXw== ) 1175 org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 1176 9db5c24a75743eb1e704b97a9fabc ) 1177 org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe 1178 f4a2f18920db5f58710dd767c293b ) 1179 org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1180 20181128000000 31918 . 1181 adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV 1182 EemgaE357S4pX5D0tVZzeZJ6A== ) 1183 . 86400 IN DNSKEY ( 256 3 13 1184 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1185 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1186 . 86400 IN DNSKEY ( 256 3 13 1187 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1188 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1189 . 86400 IN DNSKEY ( 257 3 13 1190 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1191 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1192 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1193 20181128000000 47005 . 1194 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1195 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1197 A.4. _443._tcp.www.example.org CNAME 1199 _443._tcp.www.example.org. 3600 IN CNAME ( 1200 dane311.example.org. ) 1201 _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 1202 20201202000000 20181128000000 56566 example.org. 1203 R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx 1204 Qb/a90O696120NsYaZX2+ebBA== ) 1205 dane311.example.org. 3600 IN TLSA ( 3 1 1 1206 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 1207 922 ) 1208 dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 1209 20201202000000 20181128000000 56566 example.org. 1210 f6TbTZTpu3h6MYpLkKQwWILAkYQ3EUY+Nsoa6any6yt+aeuunMUjw+IJB2QLm 1211 0x0PrD7m39JA3NUSkUp9riNNQ== ) 1212 example.org. 3600 IN DNSKEY ( 256 3 13 1213 NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N 1214 UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566 1215 example.org. 3600 IN DNSKEY ( 257 3 13 1216 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 1217 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 1218 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 1219 20201202000000 20181128000000 44384 example.org. 1220 ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk 1221 6OPPvyHjVXMAsvk0tqV0B+/ag== ) 1222 example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 1223 3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 1224 example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000 1225 20181128000000 9523 org. 1226 m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 1227 clpAfvZHx59Ackst4X+zXYpUA== ) 1228 org. 86400 IN DNSKEY ( 256 3 13 1229 fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e 1230 HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417 1231 org. 86400 IN DNSKEY ( 256 3 13 1232 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy 1233 mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523 1234 org. 86400 IN DNSKEY ( 257 3 13 1235 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 1236 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352 1237 org. 86400 IN DNSKEY ( 257 3 13 1238 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 1239 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 1240 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1241 20181128000000 12651 org. 1242 Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt 1243 us0pUgWngbT/OWXskdMYXZU4A== ) 1244 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1245 20181128000000 49352 org. 1246 VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p 1247 vZEMj1YXD+dIqb2nUK9PGBAXw== ) 1248 org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 1249 9db5c24a75743eb1e704b97a9fabc ) 1250 org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe 1251 f4a2f18920db5f58710dd767c293b ) 1252 org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1253 20181128000000 31918 . 1254 adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV 1255 EemgaE357S4pX5D0tVZzeZJ6A== ) 1256 . 86400 IN DNSKEY ( 256 3 13 1257 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1258 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1259 . 86400 IN DNSKEY ( 256 3 13 1260 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1261 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1262 . 86400 IN DNSKEY ( 257 3 13 1263 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1264 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1265 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1266 20181128000000 47005 . 1267 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1268 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1270 A.5. _443._tcp.www.example.net DNAME 1272 example.net. 3600 IN DNAME example.com. 1273 example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000 1274 20181128000000 48085 example.net. 1275 o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx 1276 OI/pDnjJcLSd/gBLtqR52WLMA== ) 1277 ; _443._tcp.www.example.net. 3600 IN CNAME ( 1278 ; _443._tcp.www.example.com. ) 1279 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 1280 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 1281 922 ) 1282 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 1283 20201202000000 20181128000000 1870 example.com. 1284 rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S 1285 z2BhaswpGLVVuoijuVdzxYjmw== ) 1286 example.net. 3600 IN DNSKEY ( 257 3 13 1287 X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d 1288 9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085 1289 example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600 1290 20201202000000 20181128000000 48085 example.net. 1291 CkwqgEt1p97oMa3w5LctIjKIuG5XVSapKrfwuHhb5p04fWXRMNsXasG/kd2F/ 1292 wlmMWiq38gOQaYCLNm+cjQzpQ== ) 1293 example.net. 172800 IN DS ( 48085 13 2 7c1998ce683df60e2fa41460c4 1294 53f88f463dac8cd5d074277b4a7c04502921be ) 1295 example.net. 172800 IN RRSIG ( DS 13 2 172800 1296 20201202000000 20181128000000 10713 net. 1297 w0JxDeiBJZNlpCdxKtRENlqfTpSxcs6Vftscsyfo/hyeTPYcIt4yItDkYsYK+ 1298 KQ6FYAVE4nisA3vDQoZVL4wow== ) 1299 net. 172800 IN DNSKEY ( 256 3 13 1300 061EoQs4sBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimi4/lw/vtyfqALuLF 1301 JiFjtCK3HMPi8HQ1jbGEwbGCA== ) ; Key ID = 10713 1302 net. 172800 IN DNSKEY ( 257 3 13 1303 LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5 1304 oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485 1305 net. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1306 20181128000000 485 net. 1307 031jXg06zSuDwI5zqYuYFJg1O5p+zy85csMXagvRxB9W2lL/wJRi6Gn9BcaCV 1308 RnDId5WR+yCADhsbKfSrrd9vQ== ) 1309 net. 86400 IN DS ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c 1310 d8c247769b23adb13ca234d1c05 ) 1311 net. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1312 20181128000000 31918 . 1313 vOXoTjxggGTYKIwssQ3kpML0ag6D0Hcm+Syy7++4zT7gaFHfRH9a6uZekIWdb 1314 oss8y7q4onW4rxKdtw2S28hwQ== ) 1315 . 86400 IN DNSKEY ( 256 3 13 1316 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1317 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1318 . 86400 IN DNSKEY ( 256 3 13 1319 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1320 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1321 . 86400 IN DNSKEY ( 257 3 13 1322 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1323 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1324 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1325 20181128000000 47005 . 1326 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1327 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1328 example.com. 3600 IN DNSKEY ( 257 3 13 1329 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 1330 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 1331 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 1332 20201202000000 20181128000000 1870 example.com. 1333 nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt 1334 QHPGSpvRxTUC4tZi62z1UgGDw== ) 1335 example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd 1336 25a986e8a44f319ac3cd302bafc08f5b81e16 ) 1337 example.com. 172800 IN RRSIG ( DS 13 2 172800 1338 20201202000000 20181128000000 34327 com. 1339 sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO 1340 J1hhWSB6jgubEVl17rGNOA/YQ== ) 1341 com. 172800 IN DNSKEY ( 256 3 13 1342 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 1343 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 1344 com. 172800 IN DNSKEY ( 257 3 13 1345 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 1346 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 1347 com. 172800 IN DNSKEY ( 257 3 13 1348 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 1349 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 1350 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1351 20181128000000 18931 com. 1352 LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5 1353 7LFdPKpcvb8BvhM+GqKWGBEsg== ) 1354 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1355 20181128000000 28809 com. 1356 sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev 1357 mDXqz6KEhhQjT+aQWDt6WFHlA== ) 1358 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 1359 f9eabb94487e658c188e7bcb52115 ) 1360 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 1361 70643bbde681db342a9e5cf2bb380 ) 1362 com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1363 20181128000000 31918 . 1364 nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb 1365 vBKTf6pk8JRCqnfzlo2QY+WXA== ) 1367 A.6. _25._tcp.smtp.example.com NSEC Denial of Existence 1369 example.com. 3600 IN SOA ( sns.dns.icann.org. noc.dns.icann.org. 1370 2017042720 7200 3600 1209600 3600 ) 1371 example.com. 3600 IN RRSIG ( SOA 13 2 3600 20201202000000 1372 20181128000000 1870 example.com. 1373 sr214XHDDSIcInHStplCFZQ0CI5pl5aIIrrFRkwyISWYbjp9KncxJlWc4nsvf 1374 6npBwVo+MP4/dg9JLO35kVkUw== ) 1375 smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA 1376 RRSIG NSEC ) 1378 smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 1379 20201202000000 20181128000000 1870 example.com. 1380 rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf 1381 crlsQZmnAUlfmBNCygxAd7JNw== ) 1382 example.com. 3600 IN DNSKEY ( 257 3 13 1383 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s 1384 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 1385 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 1386 20201202000000 20181128000000 1870 example.com. 1387 nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt 1388 QHPGSpvRxTUC4tZi62z1UgGDw== ) 1389 example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd 1390 25a986e8a44f319ac3cd302bafc08f5b81e16 ) 1391 example.com. 172800 IN RRSIG ( DS 13 2 172800 1392 20201202000000 20181128000000 34327 com. 1393 sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO 1394 J1hhWSB6jgubEVl17rGNOA/YQ== ) 1395 com. 172800 IN DNSKEY ( 256 3 13 1396 7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj 1397 3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327 1398 com. 172800 IN DNSKEY ( 257 3 13 1399 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f 1400 Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931 1401 com. 172800 IN DNSKEY ( 257 3 13 1402 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt 1403 DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809 1404 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1405 20181128000000 18931 com. 1406 LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5 1407 7LFdPKpcvb8BvhM+GqKWGBEsg== ) 1408 com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 1409 20181128000000 28809 com. 1410 sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev 1411 mDXqz6KEhhQjT+aQWDt6WFHlA== ) 1412 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 1413 f9eabb94487e658c188e7bcb52115 ) 1414 com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e 1415 70643bbde681db342a9e5cf2bb380 ) 1416 com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1417 20181128000000 31918 . 1418 nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb 1419 vBKTf6pk8JRCqnfzlo2QY+WXA== ) 1420 . 86400 IN DNSKEY ( 256 3 13 1421 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1422 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1423 . 86400 IN DNSKEY ( 256 3 13 1424 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1425 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1427 . 86400 IN DNSKEY ( 257 3 13 1428 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1429 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1430 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1431 20181128000000 47005 . 1432 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1433 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1435 A.7. _25._tcp.smtp.example.org NSEC3 Denial of Existence 1437 example.org. 3600 IN SOA ( sns.dns.icann.org. noc.dns.icann.org. 1438 2017042720 7200 3600 1209600 3600 ) 1439 example.org. 3600 IN RRSIG ( SOA 13 2 3600 20201202000000 1440 20181128000000 56566 example.org. 1441 cpKzINSSU0Jk6Y/QrsYLgfXNUY4b/pXDWsXrzIHOT8udmQcJkIU+LtnO9+Qa3 1442 2vJqiV6m65FvbBigJ612c3Wyw== ) 1443 vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN NSEC3 ( 1444 1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG ) 1445 vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG ( 1446 NSEC3 13 3 3600 20201202000000 20181128000000 56566 1447 example.org. 1448 wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh 1449 gQeV5KgP1cdvPt1BEowKqK4Sw== ) 1450 dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( 1451 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) 1452 dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( 1453 NSEC3 13 3 3600 20201202000000 20181128000000 56566 1454 example.org. 1455 guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE 1456 X38cWzEQOpreJu3t4WAfPsxdg== ) 1457 a73bi8coh6dvf1arqdeuogf95r0828mk.example.org. 3600 IN NSEC3 ( 1458 1 0 1 - c1p0lp7l1l8gdn0jl13pp1o41h35untj CNAME RRSIG ) 1459 a73bi8coh6dvf1arqdeuogf95r0828mk.example.org. 3600 IN RRSIG ( 1460 NSEC3 13 3 3600 20201202000000 20181128000000 56566 1461 example.org. 1462 ePBUuWdj8Bc+/41gHBm2Bx/IK/j/Q4W7A5uTgSj/0Sd57mP/NTWRZq3p8yBNe 1463 FPC2mBJ2oWQFi6/V9dmyiBh2A== ) 1464 example.org. 3600 IN DNSKEY ( 256 3 13 1465 NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N 1466 UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566 1467 example.org. 3600 IN DNSKEY ( 257 3 13 1468 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr 1469 Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384 1470 example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600 1471 20201202000000 20181128000000 44384 example.org. 1472 ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk 1473 6OPPvyHjVXMAsvk0tqV0B+/ag== ) 1474 example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51 1475 3c8003e1d9121f1ff11a08b4cdd348d090aa6 ) 1476 example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000 1477 20181128000000 9523 org. 1478 m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62 1479 clpAfvZHx59Ackst4X+zXYpUA== ) 1480 org. 86400 IN DNSKEY ( 256 3 13 1481 fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e 1482 HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417 1483 org. 86400 IN DNSKEY ( 256 3 13 1484 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy 1485 mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523 1486 org. 86400 IN DNSKEY ( 257 3 13 1487 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 1488 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352 1489 org. 86400 IN DNSKEY ( 257 3 13 1490 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ 1491 HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651 1492 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1493 20181128000000 12651 org. 1494 Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt 1495 us0pUgWngbT/OWXskdMYXZU4A== ) 1496 org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000 1497 20181128000000 49352 org. 1498 VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p 1499 vZEMj1YXD+dIqb2nUK9PGBAXw== ) 1500 org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f 1501 9db5c24a75743eb1e704b97a9fabc ) 1502 org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe 1503 f4a2f18920db5f58710dd767c293b ) 1504 org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1505 20181128000000 31918 . 1506 adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV 1507 EemgaE357S4pX5D0tVZzeZJ6A== ) 1508 . 86400 IN DNSKEY ( 256 3 13 1509 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1510 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1511 . 86400 IN DNSKEY ( 256 3 13 1512 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1513 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1514 . 86400 IN DNSKEY ( 257 3 13 1515 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1516 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1517 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1518 20181128000000 47005 . 1519 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1520 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1522 A.8. _443._tcp.www.insecure.example NSEC3 opt-out insecure delegation 1523 example. 432000 IN SOA ( ns.ns-servers.example. 1524 hostmaster.ns-servers.example. 1525 2018042500 1800 900 604800 43200) 1526 example. 432000 IN RRSIG ( SOA 13 1 432000 20201202000000 1527 20181128000000 15903 example. 1528 Hx4gEL0q9Za/jAB0LZ8dduuwef9qPrSyEK3RoSevb1S9UkrLQj1cL08HkiDwz 1529 mcduSc5oMky0toC/gjOoZClEA== ) 1530 c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 ( 1531 1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY 1532 NSEC3PARAM ) 1533 c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG ( 1534 NSEC3 13 2 43200 20201202000000 20181128000000 15903 1535 example. 1536 pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg 1537 RpXUsJhZBDax2dfDhK7zOk7ow== ) 1538 shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 ( 1539 1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG ) 1540 shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG ( 1541 NSEC3 13 2 43200 20201202000000 20181128000000 15903 1542 example. 1543 5Aq//A8bsWNwcXbT91pMX2Oqf8VpJQRjqH4D2yZElW00wKmt85mhgu2qYPrvH 1544 QwGEB4STMz2Nefq01/GY6NHKg== ) 1545 example. 432000 IN DNSKEY ( 257 3 13 1546 yrkqXSbVwXOoUxCjr/E9yg8XUzbZNlwPllVsoUPd73TLOnBQQ+03Qw4/k+Nme 1547 /66WIw+ZTlHYcTNalxiGYm0uQ== ) ; Key ID = 15903 1548 example. 432000 IN RRSIG ( DNSKEY 13 1 432000 1549 20201202000000 20181128000000 15903 example. 1550 wwEo3ri6JBuCqx5b33w8axFWOhIen1l+/mm0Isyc9FciuLhBiP+IqSgt+Igc8 1551 9nR8zRpJpo1D6XR/qJxZgnfaA== ) 1552 example. 86400 IN DS ( 15903 13 2 7e0ebaf1cc0d309d4a73ca7d711719d 1553 d940f4da87b3d72865167650fc73ea577 ) 1554 example. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 1555 20181128000000 31918 . 1556 B5vx4zZaS+bOYfz0PzpaPfk9VxxBvYbGjIvGhpUZV3diXzfCguXxN4JIT1Sz8 1557 eJX6BYT5QPIrbG/N35U1sIskw== ) 1558 . 86400 IN DNSKEY ( 256 3 13 1559 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW 1560 P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918 1561 . 86400 IN DNSKEY ( 256 3 13 1562 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 1563 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 1564 . 86400 IN DNSKEY ( 257 3 13 1565 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv 1566 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 1567 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 1568 20181128000000 47005 . 1569 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 1570 nBT1dtNjIczvLG9pQTnOKUsHQ== ) 1572 Authors' Addresses 1574 Viktor Dukhovni 1575 Two Sigma 1577 EMail: ietf-dane@dukhovni.org 1579 Shumon Huque 1580 Salesforce 1582 EMail: shuque@gmail.com 1584 Willem Toorop 1585 NLnet Labs 1587 EMail: willem@nlnetlabs.nl 1589 Paul Wouters 1590 Red Hat 1592 EMail: pwouters@redhat.com 1594 Melinda Shore 1595 Fastly 1597 EMail: mshore@fastly.com