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