| RFC 9102 | TLS DNSSEC Chain | August 2021 |
| Dukhovni, et al. | Experimental | [Page] |
This document describes an experimental TLS extension for the in-bandtransport of the complete set of records that can be validated by DNSSEC and that are needed toperform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need toperform separate, out-of-band DNS lookups. When the requisite DNSrecords do not exist, the extension conveys a denial-of-existence proof that can be validated.¶
This experimental extension is developed outside the IETF and ispublished here to guide implementation of the extension and to ensureinteroperability among implementations.¶
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 athttps://www.rfc-editor.org/info/rfc9102.¶
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.¶
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 theTLS server return the DNSSEC authentication chain corresponding toits DNSSEC-validated DANE TLSA resource record set (RRset) orauthenticated denial of existence of such an RRset (as described inSection 2.3.1). If the server supports this extension, itperforms the appropriate DNS queries, builds the authenticationchain, and returns it to the client. The server will typically use apreviously cached authentication chain, but it will need to rebuildit periodically as described inSection 4. The client thenauthenticates the chain using a preconfigured DNSSEC trust anchor.¶
In the absence of TLSA records, this extension conveys the requiredauthenticated denial of existence. Such proofs are needed to securelysignal that specified TLSA records are not available so that TLS clientscan safely fall back to authentication based on Public Key Infrastructure X.509 (PKIX, sometimes calledWebPKI) if allowed by local policy. These proofsare 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 bythe TLS client to clear extension pins that are no longer relevant, as described inSection 7.¶
This extension supports DANE authentication of either X.509certificates or raw public keys, as described in the DANEspecification[RFC6698][RFC7671][RFC7250].¶
This extension also mitigates against an unknown key share (UKS)attack[DANE-UKS] when using raw public keys since theserver 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 ispublished here to guide implementation of the extension and to ensureinteroperability among implementations.¶
The mechanism described in this document is intended to be used withapplications on the wider internet. One application of TLS wellsuited for the TLS DNSSEC Chain extension is DNS over TLS[RFC7858].In fact, one of the authentication methods for DNS over TLSis themechanism described in this document, as specified inSection 8.2.2 of [RFC8310].¶
The need for this mechanism when using DANE to authenticate a DNS-over-TLSresolver is obvious, since DNS may not be available to perform therequired DNS lookups. Other applications of TLS would benefit fromusing this mechanism as well. The client sides of those applicationswould not be required to be used on endpoints with a working DNSSECresolver in order for them to use the DANE authentication of the TLSservice. Therefore, we invite other TLS services to try out thismechanism as well.¶
In the TLS Working Group, concerns have been raised that the pinningtechnique as described inSection 7 would complicate deployabilityof the TLS DNSSEC chain extension. The goal of the experiment is tostudy these complications in real-world deployments. This experimenthopefully will give the TLS Working Group some insight into whetheror not this is a problem.¶
If the experiment is successful, it is expected that the findings ofthe experiment will result in an updated document for Standards Trackapproval.¶
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.¶
A clientMAY include an extension of typednssec_chain in the(extended) ClientHello. Theextension_data field of this extensionconsists of the server's 16-bit TCP port number in network(big-endian) byte order. Clients sending this extensionMUST alsosend the Server Name Identification (SNI) extension[RFC6066].Together, these make it possible for the TLS server todetermine which authenticated TLSA RRset chain needs to be used forthednssec_chain extension.¶
When a server that implements (and is configured to enable the useof) this extension receives adnssec_chain extension in theClientHello, itMUST first check whether the requested TLSA RRset(based on the port number in this extension and hostname in the SNIextension) is associated with the server. If the extension, the SNIhostname, or the port number is unsupported, the server's extendedServerHello messageMUST NOT include thednssec_chain extension.¶
Otherwise, the server's extended ServerHello messageMUST contain aserialized authentication chain using the format described below. Ifthe server does not have access to the requested DNS chain -- forexample, due to a misconfiguration or expired chain -- the serverMUSTomit the extension rather than send an incomplete chain. Clients thatare expecting this extensionMUST interpret this as a downgradeattack andMUST abort the TLS connection. Therefore, serversMUST senddenial-of-existence proofs unless, for the particular applicationprotocol or service, clients are expected to continue even in theabsence of such a proof. As with all TLS extensions, if the serverdoes not support this extension, it will not return any authenticationchain.¶
The set of supported combinations of a port number and SNI name may beconfigured explicitly by server administrators or could be inferredfrom the available certificates combined with a list of supported ports.It is important to note that the client's notional port number may bedifferent from the actual port on which the server is receivingconnections.¶
Differences between the client's notional port number and the actualport at the server could be a result of intermediate systems performingnetwork address translation or a result of a redirect via HTTPSor SVCB records (both defined in[DNSOP-SVCB-HTTPS]).¶
Though a DNS zone's HTTPS or SVCB records may be signed, a clientusing this protocol might not have direct access to a validating resolverand might not be able to check the authenticity of the target port numberor hostname. In order to avoid downgrade attacks via forged DNSrecords, the SNI name and port number inside the client extensionMUSTbe based on the original SNI name and port andMUST NOT be taken fromthe encountered HTTPS or SVCB record. The client supporting this documentand HTTPS or SVCB recordsMUST still use the HTTPS or SVCB records toselect the target transport endpoint. Servers supporting this extensionthat are targets of HTTPS or SVCB recordsMUST be provisioned to processclient extensions based on the client's logical service endpoint's SNIname and port as it is prior to HTTPS or SVCB indirection.¶
In TLS 1.3[RFC8446], when the server receives thednssec_chain extension,it adds itsdnssec_chain extension to the extension block of the Certificatemessage containing the end-entity certificate being validated rather than tothe extended ServerHello message.¶
The extension protocol behavior otherwise follows that specified forTLS version 1.2[RFC5246].¶
Theextension_data field of the client'sdnssec_chain extensionMUST contain the server's 16-bit TCP port number in network(big-endian) byte order:¶
struct { uint16 PortNumber; } DnssecChainExtension;¶Theextension_data field of the server'sdnssec_chain extensionMUST contain a DNSSEC authentication chain encoded in the followingform:¶
struct { uint16 ExtSupportLifetime; opaque AuthenticationChain<1..2^16-1> } DnssecChainExtension;¶The ExtSupportLifetime value is the number of hours that the TLSserver has committed itself to serving this extension. A value ofzero prohibits the client from unilaterally requiring ongoing use ofthe extension based on prior observation of its use (extensionpinning). This is further described inSection 7.¶
The AuthenticationChain is composed of a sequence of uncompressedwire format DNS RRs (including all requisite RRSIG RRs[RFC4034])in no particular order. The format of the resource record isdescribed in[RFC1035],Section 3.2.1.¶
RR = { owner, type, class, TTL, RDATA length, RDATA }¶The order of returned RRs is unspecified, and a TLS clientMUST NOTassume any ordering of RRs.¶
Use of DNS wire format records enables easier generation ofthe data structure on the server and easier verification of the dataon the client by means of existing DNS library functions.¶
The returned RRsetsMUST contain either the TLSA RRset or theassociated denial-of-existence proof of the configured (and requested)SNI name and port. In either case, the chain of RRsetsMUST be accompaniedby the full set of DNS records needed to authenticate the TLSA record setor its denial of existence up the DNS hierarchy to either the root zoneor another trust anchor mutually configured by the TLS server and client.¶
When some subtree in the chain is subject to redirection via DNAMErecords, the associated inferred CNAME records need not be included.They can be inferred by the DNS validation code in the client. Anyapplicable ordinary CNAME records that are not synthesized from DNAMErecordsMUST be included along with their RRSIGs.¶
In case of a server-side DNS problem, servers may be unable to constructthe authentication chain and would then have no choice but to omit theextension.¶
In the case of a denial-of-existence response, the authenticationchainMUST include all DNSSEC-signed records, starting with those from the trust anchor zone, that chain together to reach a proof of either:¶
Names that are aliased via CNAME and/or DNAME records may involvemultiple branches of the DNS tree. In this case, the authenticationchain structure needs to include DS and DNSKEY record sets that coverall the necessary branches.¶
The returned chainSHOULD also include the DNSKEY RRsets of all relevanttrust anchors (typically just the root DNS zone). Though the same trustanchors are presumably also preconfigured in the TLS client, includingthem in the response from the server permits TLS clients to use theautomated trust anchor rollover mechanism defined in[RFC5011] toupdate their configured trust anchors.¶
Barring prior knowledge of particular trust anchors that the servershares with its clients, the chain constructed by the serverMUST beextended as closely as possible to the root zone. Truncation of the chainat some intermediate trust anchor is generally only appropriate insideprivate networks where all clients and the server are expected to beconfigured with DNS trust anchors for one or more non-root domains.¶
The following is an example of the records in the AuthenticationChainstructure for the HTTPS server atwww.example.com, where there arezone cuts atcom andexample.com (record data are omitted herefor brevity):¶
_443._tcp.www.example.com. TLSARRSIG(_443._tcp.www.example.com. TLSA)example.com. DNSKEYRRSIG(example.com. DNSKEY)example.com. DSRRSIG(example.com. DS)com. DNSKEYRRSIG(com. DNSKEY)com. DSRRSIG(com. DS). DNSKEYRRSIG(. DNSKEY)¶
The following is an example of denial of existence for a TLSA RRsetat_443._tcp.www.example.com. The NSEC record in this exampleasserts the nonexistence of both the requested RRset and anypotentially relevant wildcard records.¶
www.example.com. IN NSEC example.com. A NSEC RRSIGRRSIG(www.example.com. NSEC)example.com. DNSKEYRRSIG(example.com. DNSKEY)example.com. DSRRSIG(example.com. DS)com. DNSKEYRRSIG(com. DNSKEY)com. DSRRSIG(com. DS). DNSKEYRRSIG(. DNSKEY)¶
The following is an example of (hypothetical) insecure delegation ofexample.com from the.com zone. This example shows NSEC3 records[RFC5155]with opt-out.¶
; covers example.comonib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3); covers *.com3rl2r262eg0n1ap5olhae7mah2ah09hi.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. DNSKEYRRSIG(com. DNSKEY)com. DSRRSIG(com. DS). DNSKEYRRSIG(. DNSKEY)¶
TLS servers that support this extension and respond to a requestcontaining this extension that do not have a signed TLSA record for theconfigured (and requested) SNI name and portMUST instead return a DNSSECchain that provides authenticated denial of existence for the configuredSNI name and port. A TLS client receiving proof of authenticated denialof existenceMUST use an alternative method to verify the TLS serveridentity or close the connection. Such an alternative could be theclassic PKIX model of preinstalled root certificate authorities (CAs).¶
Authenticated denial chains include NSEC or NSEC3 records thatdemonstrate one of the following facts:¶
This section describes a possible procedure for the server to use tobuild 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 recordset corresponding to the server's domain name, protocol, and portnumber.¶
The domain name of the serverMUST be that included in the TLSserver_name (SNI) extension[RFC6066]. If the serverdoes not recognize the SNI name as one of its own names but wishesto proceed with the handshake rather than abort the connection,the serverMUST NOT send adnssec_chain extension to the client.¶
The name in the client's SNI extensionMUST NOT be CNAME expanded by theserver. The TLSA base domain (Section 3 of [RFC6698])SHALL be thehostname from the client's SNI extension, and the guidance inSection 7 of [RFC7671] does not apply. SeeSection 9 for furtherdiscussion.¶
The TLSA record to be queried is constructed by prependingunderscore-prefixed port number and transport name labels to the domainname as described in[RFC6698]. The port number is taken from theclient'sdnssec_chain extension. The transport name is "tcp" for TLSservers and "udp" for DTLS servers. The port number label is theleftmost label, followed by the transport name label, followed by theserver domain name (from SNI).¶
The components of the authentication chain are typically built bystarting at the target record set and its corresponding RRSIG, thentraversing 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, seeSection 2.3 forspecific processing needed for aliases. If DNS response messagescontain any domain names utilizing name compression[RFC1035], thentheyMUST 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 datain one transaction with an upstream DNSSEC-aware recursive server.¶
DNS records have Time To Live (TTL) parameters, and DNSSEC signatureshave validity periods (specifically signature expiration times).After the TLS server constructs the serialized authentication chain,itSHOULD cache and reuse it in multiple TLS connection handshakes.However, itSHOULD refresh and rebuild the chain as TTL values require.A server implementation could carefully track TTL parameters and requerycomponent records in the chain correspondingly. Alternatively, it couldbe configured to rebuild the entire chain at some predefined periodicinterval that does not exceed the DNS TTLs of the component records inthe chain. If a record in the chain has a very short TTL (e.g., 0 up to afew seconds), the serverMAY decide to serve the authentication chain afew seconds past the minimum TTL in the chain. This allows animplementation to dedicate a process or single thread to building theauthentication chain and reuse it for more than a singlewaiting TLS client before needing to rebuild the authentication chain.¶
A serverMAY look at the signature expiration of RRSIG records. Whilethese should never expire before the TTL of the corresponding DNS recordis reached, if this situation is nevertheless encountered, the serverMAY lower the TTL to prevent serving expired RRSIGs if possible. If thesignatures are already expired, the serverMUST still include these recordsin 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 clientSHOULD handle expired RRSIGs similarly to how ithandles expired PKIX certificates.¶
A TLS client performing DANE-based verification might not need to usethis extension. For example, the TLS client could perform DNSlookups and DANE verification without this extension, or itcould fetch authentication chains via another protocol. If the TLSclient already possesses a valid TLSA record, itMAY bypass use of thisextension. However, if it includes this extension, itMUST use theTLS server reply to update the extension pinning status of the TLSserver's extension lifetime. SeeSection 7.¶
A TLS client making use of this specification that receives avalid DNSSEC authentication chain extension from a TLS serverMUST usethis information to perform DANE authentication of the TLS server. Inorder to perform the validation, it uses the mechanism specified bythe DNSSEC protocol[RFC4035][RFC5155]. This mechanism issometimes implemented in a DNSSEC validation engine or library.¶
If the authentication chain validates, the TLS client then performs DANEauthentication of the server according to the DANE TLS protocol[RFC6698][RFC7671].¶
ClientsMAY cache the server's validated TLSA RRset to amortize thecost of receiving and validating the chain over multiple connections.The period of such cachingMUST NOT exceed the TTL associated withthose records. A client that possesses a validated and unexpired TLSARRset or the full chain in its cache does not need to send thednssec_chain extension for subsequent connections to the same TLSserver. It can use the cached information to perform DANEauthentication.¶
Note that when a client and server perform TLS session resumption, theserver sends nodnssec_chain. This is particularly clear with TLS1.3, where the certificate message to which the chain might beattached is also not sent on resumption.¶
TLS applications can be designed to unconditionally mandate thisextension. Such TLS clients requesting this extension would abort aconnection to a TLS server that does not respond with anextension reply that can be validated.¶
However, in a mixed-use deployment of PKIX and DANE, there is thepossibility that the security of a TLS client is downgraded from DANEto PKIX. This can happen when a TLS client connection isintercepted and redirected to a rogue TLS server presenting a TLScertificate that is considered valid from a PKIX point of view butdoes not match the legitimate server's TLSA records. Byomitting this extension, such a rogue TLS server could downgrade theTLS client to validate the mis-issued certificate using only PKIXand not via DANE, provided the TLS client is also not able tofetch the TLSA records directly from DNS.¶
The ExtSupportLifetime element of the extension provides acountermeasure against such downgrade attacks. Its value representsthe number of hours that the TLS server (or cluster of serversserving the same server name) commits to serving this extension in thefuture. This is referred to as the "pinning time" or "extension pin"of the extension. A non-zero extension pin value receivedMUST ONLYbe used if the extension also contains a valid TLSA authenticationchain that matches the server's certificate chain (the server passesDANE 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 theassociated TLSA RRset. The same also applies if the client obtainedthe denial-of-existence proof via another method, such as throughdirect DNS queries. Based on the TLS client's local policy, itMAYthen terminate the connection orMAY continue using PKIX-basedserver authentication.¶
Extension pinsMUST also be cleared upon the completion of a DANE-authenticated handshake with a server that returns adnssec_chainextension with a zero ExtSupportLifetime.¶
Upon completion of a fully validated handshake with a server thatreturns adnssec_chain extension with a non-zero ExtSupport lifetime,the clientMUST update any existing pin lifetime for the service(name and port) to a value that is not longer than that indicated bythe server. The clientMAY, subject to local policy, create apreviously nonexistent pin, again for a lifetime that is not longerthan that indicated by the server.¶
The extension support lifetime is not constrained by any DNS TTLs orRRSIG expirations in the returned chain. The extension support lifetimeis the time for which the TLS server is committing itself to serve theextension; it is not a validity time for the returned chain data.During this period, the DNSSEC chain may be updated. Therefore, theExtSupportLifetime value is not constrained by any DNS TTLs or RRSIGexpirations in the returned chain.¶
ClientsMAY implement support for a subset of DANE certificateusages. For example, clients may support only DANE-EE(3) andDANE-TA(2)[RFC7218], only PKIX-EE(1) and PKIX-TA(0),or all four. Clients that implement DANE-EE(3) and DANE-TA(2)MUSTimplement the relevant updates in[RFC7671].¶
For a non-zero saved value ("pin") of the ExtSupportLifetime element of theextension, TLS clients that do not have a cached TLSA RRset with anunexpired TTLMUST use the extension for the associated name andport to obtain this information from the TLS server. This TLS clientthenMUST require that the TLS server respond with this extension,whichMUST contain a valid TLSA RRset or proof of nonexistence of theTLSA RRset that covers the requested name and port. Note that a nonexistenceproof or proof of insecure delegation will clear the pin. The TLS clientMUSTrequire 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 failsto receive this information, itMUST either abort the connection or delaycommunication with the server via the TLS connection until it is ableto obtain valid TLSA records (or proof of nonexistence) out of band,such as via direct DNS lookups. If attempts to obtain the TLSA RRsetout of band fail, the clientMUST abort the TLS connection. ItMAY trya new TLS connection again (for example, using an exponential back-offtimer) in an attempt to reach a different TLS server instance that doesproperly serve the extension.¶
A TLS client that has a cached validated TLSA RRset and a valid non-zero extensionpin timeMAY still refrain from requesting the extension as long as ituses the cached TLSA RRset to authenticate the TLS server. This RRsetMUST NOT be used beyond its received TTL. Once the TLSA RRset'sTTL has expired, the TLS client with a valid non-zero extension pintimeMUST request the extension andMUST abort the TLS connection ifthe server responds without the extension. A TLS clientMAY attemptto obtain the valid TLSA RRset by some other means beforeinitiating a new TLS connection.¶
Note that requiring the extension is NOT the same as requiring theuse of DANE TLSA records or even DNSSEC. A DNS zone operator may atany time delete the TLSA records or even remove the DS records todisable the secure delegation of the server's DNS zone. The TLSserver 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.¶
The trust anchor may change periodically, e.g., when the operator ofthe trust anchor zone performs a DNSSEC key rollover. TLS clientsusing this specificationMUST implement a mechanism to keep theirtrust anchors up to date. They could use the method defined in[RFC5011] to perform trust anchor updates in-band in TLS by trackingthe 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 andkeep the root trust anchor up to date. In such cases, the TLS clientapplication could simply reference that as its trust anchor,periodically checking whether it has changed. Some applications mayprefer to implement trust anchor updates as part of their automatedsoftware updates.¶
Delivery of application services is often provided by a third partyon behalf of the domain owner (hosting customer). Since the domainowner may want to be able to move the service between providers,non-zero support lifetimes for this extension should only be enabledby mutual agreement between the provider and domain owner.¶
When CNAME records are employed to redirect network connections tothe provider's network, as mentioned inSection 3, the serveruses the client's SNI hostname as the TLSA base domain without CNAMEexpansion. When the certificate chain for the service is managed bythe provider, it is impractical to coordinate certificate changes bythe provider with updates in the hosting customer's DNS. Therefore,the TLSA RRset for the hosted domain is best configured as a CNAMEfrom the customer's domain to a TLSA RRset that is managed by theprovider as part of delivering the hosted service. For example:¶
; Customer DNSwww.example.com. IN CNAME node1.provider.example._443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example.; Provider DNSnode1.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 thisextension, may perform CNAME expansion as inSection 7 of [RFC7671]. If TLSA records are associated with thefully expanded name, that name may be used as the TLSA base domain andSNI name for the TLS handshake.¶
To avoid confusion, it isRECOMMENDED that server operators notpublish TLSA RRs (_port._tcp. + base domain) based on the expandedCNAMEs used to locate their network addresses. Instead, the serveroperatorSHOULD publish TLSA RRs at an alternative DNS node (as inthe example above), to which the hosting customer will publish aCNAME alias. This results in all clients (whether they obtain TLSArecords from DNS directly or employ this extension) seeing the sameTLSA records and sending the same SNI name.¶
When DANE is being introduced incrementally into an existing PKIXenvironment, there may be scenarios in which DANE authentication fora server fails but PKIX succeeds, or vice versa. What happens heredepends on TLS client policy. If DANE authentication fails, theclient may decide to fall back to regular PKIX authentication. Inorder to do so efficiently within the same TLS handshake, the TLSserver needs to have provided the full X.509 certificate chain. WhenTLS servers only support DANE-EE or DANE-TA modes, they have theoption to send a much smaller certificate chain: just the EEcertificate for the former and a short certificate chain from theDANE trust anchor to the EE certificate for the latter. If the TLSserver supports both DANE and regular PKIX and wants to allowefficient PKIX fallback within the same handshake, they should alwaysprovide 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 ispresently advertised, it must first be changed to 0. The extensioncan be disabled once all previously advertised pin lifetimes haveexpired. Removal of TLSA records or even DNSSEC signing of the zonecan be done at any time, but the serverMUST still be able to returnthe associated denial-of-existence proofs to any clients that haveunexpired pins.¶
TLS clientsMAY reduce the received extension pin value to a maximumset by local policy. This can mitigate a theoretical yet unlikelyattack where a compromised TLS server is modified to advertise a pinvalue set to the maximum of 7 years. Care should be taken not to seta local maximum that is too short as that would reduce the downgradeattack 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 simplestapproach is to use the same key pair for all the certificates at agiven hosting node and publish "1 1 1" or "3 1 1" RRs matching thecommon public key. Since key rollover cannot be simultaneous acrossmultiple certificate updates, there will be times when multiple "1 11" (or "3 1 1") records will be required to match all the extantcertificates. Multiple TLSA records are, in any case, needed a fewTTLs before certificate updates as explained inSection 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 TLSArecord can match all end-entity certificates issues by thecertification authority in question and continues to work acrossend-entity certificate updates so long as the issuer certificate orpublic keys remain unchanged. This can be easier to implement atthe cost of greater reliance on the security of the selectedcertification authority.¶
The provider can, of course, publish separate TLSA records for eachcustomer, which increases the number of such RRsets that need to bemanaged but makes each one independent of the rest.¶
The security considerations of the normatively referenced RFCs allpertain to this extension. Since the server is delivering a chain ofDNS records and signatures to the client, itMUST rebuild the chain inaccordance with TTL and signature expiration of the chain componentsas described inSection 4. TLS clients need roughly accuratetime in order to properly authenticate these signatures. This could beachieved by running a time synchronization protocol like NTP[RFC5905]or SNTP[RFC5905], which are already widely used today. TLS clientsMUST support a mechanism to track and roll over the trust anchor keyor be able to avail themselves of a service that does this, as describedinSection 8. Security considerations related to mandating theuse of this extension are described inSection 7.¶
The received DNSSEC chain could contain DNS RRs that are not relatedto the TLSA verification of the intended DNS name. If such an unrelatedRR is not DNSSEC signed, itMUST be discarded. If the unrelated RRsetis DNSSEC signed, the TLS clientMAY decide to add these RRsets andtheir DNSSEC signatures to its cache. ItMAY even pass this data to thelocal system resolver for caching outside the application. However, caremust be taken because caching these records could be used for timing andcaching attacks to de-anonymize the TLS client or its user. A TLS clientthat wants to present the strongest anonymity protection to their usersMUST refrain from using and caching all unrelated RRs.¶
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 |
The test vectors in this appendix are representations of the contentof the "opaque AuthenticationChain" field in DNS presentation format and, except for theextension_data inAppendix A.1, do not containthe "uint16 ExtSupportLifetime" field.¶
For brevity and reproducibility, all DNS zones involved with the testvectors are signed using keys with algorithm 13 (ECDSA Curve P-256with SHA-256).¶
To reflect operational practice, different zones in the examples arein different phases of rolling their signing keys:¶
All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK),except for theexample.com andexample.net zones, which use aCombined 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 thecertificate is valid, which is between November 28, 2018 andDecember 2, 2020 with the following root trust anchor:¶
. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 641bb568746f2ffc4d4 )¶
The test vectors will authenticate the certificate used withhttps://example.com/,https://example.net/, andhttps://example.org/at the time of writing:¶
-----BEGIN CERTIFICATE-----MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBNMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5EaWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcNMjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsTClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vVrAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5grJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80eyRJRqzy8I0LSPTTkhr3okXuzOXXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9jF3pJQnucP9vTBejMh374qvyd0QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvthcNtBfhkp8kO64/hxLHrLWgOFT/l4tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8EwggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLyjnjUY4tCzhxtniMB0GA1UdDgQWBBRmmGIC4AmRp9njNvt2xrC/oW2nvjCBgQYDVR0RBHoweIIPd3d3LmV4YW1wbGUub3JnggtleGFtcGxlLmNvbYILZXhhbXBsZS5lZHWCC2V4YW1wbGUubmV0ggtleGFtcGxlLm9yZ4IPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS5lZHWCD3d3dy5leGFtcGxlLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zc2NhLXNoYTItZzYuY3JsMC+gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjB8BggrBgEFBQcBAQRwMG4wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBGBggrBgEFBQcwAoY6aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIBfwYKKwYBBAHWeQIEAgSCAW8EggFrAWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAWdcMZVGAAAEAwBIMEYCIQCEZIG3IR36Gkj1dq5L6EaGVycXsHvpO7dKV0JsooTEbAIhALuTtf4wxGTkFkx8blhTV+7sf6pFT78ORo7+cP39jkJCAHYAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMARzBFAiBvqnfSHKeUwGMtLrOG3UGLQIoaL3+uZsGTX3MfSJNQEQIhANL5nUiGBR6gl0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7zRDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKMMA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZMv1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQuN+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIaX6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN-----END CERTIFICATE-----¶
_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 = 1870example.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 = 34327com. 172800 IN DNSKEY ( 257 3 13 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931com. 172800 IN DNSKEY ( 257 3 13 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809com. 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 theextension_data of the server'sdnssec_chainextension 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 770010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 000020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b30040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 040050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 650060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 000070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 070080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 3500b0: 5f ba af 75 3c 19 28 32 fa 62 1f a7 3a 8b 85 ed00c0: 79 d3 74 11 73 87 59 8f cc 81 2e 1e f3 fb 07 6500d0: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 0000e0: 00 0e 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d00f0: 9c fe a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 250100: 12 d8 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 510110: ce b9 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be0120: 5b 2e 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c0130: 65 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f0140: 00 30 0d 02 00 00 0e 10 5f c6 d9 00 5b fd da 800150: 07 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 460160: 28 38 30 75 b8 e3 4b 74 3a 20 9b 27 ae 14 8d 110170: 0d 4e 1a 24 61 38 a9 10 83 24 9c b4 a1 2a 2d 9b0180: c4 c2 d7 ab 5e b3 af b9 f5 d1 03 7e 4d 5d a8 330190: 9c 16 2a 92 98 e9 be 18 07 41 a8 ca 74 ac cc 0701a0: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 0101b0: 00 02 a3 00 00 24 07 4e 0d 02 e9 b5 33 a0 49 7901c0: 8e 90 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac01d0: 3c d3 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 7001e0: 6c 65 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 0001f0: 57 00 2b 0d 02 00 02 a3 00 5f c6 d9 00 5b fd da0200: 80 86 17 03 63 6f 6d 00 a2 03 e7 04 a6 fa cb eb0210: 13 fc 93 84 fd d6 de 6b 50 de 56 59 27 1f 38 ce0220: 81 49 86 84 e6 36 31 72 d4 7e 23 19 fd b4 a2 2a0230: 58 a2 31 ed c2 f1 ff 4f b2 81 1a 18 07 be 72 cb0240: 52 41 aa 26 fd ae e0 39 03 63 6f 6d 00 00 30 000250: 01 00 02 a3 00 00 44 01 00 03 0d ec 82 04 e4 3a0260: 25 f2 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d0270: c2 a4 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca0280: f2 e9 cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 560290: b6 80 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 0002a0: 00 30 00 01 00 02 a3 00 00 44 01 01 03 0d 45 b902b0: 1c 3b ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 8002c0: a7 77 a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d102d0: 12 c7 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc02e0: 5f 64 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 6302f0: 6f 6d 00 00 30 00 01 00 02 a3 00 00 44 01 01 030300: 0d b3 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d90310: ac 5e 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 950320: 8f 71 c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 380330: 95 93 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 930340: 90 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 570350: 00 30 0d 01 00 02 a3 00 5f c6 d9 00 5b fd da 800360: 49 f3 03 63 6f 6d 00 18 a9 48 eb 23 d4 4f 80 ab0370: c9 92 38 fc b4 3c 5a 18 de be 57 00 4f 73 43 590380: 3f 6d eb 6e d7 1e 04 65 4a 43 3f 7a a1 97 21 300390: d9 bd 92 1c 73 dc f6 3f cf 66 5f 2f 05 a0 aa eb03a0: af b0 59 dc 12 c9 65 03 63 6f 6d 00 00 2e 00 0103b0: 00 02 a3 00 00 57 00 30 0d 01 00 02 a3 00 5f c603c0: d9 00 5b fd da 80 70 89 03 63 6f 6d 00 61 70 e603d0: 95 9b d9 ed 6e 57 58 37 b6 f5 80 bd 99 db d2 4a03e0: 44 68 2b 0a 35 96 26 a2 46 b1 81 2f 5f 90 96 b703f0: 5e 15 7e 77 84 8f 06 8a e0 08 5e 1a 60 9f c1 920400: 98 c3 3b 73 68 63 fb cc d4 d8 1f 5e b2 03 63 6f0410: 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 020420: 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 410430: 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 150440: 03 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 700450: 89 0d 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 730460: e9 2c 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf0470: 2b b3 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 800480: 00 53 00 2b 0d 01 00 01 51 80 5f c6 d9 00 5b fd0490: da 80 7c ae 00 12 2e 27 6d 45 d9 e9 81 6f 79 2204a0: ad 6e a2 e7 3e 82 d2 6f ce 0a 4b 71 86 25 f3 1404b0: 53 1a c9 2f 8a e8 24 18 df 9b 89 8f 98 9d 32 e804c0: 0b c4 de ab a7 c4 a7 c8 f1 72 ad b5 7c ed 7f b504d0: e7 7a 78 4b 07 00 00 30 00 01 00 01 51 80 00 4404e0: 01 00 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a204f0: 54 f7 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca0500: 8c e3 f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 680510: e3 58 ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d40520: ce 8d fe 14 00 00 30 00 01 00 01 51 80 00 44 010530: 00 03 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f20540: 4c ac fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b30550: 21 c1 d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 910560: 5b 16 d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d10570: 1d 17 11 00 00 30 00 01 00 01 51 80 00 44 01 010580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 4205a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 6305c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 0005e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 720600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be¶
_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 = 1870example.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 = 34327com. 172800 IN DNSKEY ( 257 3 13 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931com. 172800 IN DNSKEY ( 257 3 13 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809com. 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 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 = 56566example.org. 3600 IN DNSKEY ( 257 3 13 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384example.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 = 47417org. 86400 IN DNSKEY ( 256 3 13 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523org. 86400 IN DNSKEY ( 257 3 13 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352org. 86400 IN DNSKEY ( 257 3 13 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651org. 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 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 = 56566example.org. 3600 IN DNSKEY ( 257 3 13 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384example.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 = 47417org. 86400 IN DNSKEY ( 256 3 13 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523org. 86400 IN DNSKEY ( 257 3 13 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352org. 86400 IN DNSKEY ( 257 3 13 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651org. 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.net DNAMEexample.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 = 48085example.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 = 10713net. 172800 IN DNSKEY ( 257 3 13 LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5 oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485net. 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 = 1870example.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 = 34327com. 172800 IN DNSKEY ( 257 3 13 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931com. 172800 IN DNSKEY ( 257 3 13 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809com. 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== )¶
_25._tcp.smtp.example.com NSEC Denial of Existencesmtp.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 = 1870example.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 = 34327com. 172800 IN DNSKEY ( 257 3 13 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931com. 172800 IN DNSKEY ( 257 3 13 szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809com. 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.smtp.example.org NSEC3 Denial of Existencevkv62jbv85822q8rtmfnbhfnmnat9ve3.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 = 56566example.org. 3600 IN DNSKEY ( 257 3 13 uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384example.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 = 47417org. 86400 IN DNSKEY ( 256 3 13 zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523org. 86400 IN DNSKEY ( 257 3 13 Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6 Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352org. 86400 IN DNSKEY ( 257 3 13 0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651org. 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.insecure.example NSEC3 Opt-Out Insecure Delegationc1kgc91hrn9nqi2qjh1ms78ki8p7s75o.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 = 15903example. 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== )¶
Many thanks toAdam Langley for laying the groundwork for thisextension in[SERIALIZECHAIN]. The original idea is his,but our acknowledgment in no way implies his endorsement. Thisdocument also benefited from discussions with and review from thefollowing people:Daniel Kahn Gillmor,Jeff Hodges,Allison Mankin,Patrick McManus,Rick van Rein,Ilari Liusvaara,Eric Rescorla,Gowri Visweswaran,Duane Wessels,Nico Williams, andRichard Barnes.¶