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