RFC 9102
TLS DNSSEC Chain Extension
🎀 TLS DNSSEC Chain Extension 🎀
- Doc: RFC 9102, published August 2021 🗓️
- Stream: Independent Submission 🌸
- Category: Experimental 🧪 (it's an experiment, so it's not a Standards Track spec)
- ISSN: 2070-1721
- Authors: V. Dukhovni (Two Sigma), S. Huque (Salesforce), W. Toorop (NLnet Labs), P. Wouters (Aiven), and M. Shore (Fastly) 👯♀️
- Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 💅
Abstract ✨
okay so this doc describes an experimental TLS extension that lets a server send along, right inside the TLS handshake, the full set of DNSSEC-validatable records a client needs to do DANE authentication of the server. The big win is the client doesn't have to make separate out-of-band DNS lookups 🫶 And when the records don't exist, the extension sends a denial-of-existence proof the client can validate too, which is so clean 🦋
The whole thing was developed outside the IETF and it's published so people can build it and make sure their versions actually play nicely together 🧚
Status of This Memo 📋
this one is not an Internet Standards Track spec. It's out there for people to look at, try implementing, and evaluate 🔍
It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make zero claims about whether it's any good for implementing or deploying 🙈 Documents the RFC Editor approves aren't eligible for any level of Internet Standard either, which you can check in Section 2 of RFC 7841.
If you want the current status, any errata, or a place to send feedback, head to https://www.rfc-editor.org/info/rfc9102 💜
Copyright Notice ⚖️
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents 🗺️
1. Introduction
1.1. Scope of the Experiment
1.2. Requirements Notation
2. DNSSEC Authentication Chain Extension
2.1. Protocol, TLS 1.2
2.2. Protocol, TLS 1.3
2.3. DNSSEC Authentication Chain Data
2.3.1. Authenticated Denial of Existence
3. Construction of Serialized Authentication Chains
4. Caching and Regeneration of the Authentication Chain
5. Expired Signatures in the Authentication Chain
6. Verification
7. Extension Pinning
8. Trust Anchor Maintenance
9. Virtual Hosting
10. Operational Considerations
11. Security Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Test Vectors
A.1. "_443._tcp.www.example.com"
A.2. "_25._tcp.example.com" NSEC Wildcard
A.3. "_25._tcp.example.org" NSEC3 Wildcard
A.4. "_443._tcp.www.example.org" CNAME
A.5. "_443._tcp.www.example.net" DNAME
A.6. "_25._tcp.smtp.example.com" NSEC Denial of Existence
A.7. "_25._tcp.smtp.example.org" NSEC3 Denial of Existence
A.8. "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure
Delegation
Acknowledgments
Authors' Addresses1. Introduction 🌈
okay so bestie, this doc describes an experimental TLS [RFC5246] [RFC8446] extension for sending the complete set of resource records (RRs) that DNSSEC [RFC4033] [RFC4034] [RFC4035] validates, all in-band 💖 It lets a TLS client do DANE authentication [RFC6698] [RFC7671] of a TLS server without making any out-of-band DNS lookups. Getting those DNS records might be unavailable to the client [DISCOVERY], or it might add annoying extra latency 😭
Here's the flow. The client asks the server, through this extension, to return the DNSSEC authentication chain for its DNSSEC-validated DANE TLSA resource record set (RRset), or an authenticated denial of existence for that RRset (more on that in Section 2.3.1) 🦋 If the server supports the extension, it runs the right DNS queries, builds the chain, and sends it back. Usually it reuses a cached chain, but it has to rebuild it now and then, as Section 4 explains 🔁 Then the client checks the chain against a DNSSEC trust anchor it already has configured ✨
If there are no TLSA records, the extension still sends the needed authenticated denial of existence. This matters a lot 🙌 It securely tells the client that the TLSA records aren't there, so the client can safely fall back to authentication based on Public Key Infrastructure X.509 (PKIX, sometimes called WebPKI), but only if local policy allows that. These proofs also stop a downgrade from opportunistic authenticated TLS (when DANE TLSA records exist) to unauthenticated opportunistic TLS (when there's no DANE). Denial-of-existence records also let the client clear extension pins that aren't relevant anymore, as Section 7 covers 🧹
This extension supports DANE authentication for either X.509 certificates or raw public keys, per the DANE spec [RFC6698] [RFC7671] [RFC7250] 🔑
It also helps against an unknown key share (UKS) attack [DANE-UKS] when raw public keys are in use, because the server commits to its DNS name (which is normally in its certificate) through the content of the TLSA RRset it returns 🛡️
Like I said, this is experimental. It was developed outside the IETF and it's published to guide implementation and make sure implementations interoperate 🫶
1.1. Scope of the Experiment 🔬
This mechanism is meant for applications out on the wider internet. One TLS application that really suits the TLS DNSSEC Chain extension is DNS over TLS [RFC7858]. In fact, one of the authentication methods for DNS over TLS _is_ this mechanism, as specified in Section 8.2.2 of [RFC8310] 🍓
Using DANE to authenticate a DNS-over-TLS resolver needs this so much, because DNS might not be available to do the lookups the client needs 😩 Other TLS applications would benefit too. The client side of those applications wouldn't be required to sit on an endpoint with a working DNSSEC resolver in order to use DANE authentication of the TLS service. So we're inviting other TLS services to give this a try too 💅
The TLS Working Group raised concerns that the pinning technique in Section 7 could make the TLS DNSSEC chain extension harder to deploy 🤔 The point of the experiment is to study those complications in real-world deployments. Hopefully it gives the TLS Working Group some insight into whether that's actually a problem 👀
If the experiment works out, the findings are expected to lead to an updated document for Standards Track approval 👑
1.2. Requirements Notation 📐
Okay, so 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🔥 Otherwise they're just regular words.
2. DNSSEC Authentication Chain Extension 🧩
2.1. Protocol, TLS 1.2 💜
A client MAY include an extension of type dnssec_chain in its (extended) ClientHello. The extension_data field holds the server's 16-bit TCP port number in network (big-endian) byte order. Clients that send this extension MUST also send the Server Name Identification (SNI) extension [RFC6066]. Together those two let the TLS server work out which authenticated TLSA RRset chain to use for the dnssec_chain extension 🧚
When a server that implements this extension (and is configured to turn it on) gets a dnssec_chain extension in the ClientHello, it MUST first check whether the requested TLSA RRset is associated with the server. That lookup is based on the port number in this extension and the hostname in the SNI extension. If the extension, the SNI hostname, or the port number isn't supported, the server's extended ServerHello message MUST NOT include the dnssec_chain extension 🙅♀️
Otherwise, the server's extended ServerHello message MUST contain a serialized authentication chain in the format described below. If the server can't reach the requested DNS chain (for example, because of a misconfiguration or an expired chain), the server MUST omit the extension instead of sending an incomplete chain 🚫 Clients that expect this extension MUST treat that as a downgrade attack and MUST abort the TLS connection 🚨 So servers MUST send denial-of-existence proofs, unless the client is expected to keep going without one for that particular application protocol or service. And just like every TLS extension, if the server doesn't support this one, it won't return any authentication chain 🤷♀️
The set of supported combinations of port number and SNI name can be configured explicitly by server administrators, or it can be inferred from the available certificates combined with a list of supported ports 🗂️ It's really important to notice that the client's notional port number might not match the actual port the server is listening on 👀
That mismatch can come from intermediate systems doing network address translation, or from a redirect through HTTPS or SVCB records (both defined in [DNSOP-SVCB-HTTPS]) 🔀
Here's the sneaky bit: even if a zone's HTTPS or SVCB records are signed, a client using this protocol might not have a validating resolver handy, so it might not be able to check whether the target port number or hostname is legit 😬 To dodge downgrade attacks through forged DNS records, the SNI name and port number in the client extension MUST come from the original SNI name and port, and MUST NOT be taken from the HTTPS or SVCB record they hit. A client that supports this document and also has HTTPS or SVCB records MUST still use those records to pick the target transport endpoint 🎯 Servers that support this extension and are targets of HTTPS or SVCB records MUST be set up to process client extensions based on the client's logical service endpoint SNI name and port as they are before the HTTPS or SVCB indirection 🌸
2.2. Protocol, TLS 1.3
okay so in TLS 1.3 [RFC8446] 💅, when the server gets the "dnssec_chain" extension, it does NOT stick its "dnssec_chain" extension onto the extended ServerHello like before. instead it tucks it into the extension block of the Certificate message that carries the end-entity certificate being validated 🎀
the extension protocol behavior otherwise follows what's specified for TLS version 1.2 [RFC5246]. so the vibe is consistent, no cap ✨
2.3. DNSSEC Authentication Chain Data
okay this part is where the actual data lives 🦋. first up, the client's "dnssec_chain" extension. its "extension_data" field MUST contain the server's 16-bit TCP port number in network (big-endian) byte order:
struct {
uint16 PortNumber;
} DnssecChainExtension;now the server's side. its "extension_data" field MUST contain a DNSSEC authentication chain encoded in this form:
struct {
uint16 ExtSupportLifetime;
opaque AuthenticationChain<1..2^16-1>
} DnssecChainExtension;the ExtSupportLifetime value is the number of hours 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 a sequence of uncompressed wire format DNS RRs (including all requisite RRSIG RRs [RFC4034]) in no particular order. the format of the resource record is described in [RFC1035], Section 3.2.1. the RR shape looks like this:
RR = { owner, type, class, TTL, RDATA length, RDATA }the order of returned RRs is unspecified, and a TLS client MUST NOT assume any ordering of RRs. no vibes-based sorting, bestie 🙅♀️.
using DNS wire format records makes it easier for the server to generate the data structure, and for the client to verify it with existing DNS library functions. so everyone's life is easier 🌸.
the returned RRsets MUST contain either the TLSA RRset or the associated denial-of-existence proof of the configured (and requested) SNI name and port. either way, the chain of RRsets MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set (or its denial of existence) all the way up the DNS hierarchy to either the root zone or another trust anchor mutually configured by the TLS server and client 👑.
when some subtree in the chain gets redirected via DNAME records, the associated inferred CNAME records don't need to be included. the DNS validation code in the client can infer them. any applicable ordinary CNAME records that are NOT synthesized from DNAME records MUST be included along with their RRSIGs 💀.
if there's a server-side DNS problem, servers may be unable to construct the authentication chain. in that case they have no choice but to omit the extension 😭.
in the case of a denial-of-existence response, the authentication chain MUST include all DNSSEC-signed records, starting with those from the trust anchor zone, that chain together to reach a proof of either:
- the nonexistence of the TLSA records (possibly redirected via aliases), or
- an insecure delegation above or at the (possibly redirected) owner name of the requested TLSA RRset.
names that are aliased via CNAME and/or DNAME records can involve multiple branches of the DNS tree. in this case, the authentication chain structure needs to include DS and DNSKEY record sets that cover all the necessary branches 🌈.
the returned chain SHOULD also include the DNSKEY RRsets of all relevant trust anchors (typically just the root DNS zone). the same trust anchors are presumably also preconfigured in the TLS client, but including them in the server's response lets TLS clients use the automated trust anchor rollover mechanism defined in [RFC5011] to update their configured trust anchors 🔄.
barring prior knowledge of particular trust anchors that the server shares with its clients, the chain constructed by the server MUST be extended as closely as possible to the root zone. truncating the chain at some intermediate trust anchor is generally only appropriate inside private networks where all clients and the server are expected to be configured with DNS trust anchors for one or more non-root domains 🏠.
here's 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)and here's an example of denial of existence for a TLSA RRset at "_443._tcp.www.example.com". the NSEC record in this example asserts the nonexistence of both the requested RRset and any potentially relevant wildcard records 🙈.
www.example.com. IN NSEC example.com. A NSEC RRSIG
RRSIG(www.example.com. NSEC)
example.com. DNSKEY
RRSIG(example.com. DNSKEY)
example.com. DS
RRSIG(example.com. DS)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)last example in this bit: a (hypothetical) insecure delegation of "example.com" from the ".com" zone. this one uses NSEC3 records [RFC5155] with opt-out 🧁.
; covers example.com
onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 -
onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)
RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3)
; covers *.com
3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 -
3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG)
RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3)
; closest-encloser "com"
ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 -
ck0pojmg874ljref7efn8430qvit8bsm.com
NS SOA RRSIG DNSKEY NSEC3PARAM)
RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)2.3.1. Authenticated Denial of Existence
okay, this is the "the name doesn't exist, prove it" case 🔍. TLS servers that support this extension, and that respond to a request containing it, MUST instead return a DNSSEC chain providing authenticated denial of existence whenever they don't have a signed TLSA record for the configured (and requested) SNI name and port 🙅.
a TLS client that receives proof of authenticated denial of existence MUST use an alternative method to verify the TLS server identity, or close the connection. an example of such an alternative is the classic PKIX model of preinstalled root certificate authorities (CAs) 🔐.
authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts:
- The TLSA record (after any DNSSEC-validated alias redirection) does not exist.
- There is no signed delegation to a DNS zone that is either an ancestor of or the same as the TLSA record name (after any DNSSEC-validated alias redirection).
3. Construction of Serialized Authentication Chains
this section is a possible recipe 🍳 for how the server can 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 the one included in the TLS "server_name" (SNI) extension [RFC6066]. if the server doesn't recognize the SNI name as one of its own names but still wants to continue the handshake rather than abort the connection, the server MUST NOT send a "dnssec_chain" extension to the client 🙅♀️.
the name in the client's SNI extension MUST NOT be CNAME expanded by the server. the TLSA base domain (Section 3 of [RFC6698]) SHALL be the hostname from the client's SNI extension, and the guidance in Section 7 of [RFC7671] does not apply. see Section 9 for further discussion 📖.
the TLSA record to be queried is built by prepending underscore-prefixed port number and transport name labels to the domain name, as described in [RFC6698]. the port number is taken from the client's "dnssec_chain" extension. the transport name is "tcp" for TLS servers and "udp" for DTLS servers. so the port number label is the leftmost label, then the transport name label, then 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 toward the trust anchor zone (normally the DNS root) ⬆️. for each zone cut, the DNSKEY and DS RRsets, plus their signatures, get added. however, see Section 2.3 for the specific processing needed for aliases. if DNS response messages contain any domain names that use name compression [RFC1035], then they MUST be uncompressed before they're included in the chain 🧹.
implementations of EDNS CHAIN query requests as specified in [RFC7901] may offer an easier way to get all of the chain data in one transaction with an upstream DNSSEC-aware recursive server ⚡.
4. Caching and Regeneration of the Authentication Chain
okay, time is the enemy here ⏰. 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 across multiple TLS connection handshakes. however, it SHOULD refresh and rebuild the chain as TTL values require 🔁.
a server implementation could carefully track TTL parameters and requery the component records in the chain accordingly. alternatively, it could be configured to rebuild the entire chain at some predefined periodic interval that does not exceed the DNS TTLs of the component records in the chain 🗓️.
if a record in the chain has a very short TTL (e.g., 0 up to a few seconds), the server MAY decide to serve the authentication chain a few seconds past the minimum TTL in the chain. this lets an implementation dedicate a process or single thread to building the authentication chain, and reuse it for more than one waiting TLS client before it needs to rebuild the chain 🧵✨.
5. Expired Signatures in the Authentication Chain
the server MAY look at the signature expiration of RRSIG records 👀. these should never expire before the TTL of the corresponding DNS record is reached. but if this situation is still encountered, the server MAY lower the TTL to prevent serving expired RRSIGs, if possible 🚫.
if the signatures are already expired, the server MUST still include these records in the authentication chain. this lets the TLS client either support a grace period for staleness, or give a detailed error, either as a log message or as a message to a potential interactive user of the TLS connection 📝. the TLS client SHOULD handle expired RRSIGs similarly to how it handles expired PKIX certificates 🎀.
6. Verification ✨
okay so a TLS client doing DANE-based verification might not even need this extension 🤷♀️ it could do its own DNS lookups and DANE verification without it, or grab the authentication chains some other way. if it already has a valid TLSA record, it MAY skip this extension totally 🦋 but if it DOES include the extension, it MUST use the TLS server's reply to update the extension pinning status of the server's extension lifetime. see Section 7 💅
a TLS client using this spec that gets a valid DNSSEC authentication chain extension from a TLS server MUST use that info to do DANE authentication of the server 🔐 to validate the chain, it uses the mechanism from the DNSSEC protocol [RFC4035] [RFC5155]. sometimes that mechanism lives inside a DNSSEC validation engine or library 🧚
if the chain validates, the client then does DANE authentication of the server using the DANE TLS protocol [RFC6698] [RFC7671] 🎀
Clients MAY cache the server's validated TLSA RRset so the cost of receiving and validating the chain gets spread out over multiple connections 🧁 the caching period MUST NOT exceed the TTL on those records. a client with a validated, unexpired TLSA RRset or the full chain in its cache doesn't need to send the "dnssec_chain" extension for later connections to the same TLS server. it can just use the cached info for DANE authentication ✨
also, when a client and server do TLS session resumption, the server sends no "dnssec_chain". this is super clear with TLS 1.3, where the certificate message the chain might be attached to isn't sent on resumption either 🙈
7. Extension Pinning 🔒
TLS applications can be designed to unconditionally mandate this extension 👑 those clients would abort a connection to a TLS server that doesn't respond with an extension reply that can be validated.
but in a mixed-use deployment of PKIX and DANE, a client's security can get downgraded from DANE to PKIX 😭 this happens when a connection gets intercepted and redirected to a rogue TLS server presenting a certificate that's valid from a PKIX point of view but doesn't match the legit server's TLSA records. if the rogue server just omits this extension, it can downgrade the client to validate that mis-issued certificate using only PKIX and not DANE, as long as the client also can't fetch the TLSA records directly from DNS 💀
the ExtSupportLifetime element is the countermeasure here 🛡️ its value is the number of hours the TLS server (or the cluster of servers serving the same server name) commits to serving this extension in the future. that's called the "pinning time" or "extension pin" of the extension. a non-zero extension pin value received MUST ONLY be used if the extension also contains a valid TLSA authentication chain that matches the server's certificate chain (so 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 when a valid denial of existence for the associated TLSA RRset comes in. same goes if the client got that denial-of-existence proof some other way, like through direct DNS queries. depending on the client's local policy, it MAY then terminate the connection or MAY keep going with PKIX-based server authentication 🤔
extension pins MUST also be cleared when a DANE-authenticated handshake finishes with a server that returns a "dnssec_chain" extension with a zero ExtSupportLifetime 🧹
when a fully validated handshake finishes with a server that returns a "dnssec_chain" extension with a non-zero ExtSupportLifetime, the client MUST update any existing pin lifetime for the service (name and port) to a value that's not longer than what the server indicated 📆 the client MAY, subject to local policy, create a previously nonexistent pin too, again for a lifetime that's not longer than what the server indicated 🌈
the extension support lifetime isn't constrained by any DNS TTLs or RRSIG expirations in the returned chain. it's the time the TLS server is committing to serve the extension, and it is NOT a validity time for the returned chain data 🙅♀️ during that period, the DNSSEC chain may be updated. so the ExtSupportLifetime value isn't constrained by any DNS TTLs or RRSIG expirations in the returned chain, full stop 💅
clients MAY implement support for a subset of DANE certificate usages. for example, a client might support only DANE-EE(3) and DANE-TA(2) [RFC7218], only PKIX-EE(1) and PKIX-TA(0), or all four 🦋 clients that implement DANE-EE(3) and DANE-TA(2) MUST implement the relevant updates in [RFC7671].
for a non-zero saved value ("pin") of the ExtSupportLifetime element, TLS clients that don't have a cached TLSA RRset with an unexpired TTL MUST use the extension for the associated name and port to get this info from the TLS server 🔍 that client then MUST require the TLS server to respond with this extension, and the extension MUST contain a valid TLSA RRset or proof of nonexistence of the TLSA RRset covering the requested name and port. a nonexistence proof or proof of insecure delegation will clear the pin 🧼 the TLS client MUST require this for as long as the pin's time period lasts, no matter what the DNS TTLs say. if the TLS client fails to receive this info during all that, it MUST either abort the connection or delay communication with the server over the TLS connection until it can get valid TLSA records (or proof of nonexistence) out of band, like through direct DNS lookups 😤 if the out-of-band attempts fail, the client MUST abort the TLS connection. it MAY try a new TLS connection again (for example, using an exponential back-off timer) to reach a different server instance that does properly serve the extension 🔄
a TLS client with a cached validated TLSA RRset and a valid non-zero extension pin time MAY still refrain from requesting the extension, as long as it uses that cached RRset to authenticate the server 🧠 this RRset MUST NOT be used beyond its received TTL. once that TTL expires, the TLS client with a valid non-zero extension pin time MUST request the extension and MUST abort the TLS connection if the server responds without it 🚨 a TLS client MAY attempt to get a valid TLSA RRset by some other means before starting a new TLS connection.
okay this one is important bestie 📣 requiring the extension is NOT the same as requiring DANE TLSA records or even DNSSEC. a DNS zone operator can delete the TLSA records or even remove the DS records at any time to disable the secure delegation of the server's DNS zone 🥀 the TLS server will swap the chain for the matching denial-of-existence chain when it updates its cached TLSA authentication chain. the server's only obligation is continued support for this extension 🫶
8. Trust Anchor Maintenance 🔑
the trust anchor may change periodically, like when the operator of the trust anchor zone does 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 do trust anchor updates in-band in TLS, by tracking the introduction of new keys seen in the trust anchor DNSKEY RRset 🧩 alternative mechanisms external to TLS may also be utilized, tho. some operating systems have a system-wide service that keeps the root trust anchor up to date 🖥️ in that case, the TLS client application could just reference that as its trust anchor and periodically check whether it has changed. some apps may prefer to do trust anchor updates as part of their automated software updates 🎁
9. Virtual Hosting 🌸
delivering application services is often done by a third party on behalf of the domain owner (the 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 the domain owner 🤝
when CNAME records get used to redirect network connections to the provider's network, as mentioned in Section 3, the server uses the client's SNI hostname as the TLSA base domain without CNAME expansion 🪄 when the provider manages the certificate chain for the service, it's impractical to coordinate certificate changes by the provider with updates in the hosting customer's DNS. so the TLSA RRset for the hosted domain is best configured as a CNAME from the customer's domain to a TLSA RRset 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 get TLSA records directly from DNS, bypassing this extension, may perform CNAME expansion as in [Section 7 of RFC7671](https://www.rfc-editor.org/rfc/rfc7671#section-7)... wait, correction: as in Section 7 of [RFC7671] 🧐 if the TLSA records are associated with the fully expanded name, that name may be used as the TLSA base domain and SNI name for the TLS handshake 💜
to avoid confusion, it is RECOMMENDED that server operators not publish TLSA RRs (_port._tcp. + base domain) based on the expanded CNAMEs used to locate their network addresses 🙅 instead, the server operator SHOULD publish TLSA RRs at an alternative DNS node (like in the example above), and the hosting customer will publish a CNAME alias pointing to it 🍓 this way, all clients (whether they get TLSA records straight from DNS or use this extension) see the same TLSA records and send the same SNI name 🎀✨
10. Operational Considerations 🛠️
okay so, when DANE is being introduced bit by bit into an existing PKIX setup, you can totally run into a situation where DANE auth fails for a server but PKIX still succeeds, or the other way around 😭. What happens next is up to the TLS client's policy. If DANE auth fails, the client may decide to fall back to regular PKIX auth. To do that efficiently inside the same TLS handshake, the TLS server needs to have provided the full X.509 certificate chain 🎀.
If a TLS server only supports DANE-EE or DANE-TA modes, it has the option to send a much smaller certificate chain. For DANE-EE, that's just the EE certificate. For DANE-TA, it's a short certificate chain from the DANE trust anchor to the EE certificate. If the server supports both DANE and regular PKIX and wants efficient PKIX fallback in the same handshake, they should always provide the full X.509 certificate chain 💅.
When a TLS server operator wants to stop deploying this extension, it must properly decommission its use 🧹. If a non-zero pin lifetime is currently advertised, it must first be changed to 0. The extension can be disabled once all previously advertised pin lifetimes have expired. Removing TLSA records, or even DNSSEC signing 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 👀. Just be careful not to set a local maximum that is too short, because 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 🔑. Key rollover can't happen at the same time across multiple certificate updates, so there will be times when multiple "1 1 1" (or "3 1 1") records are required to match all the extant certificates. Either way, multiple TLSA records are 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 issued by the certification authority in question. It keeps working across end-entity certificate updates as long as the issuer certificate or public keys remain unchanged 🌸. This can be easier to implement, but it comes with greater reliance on the security of the selected certification authority 🫠.
The provider can, of course, publish separate TLSA records for each customer. That means more RRsets to manage, but each one is independent of the rest 🧚.
11. Security Considerations 🔐
Okay, this part is serious, so buckle up 😭🚨. The security considerations of the normatively referenced RFCs all pertain to this extension. Since the server is delivering a chain of DNS records and signatures to the client, it MUST rebuild the chain in accordance with TTL and signature expiration of the chain components, as described in Section 4. TLS clients need roughly accurate time in order to properly authenticate these signatures ⏰. This could be achieved by running a time synchronization protocol like NTP [RFC5905] or SNTP [RFC5905], which are already widely used today. TLS clients MUST support a mechanism to track and roll over the trust anchor key, or be able to avail themselves of a service that does this, as described in Section 8 🔄. Security considerations related to mandating the use of this extension are described in Section 7.
The received DNSSEC chain could contain DNS RRs that aren't related to the TLSA verification of the intended DNS name 🧐. If such an unrelated RR is not DNSSEC signed, it MUST be discarded 🗑️. If the unrelated RRset is DNSSEC signed, the TLS client MAY decide to add these RRsets and their DNSSEC signatures to its cache. It MAY even pass this data to the local system resolver for caching outside the application. However, care must be taken, because caching these records could be used for timing and caching attacks to de-anonymize the TLS client or its user 🕵️♀️. A TLS client that wants to present the strongest anonymity protection to their users MUST refrain from using and caching all unrelated RRs 🛡️💖.
12. IANA Considerations 📋
IANA has made the following assignment in the "TLS ExtensionType Values" registry 🎉:
+=======+================+=========+=============+===========+
| Value | Extension Name | TLS 1.3 | Recommended | Reference |
+=======+================+=========+=============+===========+
| 59 | dnssec_chain | CH | No | RFC 9102 |
+-------+----------------+---------+-------------+-----------+
Table 113. References 📚
13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April
2014, <https://www.rfc-editor.org/info/rfc7218>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.13.2. Informative References
[DANE-UKS] Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-
Share Attacks on DNS-Based Authentications of Named
Entities (DANE)", Work in Progress, Internet-Draft, draft-
barnes-dane-uks-00, 9 October 2016,
<https://datatracker.ietf.org/doc/html/draft-barnes-dane-
uks-00>.
[DISCOVERY]
Gorjon, X. and W. Toorop, "Discovery method for a DNSSEC
validating stub resolver", 14 July 2015,
<https://www.nlnetlabs.nl/downloads/publications/
os3-2015-rp2-xavier-torrent-gorjon.pdf>.
[DNSOP-SVCB-HTTPS]
Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (DNS SVCB and
HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-
dnsop-svcb-https-07, 16 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-07>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
DOI 10.17487/RFC7901, June 2016,
<https://www.rfc-editor.org/info/rfc7901>.
[SERIALIZECHAIN]
Langley, A., "Serializing DNS Records with DNSSEC
Authentication", Work in Progress, Internet-Draft, draft-
agl-dane-serializechain-01, 1 July 2011,
<https://datatracker.ietf.org/doc/html/draft-agl-dane-
serializechain-01>.Appendix A. Test Vectors 🧪
okay so these test vectors are basically the content of the "opaque AuthenticationChain" field, written out in DNS presentation format 💅 and, except for the "extension_data" in Appendix A.1, they do not include the "uint16 ExtSupportLifetime" field 🙈
for brevity and reproducibility, every DNS zone in these vectors is signed with keys using algorithm 13 (ECDSA Curve P-256 with SHA-256) ✨
to reflect how things actually work in the wild, the zones are at different stages of rolling their signing keys 🔄
- all zones use a Key Signing Key (KSK) and a Zone Signing Key (ZSK), except for the "example.com" and "example.net" zones, which use a Combined Signing Key (CSK) 💜
- the root and org zones are rolling their ZSKs 🌸
- the com and org zones are rolling their KSKs 🦋
the test vectors are DNSSEC valid for the same period the certificate is valid, which is between November 28, 2018 and December 2, 2020, using this root trust anchor 👑
. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
641bb568746f2ffc4d4 )and the vectors will authenticate the certificate used with https://example.com/, https://example.net/, and https://example.org/ at the time of writing 🎀
-----BEGIN CERTIFICATE-----
MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN
MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw
b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT
ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV
rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g
rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80
eyRJRqzy8I0LSPTTkhr3okXuzOXXg38ugr1x3SgZWDNuEaE6oGpyYJIBWZ9jF3pJ
QnucP9vTBejMh374qvyd0QVQq3WxHrogy4nUbWw3gihMxT98wRD1oKVma1NTydvt
hcNtBfhkp8kO64/hxLHrLWgOFT/l4tz8IWQt7mkrBHjbd2XLVPkCAwEAAaOCA8Ew
ggO9MB8GA1UdIwQYMBaAFA+AYRyCMWHVLyjnjUY4tCzhxtniMB0GA1UdDgQWBBRm
mGIC4AmRp9njNvt2xrC/oW2nvjCBgQYDVR0RBHoweIIPd3d3LmV4YW1wbGUub3Jn
ggtleGFtcGxlLmNvbYILZXhhbXBsZS5lZHWCC2V4YW1wbGUubmV0ggtleGFtcGxl
Lm9yZ4IPd3d3LmV4YW1wbGUuY29tgg93d3cuZXhhbXBsZS5lZHWCD3d3dy5leGFt
cGxlLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMGsGA1UdHwRkMGIwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNv
bS9zc2NhLXNoYTItZzYuY3JsMC+gLaArhilodHRwOi8vY3JsNC5kaWdpY2VydC5j
b20vc3NjYS1zaGEyLWc2LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAEC
AjB8BggrBgEFBQcBAQRwMG4wJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj
ZXJ0LmNvbTBGBggrBgEFBQcwAoY6aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29t
L0RpZ2lDZXJ0U0hBMlNlY3VyZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB
fwYKKwYBBAHWeQIEAgSCAW8EggFrAWkAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb
37jjd80OyA3cEAAAAWdcMZVGAAAEAwBIMEYCIQCEZIG3IR36Gkj1dq5L6EaGVycX
sHvpO7dKV0JsooTEbAIhALuTtf4wxGTkFkx8blhTV+7sf6pFT78ORo7+cP39jkJC
AHYAh3W/51l8+IxDmV+9827/Vo1HVjb/SrVgwbTq/16ggw8AAAFnXDGWFQAABAMA
RzBFAiBvqnfSHKeUwGMtLrOG3UGLQIoaL3+uZsGTX3MfSJNQEQIhANL5nUiGBR6g
l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC
wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z
RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM
MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R
8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM
v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu
N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa
X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I
0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN
-----END CERTIFICATE-----A.1. "_443._tcp.www.example.com" 🦋
okay so this is the first test vector and it's giving main character energy 💅 it's a DNS chain for _443._tcp.www.example.com, which means a TLSA record plus the RRSIG, DNSKEY, and DS records that tie everything back up to the root 🌸 here's the whole chain, verbatim:
_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== )okay and now the fun part 🎀 the server's dnssec_chain extension, once you turn it into its extension_data form with ExtSupportLifetime set to 0, looks like this hex dump 🧚 it's a LOT of bytes, but every single one matters, so here it is exactly as it should be:
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 bethat hex dump is the exact byte-level receipt for this test vector, so if your bytes don't match it bestie, something's off 🙈
A.2. "_25._tcp.example.com" NSEC Wildcard ✨
okay bestie, here's the next zone data drop 💅
_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 1870 example.com.
BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2
rfL4DFP8rO3VMgI0v+ogrox0w== )
*._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG
NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20201202000000 20181128000000 1870 example.com.
K6u8KrR8ca5bjtbce3w8yjMXr9vw12225lAwyIHpxptY43OMLCUCenwpYW5qd
mpFvAacqj4+tSkKiN279SI9pA== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com.
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
QHPGSpvRxTUC4tZi62z1UgGDw== )
example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd
25a986e8a44f319ac3cd302bafc08f5b81e16 )
example.com. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 34327 com.
sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
J1hhWSB6jgubEVl17rGNOA/YQ== )
com. 172800 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 172800 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 172800 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 18931 com.
LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
7LFdPKpcvb8BvhM+GqKWGBEsg== )
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 28809 com.
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
vBKTf6pk8JRCqnfzlo2QY+WXA== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )A.3. "_25._tcp.example.org" NSEC3 Wildcard 🌸
next up, the NSEC3 version of the same vibe 🧚
_25._tcp.example.org. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
_25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 56566 example.org.
lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL
cYzJ7vCvqb9gFCiCJjK2gAamw== )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 (
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566
example.org.
guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
X38cWzEQOpreJu3t4WAfPsxdg== )
example.org. 3600 IN DNSKEY ( 256 3 13
NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
example.org. 3600 IN DNSKEY ( 257 3 13
uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 44384 example.org.
ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
6OPPvyHjVXMAsvk0tqV0B+/ag== )
example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000
20181128000000 9523 org.
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
clpAfvZHx59Ackst4X+zXYpUA== )
org. 86400 IN DNSKEY ( 256 3 13
fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
org. 86400 IN DNSKEY ( 256 3 13
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
org. 86400 IN DNSKEY ( 257 3 13
Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
org. 86400 IN DNSKEY ( 257 3 13
0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 12651 org.
Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
us0pUgWngbT/OWXskdMYXZU4A== )
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 49352 org.
VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
vZEMj1YXD+dIqb2nUK9PGBAXw== )
org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
9db5c24a75743eb1e704b97a9fabc )
org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
f4a2f18920db5f58710dd767c293b )
org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
EemgaE357S4pX5D0tVZzeZJ6A== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )A.4. "_443._tcp.www.example.org" CNAME 🦋
last one in this batch, bestie, and it's a CNAME 💜
_443._tcp.www.example.org. 3600 IN CNAME (
dane311.example.org. )
_443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600
20201202000000 20181128000000 56566 example.org.
R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx
Qb/a90O696120NsYaZX2+ebBA== )
dane311.example.org. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 56566 example.org.
f6TbTZTpu3h6MYpLkKQwWILAkYQ3EUY+Nsoa6any6yt+aeuunMUjw+IJB2QLm
0x0PrD7m39JA3NUSkUp9riNNQ== )
example.org. 3600 IN DNSKEY ( 256 3 13
NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
example.org. 3600 IN DNSKEY ( 257 3 13
uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 44384 example.org.
ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
6OPPvyHjVXMAsvk0tqV0B+/ag== )
example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000
20181128000000 9523 org.
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
clpAfvZHx59Ackst4X+zXYpUA== )
org. 86400 IN DNSKEY ( 256 3 13
fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
org. 86400 IN DNSKEY ( 256 3 13
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
org. 86400 IN DNSKEY ( 257 3 13
Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
org. 86400 IN DNSKEY ( 257 3 13
0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 12651 org.
Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
us0pUgWngbT/OWXskdMYXZU4A== )
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 49352 org.
VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
vZEMj1YXD+dIqb2nUK9PGBAXw== )
org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
9db5c24a75743eb1e704b97a9fabc )
org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
f4a2f18920db5f58710dd767c293b )
org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
EemgaE357S4pX5D0tVZzeZJ6A== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )A.5. "_443._tcp.www.example.net" DNAME 🌸
okay bestie, this one is giving redirect drama 💅 example.net has a DNAME pointing over to example.com, so the whole _443._tcp.www name gets sent along to example.com. the commented-out line shows the CNAME that comes out of that, and the TLSA record and every signature around it are all there too 🔥
example.net. 3600 IN DNAME example.com.
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000
20181128000000 48085 example.net.
o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx
OI/pDnjJcLSd/gBLtqR52WLMA== )
; _443._tcp.www.example.net. 3600 IN CNAME (
; _443._tcp.www.example.com. )
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20201202000000 20181128000000 1870 example.com.
rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
z2BhaswpGLVVuoijuVdzxYjmw== )
example.net. 3600 IN DNSKEY ( 257 3 13
X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d
9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085
example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 48085 example.net.
CkwqgEt1p97oMa3w5LctIjKIuG5XVSapKrfwuHhb5p04fWXRMNsXasG/kd2F/
wlmMWiq38gOQaYCLNm+cjQzpQ== )
example.net. 172800 IN DS ( 48085 13 2 7c1998ce683df60e2fa41460c4
53f88f463dac8cd5d074277b4a7c04502921be )
example.net. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 10713 net.
w0JxDeiBJZNlpCdxKtRENlqfTpSxcs6Vftscsyfo/hyeTPYcIt4yItDkYsYK+
KQ6FYAVE4nisA3vDQoZVL4wow== )
net. 172800 IN DNSKEY ( 256 3 13
061EoQs4sBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimi4/lw/vtyfqALuLF
JiFjtCK3HMPi8HQ1jbGEwbGCA== ) ; Key ID = 10713
net. 172800 IN DNSKEY ( 257 3 13
LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5
oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485
net. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 485 net.
031jXg06zSuDwI5zqYuYFJg1O5p+zy85csMXagvRxB9W2lL/wJRi6Gn9BcaCV
RnDId5WR+yCADhsbKfSrrd9vQ== )
net. 86400 IN DS ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c
d8c247769b23adb13ca234d1c05 )
net. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
vOXoTjxggGTYKIwssQ3kpML0ag6D0Hcm+Syy7++4zT7gaFHfRH9a6uZekIWdb
oss8y7q4onW4rxKdtw2S28hwQ== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com.
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
QHPGSpvRxTUC4tZi62z1UgGDw== )
example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd
25a986e8a44f319ac3cd302bafc08f5b81e16 )
example.com. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 34327 com.
sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
J1hhWSB6jgubEVl17rGNOA/YQ== )
com. 172800 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 172800 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 172800 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 18931 com.
LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
7LFdPKpcvb8BvhM+GqKWGBEsg== )
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 28809 com.
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
vBKTf6pk8JRCqnfzlo2QY+WXA== )A.6. "_25._tcp.smtp.example.com" NSEC Denial of Existence ✨
this one is the denial-of-existence moment 🙈 the NSEC record for smtp.example.com lists the types that do exist at that name, and it's signed, with the DNSKEY and DS records all the way up to the root so you can check the chain yourself 🦋
smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA
RRSIG NSEC )
smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20201202000000 20181128000000 1870 example.com.
rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf
crlsQZmnAUlfmBNCygxAd7JNw== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com.
nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
QHPGSpvRxTUC4tZi62z1UgGDw== )
example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd
25a986e8a44f319ac3cd302bafc08f5b81e16 )
example.com. 172800 IN RRSIG ( DS 13 2 172800
20201202000000 20181128000000 34327 com.
sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
J1hhWSB6jgubEVl17rGNOA/YQ== )
com. 172800 IN DNSKEY ( 256 3 13
7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
com. 172800 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 172800 IN DNSKEY ( 257 3 13
szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 18931 com.
LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
7LFdPKpcvb8BvhM+GqKWGBEsg== )
com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000
20181128000000 28809 com.
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
vBKTf6pk8JRCqnfzlo2QY+WXA== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )A.7. "_25._tcp.smtp.example.org" NSEC3 Denial of Existence 💌
Okay, this one is the NSEC3 denial-of-existence vibe, and the records are giving 🧚✨
vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN NSEC3 (
1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG )
vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566
example.org.
wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh
gQeV5KgP1cdvPt1BEowKqK4Sw== )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 (
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566
example.org.
guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
X38cWzEQOpreJu3t4WAfPsxdg== )
a73bi8coh6dvf1arqdeuogf95r0828mk.example.org. 3600 IN NSEC3 (
1 0 1 - c1p0lp7l1l8gdn0jl13pp1o41h35untj CNAME RRSIG )
a73bi8coh6dvf1arqdeuogf95r0828mk.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566
example.org.
ePBUuWdj8Bc+/41gHBm2Bx/IK/j/Q4W7A5uTgSj/0Sd57mP/NTWRZq3p8yBNe
FPC2mBJ2oWQFi6/V9dmyiBh2A== )
example.org. 3600 IN DNSKEY ( 256 3 13
NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
example.org. 3600 IN DNSKEY ( 257 3 13
uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 44384 example.org.
ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
6OPPvyHjVXMAsvk0tqV0B+/ag== )
example.org. 86400 IN DS ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
example.org. 86400 IN RRSIG ( DS 13 2 86400 20201202000000
20181128000000 9523 org.
m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
clpAfvZHx59Ackst4X+zXYpUA== )
org. 86400 IN DNSKEY ( 256 3 13
fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
org. 86400 IN DNSKEY ( 256 3 13
zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
org. 86400 IN DNSKEY ( 257 3 13
Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
org. 86400 IN DNSKEY ( 257 3 13
0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 12651 org.
Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
us0pUgWngbT/OWXskdMYXZU4A== )
org. 86400 IN RRSIG ( DNSKEY 13 1 86400 20201202000000
20181128000000 49352 org.
VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
vZEMj1YXD+dIqb2nUK9PGBAXw== )
org. 86400 IN DS ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
9db5c24a75743eb1e704b97a9fabc )
org. 86400 IN DS ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
f4a2f18920db5f58710dd767c293b )
org. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
EemgaE357S4pX5D0tVZzeZJ6A== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )A.8. "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure Delegation 🦋
And last test vector, bestie! This one is the opt-out insecure delegation, and it's so iconic 👑
c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 (
1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY
NSEC3PARAM )
c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG (
NSEC3 13 2 43200 20201202000000 20181128000000 15903
example.
pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg
RpXUsJhZBDax2dfDhK7zOk7ow== )
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 (
1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG )
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG (
NSEC3 13 2 43200 20201202000000 20181128000000 15903
example.
5Aq//A8bsWNwcXbT91pMX2Oqf8VpJQRjqH4D2yZElW00wKmt85mhgu2qYPrvH
QwGEB4STMz2Nefq01/GY6NHKg== )
example. 432000 IN DNSKEY ( 257 3 13
yrkqXSbVwXOoUxCjr/E9yg8XUzbZNlwPllVsoUPd73TLOnBQQ+03Qw4/k+Nme
/66WIw+ZTlHYcTNalxiGYm0uQ== ) ; Key ID = 15903
example. 432000 IN RRSIG ( DNSKEY 13 1 432000
20201202000000 20181128000000 15903 example.
wwEo3ri6JBuCqx5b33w8axFWOhIen1l+/mm0Isyc9FciuLhBiP+IqSgt+Igc8
9nR8zRpJpo1D6XR/qJxZgnfaA== )
example. 86400 IN DS ( 15903 13 2 7e0ebaf1cc0d309d4a73ca7d711719d
d940f4da87b3d72865167650fc73ea577 )
example. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 .
B5vx4zZaS+bOYfz0PzpaPfk9VxxBvYbGjIvGhpUZV3diXzfCguXxN4JIT1Sz8
eJX6BYT5QPIrbG/N35U1sIskw== )
. 86400 IN DNSKEY ( 256 3 13
zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
. 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== )Acknowledgments 🫶
Huge thank-yous to Adam Langley, who laid the groundwork for this extension in [SERIALIZECHAIN] 💜 The original idea is his, but us thanking him does not mean he endorses this doc, so don't get it twisted 🙈
This doc also got better thanks to chats with and reviews from 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. Iconic squad, literally 🌈
Authors' Addresses ✨
Here's where you can find the authors, bestie 💅
Viktor Dukhovni Two Sigma
Email: ietf-dane@dukhovni.org
Shumon Huque
Salesforce
3rd Floor
415 Mission Street
San Francisco, CA 94105
United States of America
Email: shuque@gmail.comWillem Toorop
NLnet Labs
Science Park 400
1098 XH Amsterdam
Netherlands
Email: willem@nlnetlabs.nlPaul Wouters
Aiven
Toronto
Canada
Email: paul.wouters@aiven.ioMelinda Shore
Fastly
Email: mshore@fastly.com📦 where this page comes from
- ietf: rfc9102 2021-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms