doc: Add RFC documents

1 files changed, 1698 insertions, 0 deletions

diff --git a/doc/rfc/rfc9102.txt b/doc/rfc/rfc9102.txt
new file mode 100644
index 0000000..564b7ab
--- /dev/null
+++ b/doc/rfc/rfc9102.txt
@@ -0,0 +1,1698 @@
+
+
+
+
+Independent Submission                                       V. Dukhovni
+Request for Comments: 9102                                     Two Sigma
+Category: Experimental                                          S. Huque
+ISSN: 2070-1721                                               Salesforce
+                                                               W. Toorop
+                                                              NLnet Labs
+                                                              P. Wouters
+                                                                   Aiven
+                                                                M. Shore
+                                                                  Fastly
+                                                             August 2021
+
+
+                       TLS DNSSEC Chain Extension
+
+Abstract
+
+   This document describes an experimental TLS extension for the in-band
+   transport of the complete set of records that can be validated by
+   DNSSEC and that are needed to perform DNS-Based Authentication of
+   Named Entities (DANE) of a TLS server.  This extension obviates the
+   need to perform separate, out-of-band DNS lookups.  When the
+   requisite DNS records do not exist, the extension conveys a denial-
+   of-existence proof that can be validated.
+
+   This experimental extension is developed outside the IETF and is
+   published here to guide implementation of the extension and to ensure
+   interoperability among implementations.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9102.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Scope of the Experiment
+     1.2.  Requirements Notation
+   2.  DNSSEC Authentication Chain Extension
+     2.1.  Protocol, TLS 1.2
+     2.2.  Protocol, TLS 1.3
+     2.3.  DNSSEC Authentication Chain Data
+       2.3.1.  Authenticated Denial of Existence
+   3.  Construction of Serialized Authentication Chains
+   4.  Caching and Regeneration of the Authentication Chain
+   5.  Expired Signatures in the Authentication Chain
+   6.  Verification
+   7.  Extension Pinning
+   8.  Trust Anchor Maintenance
+   9.  Virtual Hosting
+   10. Operational Considerations
+   11. Security Considerations
+   12. IANA Considerations
+   13. References
+     13.1.  Normative References
+     13.2.  Informative References
+   Appendix A.  Test Vectors
+     A.1.  "_443._tcp.www.example.com"
+     A.2.  "_25._tcp.example.com" NSEC Wildcard
+     A.3.  "_25._tcp.example.org" NSEC3 Wildcard
+     A.4.  "_443._tcp.www.example.org" CNAME
+     A.5.  "_443._tcp.www.example.net" DNAME
+     A.6.  "_25._tcp.smtp.example.com" NSEC Denial of Existence
+     A.7.  "_25._tcp.smtp.example.org" NSEC3 Denial of Existence
+     A.8.  "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure
+           Delegation
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes an experimental TLS [RFC5246] [RFC8446]
+   extension for in-band transport of the complete set of resource
+   records (RRs) validated by DNSSEC [RFC4033] [RFC4034] [RFC4035].
+   This extension enables a TLS client to perform DANE authentication
+   [RFC6698] [RFC7671] of a TLS server without the need to perform out-
+   of-band DNS lookups.  Retrieval of the required DNS records may be
+   unavailable to the client [DISCOVERY] or may incur undesirable
+   additional latency.
+
+   The extension described here allows a TLS client to request that the
+   TLS server return the DNSSEC authentication chain corresponding to
+   its DNSSEC-validated DANE TLSA resource record set (RRset) or
+   authenticated denial of existence of such an RRset (as described in
+   Section 2.3.1).  If the server supports this extension, it performs
+   the appropriate DNS queries, builds the authentication chain, and
+   returns it to the client.  The server will typically use a previously
+   cached authentication chain, but it will need to rebuild it
+   periodically as described in Section 4.  The client then
+   authenticates the chain using a preconfigured DNSSEC trust anchor.
+
+   In the absence of TLSA records, this extension conveys the required
+   authenticated denial of existence.  Such proofs are needed to
+   securely signal that specified TLSA records are not available so that
+   TLS clients can safely fall back to authentication based on Public
+   Key Infrastructure X.509 (PKIX, sometimes called WebPKI) if allowed
+   by local policy.  These proofs are also needed to avoid downgrade
+   from opportunistic authenticated TLS (when DANE TLSA records are
+   present) to unauthenticated opportunistic TLS (in the absence of
+   DANE).  Denial-of-existence records are also used by the TLS client
+   to clear extension pins that are no longer relevant, as described in
+   Section 7.
+
+   This extension supports DANE authentication of either X.509
+   certificates or raw public keys, as described in the DANE
+   specification [RFC6698] [RFC7671] [RFC7250].
+
+   This extension also mitigates against an unknown key share (UKS)
+   attack [DANE-UKS] when using raw public keys since the server commits
+   to its DNS name (normally found in its certificate) via the content
+   of the returned TLSA RRset.
+
+   This experimental extension is developed outside the IETF and is
+   published here to guide implementation of the extension and to ensure
+   interoperability among implementations.
+
+1.1.  Scope of the Experiment
+
+   The mechanism described in this document is intended to be used with
+   applications on the wider internet.  One application of TLS well
+   suited for the TLS DNSSEC Chain extension is DNS over TLS [RFC7858].
+   In fact, one of the authentication methods for DNS over TLS _is_ the
+   mechanism described in this document, as specified in Section 8.2.2
+   of [RFC8310].
+
+   The need for this mechanism when using DANE to authenticate a DNS-
+   over-TLS resolver is obvious, since DNS may not be available to
+   perform the required DNS lookups.  Other applications of TLS would
+   benefit from using this mechanism as well.  The client sides of those
+   applications would not be required to be used on endpoints with a
+   working DNSSEC resolver in order for them to use the DANE
+   authentication of the TLS service.  Therefore, we invite other TLS
+   services to try out this mechanism as well.
+
+   In the TLS Working Group, concerns have been raised that the pinning
+   technique as described in Section 7 would complicate deployability of
+   the TLS DNSSEC chain extension.  The goal of the experiment is to
+   study these complications in real-world deployments.  This experiment
+   hopefully will give the TLS Working Group some insight into whether
+   or not this is a problem.
+
+   If the experiment is successful, it is expected that the findings of
+   the experiment will result in an updated document for Standards Track
+   approval.
+
+1.2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  DNSSEC Authentication Chain Extension
+
+2.1.  Protocol, TLS 1.2
+
+   A client MAY include an extension of type "dnssec_chain" in the
+   (extended) ClientHello.  The "extension_data" field of this extension
+   consists of the server's 16-bit TCP port number in network (big-
+   endian) byte order.  Clients sending this extension MUST also send
+   the Server Name Identification (SNI) extension [RFC6066].  Together,
+   these make it possible for the TLS server to determine which
+   authenticated TLSA RRset chain needs to be used for the
+   "dnssec_chain" extension.
+
+   When a server that implements (and is configured to enable the use
+   of) this extension receives a "dnssec_chain" extension in the
+   ClientHello, it MUST first check whether the requested TLSA RRset
+   (based on the port number in this extension and hostname in the SNI
+   extension) is associated with the server.  If the extension, the SNI
+   hostname, or the port number is unsupported, the server's extended
+   ServerHello message MUST NOT include the "dnssec_chain" extension.
+
+   Otherwise, the server's extended ServerHello message MUST contain a
+   serialized authentication chain using the format described below.  If
+   the server does not have access to the requested DNS chain -- for
+   example, due to a misconfiguration or expired chain -- the server
+   MUST omit the extension rather than send an incomplete chain.
+   Clients that are expecting this extension MUST interpret this as a
+   downgrade attack and MUST abort the TLS connection.  Therefore,
+   servers MUST send denial-of-existence proofs unless, for the
+   particular application protocol or service, clients are expected to
+   continue even in the absence of such a proof.  As with all TLS
+   extensions, if the server does not support this extension, it will
+   not return any authentication chain.
+
+   The set of supported combinations of a port number and SNI name may
+   be configured explicitly by server administrators or could be
+   inferred from the available certificates combined with a list of
+   supported ports.  It is important to note that the client's notional
+   port number may be different from the actual port on which the server
+   is receiving connections.
+
+   Differences between the client's notional port number and the actual
+   port at the server could be a result of intermediate systems
+   performing network address translation or a result of a redirect via
+   HTTPS or SVCB records (both defined in [DNSOP-SVCB-HTTPS]).
+
+   Though a DNS zone's HTTPS or SVCB records may be signed, a client
+   using this protocol might not have direct access to a validating
+   resolver and might not be able to check the authenticity of the
+   target port number or hostname.  In order to avoid downgrade attacks
+   via forged DNS records, the SNI name and port number inside the
+   client extension MUST be based on the original SNI name and port and
+   MUST NOT be taken from the encountered HTTPS or SVCB record.  The
+   client supporting this document and HTTPS or SVCB records MUST still
+   use the HTTPS or SVCB records to select the target transport
+   endpoint.  Servers supporting this extension that are targets of
+   HTTPS or SVCB records MUST be provisioned to process client
+   extensions based on the client's logical service endpoint's SNI name
+   and port as it is prior to HTTPS or SVCB indirection.
+
+2.2.  Protocol, TLS 1.3
+
+   In TLS 1.3 [RFC8446], when the server receives the "dnssec_chain"
+   extension, it adds its "dnssec_chain" extension to the extension
+   block of the Certificate message containing the end-entity
+   certificate being validated rather than to the extended ServerHello
+   message.
+
+   The extension protocol behavior otherwise follows that specified for
+   TLS version 1.2 [RFC5246].
+
+2.3.  DNSSEC Authentication Chain Data
+
+   The "extension_data" field of the client's "dnssec_chain" extension
+   MUST contain the server's 16-bit TCP port number in network (big-
+   endian) byte order:
+
+       struct {
+           uint16 PortNumber;
+       } DnssecChainExtension;
+
+   The "extension_data" field of the server's "dnssec_chain" extension
+   MUST contain a DNSSEC authentication chain encoded in the following
+   form:
+
+       struct {
+           uint16 ExtSupportLifetime;
+           opaque AuthenticationChain<1..2^16-1>
+       } DnssecChainExtension;
+
+   The ExtSupportLifetime value is the number of hours that the TLS
+   server has committed itself to serving this extension.  A value of
+   zero prohibits the client from unilaterally requiring ongoing use of
+   the extension based on prior observation of its use (extension
+   pinning).  This is further described in Section 7.
+
+   The AuthenticationChain is composed of a sequence of uncompressed
+   wire format DNS RRs (including all requisite RRSIG RRs [RFC4034]) in
+   no particular order.  The format of the resource record is described
+   in [RFC1035], Section 3.2.1.
+
+       RR = { owner, type, class, TTL, RDATA length, RDATA }
+
+   The order of returned RRs is unspecified, and a TLS client MUST NOT
+   assume any ordering of RRs.
+
+   Use of DNS wire format records enables easier generation of the data
+   structure on the server and easier verification of the data on the
+   client by means of existing DNS library functions.
+
+   The returned RRsets MUST contain either the TLSA RRset or the
+   associated denial-of-existence proof of the configured (and
+   requested) SNI name and port.  In either case, the chain of RRsets
+   MUST be accompanied by the full set of DNS records needed to
+   authenticate the TLSA record set or its denial of existence up the
+   DNS hierarchy to either the root zone or another trust anchor
+   mutually configured by the TLS server and client.
+
+   When some subtree in the chain is subject to redirection via DNAME
+   records, the associated inferred CNAME records need not be included.
+   They can be inferred by the DNS validation code in the client.  Any
+   applicable ordinary CNAME records that are not synthesized from DNAME
+   records MUST be included along with their RRSIGs.
+
+   In case of a server-side DNS problem, servers may be unable to
+   construct the authentication chain and would then have no choice but
+   to omit the extension.
+
+   In the case of a denial-of-existence response, the authentication
+   chain MUST include all DNSSEC-signed records, starting with those
+   from the trust anchor zone, that chain together to reach a proof of
+   either:
+
+   *  the nonexistence of the TLSA records (possibly redirected via
+      aliases) or
+
+   *  an insecure delegation above or at the (possibly redirected) owner
+      name of the requested TLSA RRset.
+
+   Names that are aliased via CNAME and/or DNAME records may involve
+   multiple branches of the DNS tree.  In this case, the authentication
+   chain structure needs to include DS and DNSKEY record sets that cover
+   all the necessary branches.
+
+   The returned chain SHOULD also include the DNSKEY RRsets of all
+   relevant trust anchors (typically just the root DNS zone).  Though
+   the same trust anchors are presumably also preconfigured in the TLS
+   client, including them in the response from the server permits TLS
+   clients to use the automated trust anchor rollover mechanism defined
+   in [RFC5011] to update their configured trust anchors.
+
+   Barring prior knowledge of particular trust anchors that the server
+   shares with its clients, the chain constructed by the server MUST be
+   extended as closely as possible to the root zone.  Truncation of the
+   chain at some intermediate trust anchor is generally only appropriate
+   inside private networks where all clients and the server are expected
+   to be configured with DNS trust anchors for one or more non-root
+   domains.
+
+   The following is an example of the records in the AuthenticationChain
+   structure for the HTTPS server at "www.example.com", where there are
+   zone cuts at "com" and "example.com" (record data are omitted here
+   for brevity):
+
+   _443._tcp.www.example.com. TLSA
+   RRSIG(_443._tcp.www.example.com. TLSA)
+   example.com. DNSKEY
+   RRSIG(example.com. DNSKEY)
+   example.com. DS
+   RRSIG(example.com. DS)
+   com. DNSKEY
+   RRSIG(com. DNSKEY)
+   com. DS
+   RRSIG(com. DS)
+   . DNSKEY
+   RRSIG(. DNSKEY)
+
+   The following is an example of denial of existence for a TLSA RRset
+   at "_443._tcp.www.example.com".  The NSEC record in this example
+   asserts the nonexistence of both the requested RRset and any
+   potentially relevant wildcard records.
+
+   www.example.com. IN NSEC example.com. A NSEC RRSIG
+   RRSIG(www.example.com. NSEC)
+   example.com. DNSKEY
+   RRSIG(example.com. DNSKEY)
+   example.com. DS
+   RRSIG(example.com. DS)
+   com. DNSKEY
+   RRSIG(com. DNSKEY)
+   com. DS
+   RRSIG(com. DS)
+   . DNSKEY
+   RRSIG(. DNSKEY)
+
+   The following is an example of (hypothetical) insecure delegation of
+   "example.com" from the ".com" zone.  This example shows NSEC3 records
+   [RFC5155] with opt-out.
+
+   ; covers example.com
+   onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 -
+     onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)
+   RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3)
+   ; covers *.com
+   3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 -
+     3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG)
+   RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3)
+   ; closest-encloser "com"
+   ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 -
+     ck0pojmg874ljref7efn8430qvit8bsm.com
+     NS SOA RRSIG DNSKEY NSEC3PARAM)
+   RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3)
+   com. DNSKEY
+   RRSIG(com. DNSKEY)
+   com. DS
+   RRSIG(com. DS)
+   . DNSKEY
+   RRSIG(. DNSKEY)
+
+2.3.1.  Authenticated Denial of Existence
+
+   TLS servers that support this extension and respond to a request
+   containing this extension that do not have a signed TLSA record for
+   the configured (and requested) SNI name and port MUST instead return
+   a DNSSEC chain that provides authenticated denial of existence for
+   the configured SNI name and port.  A TLS client receiving proof of
+   authenticated denial of existence MUST use an alternative method to
+   verify the TLS server identity or close the connection.  Such an
+   alternative could be the classic PKIX model of preinstalled root
+   certificate authorities (CAs).
+
+   Authenticated denial chains include NSEC or NSEC3 records that
+   demonstrate one of the following facts:
+
+   *  The TLSA record (after any DNSSEC-validated alias redirection)
+      does not exist.
+
+   *  There is no signed delegation to a DNS zone that is either an
+      ancestor of or the same as the TLSA record name (after any DNSSEC-
+      validated alias redirection).
+
+3.  Construction of Serialized Authentication Chains
+
+   This section describes a possible procedure for the server to use to
+   build the serialized DNSSEC chain.
+
+   When the goal is to perform DANE authentication [RFC6698] [RFC7671]
+   of the server, the DNS record set to be serialized is a TLSA record
+   set corresponding to the server's domain name, protocol, and port
+   number.
+
+   The domain name of the server MUST be that included in the TLS
+   "server_name" (SNI) extension [RFC6066].  If the server does not
+   recognize the SNI name as one of its own names but wishes to proceed
+   with the handshake rather than abort the connection, the server MUST
+   NOT send a "dnssec_chain" extension to the client.
+
+   The name in the client's SNI extension MUST NOT be CNAME expanded by
+   the server.  The TLSA base domain (Section 3 of [RFC6698]) SHALL be
+   the hostname from the client's SNI extension, and the guidance in
+   Section 7 of [RFC7671] does not apply.  See Section 9 for further
+   discussion.
+
+   The TLSA record to be queried is constructed by prepending
+   underscore-prefixed port number and transport name labels to the
+   domain name as described in [RFC6698].  The port number is taken from
+   the client's "dnssec_chain" extension.  The transport name is "tcp"
+   for TLS servers and "udp" for DTLS servers.  The port number label is
+   the leftmost label, followed by the transport name label, followed by
+   the server domain name (from SNI).
+
+   The components of the authentication chain are typically built by
+   starting at the target record set and its corresponding RRSIG, then
+   traversing the DNS tree upwards towards the trust anchor zone
+   (normally the DNS root).  For each zone cut, the DNSKEY, DS RRsets,
+   and their signatures are added.  However, see Section 2.3 for
+   specific processing needed for aliases.  If DNS response messages
+   contain any domain names utilizing name compression [RFC1035], then
+   they MUST be uncompressed prior to inclusion in the chain.
+
+   Implementations of EDNS CHAIN query requests as specified in
+   [RFC7901] may offer an easier way to obtain all of the chain data in
+   one transaction with an upstream DNSSEC-aware recursive server.
+
+4.  Caching and Regeneration of the Authentication Chain
+
+   DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
+   have validity periods (specifically signature expiration times).
+   After the TLS server constructs the serialized authentication chain,
+   it SHOULD cache and reuse it in multiple TLS connection handshakes.
+   However, it SHOULD refresh and rebuild the chain as TTL values
+   require.  A server implementation could carefully track TTL
+   parameters and requery component records in the chain
+   correspondingly.  Alternatively, it could be configured to rebuild
+   the entire chain at some predefined periodic interval that does not
+   exceed the DNS TTLs of the component records in the chain.  If a
+   record in the chain has a very short TTL (e.g., 0 up to a few
+   seconds), the server MAY decide to serve the authentication chain a
+   few seconds past the minimum TTL in the chain.  This allows an
+   implementation to dedicate a process or single thread to building the
+   authentication chain and reuse it for more than a single waiting TLS
+   client before needing to rebuild the authentication chain.
+
+5.  Expired Signatures in the Authentication Chain
+
+   A server MAY look at the signature expiration of RRSIG records.
+   While these should never expire before the TTL of the corresponding
+   DNS record is reached, if this situation is nevertheless encountered,
+   the server MAY lower the TTL to prevent serving expired RRSIGs if
+   possible.  If the signatures are already expired, the server MUST
+   still include these records in the authentication chain.  This allows
+   the TLS client to either support a grace period for staleness or give
+   a detailed error, either as a log message or a message to a potential
+   interactive user of the TLS connection.  The TLS client SHOULD handle
+   expired RRSIGs similarly to how it handles expired PKIX certificates.
+
+6.  Verification
+
+   A TLS client performing DANE-based verification might not need to use
+   this extension.  For example, the TLS client could perform DNS
+   lookups and DANE verification without this extension, or it could
+   fetch authentication chains via another protocol.  If the TLS client
+   already possesses a valid TLSA record, it MAY bypass use of this
+   extension.  However, if it includes this extension, it MUST use the
+   TLS server reply to update the extension pinning status of the TLS
+   server's extension lifetime.  See Section 7.
+
+   A TLS client making use of this specification that receives a valid
+   DNSSEC authentication chain extension from a TLS server MUST use this
+   information to perform DANE authentication of the TLS server.  In
+   order to perform the validation, it uses the mechanism specified by
+   the DNSSEC protocol [RFC4035] [RFC5155].  This mechanism is sometimes
+   implemented in a DNSSEC validation engine or library.
+
+   If the authentication chain validates, the TLS client then performs
+   DANE authentication of the server according to the DANE TLS protocol
+   [RFC6698] [RFC7671].
+
+   Clients MAY cache the server's validated TLSA RRset to amortize the
+   cost of receiving and validating the chain over multiple connections.
+   The period of such caching MUST NOT exceed the TTL associated with
+   those records.  A client that possesses a validated and unexpired
+   TLSA RRset or the full chain in its cache does not need to send the
+   "dnssec_chain" extension for subsequent connections to the same TLS
+   server.  It can use the cached information to perform DANE
+   authentication.
+
+   Note that when a client and server perform TLS session resumption,
+   the server sends no "dnssec_chain".  This is particularly clear with
+   TLS 1.3, where the certificate message to which the chain might be
+   attached is also not sent on resumption.
+
+7.  Extension Pinning
+
+   TLS applications can be designed to unconditionally mandate this
+   extension.  Such TLS clients requesting this extension would abort a
+   connection to a TLS server that does not respond with an extension
+   reply that can be validated.
+
+   However, in a mixed-use deployment of PKIX and DANE, there is the
+   possibility that the security of a TLS client is downgraded from DANE
+   to PKIX.  This can happen when a TLS client connection is intercepted
+   and redirected to a rogue TLS server presenting a TLS certificate
+   that is considered valid from a PKIX point of view but does not match
+   the legitimate server's TLSA records.  By omitting this extension,
+   such a rogue TLS server could downgrade the TLS client to validate
+   the mis-issued certificate using only PKIX and not via DANE, provided
+   the TLS client is also not able to fetch the TLSA records directly
+   from DNS.
+
+   The ExtSupportLifetime element of the extension provides a
+   countermeasure against such downgrade attacks.  Its value represents
+   the number of hours that the TLS server (or cluster of servers
+   serving the same server name) commits to serving this extension in
+   the future.  This is referred to as the "pinning time" or "extension
+   pin" of the extension.  A non-zero extension pin value received MUST
+   ONLY be used if the extension also contains a valid TLSA
+   authentication chain that matches the server's certificate chain (the
+   server passes DANE authentication based on the enclosed TLSA RRset).
+
+   Any existing extension pin for the server instance (name and port)
+   MUST be cleared on receipt of a valid denial of existence for the
+   associated TLSA RRset.  The same also applies if the client obtained
+   the denial-of-existence proof via another method, such as through
+   direct DNS queries.  Based on the TLS client's local policy, it MAY
+   then terminate the connection or MAY continue using PKIX-based server
+   authentication.
+
+   Extension pins MUST also be cleared upon the completion of a DANE-
+   authenticated handshake with a server that returns a "dnssec_chain"
+   extension with a zero ExtSupportLifetime.
+
+   Upon completion of a fully validated handshake with a server that
+   returns a "dnssec_chain" extension with a non-zero ExtSupport
+   lifetime, the client MUST update any existing pin lifetime for the
+   service (name and port) to a value that is not longer than that
+   indicated by the server.  The client MAY, subject to local policy,
+   create a previously nonexistent pin, again for a lifetime that is not
+   longer than that indicated by the server.
+
+   The extension support lifetime is not constrained by any DNS TTLs or
+   RRSIG expirations in the returned chain.  The extension support
+   lifetime is the time for which the TLS server is committing itself to
+   serve the extension; it is not a validity time for the returned chain
+   data.  During this period, the DNSSEC chain may be updated.
+   Therefore, the ExtSupportLifetime value is not constrained by any DNS
+   TTLs or RRSIG expirations in the returned chain.
+
+   Clients MAY implement support for a subset of DANE certificate
+   usages.  For example, clients may support only DANE-EE(3) and DANE-
+   TA(2) [RFC7218], only PKIX-EE(1) and PKIX-TA(0), or all four.
+   Clients that implement DANE-EE(3) and DANE-TA(2) MUST implement the
+   relevant updates in [RFC7671].
+
+   For a non-zero saved value ("pin") of the ExtSupportLifetime element
+   of the extension, TLS clients that do not have a cached TLSA RRset
+   with an unexpired TTL MUST use the extension for the associated name
+   and port to obtain this information from the TLS server.  This TLS
+   client then MUST require that the TLS server respond with this
+   extension, which MUST contain a valid TLSA RRset or proof of
+   nonexistence of the TLSA RRset that covers the requested name and
+   port.  Note that a nonexistence proof or proof of insecure delegation
+   will clear the pin.  The TLS client MUST require this for as long as
+   the time period specified by the pin value, independent of the DNS
+   TTLs.  During this process, if the TLS client fails to receive this
+   information, it MUST either abort the connection or delay
+   communication with the server via the TLS connection until it is able
+   to obtain valid TLSA records (or proof of nonexistence) out of band,
+   such as via direct DNS lookups.  If attempts to obtain the TLSA RRset
+   out of band fail, the client MUST abort the TLS connection.  It MAY
+   try a new TLS connection again (for example, using an exponential
+   back-off timer) in an attempt to reach a different TLS server
+   instance that does properly serve the extension.
+
+   A TLS client that has a cached validated TLSA RRset and a valid non-
+   zero extension pin time MAY still refrain from requesting the
+   extension as long as it uses the cached TLSA RRset to authenticate
+   the TLS server.  This RRset MUST NOT be used beyond its received TTL.
+   Once the TLSA RRset's TTL has expired, the TLS client with a valid
+   non-zero extension pin time MUST request the extension and MUST abort
+   the TLS connection if the server responds without the extension.  A
+   TLS client MAY attempt to obtain the valid TLSA RRset by some other
+   means before initiating a new TLS connection.
+
+   Note that requiring the extension is NOT the same as requiring the
+   use of DANE TLSA records or even DNSSEC.  A DNS zone operator may at
+   any time delete the TLSA records or even remove the DS records to
+   disable the secure delegation of the server's DNS zone.  The TLS
+   server will replace the chain with the corresponding denial-of-
+   existence chain when it updates its cached TLSA authentication chain.
+   The server's only obligation is continued support for this extension.
+
+8.  Trust Anchor Maintenance
+
+   The trust anchor may change periodically, e.g., when the operator of
+   the trust anchor zone performs a DNSSEC key rollover.  TLS clients
+   using this specification MUST implement a mechanism to keep their
+   trust anchors up to date.  They could use the method defined in
+   [RFC5011] to perform trust anchor updates in-band in TLS by tracking
+   the introduction of new keys seen in the trust anchor DNSKEY RRset.
+   However, alternative mechanisms external to TLS may also be utilized.
+   Some operating systems may have a system-wide service to maintain and
+   keep the root trust anchor up to date.  In such cases, the TLS client
+   application could simply reference that as its trust anchor,
+   periodically checking whether it has changed.  Some applications may
+   prefer to implement trust anchor updates as part of their automated
+   software updates.
+
+9.  Virtual Hosting
+
+   Delivery of application services is often provided by a third party
+   on behalf of the domain owner (hosting customer).  Since the domain
+   owner may want to be able to move the service between providers, non-
+   zero support lifetimes for this extension should only be enabled by
+   mutual agreement between the provider and domain owner.
+
+   When CNAME records are employed to redirect network connections to
+   the provider's network, as mentioned in Section 3, the server uses
+   the client's SNI hostname as the TLSA base domain without CNAME
+   expansion.  When the certificate chain for the service is managed by
+   the provider, it is impractical to coordinate certificate changes by
+   the provider with updates in the hosting customer's DNS.  Therefore,
+   the TLSA RRset for the hosted domain is best configured as a CNAME
+   from the customer's domain to a TLSA RRset that is managed by the
+   provider as part of delivering the hosted service.  For example:
+
+   ; Customer DNS
+   www.example.com. IN CNAME node1.provider.example.
+   _443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example.
+   ; Provider DNS
+   node1.provider.example. IN A 192.0.2.1
+   _dane443.node1.provider.example. IN TLSA 1 1 1 ...
+
+   Clients that obtain TLSA records directly from DNS, bypassing this
+   extension, may perform CNAME expansion as in Section 7 of [RFC7671].
+   If TLSA records are associated with the fully expanded name, that
+   name may be used as the TLSA base domain and SNI name for the TLS
+   handshake.
+
+   To avoid confusion, it is RECOMMENDED that server operators not
+   publish TLSA RRs (_port._tcp. + base domain) based on the expanded
+   CNAMEs used to locate their network addresses.  Instead, the server
+   operator SHOULD publish TLSA RRs at an alternative DNS node (as in
+   the example above), to which the hosting customer will publish a
+   CNAME alias.  This results in all clients (whether they obtain TLSA
+   records from DNS directly or employ this extension) seeing the same
+   TLSA records and sending the same SNI name.
+
+10.  Operational Considerations
+
+   When DANE is being introduced incrementally into an existing PKIX
+   environment, there may be scenarios in which DANE authentication for
+   a server fails but PKIX succeeds, or vice versa.  What happens here
+   depends on TLS client policy.  If DANE authentication fails, the
+   client may decide to fall back to regular PKIX authentication.  In
+   order to do so efficiently within the same TLS handshake, the TLS
+   server needs to have provided the full X.509 certificate chain.  When
+   TLS servers only support DANE-EE or DANE-TA modes, they have the
+   option to send a much smaller certificate chain: just the EE
+   certificate for the former and a short certificate chain from the
+   DANE trust anchor to the EE certificate for the latter.  If the TLS
+   server supports both DANE and regular PKIX and wants to allow
+   efficient PKIX fallback within the same handshake, they should always
+   provide the full X.509 certificate chain.
+
+   When a TLS server operator wishes to no longer deploy this extension,
+   it must properly decommission its use.  If a non-zero pin lifetime is
+   presently advertised, it must first be changed to 0.  The extension
+   can be disabled once all previously advertised pin lifetimes have
+   expired.  Removal of TLSA records or even DNSSEC signing of the zone
+   can be done at any time, but the server MUST still be able to return
+   the associated denial-of-existence proofs to any clients that have
+   unexpired pins.
+
+   TLS clients MAY reduce the received extension pin value to a maximum
+   set by local policy.  This can mitigate a theoretical yet unlikely
+   attack where a compromised TLS server is modified to advertise a pin
+   value set to the maximum of 7 years.  Care should be taken not to set
+   a local maximum that is too short as that would reduce the downgrade
+   attack protection that the extension pin offers.
+
+   If the hosting provider intends to use end-entity TLSA records
+   (certificate usage PKIX-EE(1) or DANE-EE(3)), then the simplest
+   approach is to use the same key pair for all the certificates at a
+   given hosting node and publish "1 1 1" or "3 1 1" RRs matching the
+   common public key.  Since key rollover cannot be simultaneous across
+   multiple certificate updates, there will be times when multiple "1 1
+   1" (or "3 1 1") records will be required to match all the extant
+   certificates.  Multiple TLSA records are, in any case, needed a few
+   TTLs before certificate updates as explained in Section 8 of
+   [RFC7671].
+
+   If the hosting provider intends to use trust anchor TLSA records
+   (certificate usage PKIX-TA(0) or DANE-TA(2)), then the same TLSA
+   record can match all end-entity certificates issues by the
+   certification authority in question and continues to work across end-
+   entity certificate updates so long as the issuer certificate or
+   public keys remain unchanged.  This can be easier to implement at the
+   cost of greater reliance on the security of the selected
+   certification authority.
+
+   The provider can, of course, publish separate TLSA records for each
+   customer, which increases the number of such RRsets that need to be
+   managed but makes each one independent of the rest.
+
+11.  Security Considerations
+
+   The security considerations of the normatively referenced RFCs all
+   pertain to this extension.  Since the server is delivering a chain of
+   DNS records and signatures to the client, it MUST rebuild the chain
+   in accordance with TTL and signature expiration of the chain
+   components as described in Section 4.  TLS clients need roughly
+   accurate time in order to properly authenticate these signatures.
+   This could be achieved by running a time synchronization protocol
+   like NTP [RFC5905] or SNTP [RFC5905], which are already widely used
+   today.  TLS clients MUST support a mechanism to track and roll over
+   the trust anchor key or be able to avail themselves of a service that
+   does this, as described in Section 8.  Security considerations
+   related to mandating the use of this extension are described in
+   Section 7.
+
+   The received DNSSEC chain could contain DNS RRs that are not related
+   to the TLSA verification of the intended DNS name.  If such an
+   unrelated RR is not DNSSEC signed, it MUST be discarded.  If the
+   unrelated RRset is DNSSEC signed, the TLS client MAY decide to add
+   these RRsets and their DNSSEC signatures to its cache.  It MAY even
+   pass this data to the local system resolver for caching outside the
+   application.  However, care must be taken because caching these
+   records could be used for timing and caching attacks to de-anonymize
+   the TLS client or its user.  A TLS client that wants to present the
+   strongest anonymity protection to their users MUST refrain from using
+   and caching all unrelated RRs.
+
+12.  IANA Considerations
+
+   IANA has made the following assignment in the "TLS ExtensionType
+   Values" registry:
+
+      +=======+================+=========+=============+===========+
+      | Value | Extension Name | TLS 1.3 | Recommended | Reference |
+      +=======+================+=========+=============+===========+
+      |    59 | dnssec_chain   | CH      | No          | RFC 9102  |
+      +-------+----------------+---------+-------------+-----------+
+
+                                 Table 1
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, DOI 10.17487/RFC4034, March 2005,
+              <https://www.rfc-editor.org/info/rfc4034>.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+              <https://www.rfc-editor.org/info/rfc4035>.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+              <https://www.rfc-editor.org/info/rfc5155>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+              of Named Entities (DANE) Transport Layer Security (TLS)
+              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
+              2012, <https://www.rfc-editor.org/info/rfc6698>.
+
+   [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
+              Conversations about DNS-Based Authentication of Named
+              Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April
+              2014, <https://www.rfc-editor.org/info/rfc7218>.
+
+   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
+              Authentication of Named Entities (DANE) Protocol: Updates
+              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
+              October 2015, <https://www.rfc-editor.org/info/rfc7671>.
+
+   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "Specification for DNS over Transport
+              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
+              2016, <https://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
+              for DNS over TLS and DNS over DTLS", RFC 8310,
+              DOI 10.17487/RFC8310, March 2018,
+              <https://www.rfc-editor.org/info/rfc8310>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+13.2.  Informative References
+
+   [DANE-UKS] Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-
+              Share Attacks on DNS-Based Authentications of Named
+              Entities (DANE)", Work in Progress, Internet-Draft, draft-
+              barnes-dane-uks-00, 9 October 2016,
+              <https://datatracker.ietf.org/doc/html/draft-barnes-dane-
+              uks-00>.
+
+   [DISCOVERY]
+              Gorjon, X. and W. Toorop, "Discovery method for a DNSSEC
+              validating stub resolver", 14 July 2015,
+              <https://www.nlnetlabs.nl/downloads/publications/
+              os3-2015-rp2-xavier-torrent-gorjon.pdf>.
+
+   [DNSOP-SVCB-HTTPS]
+              Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
+              and Parameter Specification via the DNS (DNS SVCB and
+              HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
+              dnsop-svcb-https-07, 16 June 2021,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
+              svcb-https-07>.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
+              September 2007, <https://www.rfc-editor.org/info/rfc5011>.
+
+   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+              "Network Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
+              <https://www.rfc-editor.org/info/rfc5905>.
+
+   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
+              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
+              Transport Layer Security (TLS) and Datagram Transport
+              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
+              June 2014, <https://www.rfc-editor.org/info/rfc7250>.
+
+   [RFC7901]  Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
+              DOI 10.17487/RFC7901, June 2016,
+              <https://www.rfc-editor.org/info/rfc7901>.
+
+   [SERIALIZECHAIN]
+              Langley, A., "Serializing DNS Records with DNSSEC
+              Authentication", Work in Progress, Internet-Draft, draft-
+              agl-dane-serializechain-01, 1 July 2011,
+              <https://datatracker.ietf.org/doc/html/draft-agl-dane-
+              serializechain-01>.
+
+Appendix A.  Test Vectors
+
+   The test vectors in this appendix are representations of the content
+   of the "opaque AuthenticationChain" field in DNS presentation format
+   and, except for the "extension_data" in Appendix A.1, do not contain
+   the "uint16 ExtSupportLifetime" field.
+
+   For brevity and reproducibility, all DNS zones involved with the test
+   vectors are signed using keys with algorithm 13 (ECDSA Curve P-256
+   with SHA-256).
+
+   To reflect operational practice, different zones in the examples are
+   in different phases of rolling their signing keys:
+
+   *  All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK),
+      except for the "example.com" and "example.net" zones, which use a
+      Combined Signing Key (CSK).
+
+   *  The root and org zones are rolling their ZSKs.
+
+   *  The com and org zones are rolling their KSKs.
+
+   The test vectors are DNSSEC valid in the same period as the
+   certificate is valid, which is between November 28, 2018 and December
+   2, 2020 with the following root trust anchor:
+
+   .  IN  DS  ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
+           641bb568746f2ffc4d4 )
+
+   The test vectors will authenticate the certificate used with
+   "https://example.com/", "https://example.net/", and
+   "https://example.org/" at the time of writing:
+
+   -----BEGIN CERTIFICATE-----
+   MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN
+   MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
+   aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN
+   MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
+   aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw
+   b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT
+   ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI
+   hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV
+   rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g
+   rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80
+   eyRJRqzy8I0LSPTTkhr3okXuzOXXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9jF3pJ
+   QnucP9vTBejMh374qvyd0QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvt
+   hcNtBfhkp8kO64/hxLHrLWgOFT/l4tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8Ew
+   ggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLyjnjUY4tCzhxtniMB0GA1UdDgQWBBRm
+   mGIC4AmRp9njNvt2xrC/oW2nvjCBgQYDVR0RBHoweIIPd3d3LmV4YW1wbGUub3Jn
+   ggtleGFtcGxlLmNvbYILZXhhbXBsZS5lZHWCC2V4YW1wbGUubmV0ggtleGFtcGxl
+   Lm9yZ4IPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS5lZHWCD3d3dy5leGFt
+   cGxlLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
+   AQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNv
+   bS9zc2NhLXNoYTItZzYuY3JsMC+gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5j
+   b20vc3NjYS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgG
+   CCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAEC
+   AjB8BggrBgEFBQcBAQRwMG4wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj
+   ZXJ0LmNvbTBGBggrBgEFBQcwAoY6aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29t
+   L0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB
+   fwYKKwYBBAHWeQIEAgSCAW8EggFrAWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb
+   37jjd80OyA3cEAAAAWdcMZVGAAAEAwBIMEYCIQCEZIG3IR36Gkj1dq5L6EaGVycX
+   sHvpO7dKV0JsooTEbAIhALuTtf4wxGTkFkx8blhTV+7sf6pFT78ORo7+cP39jkJC
+   AHYAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMA
+   RzBFAiBvqnfSHKeUwGMtLrOG3UGLQIoaL3+uZsGTX3MfSJNQEQIhANL5nUiGBR6g
+   l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC
+   wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z
+   RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM
+   MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R
+   8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM
+   v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu
+   N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa
+   X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I
+   0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN
+   -----END CERTIFICATE-----
+
+A.1.  "_443._tcp.www.example.com"
+
+   _443._tcp.www.example.com.  3600  IN  TLSA  ( 3 1 1
+           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
+           922 )
+   _443._tcp.www.example.com.  3600  IN  RRSIG  ( TLSA 13 5 3600
+           20201202000000 20181128000000 1870 example.com.
+           rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
+           z2BhaswpGLVVuoijuVdzxYjmw== )
+   example.com.  3600  IN  DNSKEY  ( 257 3 13
+           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
+           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
+   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 1870 example.com.
+           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
+           QHPGSpvRxTUC4tZi62z1UgGDw== )
+   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
+          25a986e8a44f319ac3cd302bafc08f5b81e16)
+   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
+           20201202000000 20181128000000 34327 com.
+           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
+           J1hhWSB6jgubEVl17rGNOA/YQ== )
+   com.  172800  IN  DNSKEY  ( 256 3 13
+           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
+           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
+           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
+           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 18931 com.
+           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
+           7LFdPKpcvb8BvhM+GqKWGBEsg== )
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 28809 com.
+           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
+           mDXqz6KEhhQjT+aQWDt6WFHlA== )
+   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
+           f9eabb94487e658c188e7bcb52115 )
+   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
+           70643bbde681db342a9e5cf2bb380 )
+   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
+           vBKTf6pk8JRCqnfzlo2QY+WXA== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+   A hex dump of the "extension_data" of the server's "dnssec_chain"
+   extension representation of this with an ExtSupportLifetime value of
+   0 is:
+
+   0000:  00 00 04 5f 34 34 33 04  5f 74 63 70 03 77 77 77
+   0010:  07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 34 00
+   0020:  01 00 00 0e 10 00 23 03  01 01 8b d1 da 95 27 2f
+   0030:  7f a4 ff b2 41 37 fc 0e  d0 3a ae 67 e5 c4 d8 b3
+   0040:  c5 07 34 e1 05 0a 79 20  b9 22 04 5f 34 34 33 04
+   0050:  5f 74 63 70 03 77 77 77  07 65 78 61 6d 70 6c 65
+   0060:  03 63 6f 6d 00 00 2e 00  01 00 00 0e 10 00 5f 00
+   0070:  34 0d 05 00 00 0e 10 5f  c6 d9 00 5b fd da 80 07
+   0080:  4e 07 65 78 61 6d 70 6c  65 03 63 6f 6d 00 ce 1d
+   0090:  3a de b7 dc 7c ee 65 6d  61 cf b4 72 c5 97 7c 8c
+   00a0:  9c ae ae 9b 76 51 55 c5  18 fb 10 7b 6a 1f e0 35
+   00b0:  5f ba af 75 3c 19 28 32  fa 62 1f a7 3a 8b 85 ed
+   00c0:  79 d3 74 11 73 87 59 8f  cc 81 2e 1e f3 fb 07 65
+   00d0:  78 61 6d 70 6c 65 03 63  6f 6d 00 00 30 00 01 00
+   00e0:  00 0e 10 00 44 01 01 03  0d 26 70 35 5e 0c 89 4d
+   00f0:  9c fe a6 c5 af 6e b7 d4  58 b5 7a 50 ba 88 27 25
+   0100:  12 d8 24 1d 85 41 fd 54  ad f9 6e c9 56 78 9a 51
+   0110:  ce b9 71 09 4b 3b b3 f4  ec 49 f6 4c 68 65 95 be
+   0120:  5b 2e 89 e8 79 9c 77 17  cc 07 65 78 61 6d 70 6c
+   0130:  65 03 63 6f 6d 00 00 2e  00 01 00 00 0e 10 00 5f
+   0140:  00 30 0d 02 00 00 0e 10  5f c6 d9 00 5b fd da 80
+   0150:  07 4e 07 65 78 61 6d 70  6c 65 03 63 6f 6d 00 46
+   0160:  28 38 30 75 b8 e3 4b 74  3a 20 9b 27 ae 14 8d 11
+   0170:  0d 4e 1a 24 61 38 a9 10  83 24 9c b4 a1 2a 2d 9b
+   0180:  c4 c2 d7 ab 5e b3 af b9  f5 d1 03 7e 4d 5d a8 33
+   0190:  9c 16 2a 92 98 e9 be 18  07 41 a8 ca 74 ac cc 07
+   01a0:  65 78 61 6d 70 6c 65 03  63 6f 6d 00 00 2b 00 01
+   01b0:  00 02 a3 00 00 24 07 4e  0d 02 e9 b5 33 a0 49 79
+   01c0:  8e 90 0b 5c 29 c9 0c d2  5a 98 6e 8a 44 f3 19 ac
+   01d0:  3c d3 02 ba fc 08 f5 b8  1e 16 07 65 78 61 6d 70
+   01e0:  6c 65 03 63 6f 6d 00 00  2e 00 01 00 02 a3 00 00
+   01f0:  57 00 2b 0d 02 00 02 a3  00 5f c6 d9 00 5b fd da
+   0200:  80 86 17 03 63 6f 6d 00  a2 03 e7 04 a6 fa cb eb
+   0210:  13 fc 93 84 fd d6 de 6b  50 de 56 59 27 1f 38 ce
+   0220:  81 49 86 84 e6 36 31 72  d4 7e 23 19 fd b4 a2 2a
+   0230:  58 a2 31 ed c2 f1 ff 4f  b2 81 1a 18 07 be 72 cb
+   0240:  52 41 aa 26 fd ae e0 39  03 63 6f 6d 00 00 30 00
+   0250:  01 00 02 a3 00 00 44 01  00 03 0d ec 82 04 e4 3a
+   0260:  25 f2 34 8c 52 a1 d3 bc  e3 a2 65 aa 5d 11 b4 3d
+   0270:  c2 a4 71 16 2f f3 41 c4  9d b9 f5 0a 2e 1a 41 ca
+   0280:  f2 e9 cd 20 10 4e a0 96  8f 75 11 21 9f 0b dc 56
+   0290:  b6 80 12 cc 39 95 33 67  51 90 0b 03 63 6f 6d 00
+   02a0:  00 30 00 01 00 02 a3 00  00 44 01 01 03 0d 45 b9
+   02b0:  1c 3b ef 7a 5d 99 a7 a7  c8 d8 22 e3 38 96 bc 80
+   02c0:  a7 77 a0 42 34 a6 05 a4  a8 88 0e c7 ef a4 e6 d1
+   02d0:  12 c7 3c d3 d4 c6 55 64  fa 74 34 7c 87 37 23 cc
+   02e0:  5f 64 33 70 f1 66 b4 3d  ed ff 83 64 00 ff 03 63
+   02f0:  6f 6d 00 00 30 00 01 00  02 a3 00 00 44 01 01 03
+   0300:  0d b3 37 3b 6e 22 e8 e4  9e 0e 1e 59 1a 9f 5b d9
+   0310:  ac 5e 1a 0f 86 18 7f e3  47 03 f1 80 a9 d3 6c 95
+   0320:  8f 71 c4 af 48 ce 0e bc  5c 79 2a 72 4e 11 b4 38
+   0330:  95 93 7e e5 34 04 26 81  29 47 6e b1 ae d3 23 93
+   0340:  90 03 63 6f 6d 00 00 2e  00 01 00 02 a3 00 00 57
+   0350:  00 30 0d 01 00 02 a3 00  5f c6 d9 00 5b fd da 80
+   0360:  49 f3 03 63 6f 6d 00 18  a9 48 eb 23 d4 4f 80 ab
+   0370:  c9 92 38 fc b4 3c 5a 18  de be 57 00 4f 73 43 59
+   0380:  3f 6d eb 6e d7 1e 04 65  4a 43 3f 7a a1 97 21 30
+   0390:  d9 bd 92 1c 73 dc f6 3f  cf 66 5f 2f 05 a0 aa eb
+   03a0:  af b0 59 dc 12 c9 65 03  63 6f 6d 00 00 2e 00 01
+   03b0:  00 02 a3 00 00 57 00 30  0d 01 00 02 a3 00 5f c6
+   03c0:  d9 00 5b fd da 80 70 89  03 63 6f 6d 00 61 70 e6
+   03d0:  95 9b d9 ed 6e 57 58 37  b6 f5 80 bd 99 db d2 4a
+   03e0:  44 68 2b 0a 35 96 26 a2  46 b1 81 2f 5f 90 96 b7
+   03f0:  5e 15 7e 77 84 8f 06 8a  e0 08 5e 1a 60 9f c1 92
+   0400:  98 c3 3b 73 68 63 fb cc  d4 d8 1f 5e b2 03 63 6f
+   0410:  6d 00 00 2b 00 01 00 01  51 80 00 24 49 f3 0d 02
+   0420:  20 f7 a9 db 42 d0 e2 04  2f bb b9 f9 ea 01 59 41
+   0430:  20 2f 9e ab b9 44 87 e6  58 c1 88 e7 bc b5 21 15
+   0440:  03 63 6f 6d 00 00 2b 00  01 00 01 51 80 00 24 70
+   0450:  89 0d 02 ad 66 b3 27 6f  79 62 23 aa 45 ed a7 73
+   0460:  e9 2c 6d 98 e7 06 43 bb  de 68 1d b3 42 a9 e5 cf
+   0470:  2b b3 80 03 63 6f 6d 00  00 2e 00 01 00 01 51 80
+   0480:  00 53 00 2b 0d 01 00 01  51 80 5f c6 d9 00 5b fd
+   0490:  da 80 7c ae 00 12 2e 27  6d 45 d9 e9 81 6f 79 22
+   04a0:  ad 6e a2 e7 3e 82 d2 6f  ce 0a 4b 71 86 25 f3 14
+   04b0:  53 1a c9 2f 8a e8 24 18  df 9b 89 8f 98 9d 32 e8
+   04c0:  0b c4 de ab a7 c4 a7 c8  f1 72 ad b5 7c ed 7f b5
+   04d0:  e7 7a 78 4b 07 00 00 30  00 01 00 01 51 80 00 44
+   04e0:  01 00 03 0d cc ac fe 0c  25 a4 34 0f ef ba 17 a2
+   04f0:  54 f7 06 aa c1 f8 d1 4f  38 29 90 25 ac c4 48 ca
+   0500:  8c e3 f5 61 f3 7f c3 ec  16 9f e8 47 c8 fc be 68
+   0510:  e3 58 ff 7c 71 bb 5e e1  df 0d be 51 8b c7 36 d4
+   0520:  ce 8d fe 14 00 00 30 00  01 00 01 51 80 00 44 01
+   0530:  00 03 0d f3 03 19 67 89  73 1d dc 8a 67 87 ef f2
+   0540:  4c ac fe dd d0 32 58 2f  11 a7 5b b1 bc aa 5a b3
+   0550:  21 c1 d7 52 5c 26 58 19  1a ec 01 b3 e9 8a b7 91
+   0560:  5b 16 d5 71 dd 55 b4 ea  e5 14 17 11 0c c4 cd d1
+   0570:  1d 17 11 00 00 30 00 01  00 01 51 80 00 44 01 01
+   0580:  03 0d ca f5 fe 54 d4 d4  8f 16 62 1a fb 6b d3 ad
+   0590:  21 55 ba cf 57 d1 fa ad  5b ac 42 d1 7d 94 8c 42
+   05a0:  17 36 d9 38 9c 4c 40 11  66 6e a9 5c f1 77 25 bd
+   05b0:  0f a0 0c e5 e7 14 e4 ec  82 cf df ac c9 b1 c8 63
+   05c0:  ad 46 00 00 2e 00 01 00  01 51 80 00 53 00 30 0d
+   05d0:  00 00 01 51 80 5f c6 d9  00 5b fd da 80 b7 9d 00
+   05e0:  de 7a 67 40 ee ec ba 4b  da 1e 5c 2d d4 89 9b 2c
+   05f0:  96 58 93 f3 78 6c e7 47  f4 1e 50 d9 de 8c 0a 72
+   0600:  df 82 56 0d fb 48 d7 14  de 32 83 ae 99 a4 9c 0f
+   0610:  cb 50 d3 aa ad b1 a3 fc  62 ee 3a 8a 09 88 b6 be
+
+A.2.  "_25._tcp.example.com" NSEC Wildcard
+
+   _25._tcp.example.com.  3600  IN  TLSA  ( 3 1 1
+           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
+           922 )
+   _25._tcp.example.com.  3600  IN  RRSIG  ( TLSA 13 3 3600
+           20201202000000 20181128000000 1870 example.com.
+           BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2
+           rfL4DFP8rO3VMgI0v+ogrox0w== )
+   *._tcp.example.com.  3600  IN  NSEC  ( smtp.example.com. RRSIG
+           NSEC TLSA )
+   *._tcp.example.com.  3600  IN  RRSIG  ( NSEC 13 3 3600
+           20201202000000 20181128000000 1870 example.com.
+           K6u8KrR8ca5bjtbce3w8yjMXr9vw12225lAwyIHpxptY43OMLCUCenwpYW5qd
+           mpFvAacqj4+tSkKiN279SI9pA== )
+   example.com.  3600  IN  DNSKEY  ( 257 3 13
+           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
+           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
+   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 1870 example.com.
+           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
+           QHPGSpvRxTUC4tZi62z1UgGDw== )
+   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
+           25a986e8a44f319ac3cd302bafc08f5b81e16 )
+   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
+           20201202000000 20181128000000 34327 com.
+           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
+           J1hhWSB6jgubEVl17rGNOA/YQ== )
+   com.  172800  IN  DNSKEY  ( 256 3 13
+           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
+           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
+           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
+           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 18931 com.
+           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
+           7LFdPKpcvb8BvhM+GqKWGBEsg== )
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 28809 com.
+           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
+           mDXqz6KEhhQjT+aQWDt6WFHlA== )
+   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
+           f9eabb94487e658c188e7bcb52115 )
+   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
+           70643bbde681db342a9e5cf2bb380 )
+   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
+           vBKTf6pk8JRCqnfzlo2QY+WXA== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+A.3.  "_25._tcp.example.org" NSEC3 Wildcard
+
+   _25._tcp.example.org.  3600  IN  TLSA  ( 3 1 1
+           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
+           922 )
+   _25._tcp.example.org.  3600  IN  RRSIG  ( TLSA 13 3 3600
+           20201202000000 20181128000000 56566 example.org.
+           lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL
+           cYzJ7vCvqb9gFCiCJjK2gAamw== )
+   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  NSEC3  (
+           1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
+   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  RRSIG  (
+           NSEC3 13 3 3600 20201202000000 20181128000000 56566
+           example.org.
+           guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
+           X38cWzEQOpreJu3t4WAfPsxdg== )
+   example.org.  3600  IN  DNSKEY  ( 256 3 13
+           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
+           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
+   example.org.  3600  IN  DNSKEY  ( 257 3 13
+           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
+           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
+   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 44384 example.org.
+           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
+           6OPPvyHjVXMAsvk0tqV0B+/ag== )
+   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
+           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
+   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
+           20181128000000 9523 org.
+           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
+           clpAfvZHx59Ackst4X+zXYpUA== )
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
+           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
+           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
+           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
+           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 12651 org.
+           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
+           us0pUgWngbT/OWXskdMYXZU4A== )
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 49352 org.
+           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
+           vZEMj1YXD+dIqb2nUK9PGBAXw== )
+   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
+           9db5c24a75743eb1e704b97a9fabc )
+   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
+           f4a2f18920db5f58710dd767c293b )
+   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
+           EemgaE357S4pX5D0tVZzeZJ6A== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+A.4.  "_443._tcp.www.example.org" CNAME
+
+   _443._tcp.www.example.org.  3600  IN  CNAME  (
+           dane311.example.org. )
+   _443._tcp.www.example.org.  3600  IN  RRSIG  ( CNAME 13 5 3600
+           20201202000000 20181128000000 56566 example.org.
+           R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx
+           Qb/a90O696120NsYaZX2+ebBA== )
+   dane311.example.org.  3600  IN  TLSA  ( 3 1 1
+           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
+           922 )
+   dane311.example.org.  3600  IN  RRSIG  ( TLSA 13 3 3600
+           20201202000000 20181128000000 56566 example.org.
+           f6TbTZTpu3h6MYpLkKQwWILAkYQ3EUY+Nsoa6any6yt+aeuunMUjw+IJB2QLm
+           0x0PrD7m39JA3NUSkUp9riNNQ== )
+   example.org.  3600  IN  DNSKEY  ( 256 3 13
+           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
+           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
+   example.org.  3600  IN  DNSKEY  ( 257 3 13
+           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
+           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
+   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 44384 example.org.
+           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
+           6OPPvyHjVXMAsvk0tqV0B+/ag== )
+   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
+           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
+   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
+           20181128000000 9523 org.
+           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
+           clpAfvZHx59Ackst4X+zXYpUA== )
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
+           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
+           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
+           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
+           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 12651 org.
+           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
+           us0pUgWngbT/OWXskdMYXZU4A== )
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 49352 org.
+           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
+           vZEMj1YXD+dIqb2nUK9PGBAXw== )
+   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
+           9db5c24a75743eb1e704b97a9fabc )
+   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
+           f4a2f18920db5f58710dd767c293b )
+   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
+           EemgaE357S4pX5D0tVZzeZJ6A== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+A.5.  "_443._tcp.www.example.net" DNAME
+
+   example.net.  3600  IN  DNAME  example.com.
+   example.net.  3600  IN  RRSIG  ( DNAME 13 2 3600 20201202000000
+           20181128000000 48085 example.net.
+           o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx
+           OI/pDnjJcLSd/gBLtqR52WLMA== )
+   ; _443._tcp.www.example.net.  3600  IN  CNAME  (
+   ;         _443._tcp.www.example.com. )
+   _443._tcp.www.example.com.  3600  IN  TLSA  ( 3 1 1
+           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
+           922 )
+   _443._tcp.www.example.com.  3600  IN  RRSIG  ( TLSA 13 5 3600
+           20201202000000 20181128000000 1870 example.com.
+           rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
+           z2BhaswpGLVVuoijuVdzxYjmw== )
+   example.net.  3600  IN  DNSKEY  ( 257 3 13
+           X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d
+           9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085
+   example.net.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 48085 example.net.
+           CkwqgEt1p97oMa3w5LctIjKIuG5XVSapKrfwuHhb5p04fWXRMNsXasG/kd2F/
+           wlmMWiq38gOQaYCLNm+cjQzpQ== )
+   example.net.  172800  IN  DS  ( 48085 13 2 7c1998ce683df60e2fa41460c4
+           53f88f463dac8cd5d074277b4a7c04502921be )
+   example.net.  172800  IN  RRSIG  ( DS 13 2 172800
+           20201202000000 20181128000000 10713 net.
+           w0JxDeiBJZNlpCdxKtRENlqfTpSxcs6Vftscsyfo/hyeTPYcIt4yItDkYsYK+
+           KQ6FYAVE4nisA3vDQoZVL4wow== )
+   net.  172800  IN  DNSKEY  ( 256 3 13
+           061EoQs4sBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimi4/lw/vtyfqALuLF
+           JiFjtCK3HMPi8HQ1jbGEwbGCA== ) ; Key ID = 10713
+   net.  172800  IN  DNSKEY  ( 257 3 13
+           LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5
+           oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485
+   net.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 485 net.
+           031jXg06zSuDwI5zqYuYFJg1O5p+zy85csMXagvRxB9W2lL/wJRi6Gn9BcaCV
+           RnDId5WR+yCADhsbKfSrrd9vQ== )
+   net.  86400  IN  DS  ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c
+           d8c247769b23adb13ca234d1c05 )
+   net.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           vOXoTjxggGTYKIwssQ3kpML0ag6D0Hcm+Syy7++4zT7gaFHfRH9a6uZekIWdb
+           oss8y7q4onW4rxKdtw2S28hwQ== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+   example.com.  3600  IN  DNSKEY  ( 257 3 13
+           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
+           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
+   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 1870 example.com.
+           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
+           QHPGSpvRxTUC4tZi62z1UgGDw== )
+   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
+           25a986e8a44f319ac3cd302bafc08f5b81e16 )
+   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
+           20201202000000 20181128000000 34327 com.
+           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
+           J1hhWSB6jgubEVl17rGNOA/YQ== )
+   com.  172800  IN  DNSKEY  ( 256 3 13
+           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
+           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
+           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
+           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 18931 com.
+           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
+           7LFdPKpcvb8BvhM+GqKWGBEsg== )
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 28809 com.
+           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
+           mDXqz6KEhhQjT+aQWDt6WFHlA== )
+   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
+           f9eabb94487e658c188e7bcb52115 )
+   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
+           70643bbde681db342a9e5cf2bb380 )
+   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
+           vBKTf6pk8JRCqnfzlo2QY+WXA== )
+
+A.6.  "_25._tcp.smtp.example.com" NSEC Denial of Existence
+
+   smtp.example.com.  3600  IN  NSEC  ( www.example.com. A AAAA
+           RRSIG NSEC )
+   smtp.example.com.  3600  IN  RRSIG  ( NSEC 13 3 3600
+           20201202000000 20181128000000 1870 example.com.
+           rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf
+           crlsQZmnAUlfmBNCygxAd7JNw== )
+   example.com.  3600  IN  DNSKEY  ( 257 3 13
+           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
+           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
+   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 1870 example.com.
+           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
+           QHPGSpvRxTUC4tZi62z1UgGDw== )
+   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
+           25a986e8a44f319ac3cd302bafc08f5b81e16 )
+   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
+           20201202000000 20181128000000 34327 com.
+           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
+           J1hhWSB6jgubEVl17rGNOA/YQ== )
+   com.  172800  IN  DNSKEY  ( 256 3 13
+           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
+           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
+           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
+   com.  172800  IN  DNSKEY  ( 257 3 13
+           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
+           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 18931 com.
+           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
+           7LFdPKpcvb8BvhM+GqKWGBEsg== )
+   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
+           20181128000000 28809 com.
+           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
+           mDXqz6KEhhQjT+aQWDt6WFHlA== )
+   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
+           f9eabb94487e658c188e7bcb52115 )
+   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
+           70643bbde681db342a9e5cf2bb380 )
+   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
+           vBKTf6pk8JRCqnfzlo2QY+WXA== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+A.7.  "_25._tcp.smtp.example.org" NSEC3 Denial of Existence
+
+   vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org.  3600  IN  NSEC3  (
+           1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG )
+   vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org.  3600  IN  RRSIG  (
+           NSEC3 13 3 3600 20201202000000 20181128000000 56566
+           example.org.
+           wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh
+           gQeV5KgP1cdvPt1BEowKqK4Sw== )
+   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  NSEC3  (
+           1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
+   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  RRSIG  (
+           NSEC3 13 3 3600 20201202000000 20181128000000 56566
+           example.org.
+           guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
+           X38cWzEQOpreJu3t4WAfPsxdg== )
+   a73bi8coh6dvf1arqdeuogf95r0828mk.example.org.  3600  IN  NSEC3  (
+           1 0 1 - c1p0lp7l1l8gdn0jl13pp1o41h35untj CNAME RRSIG )
+   a73bi8coh6dvf1arqdeuogf95r0828mk.example.org.  3600  IN  RRSIG  (
+           NSEC3 13 3 3600 20201202000000 20181128000000 56566
+           example.org.
+           ePBUuWdj8Bc+/41gHBm2Bx/IK/j/Q4W7A5uTgSj/0Sd57mP/NTWRZq3p8yBNe
+           FPC2mBJ2oWQFi6/V9dmyiBh2A== )
+   example.org.  3600  IN  DNSKEY  ( 256 3 13
+           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
+           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
+   example.org.  3600  IN  DNSKEY  ( 257 3 13
+           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
+           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
+   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
+           20201202000000 20181128000000 44384 example.org.
+           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
+           6OPPvyHjVXMAsvk0tqV0B+/ag== )
+   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
+           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
+   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
+           20181128000000 9523 org.
+           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
+           clpAfvZHx59Ackst4X+zXYpUA== )
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
+           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
+   org.  86400  IN  DNSKEY  ( 256 3 13
+           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
+           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
+           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
+   org.  86400  IN  DNSKEY  ( 257 3 13
+           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
+           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 12651 org.
+           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
+           us0pUgWngbT/OWXskdMYXZU4A== )
+   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
+           20181128000000 49352 org.
+           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
+           vZEMj1YXD+dIqb2nUK9PGBAXw== )
+   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
+           9db5c24a75743eb1e704b97a9fabc )
+   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
+           f4a2f18920db5f58710dd767c293b )
+   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
+           EemgaE357S4pX5D0tVZzeZJ6A== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+A.8.  "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure Delegation
+
+   c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example.  43200  IN  NSEC3  (
+           1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY
+           NSEC3PARAM )
+   c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example.  43200  IN  RRSIG  (
+           NSEC3 13 2 43200 20201202000000 20181128000000 15903
+           example.
+           pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg
+           RpXUsJhZBDax2dfDhK7zOk7ow== )
+   shn05itmoa45mmnv74lc4p0nnfmimtjt.example.  43200  IN  NSEC3  (
+           1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG )
+   shn05itmoa45mmnv74lc4p0nnfmimtjt.example.  43200  IN  RRSIG  (
+           NSEC3 13 2 43200 20201202000000 20181128000000 15903
+           example.
+           5Aq//A8bsWNwcXbT91pMX2Oqf8VpJQRjqH4D2yZElW00wKmt85mhgu2qYPrvH
+           QwGEB4STMz2Nefq01/GY6NHKg== )
+   example.  432000  IN  DNSKEY  ( 257 3 13
+           yrkqXSbVwXOoUxCjr/E9yg8XUzbZNlwPllVsoUPd73TLOnBQQ+03Qw4/k+Nme
+           /66WIw+ZTlHYcTNalxiGYm0uQ== ) ; Key ID = 15903
+   example.  432000  IN  RRSIG  ( DNSKEY 13 1 432000
+           20201202000000 20181128000000 15903 example.
+           wwEo3ri6JBuCqx5b33w8axFWOhIen1l+/mm0Isyc9FciuLhBiP+IqSgt+Igc8
+           9nR8zRpJpo1D6XR/qJxZgnfaA== )
+   example.  86400  IN  DS  ( 15903 13 2 7e0ebaf1cc0d309d4a73ca7d711719d
+           d940f4da87b3d72865167650fc73ea577 )
+   example.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
+           20181128000000 31918 .
+           B5vx4zZaS+bOYfz0PzpaPfk9VxxBvYbGjIvGhpUZV3diXzfCguXxN4JIT1Sz8
+           eJX6BYT5QPIrbG/N35U1sIskw== )
+   .  86400  IN  DNSKEY  ( 256 3 13
+           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
+           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
+   .  86400  IN  DNSKEY  ( 256 3 13
+           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
+           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
+   .  86400  IN  DNSKEY  ( 257 3 13
+           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
+           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
+   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
+           20181128000000 47005 .
+           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
+           nBT1dtNjIczvLG9pQTnOKUsHQ== )
+
+Acknowledgments
+
+   Many thanks to Adam Langley for laying the groundwork for this
+   extension in [SERIALIZECHAIN].  The original idea is his, but our
+   acknowledgment in no way implies his endorsement.  This document also
+   benefited from discussions with and review from the following people:
+   Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus,
+   Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri Visweswaran,
+   Duane Wessels, Nico Williams, and Richard Barnes.
+
+Authors' Addresses
+
+   Viktor Dukhovni
+   Two Sigma
+
+   Email: ietf-dane@dukhovni.org
+
+
+   Shumon Huque
+   Salesforce
+   3rd Floor
+   415 Mission Street
+   San Francisco, CA 94105
+   United States of America
+
+   Email: shuque@gmail.com
+
+
+   Willem Toorop
+   NLnet Labs
+   Science Park 400
+   1098 XH Amsterdam
+   Netherlands
+
+   Email: willem@nlnetlabs.nl
+
+
+   Paul Wouters
+   Aiven
+   Toronto
+   Canada
+
+   Email: paul.wouters@aiven.io
+
+
+   Melinda Shore
+   Fastly
+
+   Email: mshore@fastly.com