| TLS | V. Dukhovni |
| Internet-Draft | Two Sigma |
| Intended status: Experimental | S. Huque |
| Expires: May 7, 2020 | Salesforce |
| W. Toorop | |
| NLnet Labs | |
| P. Wouters | |
| Red Hat | |
| M. Shore | |
| Fastly | |
| November 4, 2019 |
The DANE Authentication Chain Extension for TLS
draft-dukhovni-tls-dnssec-chain-00
This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. This allows TLS clients to perform DANE authentication of a TLS server without the need to perform additional DNS record lookups.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020.
Copyright (c) 2019 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
This document describes a new TLS [RFC5246] [RFC8446] extension for transport of DNSSEC signed DNS Resource Records (RRs). This allows TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without the need to perform additional DNS record lookups. Retrieval of the required DNS records may be unavailable to the client ([HAMPERING]), or may incur undesirable additional latency. It further allows a TLS client to validate the server's DANE (TLSA) records itself without requiring access to a validating DNS resolver to which it must have a secure connection.
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 3.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 5. The client then authenticates the chain using a pre-configured DNSSEC trust anchor.
In the absense 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 WebPKI based authentication 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 no longer relevant extension pins, as described in Section 7.
As described in the DANE specification [RFC6698] [RFC7671], this procedure applies to the DANE authentication of X.509 certificates or raw public keys [RFC7250].
This extension also mitigates againts an unknown key share (UKS) attack [I-D.barnes-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.
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, [RFC6066]) extension. Together, these make it possible for the 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 SHALL 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 session. 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.
In TLS 1.3, the server adds its dnssec_chain extension in 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.
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 for which 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 Resource Record sets (RRsets) and corresponding Resource Record signatures (RRSIGs).
This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on client by means of existing DNS library functions.
Each RRset in the chain is composed of a sequence of wire format DNS Resource Records. The format of the Resource Record is described in [RFC1035], Section 3.2.1.
RR(i) = owner | type | class | TTL | RDATA length | RDATA
where RR(i) denotes the ith RR.
The Resource Records that make up a RRset all have the same owner, type, class and TTL, but different RDATA as specified in [RFC2181], Section 5.
Each signed RRset in the sequence is followed by its associated RRsig record set. This RRset has the same owner and class as the preceding RRset, but has type RRSIG. The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in [RFC4034]>, Section 3.
The RRsig record wire format is described in [RFC4034], Section 3.1. The signature portion of the RDATA, as described in the same section, is the following:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field excluded.
The order of returned RRsets is unspecified and a TLS client MUST NOT assume any ordering of RRsets.
Unsigned CNAMEs that are implied by associated DNAME records MUST not be included, they can be inferred from the DNAME records. Any NSEC or NSEC3 denial of existence records must be accompanied by the associated SOA record.
The returned RRsets MUST contain either the requested TLSA RRset, perhaps or the associated denial of existence proof. In either case, the chain of RRsets MUST be accompanied with the full set of DNS records needed to authenticate the TLSA record set or its denial of existence up the DNS hierarchy up to either the Root Zone or another trust anchor mutually configured by the TLS server and client.
The chain will contain a unique class 1 (IN) RRset whose owner is equal to or is the closest ancestore of the requested TLSA RRset, and whose record type is one of TLSA, SOA, CNAME or DNAME. These four cases correspond to either:
The first two cases determine whether the TLSA RRset does or does not exist. The last two just redirect the requested name to the target of the alias (actual with CNAME, or implied with DNAME), with the status determined there or after further alias indirection. Clients MUST be prepared to encounter alias loops, and then conclude that the requested TLSA RRset therefore does not exist. In the presence of a CNAME loop or other 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 response chain should include all DNSSEC signed records from the root zone to the proof of non-existence of a validable entry in the chain that disproves the existence of a a secure delegation to - or of - the TLSA record.
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.
If the TLSA record set was synthesized by a DNS wildcard, the chain MUST include the signed NSEC or NSEC3 records that prove that there was no explicit match of the TLSA record name and no closer wildcard match.
The topmost DNSKEY RRset in the authentication chain corresponds to the trust anchor (typically the DNS root). This trust anchor is also preconfigured in the TLS client, but including it in the response from the server permits TLS clients to use the automated trust anchor rollover mechanism defined in RFC 5011 [RFC5011] to update their configured trust anchor.
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 non-existence of both the requested RRset and any potentially relevant wildcard records.
www.example.com. IN NSEC (example.com. DNSKEY SOA NS 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 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)
TLS servers supporting this extension that do not have a signed TLSA record MUST instead return a DNSSEC chain that provides authenticated denial of existence. 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 WebPKI model of preinstalled root CA's.
Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts:
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 if its own names, but wishes to proceed with the handshake rather than to abort the connection, the server MUST NOT send a dnssec_chain extension to the client.
The name in 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 the _port and _transport labels to the domain name as described in [RFC6698], where "port" is the port number taken from the client's dnssec_chain extension. The transport is "tcp" for TLS servers, and "udp" for DTLS servers. The port number label is the left-most label, followed by the transport, 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 and DS RRsets and their signatures are added. However, see Section 3.3 for specific processing needed for aliases and wildcards. 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.
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 MUST refresh and rebuild the chain as TTLs and signature validity periods dictate. A server implementation could carefully track these 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 or signature validity periods of the component records in the chain.
A TLS client performing DANE based verification might not need to use this extension. For example, the TLS client could perform native DNS lookups and perform 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 omit using 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, and which receives a valid DNSSEC authentication chain extension from a server, MUST use this information to perform DANE authentication of the 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 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 ammortize 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.
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 a validatable extension reply.
However, in a mixed use deployment of WebPKI and DANE, there is the possibility that the security of a TLS client is downgraded from DANE to WebPKI. 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 WebPKI point of view, but one that 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 the WebPKI 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 counter-measure against such downgrade attacks. It's value represents the number of hours that the TLS server (or cluster of servers serving the same Server Name) commit to serving this extension in the future. This is referred to as the "pinning time" or "extension pin" of the extension. A non-zero extenion pin value received MUST ONLY be used if the extention 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 WebPKI 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 full validated hanshake 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 no longer than that indicated by the server. The client MAY, subject to local policy, create a previously non-existent 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.
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 of the ExtSupportLifetime element of the extension, TLS clients MUST mandate ("pin") the use of this extension by the corresponding TLS servers for the time period specified by the pinning value. If during this time, the TLS client does not have a valid TLSA record and connects to a TLS server using this extension for the associated name and port, and it does not obtain a valid authentication chain in this extension, it MUST either abort the connection or delay communication with the server via the TLS session until it is able to obtain valid TLSA records (or non-existence proof) 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 session.
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, when it updates its cached TLSA authentication chain, replace the chain with the corresponding denial of existence chain. The server's only obligation is continued support for this extension.
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 inband 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.
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 4 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 however perform CNAME-expansion as in Section 7 of [RFC7671], and if TLSA records are associated with the fully-expanded name, may use that name 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.
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 traditional 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 traditional 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 lifetim 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 remains unchanged. This can be easier to implement, at the cost of greater reliance on the security of the selected provider.
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.
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 5. 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.
This document defines one new entry in the TLS ExtensionsType Values registry:
Value Extension Name TLS 1.3 Recommended Reference
----- -------------- ------- ----------- ---------------
TBD dnssec_chain CH No [this document]
Figure 1
Many thanks to Adam Langley for laying the groundwork for this extension in [I-D.agl-dane-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.
The test vectors in this appendix are representations of the content of the "opaque AuthenticationChain" field in DNS presentation format. And except for the "extention_data" in Figure 2, 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:
The test vectors are DNSSEC valid in the same period as the certificate is valid, which is in 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-----
_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 represention 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
Figure 2
_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== )
_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== )
_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== )
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== )
example.com. 3600 IN SOA ( sns.dns.icann.org. noc.dns.icann.org.
2017042720 7200 3600 1209600 3600 )
example.com. 3600 IN RRSIG ( SOA 13 2 3600 20201202000000
20181128000000 1870 example.com.
sr214XHDDSIcInHStplCFZQ0CI5pl5aIIrrFRkwyISWYbjp9KncxJlWc4nsvf
6npBwVo+MP4/dg9JLO35kVkUw== )
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== )
example.org. 3600 IN SOA ( sns.dns.icann.org. noc.dns.icann.org.
2017042720 7200 3600 1209600 3600 )
example.org. 3600 IN RRSIG ( SOA 13 2 3600 20201202000000
20181128000000 56566 example.org.
cpKzINSSU0Jk6Y/QrsYLgfXNUY4b/pXDWsXrzIHOT8udmQcJkIU+LtnO9+Qa3
2vJqiV6m65FvbBigJ612c3Wyw== )
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== )
example. 432000 IN SOA ( ns.ns-servers.example.
hostmaster.ns-servers.example.
2018042500 1800 900 604800 43200)
example. 432000 IN RRSIG ( SOA 13 1 432000 20201202000000
20181128000000 15903 example.
Hx4gEL0q9Za/jAB0LZ8dduuwef9qPrSyEK3RoSevb1S9UkrLQj1cL08HkiDwz
mcduSc5oMky0toC/gjOoZClEA== )
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== )