rfc9102.original.xml   rfc9102.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
or - mmark.miek.nl" --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc version="3" ipr="trust200902" docName="draft-dukhovni-tls-dnssec-chain-08"
submissionType="independent" category="exp" xml:lang="en" xmlns:xi="http://www.w <rfc version="3" ipr="trust200902" docName="draft-dukhovni-tls-dnssec-chain-08"
3.org/2001/XInclude"> number="9102" submissionType="independent" category="exp" updates="" obsoletes="
" tocInclude="true" symRefs="true" sortRefs="true" xml:lang="en" xmlns:xi="http:
//www.w3.org/2001/XInclude">
<front> <front>
<title abbrev="tls-dnssec-chain">TLS DNSSEC Chain Extension</title><seriesInfo v <title abbrev="TLS DNSSEC Chain">TLS DNSSEC Chain Extension</title>
alue="draft-dukhovni-tls-dnssec-chain-08" stream="independent" status="experimen <seriesInfo name="RFC" value="9102"/>
tal" name="Internet-Draft"></seriesInfo> <author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni">
<author initials="V." surname="Dukhovni" fullname="Viktor Dukhovni"><organizatio <organization>Two Sigma</organization><address><postal>
n>Two Sigma</organization><address><postal><street></street>
</postal><email>ietf-dane@dukhovni.org</email> </postal><email>ietf-dane@dukhovni.org</email>
</address></author> </address></author>
<author initials="S." surname="Huque" fullname="Shumon Huque"><organization>Sale <author initials="S." surname="Huque" fullname="Shumon Huque">
sforce</organization><address><postal><street>415 Mission Street, 3rd Floor</str <organization>Salesforce</organization>
eet> <address>
<postal>
<extaddr>3rd Floor</extaddr>
<street>415 Mission Street</street>
<city>San Francisco</city> <city>San Francisco</city>
<code>CA 94105</code> <region>CA</region>
<code>94105</code>
<country>United States of America</country> <country>United States of America</country>
</postal><email>shuque@gmail.com</email> </postal><email>shuque@gmail.com</email>
</address></author> </address></author>
<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL net Labs</organization><address><postal><street>Science Park 400</street> <author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL net Labs</organization><address><postal><street>Science Park 400</street>
<city>Amsterdam</city> <city>Amsterdam</city>
<code>1098 XH</code> <code>1098 XH</code>
<country>Netherlands</country> <country>Netherlands</country>
</postal><email>willem@nlnetlabs.nl</email> </postal><email>willem@nlnetlabs.nl</email>
</address></author> </address></author>
<author initials="P." surname="Wouters" fullname="Paul Wouters"><organization>Ai ven</organization><address><postal><street></street> <author initials="P." surname="Wouters" fullname="Paul Wouters"><organization>Ai ven</organization><address><postal>
<city>Toronto</city> <city>Toronto</city>
<country>Canada</country> <country>Canada</country>
</postal><email>paul.wouters@aiven.io</email> </postal><email>paul.wouters@aiven.io</email>
</address></author> </address></author>
<author initials="M." surname="Shore" fullname="Melinda Shore"><organization>Fas tly</organization><address><postal><street></street> <author initials="M." surname="Shore" fullname="Melinda Shore"><organization>Fas tly</organization><address><postal>
</postal><email>mshore@fastly.com</email> </postal><email>mshore@fastly.com</email>
</address></author> </address></author>
<date year="2021" month="June" day="10"></date> <date year="2021" month="July" />
<area>Security</area>
<workgroup></workgroup>
<abstract> <abstract>
<t>This document describes an experimental TLS extension for in-band <t>This document describes an experimental TLS extension for the in-band
transport of the complete set of DNSSEC validatable records needed to transport of the complete set of records that can be validated by DNSSEC and tha
perform DANE authentication of a TLS server without the need to t are needed to
perform separate out-of-band DNS lookups. When the requisite DNS perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This
records do not exist, the extension conveys a validatable denial of extension obviates the need to
existence proof.</t> perform separate, out-of-band DNS lookups. When the requisite DNS
records do not exist, the extension conveys a denial-of-existence proof that can
be validated.</t>
<t>This experimental extension is developed outside the IETF and is <t>This experimental extension is developed outside the IETF and is
published here to guide implementation of the extension and to ensure published here to guide implementation of the extension and to ensure
interoperability among implementations.</t> interoperability among implementations.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"><name>Introduction</name> <section anchor="introduction"><name>Introduction</name>
<t>This document describes an experimental TLS <xref target="RFC5246"></xref><xr <t>This document describes an experimental TLS <xref target="RFC5246"></xref> <x
ef target="RFC8446"></xref> ref target="RFC8446"></xref>
extension for in-band transport of the complete set of DNSSEC extension for in-band transport of the complete set of resource records (RRs) va
<xref target="RFC4033"></xref><xref target="RFC4034"></xref><xref target="RFC403 lidated by DNSSEC <xref target="RFC4033"></xref> <xref target="RFC4034"></xref>
5"></xref> validated Resource Records (RRs) that <xref target="RFC4035"></xref>. This extension enables a TLS client to perform D
enable a TLS client to perform DANE Authentication <xref target="RFC6698"></xref ANE authentication <xref target="RFC6698"></xref> <xref target="RFC7671"></xref>
><xref target="RFC7671"></xref>
of a TLS server without the need to perform out-of-band DNS lookups. 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 Retrieval of the required DNS records may be unavailable to the client
<xref target="NLNETLABS"></xref>, or may incur undesirable additional latency.</ t> <xref target="DISCOVERY"></xref> or may incur undesirable additional latency.</t >
<t>The extension described here allows a TLS client to request that the <t>The extension described here allows a TLS client to request that the
TLS server return the DNSSEC authentication chain corresponding to TLS server return the DNSSEC authentication chain corresponding to
its DNSSEC-validated DANE TLSA Resource Record set (RRset), or its DNSSEC-validated DANE TLSA resource record set (RRset) or
authenticated denial of existence of such an RRset (as described in authenticated denial of existence of such an RRset (as described in
<xref target="denial_of_existence"></xref>). If the server supports this extensi on it <xref target="denial_of_existence"></xref>). If the server supports this extensi on, it
performs the appropriate DNS queries, builds the authentication performs the appropriate DNS queries, builds the authentication
chain, and returns it to the client. The server will typically use a chain, and returns it to the client. The server will typically use a
previously cached authentication chain, but it will need to rebuild previously cached authentication chain, but it will need to rebuild
it periodically as described in <xref target="sec_caching"></xref>. The client t hen it periodically as described in <xref target="sec_caching"></xref>. The client t hen
authenticates the chain using a preconfigured DNSSEC trust anchor.</t> authenticates the chain using a preconfigured DNSSEC trust anchor.</t>
<t>In the absence of TLSA records, this extension conveys the required <t>In the absence of TLSA records, this extension conveys the required
authenticated denial of existence. Such proofs are needed to securely authenticated denial of existence. Such proofs are needed to securely
signal that specified TLSA records are not available so that TLS clients signal that specified TLSA records are not available so that TLS clients
can safely fall back to Public-Key Infrastructure X.509 (PKIX, sometimes called can safely fall back to authentication based on Public Key Infrastructure X.509
WebPKI) based authentication if allowed by local policy. These proofs (PKIX, sometimes called
WebPKI) if allowed by local policy. These proofs
are also needed to avoid downgrade from opportunistic authenticated TLS are also needed to avoid downgrade from opportunistic authenticated TLS
(when DANE TLSA records are present) to unauthenticated opportunistic TLS (when DANE TLSA records are present) to unauthenticated opportunistic TLS
(in the absence of DANE). Denial of existence records are also used by (in the absence of DANE). Denial-of-existence records are also used by
the TLS client to clear no longer relevant extension pins, as described in the TLS client to clear extension pins that are no longer relevant, as described
in
<xref target="pinning"></xref>.</t> <xref target="pinning"></xref>.</t>
<t>This extension supports DANE authentication of either X.509 <t>This extension supports DANE authentication of either X.509
certificates or raw public keys as described in the DANE certificates or raw public keys, as described in the DANE
specification <xref target="RFC6698"></xref><xref target="RFC7671"></xref> and < specification <xref target="RFC6698"></xref> <xref target="RFC7671"></xref> <xre
xref target="RFC7250"></xref>.</t> f target="RFC7250"></xref>.</t>
<t>This extension also mitigates against an unknown key share (UKS) <t>This extension also mitigates against an unknown key share (UKS)
attack <xref target="I-D.barnes-dane-uks"></xref> when using raw public keys, si nce the attack <xref target="I-D.barnes-dane-uks"></xref> when using raw public keys sin ce the
server commits to its DNS name (normally found in its certificate) server commits to its DNS name (normally found in its certificate)
via the content of the returned TLSA RRset.</t> via the content of the returned TLSA RRset.</t>
<t>This experimental extension is developed outside the IETF and is <t>This experimental extension is developed outside the IETF and is
published here to guide implementation of the extension and to ensure published here to guide implementation of the extension and to ensure
interoperability among implementations.</t> interoperability among implementations.</t>
<section anchor="scope-of-the-experiment"><name>Scope of the experiment</name> <section anchor="scope-of-the-experiment"><name>Scope of the Experiment</name>
<t>The mechanism described in this document is intended to be used with <t>The mechanism described in this document is intended to be used with
applications on the wider internet. One application of TLS well applications on the wider internet. One application of TLS well
suited for the TLS DNSSEC Chain extension is DNS over TLS <xref target="RFC7858" ></xref>. suited for the TLS DNSSEC Chain extension is DNS over TLS <xref target="RFC7858" ></xref>.
In fact, one of the authentication methods for DNS over TLS <em>is</em> the In fact, one of the authentication methods for DNS over TLS <em>is</em> the
mechanism described in this document, as specified in Section 8.2.2 mechanism described in this document, as specified in <xref target="RFC8310" sec
of <xref target="RFC8310"></xref>.</t> tion="8.2.2" sectionFormat="of"></xref>.</t>
<t>The need for this mechanism when using DANE to authenticate a DNS over TLS <t>The need for this mechanism when using DANE to authenticate a DNS-over-TLS
resolver is obvious, since DNS may not be available to perform the resolver is obvious, since DNS may not be available to perform the
required DNS lookups. Other applications of TLS would benefit from required DNS lookups. Other applications of TLS would benefit from
using this mechanism as well. The client sides of those applications using this mechanism as well. The client sides of those applications
would not be required to be used on end-points with a working DNSSEC would not be required to be used on endpoints with a working DNSSEC
resolver in order for them to use DANE authentication of the TLS resolver in order for them to use the DANE authentication of the TLS
service. Therefore we invite other TLS services to try out this service. Therefore, we invite other TLS services to try out this
mechanism as well.</t> mechanism as well.</t>
<t>In the TLS working group, concerns have been raised that the pinning <t>In the TLS Working Group, concerns have been raised that the pinning
technique as described in <xref target="pinning"></xref> would complicate deploy ability technique as described in <xref target="pinning"></xref> would complicate deploy ability
of the TLS DNSSEC Chain extension. The goal of the experiment is to of the TLS DNSSEC chain extension. The goal of the experiment is to
study these complications in real world deployments. This experiment study these complications in real-world deployments. This experiment
hopefully will give the TLS working group some insight into whether hopefully will give the TLS Working Group some insight into whether
or not this is a problem.</t> or not this is a problem.</t>
<t>If the experiment is successful, it is expected that the findings of <t>If the experiment is successful, it is expected that the findings of
the experiment will result in an updated document for standards track the experiment will result in an updated document for Standards Track
approval.</t> approval.</t>
</section> </section>
<section anchor="requirements-notation"><name>Requirements Notation</name> <section anchor="requirements-notation"><name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", <t>
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and o RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nly when, they appear in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="dnssec-authentication-chain-extension"><name>DNSSEC Authenticat ion Chain Extension</name> <section anchor="dnssec-authentication-chain-extension"><name>DNSSEC Authenticat ion Chain Extension</name>
<section anchor="protocol-tls-1-2"><name>Protocol, TLS 1.2</name> <section anchor="protocol-tls-1-2"><name>Protocol, TLS 1.2</name>
<t>A client MAY include an extension of type <tt>dnssec_chain</tt> in the <t>A client <bcp14>MAY</bcp14> include an extension of type <tt>dnssec_chain</tt > in the
(extended) ClientHello. The <tt>extension_data</tt> field of this extension (extended) ClientHello. The <tt>extension_data</tt> field of this extension
consists of the server's 16-bit TCP port number in network consists of the server's 16-bit TCP port number in network
(big-endian) byte order. Clients sending this extension MUST also (big-endian) byte order. Clients sending this extension <bcp14>MUST</bcp14> also
send the Server Name Identification (SNI, <xref target="RFC6066"></xref>) send the Server Name Identification (SNI) extension <xref target="RFC6066"></xre
extension. Together, these make it possible for the TLS server to f>.
Together, these make it possible for the TLS server to
determine which authenticated TLSA RRset chain needs to be used for determine which authenticated TLSA RRset chain needs to be used for
the <tt>dnssec_chain</tt> extension.</t> the <tt>dnssec_chain</tt> extension.</t>
<t>When a server that implements (and is configured to enable the use <t>When a server that implements (and is configured to enable the use
of) this extension receives a <tt>dnssec_chain</tt> extension in the of) this extension receives a <tt>dnssec_chain</tt> extension in the
ClientHello, it MUST first check whether the requested TLSA RRset ClientHello, it <bcp14>MUST</bcp14> first check whether the requested TLSA RRset
(based on the port number in this extension and hostname in the SNI (based on the port number in this extension and hostname in the SNI
extension) is associated with the server. If the extension, the SNI extension) is associated with the server. If the extension, the SNI
hostname or the port number is unsupported, the server's extended hostname, or the port number is unsupported, the server's extended
ServerHello message MUST NOT include the <tt>dnssec_chain</tt> extension.</t> ServerHello message <bcp14>MUST NOT</bcp14> include the <tt>dnssec_chain</tt> ex
<t>Otherwise, the server's extended ServerHello message MUST contain a tension.</t>
<t>Otherwise, the server's extended ServerHello message <bcp14>MUST</bcp14> cont
ain a
serialized authentication chain using the format described below. If serialized authentication chain using the format described below. If
the server does not have access to the requested DNS chain - for the server does not have access to the requested DNS chain -- for
example due to a misconfiguration or expired chain - the server MUST example, due to a misconfiguration or expired chain -- the server <bcp14>MUST</b
cp14>
omit the extension rather than send an incomplete chain. Clients that omit the extension rather than send an incomplete chain. Clients that
are expecting this extension MUST interpret this as a downgrade are expecting this extension <bcp14>MUST</bcp14> interpret this as a downgrade
attack and MUST abort the TLS connection. Therefore, servers MUST send attack and <bcp14>MUST</bcp14> abort the TLS connection. Therefore, servers <bc
denial of existence proofs, unless, for the particular application p14>MUST</bcp14> send
denial-of-existence proofs unless, for the particular application
protocol or service, clients are expected to continue even in the protocol or service, clients are expected to continue even in the
absence of such a proof. As with all TLS extensions, if the server absence of such a proof. As with all TLS extensions, if the server
does not support this extension it will not return any authentication does not support this extension, it will not return any authentication
chain.</t> chain.</t>
<t>The set of supported combinations of port number and SNI name may be <t>The set of supported combinations of a port number and SNI name may be
configured explicitly by server administrators, or could be inferred configured explicitly by server administrators or could be inferred
from the available certificates combined with a list of supported ports. from the available certificates combined with a list of supported ports.
It is important to note that the client's notional port number may be It is important to note that the client's notional port number may be
different from the actual port on which the server is receiving different from the actual port on which the server is receiving
connections.</t> connections.</t>
<t>Differences between the client's notional port number and the actual <t>Differences between the client's notional port number and the actual
port at the server could be a result of intermediate systems performing port at the server could be a result of intermediate systems performing
network address translation, or perhaps a result of a redirect via HTTPS network address translation or a result of a redirect via HTTPS
or SVCB records (both defined in <xref target="I-D.ietf-dnsop-svcb-https"></xref >).</t> or SVCB records (both defined in <xref target="I-D.ietf-dnsop-svcb-https"></xref >).</t>
<t>Though a DNS zone's HTTPS or SVCB records may be signed, a client <t>Though a DNS zone's HTTPS or SVCB records may be signed, a client
using this protocol might not have direct access to a validating resolver, using this protocol might not have direct access to a validating resolver
and might not be able to check the authenticity of the target port number and might not be able to check the authenticity of the target port number
or hostname. In order to avoid downgrade attacks via forged DNS or hostname. In order to avoid downgrade attacks via forged DNS
records, the SNI name and port number inside the client extension MUST records, the SNI name and port number inside the client extension <bcp14>MUST</b
be based on the original SNI name and port and MUST NOT be taken from cp14>
the encountered HTTPS or SVCB record. The client supporting this document be based on the original SNI name and port and <bcp14>MUST NOT</bcp14> be taken
and HTTPS / SVCB records, MUST still use the HTTPS or SVCB records to from
the encountered HTTPS or SVCB record.
The client supporting this document
and HTTPS or SVCB records <bcp14>MUST</bcp14> still use the HTTPS or SVCB record
s to
select the target transport endpoint. Servers supporting this extension select the target transport endpoint. Servers supporting this extension
that are targets of HTTPS or SVCB records MUST be provisioned to process that are targets of HTTPS or SVCB records <bcp14>MUST</bcp14> be provisioned to process
client extensions based on the client's logical service endpoint's SNI client extensions based on the client's logical service endpoint's SNI
name and port as it is prior to HTTPS or SVCB indirection.</t> name and port as it is prior to HTTPS or SVCB indirection.</t>
</section> </section>
<section anchor="protocol-tls-1-3"><name>Protocol, TLS 1.3</name> <section anchor="protocol-tls-1-3"><name>Protocol, TLS 1.3</name>
<t>In TLS 1.3 <xref target="RFC8446"></xref>, when the server receives the <tt>d nssec_chain</tt> extension, <t>In TLS 1.3 <xref target="RFC8446"></xref>, when the server receives the <tt>d nssec_chain</tt> extension,
it adds its <tt>dnssec_chain</tt> extension to the extension block of the Certif icate it adds its <tt>dnssec_chain</tt> extension to the extension block of the Certif icate
message containing the end entity certificate being validated, rather than to message containing the end-entity certificate being validated rather than to
the extended ServerHello message.</t> the extended ServerHello message.</t>
<t>The extension protocol behavior otherwise follows that specified for <t>The extension protocol behavior otherwise follows that specified for
TLS version 1.2 <xref target="RFC5246"></xref>.</t> TLS version 1.2 <xref target="RFC5246"></xref>.</t>
</section> </section>
<section anchor="auth_chain_data"><name>DNSSEC Authentication Chain Data</name> <section anchor="auth_chain_data"><name>DNSSEC Authentication Chain Data</name>
<t>The <tt>extension_data</tt> field of the client's <tt>dnssec_chain</tt> exten sion <t>The <tt>extension_data</tt> field of the client's <tt>dnssec_chain</tt> exten sion
MUST contain the server's 16-bit TCP port number in network <bcp14>MUST</bcp14> contain the server's 16-bit TCP port number in network
(big-endian) byte order:</t> (big-endian) byte order:</t>
<sourcecode> struct {
<artwork> struct {
uint16 PortNumber; uint16 PortNumber;
} DnssecChainExtension; } DnssecChainExtension;
</artwork> </sourcecode>
<t>The <tt>extension_data</tt> field of the server's <tt>dnssec_chain</tt> exten sion <t>The <tt>extension_data</tt> field of the server's <tt>dnssec_chain</tt> exten sion
MUST contain a DNSSEC Authentication Chain encoded in the following <bcp14>MUST</bcp14> contain a DNSSEC authentication chain encoded in the followi ng
form:</t> form:</t>
<artwork> struct { <sourcecode> struct {
uint16 ExtSupportLifetime; uint16 ExtSupportLifetime;
opaque AuthenticationChain&amp;lt;1..2^16-1&amp;gt; opaque AuthenticationChain&lt;1..2^16-1&amp;gt;
} DnssecChainExtension; } DnssecChainExtension;
</artwork> </sourcecode>
<t>The ExtSupportLifetime value is the number of hours for which the TLS <t>The ExtSupportLifetime value is the number of hours that the TLS
server has committed itself to serving this extension. A value of server has committed itself to serving this extension. A value of
zero prohibits the client from unilaterally requiring ongoing use of zero prohibits the client from unilaterally requiring ongoing use of
the extension based on prior observation of its use (extension the extension based on prior observation of its use (extension
pinning). This is further described in <xref target="pinning"></xref>.</t> pinning). This is further described in <xref target="pinning"></xref>.</t>
<t>The AuthenticationChain is composed of a sequence of uncompressed <t>The AuthenticationChain is composed of a sequence of uncompressed
wire format DNS RRs (including all requisite RRSIG <xref target="RFC4034"></xref wire format DNS RRs (including all requisite RRSIG RRs <xref target="RFC4034"></
> RRs) xref>)
in no particular order. The format of the Resource Record is in no particular order. The format of the resource record is
described in <xref target="RFC1035"></xref>, Section 3.2.1.</t> described in <xref target="RFC1035" sectionFormat="comma" section="3.2.1"></xref
>.</t>
<artwork> RR = { owner, type, class, TTL, RDATA length, RDATA } <artwork> RR = { owner, type, class, TTL, RDATA length, RDATA }
</artwork> </artwork>
<t>The order of returned RRs is unspecified and a TLS client MUST NOT <t>The order of returned RRs is unspecified, and a TLS client <bcp14>MUST NOT</b cp14>
assume any ordering of RRs.</t> assume any ordering of RRs.</t>
<t>Use of native DNS wire format records enables easier generation of
<t>Use of DNS wire format records enables easier generation of
the data structure on the server and easier verification of the data the data structure on the server and easier verification of the data
on client by means of existing DNS library functions.</t> on the client by means of existing DNS library functions.</t>
<t>The returned RRsets MUST contain either the TLSA RRset or else the <t>The returned RRsets <bcp14>MUST</bcp14> contain either the TLSA RRset or the
associated denial of existence proof of the configured (and requested) associated denial-of-existence proof of the configured (and requested)
SNI name and port. In either case, the chain of RRsets MUST be accompanied SNI name and port. In either case, the chain of RRsets <bcp14>MUST</bcp14> be ac
companied
by the full set of DNS records needed to authenticate the TLSA record set by the full set of DNS records needed to authenticate the TLSA record set
or its denial of existence up the DNS hierarchy to either the Root Zone or its denial of existence up the DNS hierarchy to either the root zone
or another trust anchor mutually configured by the TLS server and client.</t> or another trust anchor mutually configured by the TLS server and client.</t>
<t>When some subtree in the chain is subject to redirection via DNAME <t>When some subtree in the chain is subject to redirection via DNAME
records, the associated inferred CNAME records need not be included. records, the associated inferred CNAME records need not be included.
They can be inferred by the DNS validation code in the client. Any They can be inferred by the DNS validation code in the client. Any
applicable ordinary CNAME records that are not synthesized from DNAME applicable ordinary CNAME records that are not synthesized from DNAME
records MUST be included along with their RRSIGs.</t> records <bcp14>MUST</bcp14> be included along with their RRSIGs.</t>
<t>In case of a server-side DNS problem, servers may be unable to construct <t>In case of a server-side DNS problem, servers may be unable to construct
the authentication chain and would then have no choice but to omit the the authentication chain and would then have no choice but to omit the
extension.</t> extension.</t>
<t>In the case of a denial of existence response, the authentication <t>In the case of a denial-of-existence response, the authentication
chain MUST include all DNSSEC signed records from the trust-anchor chain <bcp14>MUST</bcp14> include all DNSSEC-signed records, starting with those
zone to a proof of either the non-existence of the (possibly redirected from the trust anchor zone, that chain together to reach a proof of either:</t>
via aliases) TLSA records or else of an insecure delegation above or <ul empty="false">
at the (possibly redirected) owner name of the requested TLSA RRset.</t> <li>the nonexistence of the TLSA records (possibly redirected
via aliases) or</li><li>an insecure delegation above or
at the (possibly redirected) owner name of the requested TLSA RRset.</li></ul>
<t>Names that are aliased via CNAME and/or DNAME records may involve <t>Names that are aliased via CNAME and/or DNAME records may involve
multiple branches of the DNS tree. In this case, the authentication multiple branches of the DNS tree. In this case, the authentication
chain structure needs to include DS and DNSKEY record sets that cover chain structure needs to include DS and DNSKEY record sets that cover
all the necessary branches.</t> all the necessary branches.</t>
<t>The returned chain SHOULD also include the DNSKEY RRSets of all relevant <t>The returned chain <bcp14>SHOULD</bcp14> also include the DNSKEY RRsets of al l relevant
trust anchors (typically just the root DNS zone). Though the same trust trust anchors (typically just the root DNS zone). Though the same trust
anchors are presumably also preconfigured in the TLS client, including anchors are presumably also preconfigured in the TLS client, including
them in the response from the server permits TLS clients to use the them in the response from the server permits TLS clients to use the
automated trust anchor rollover mechanism defined in <xref target="RFC5011"></xr ef> to automated trust anchor rollover mechanism defined in <xref target="RFC5011"></xr ef> to
update their configured trust anchors.</t> update their configured trust anchors.</t>
<t>Barring prior knowledge of particular trust anchors that the server <t>Barring prior knowledge of particular trust anchors that the server
shares with its clients, the chain constructed by the server MUST be shares with its clients, the chain constructed by the server <bcp14>MUST</bcp14>
extended as close as possible to the root zone. Truncation of the chain be
extended as closely as possible to the root zone. Truncation of the chain
at some intermediate trust anchor is generally only appropriate inside at some intermediate trust anchor is generally only appropriate inside
private networks where all clients and the server are expected to be private networks where all clients and the server are expected to be
configured with DNS trust anchors for one or more non-root domains.</t> configured with DNS trust anchors for one or more non-root domains.</t>
<t>The following is an example of the records in the AuthenticationChain <t>The following is an example of the records in the AuthenticationChain
structure for the HTTPS server at <tt>www.example.com</tt>, where there are structure for the HTTPS server at <tt>www.example.com</tt>, where there are
zone cuts at <tt>com.</tt> and <tt>example.com.</tt> (record data are omitted he re zone cuts at <tt>com</tt> and <tt>example.com</tt> (record data are omitted here
for brevity):</t> for brevity):</t>
<artwork>_443._tcp.www.example.com. TLSA <sourcecode type="dns-rr">_443._tcp.www.example.com. TLSA
RRSIG(_443._tcp.www.example.com. TLSA) RRSIG(_443._tcp.www.example.com. TLSA)
example.com. DNSKEY example.com. DNSKEY
RRSIG(example.com. DNSKEY) RRSIG(example.com. DNSKEY)
example.com. DS example.com. DS
RRSIG(example.com. DS) RRSIG(example.com. DS)
com. DNSKEY com. DNSKEY
RRSIG(com. DNSKEY) RRSIG(com. DNSKEY)
com. DS com. DS
RRSIG(com. DS) RRSIG(com. DS)
. DNSKEY . DNSKEY
RRSIG(. DNSKEY) RRSIG(. DNSKEY)
</artwork> </sourcecode>
<t>The following is an example of denial of existence for a TLSA RRset <t>The following is an example of denial of existence for a TLSA RRset
at <tt>_443._tcp.www.example.com</tt>. The NSEC record in this example at <tt>_443._tcp.www.example.com</tt>. The NSEC record in this example
asserts the non-existence of both the requested RRset and any asserts the nonexistence of both the requested RRset and any
potentially relevant wildcard records.</t> potentially relevant wildcard records.</t>
<artwork>www.example.com. IN NSEC example.com. A NSEC RRSIG <sourcecode type="dns-rr">www.example.com. IN NSEC example.com. A NSEC RRSIG
RRSIG(www.example.com. NSEC) RRSIG(www.example.com. NSEC)
example.com. DNSKEY example.com. DNSKEY
RRSIG(example.com. DNSKEY) RRSIG(example.com. DNSKEY)
example.com. DS example.com. DS
RRSIG(example.com. DS) RRSIG(example.com. DS)
com. DNSKEY com. DNSKEY
RRSIG(com. DNSKEY) RRSIG(com. DNSKEY)
com. DS com. DS
RRSIG(com. DS) RRSIG(com. DS)
. DNSKEY . DNSKEY
RRSIG(. DNSKEY) RRSIG(. DNSKEY)
</artwork> </sourcecode>
<t>The following is an example of (hypothetical) insecure delegation of <t>The following is an example of (hypothetical) insecure delegation of
<tt>example.com</tt> from the <tt>.com</tt> zone. This example shows NSEC3 <xref <tt>example.com</tt> from the <tt>.com</tt> zone. This example shows NSEC3 recor
target="RFC5155"></xref> ds <xref target="RFC5155"></xref>
records with opt-out.</t> with opt-out.</t>
<artwork>; covers example.com <sourcecode type="dns-rr">; covers example.com
onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 - onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 -
onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG) onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)
RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3) RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3)
; covers *.com ; covers *.com
3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 - 3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 -
3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG) 3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG)
RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3) RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3)
; closest-encloser "com" ; closest-encloser "com"
ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 - ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 -
ck0pojmg874ljref7efn8430qvit8bsm.com ck0pojmg874ljref7efn8430qvit8bsm.com
NS SOA RRSIG DNSKEY NSEC3PARAM) NS SOA RRSIG DNSKEY NSEC3PARAM)
RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3) RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3)
com. DNSKEY com. DNSKEY
RRSIG(com. DNSKEY) RRSIG(com. DNSKEY)
com. DS com. DS
RRSIG(com. DS) RRSIG(com. DS)
. DNSKEY . DNSKEY
RRSIG(. DNSKEY) RRSIG(. DNSKEY)
</artwork> </sourcecode>
<section anchor="denial_of_existence"><name>Authenticated Denial of Existence</n ame> <section anchor="denial_of_existence"><name>Authenticated Denial of Existence</n ame>
<t>TLS servers that support this extension and respond to a request <t>TLS servers that support this extension and respond to a request
containing this extension that do not have a signed TLSA record for the containing this extension that do not have a signed TLSA record for the
configured (and requested) SNI name and port MUST instead return a DNSSEC configured (and requested) SNI name and port <bcp14>MUST</bcp14> instead return a DNSSEC
chain that provides authenticated denial of existence for the configured chain that provides authenticated denial of existence for the configured
SNI name and port. A TLS client receiving proof of authenticated denial SNI name and port. A TLS client receiving proof of authenticated denial
of existence MUST use an alternative method to verify the TLS server of existence <bcp14>MUST</bcp14> use an alternative method to verify the TLS ser ver
identity or close the connection. Such an alternative could be the identity or close the connection. Such an alternative could be the
classic PKIX model of preinstalled root CA's.</t> classic PKIX model of preinstalled root certificate authorities (CAs).</t>
<t>Authenticated denial chains include NSEC or NSEC3 records that <t>Authenticated denial chains include NSEC or NSEC3 records that
demonstrate one of the following facts:</t> demonstrate one of the following facts:</t>
<ul> <ul>
<li><t>The TLSA record (after any DNSSEC validated alias redirection) <li><t>The TLSA record (after any DNSSEC-validated alias redirection)
does not exist.</t> does not exist.</t>
</li> </li>
<li><t>There is no signed delegation to a DNS zone which is either an <li><t>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 ancestor of or the same as the TLSA record name (after any
DNSSEC validated alias redirection).</t> DNSSEC-validated alias redirection).</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="construction"><name>Construction of Serialized Authentication C hains</name> <section anchor="construction"><name>Construction of Serialized Authentication C hains</name>
<t>This section describes a possible procedure for the server to use to <t>This section describes a possible procedure for the server to use to
build the serialized DNSSEC chain.</t> build the serialized DNSSEC chain.</t>
<t>When the goal is to perform DANE authentication <xref target="RFC6698"></xref ><xref target="RFC7671"></xref> <t>When the goal is to perform DANE authentication <xref target="RFC6698"></xref > <xref target="RFC7671"></xref>
of the server, the DNS record set to be serialized is a TLSA record 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 set corresponding to the server's domain name, protocol, and port
number.</t> number.</t>
<t>The domain name of the server MUST be that included in the TLS
<t>The domain name of the server <bcp14>MUST</bcp14> be that included in the TLS
<tt>server_name</tt> (SNI) extension <xref target="RFC6066"></xref>. If the serv er <tt>server_name</tt> (SNI) extension <xref target="RFC6066"></xref>. If the serv er
does not recognize the SNI name as one if its own names, but wishes does not recognize the SNI name as one of its own names but wishes
to proceed with the handshake rather than to abort the connection, to proceed with the handshake rather than abort the connection,
the server MUST NOT send a <tt>dnssec_chain</tt> extension to the client.</t> the server <bcp14>MUST NOT</bcp14> send a <tt>dnssec_chain</tt> extension to the
<t>The name in client's SNI extension MUST NOT be CNAME-expanded by the client.</t>
server. The TLSA base domain (Section 3 of <xref target="RFC6698"></xref>) SHALL <t>The name in the client's SNI extension <bcp14>MUST NOT</bcp14> be CNAME expan
be the ded by the
hostname from the client's SNI extension and the guidance in Section server. The TLSA base domain (<xref target="RFC6698" sectionFormat="of" section=
7 of <xref target="RFC7671"></xref> does not apply. See <xref target="virtual"> "3"></xref>) <bcp14>SHALL</bcp14> be the
</xref> for further hostname from the client's SNI extension, and the guidance in <xref target="RFC7
671" sectionFormat="of" section="7"></xref> does not apply. See <xref target="v
irtual"></xref> for further
discussion.</t> discussion.</t>
<t>The TLSA record to be queried is constructed by prepending <t>The TLSA record to be queried is constructed by prepending
underscore-prefixed port number and transport name labels to the domain underscore-prefixed port number and transport name labels to the domain
name as described in <xref target="RFC6698"></xref>. The port number is taken f rom the name as described in <xref target="RFC6698"></xref>. The port number is taken f rom the
client's <tt>dnssec_chain</tt> extension. The transport name is "tcp" for TLS client's <tt>dnssec_chain</tt> extension. The transport name is "tcp" for TLS
servers, and "udp" for DTLS servers. The port number label is the servers and "udp" for DTLS servers. The port number label is the
left-most label, followed by the transport name label, followed by the leftmost label, followed by the transport name label, followed by the
server domain name (from SNI).</t> server domain name (from SNI).</t>
<t>The components of the authentication chain are typically built by <t>The components of the authentication chain are typically built by
starting at the target record set and its corresponding RRSIG. Then starting at the target record set and its corresponding RRSIG, then
traversing the DNS tree upwards towards the trust anchor zone traversing the DNS tree upwards towards the trust anchor zone
(normally the DNS root). For each zone cut, the DNSKEY and DS RRsets (normally the DNS root). For each zone cut, the DNSKEY, DS RRsets,
and their signatures are added. However, see <xref target="auth_chain_data"></xr ef> for and their signatures are added. However, see <xref target="auth_chain_data"></xr ef> for
specific processing needed for aliases. If DNS response messages specific processing needed for aliases. If DNS response messages
contain any domain names utilizing name compression <xref target="RFC1035"></xre f>, then contain any domain names utilizing name compression <xref target="RFC1035"></xre f>, then
they MUST be uncompressed prior to inclusion in the chain.</t> they <bcp14>MUST</bcp14> be uncompressed prior to inclusion in the chain.</t>
<t>Implementations of EDNS Chain Query Requests as specified in <t>Implementations of EDNS CHAIN query requests as specified in
<xref target="RFC7901"></xref> may offer an easier way to obtain all of the chai n data <xref target="RFC7901"></xref> may offer an easier way to obtain all of the chai n data
in one transaction with an upstream DNSSEC aware recursive server.</t> in one transaction with an upstream DNSSEC-aware recursive server.</t>
</section> </section>
<section anchor="sec_caching"><name>Caching and Regeneration of the Authenticati on Chain</name> <section anchor="sec_caching"><name>Caching and Regeneration of the Authenticati on Chain</name>
<t>DNS records have Time To Live (TTL) parameters, and DNSSEC signatures <t>DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
have validity periods (specifically signature expiration times). have validity periods (specifically signature expiration times).
After the TLS server constructs the serialized authentication chain, After the TLS server constructs the serialized authentication chain,
it SHOULD cache and reuse it in multiple TLS connection handshakes. it <bcp14>SHOULD</bcp14> cache and reuse it in multiple TLS connection handshake
However, it SHOULD refresh and rebuild the chain as TTL values require. s.
However, it <bcp14>SHOULD</bcp14> refresh and rebuild the chain as TTL values re
quire.
A server implementation could carefully track TTL parameters and requery A server implementation could carefully track TTL parameters and requery
component records in the chain correspondingly. Alternatively, it could component records in the chain correspondingly. Alternatively, it could
be configured to rebuild the entire chain at some predefined periodic be configured to rebuild the entire chain at some predefined periodic
interval that does not exceed the DNS TTLs of the component records in 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 (eg 0 up to a 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), the server <bcp14>MAY</bcp14> decide to serve the authentication c
hain a
few seconds past the minimum TTL in the chain. This allows an few seconds past the minimum TTL in the chain. This allows an
implementation to dedicate a process or single thread to building the implementation to dedicate a process or single thread to building the
authentication chain and re-use it for more than a single authentication chain and reuse it for more than a single
waiting TLS client before needing to rebuild the authentication chain.</t> waiting TLS client before needing to rebuild the authentication chain.</t>
</section> </section>
<section anchor="sec_caching_exp"><name>Expired signatures in the Authentication <section anchor="sec_caching_exp"><name>Expired Signatures in the Authentication
Chain</name> Chain</name>
<t>A server MAY look at the signature expiration of RRSIG records. While <t>A server <bcp14>MAY</bcp14> look at the signature expiration of RRSIG records
. While
these should never expire before the TTL of the corresponding DNS record these should never expire before the TTL of the corresponding DNS record
is reached, if this situation is encountered nevertheless, the server is reached, if this situation is nevertheless encountered, the server
MAY lower the TTL to prevent serving expired RRSIGs if possible. If the <bcp14>MAY</bcp14> lower the TTL to prevent serving expired RRSIGs if possible.
signatures are already expired, the server MUST still include these records If the
into the authentication chain. This allows the TLS client to either support signatures are already expired, the server <bcp14>MUST</bcp14> still include the
a grace period for staleness, or allows the TLS client to give a detailed se records
error, either as log message or to a potential interactive user of the TLS in the authentication chain.
connection. The TLS client SHOULD handle expired RRSIGs similar to how it
This allows the TLS client to either support a grace period for staleness or giv
e a detailed error, either as a log
message or a message to a potential interactive user of the TLS connection. T
he TLS client <bcp14>SHOULD</bcp14> handle expired RRSIGs similarly to how it
handles expired PKIX certificates.</t> handles expired PKIX certificates.</t>
</section> </section>
<section anchor="sec_verification"><name>Verification</name> <section anchor="sec_verification"><name>Verification</name>
<t>A TLS client performing DANE based verification might not need to use <t>A TLS client performing DANE-based verification might not need to use
this extension. For example, the TLS client could perform native DNS this extension. For example, the TLS client could perform DNS
lookups and perform DANE verification without this extension. Or it lookups and DANE verification without this extension, or it
could fetch authentication chains via another protocol. If the TLS could fetch authentication chains via another protocol.
client already possesses a valid TLSA record, it MAY omit using this
extension. However, if it includes this extension, it MUST use the If the TLS
client already possesses a valid TLSA record, it <bcp14>MAY</bcp14> bypass use o
f this
extension. However, if it includes this extension, it <bcp14>MUST</bcp14> use th
e
TLS server reply to update the extension pinning status of the TLS TLS server reply to update the extension pinning status of the TLS
server's extension lifetime. See <xref target="pinning"></xref>.</t> server's extension lifetime. See <xref target="pinning"></xref>.</t>
<t>A TLS client making use of this specification, and which receives a <t>A TLS client making use of this specification that receives a
valid DNSSEC authentication chain extension from a TLS server, MUST use valid DNSSEC authentication chain extension from a TLS server <bcp14>MUST</bcp14
> use
this information to perform DANE authentication of the TLS server. In this information to perform DANE authentication of the TLS server. In
order to perform the validation, it uses the mechanism specified by order to perform the validation, it uses the mechanism specified by
the DNSSEC protocol <xref target="RFC4035"></xref><xref target="RFC5155"></xref> . This mechanism is the DNSSEC protocol <xref target="RFC4035"></xref> <xref target="RFC5155"></xref >. This mechanism is
sometimes implemented in a DNSSEC validation engine or library.</t> sometimes implemented in a DNSSEC validation engine or library.</t>
<t>If the authentication chain validates, the TLS client then performs DANE <t>If the authentication chain validates, the TLS client then performs DANE
authentication of the server according to the DANE TLS protocol authentication of the server according to the DANE TLS protocol
<xref target="RFC6698"></xref><xref target="RFC7671"></xref>.</t> <xref target="RFC6698"></xref> <xref target="RFC7671"></xref>.</t>
<t>Clients MAY cache the server's validated TLSA RRset to amortize the <t>Clients <bcp14>MAY</bcp14> cache the server's validated TLSA RRset to amortiz
e the
cost of receiving and validating the chain over multiple connections. cost of receiving and validating the chain over multiple connections.
The period of such caching MUST NOT exceed the TTL associated with The period of such caching <bcp14>MUST NOT</bcp14> exceed the TTL associated wit h
those records. A client that possesses a validated and unexpired TLSA those records. A client that possesses a validated and unexpired TLSA
RRset or the full chain in its cache does not need to send the RRset or the full chain in its cache does not need to send the
<tt>dnssec_chain</tt> extension for subsequent connections to the same TLS <tt>dnssec_chain</tt> extension for subsequent connections to the same TLS
server. It can use the cached information to perform DANE server. It can use the cached information to perform DANE
authentication.</t> authentication.</t>
<t>Note that when a client and server perform TLS session resumption the <t>Note that when a client and server perform TLS session resumption, the
server sends no <tt>dnssec_chain</tt>. This is particularly clear with TLS server sends no <tt>dnssec_chain</tt>. This is particularly clear with TLS
1.3, where the certificate message to which the chain might be 1.3, where the certificate message to which the chain might be
attached is also not sent on resumption.</t> attached is also not sent on resumption.</t>
</section> </section>
<section anchor="pinning"><name>Extension Pinning</name> <section anchor="pinning"><name>Extension Pinning</name>
<t>TLS applications can be designed to unconditionally mandate this <t>TLS applications can be designed to unconditionally mandate this
extension. Such TLS clients requesting this extension would abort a extension. Such TLS clients requesting this extension would abort a
connection to a TLS server that does not respond with a validatable connection to a TLS server that does not respond with an
extension reply.</t> extension reply that can be validated.</t>
<t>However, in a mixed-use deployment of PKIX and DANE, there is the <t>However, in a mixed-use deployment of PKIX and DANE, there is the
possibility that the security of a TLS client is downgraded from DANE possibility that the security of a TLS client is downgraded from DANE
to PKIX. This can happen when a TLS client connection is to PKIX. This can happen when a TLS client connection is
intercepted and redirected to a rogue TLS server presenting a TLS intercepted and redirected to a rogue TLS server presenting a TLS
certificate that is considered valid from a PKIX point of view, but certificate that is considered valid from a PKIX point of view but
one that does not match the legitimate server's TLSA records. By does not match the legitimate server's TLSA records. By
omitting this extension, such a rogue TLS server could downgrade the omitting this extension, such a rogue TLS server could downgrade the
TLS client to validate the mis-issued certificate using only PKIX TLS client to validate the mis-issued certificate using only PKIX
and not via DANE, provided the TLS client is also not able to and not via DANE, provided the TLS client is also not able to
fetch the TLSA records directly from DNS.</t> fetch the TLSA records directly from DNS.</t>
<t>The ExtSupportLifetime element of the extension provides a <t>The ExtSupportLifetime element of the extension provides a
countermeasure against such downgrade attacks. Its value represents countermeasure against such downgrade attacks. Its value represents
the number of hours that the TLS server (or cluster of servers the number of hours that the TLS server (or cluster of servers
serving the same Server Name) commit to serving this extension in the serving the same server name) commits to serving this extension in the
future. This is referred to as the "pinning time" or "extension pin" future. This is referred to as the "pinning time" or "extension pin"
of the extension. A non-zero extension pin value received MUST ONLY of the extension. A non-zero extension pin value received <bcp14>MUST</bcp14> O NLY
be used if the extension also contains a valid TLSA authentication be used if the extension also contains a valid TLSA authentication
chain that matches the server's certificate chain (the server passes chain that matches the server's certificate chain (the server passes
DANE authentication based on the enclosed TLSA RRset).</t> DANE authentication based on the enclosed TLSA RRset).</t>
<t>Any existing extension pin for the server instance (name and port) <t>Any existing extension pin for the server instance (name and port)
MUST be cleared on receipt of a valid denial of existence for the <bcp14>MUST</bcp14> be cleared on receipt of a valid denial of existence for the
associated TLSA RRset. The same also applies if the client obtained associated TLSA RRset. The same also applies if the client obtained
the denial of existence proof via another method, such as through the denial-of-existence proof via another method, such as through
direct DNS queries. Based on the TLS client's local policy, it MAY direct DNS queries. Based on the TLS client's local policy, it <bcp14>MAY</bcp1
then terminate the connection or MAY continue using PKIX based 4>
then terminate the connection or <bcp14>MAY</bcp14> continue using PKIX-based
server authentication.</t> server authentication.</t>
<t>Extension pins MUST also be cleared upon the completion of a DANE <t>Extension pins <bcp14>MUST</bcp14> also be cleared upon the completion of a D
authenticated handshake with a server that returns a <tt>dnssec_chain</tt> ANE-authenticated handshake with a server that returns a <tt>dnssec_chain</tt>
extension with a zero ExtSupportLifetime.</t> extension with a zero ExtSupportLifetime.</t>
<t>Upon completion of a full validated handshake with a server that <t>Upon completion of a fully validated handshake with a server that
returns a <tt>dnssec_chain</tt> extension with a non-zero ExtSupport lifetime, returns a <tt>dnssec_chain</tt> extension with a non-zero ExtSupport lifetime,
the client MUST update any existing pin lifetime for the service the client <bcp14>MUST</bcp14> update any existing pin lifetime for the service
(name and port) to a value that is no longer than that indicated by (name and port) to a value that is not longer than that indicated by
the server. The client MAY, subject to local policy, create a the server. The client <bcp14>MAY</bcp14>, subject to local policy, create a
previously non-existent pin, again for a lifetime that is not longer previously nonexistent pin, again for a lifetime that is not longer
than that indicated by the server.</t> than that indicated by the server.</t>
<t>The extension support lifetime is not constrained by any DNS TTLs or <t>The extension support lifetime is not constrained by any DNS TTLs or
RRSIG expirations in the returned chain. The extension support lifetime RRSIG expirations in the returned chain. The extension support lifetime
is the time for which the TLS server is committing itself to serve the is the time for which the TLS server is committing itself to serve the
extension; it is not a validity time for the returned chain data. extension; it is not a validity time for the returned chain data.
During this period the DNSSEC chain may be updated. Therefore, the During this period, the DNSSEC chain may be updated. Therefore, the
ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG
expirations in the returned chain.</t> expirations in the returned chain.</t>
<t>Clients MAY implement support for a subset of DANE certificate <t>Clients <bcp14>MAY</bcp14> implement support for a subset of DANE certificate
usages. For example, clients may support only DANE-EE(3) and usages. For example, clients may support only DANE-EE(3) and
DANE-TA(2) <xref target="RFC7218"></xref>, only PKIX-EE(1) and PKIX-TA(0) DANE-TA(2) <xref target="RFC7218"></xref>, only PKIX-EE(1) and PKIX-TA(0),
or all four. Clients that implement DANE-EE(3) and DANE-TA(2) MUST or all four. Clients that implement DANE-EE(3) and DANE-TA(2) <bcp14>MUST</bcp1
4>
implement the relevant updates in <xref target="RFC7671"></xref>.</t> implement the relevant updates in <xref target="RFC7671"></xref>.</t>
<t>For a non-zero saved value ("pin") of the ExtSupportLifetime element of the <t>For a non-zero saved value ("pin") of the ExtSupportLifetime element of the
extension, TLS clients that do not have a cached TLSA RRset with an extension, TLS clients that do not have a cached TLSA RRset with an
unexpired TTL MUST use the extension for the associated name and unexpired TTL <bcp14>MUST</bcp14> use the extension for the associated name and
port to obtain this information from the TLS server. This TLS client port to obtain this information from the TLS server.
then MUST require that the TLS server responds with this extension
that MUST contain a valid TLSA RRset or proof of non-existence of the This TLS client
TLSA RRset that covers the requested name and port. Note that a non-existence then <bcp14>MUST</bcp14> require that the TLS server respond with this extension
proof or proof of insecure delegation will clear the pin. The TLS client MUST ,
which <bcp14>MUST</bcp14> contain a valid TLSA RRset or proof of nonexistence of
the
TLSA RRset that covers the requested name and port. Note that a nonexistence
proof or proof of insecure delegation will clear the pin. The TLS client <bcp14>
MUST</bcp14>
require this for as long as the time period specified by the pin value, require this for as long as the time period specified by the pin value,
independent of the DNS TTLs. If during this process, the TLS client fails independent of the DNS TTLs. During this process, if the TLS client fails
to receive this information, it MUST either abort the connection or delay to receive this information, it <bcp14>MUST</bcp14> either abort the connection
or delay
communication with the server via the TLS connection until it is able communication with the server via the TLS connection until it is able
to obtain valid TLSA records (or proof of non-existence) out of band, to obtain valid TLSA records (or proof of nonexistence) out of band,
such as via direct DNS lookups. If attempts to obtain the TLSA RRset such as via direct DNS lookups. If attempts to obtain the TLSA RRset
out of band fail, the client MUST abort the TLS connection. It MAY try out of band fail, the client <bcp14>MUST</bcp14> abort the TLS connection. It <b
a new TLS connection again, for example using an exponential back-off cp14>MAY</bcp14> try
timer, in an attempt to reach a different TLS server instance that does a new TLS connection again (for example, using an exponential back-off
timer) in an attempt to reach a different TLS server instance that does
properly serve the extension.</t> properly serve the extension.</t>
<t>A TLS client that has a cached validated TLSA RRset and a valid non-zero exte nsion <t>A TLS client that has a cached validated TLSA RRset and a valid non-zero exte nsion
pin time MAY still refrain from requesting the extension as long as it pin time <bcp14>MAY</bcp14> still refrain from requesting the extension as long as it
uses the cached TLSA RRset to authenticate the TLS server. This RRset uses the cached TLSA RRset to authenticate the TLS server. This RRset
MUST NOT be used beyond its received TTL. Once the TLSA RRset's <bcp14>MUST NOT</bcp14> be used beyond its received TTL. Once the TLSA RRset's
TTL has expired, the TLS client with a valid non-zero extension pin TTL has expired, the TLS client with a valid non-zero extension pin
time MUST request the extension and MUST abort the TLS connection if time <bcp14>MUST</bcp14> request the extension and <bcp14>MUST</bcp14> abort the
the server responds without the extension. A TLS client MAY attempt TLS connection if
the server responds without the extension. A TLS client <bcp14>MAY</bcp14> attem
pt
to obtain the valid TLSA RRset by some other means before to obtain the valid TLSA RRset by some other means before
initiating a new TLS connection.</t> initiating a new TLS connection.</t>
<t>Note that requiring the extension is NOT the same as requiring the <t>Note that requiring the extension is NOT the same as requiring the
use of DANE TLSA records or even DNSSEC. A DNS zone operator may at use of DANE TLSA records or even DNSSEC. A DNS zone operator may at
any time delete the TLSA records, or even remove the DS records to any time delete the TLSA records or even remove the DS records to
disable the secure delegation of the server's DNS zone. The TLS disable the secure delegation of the server's DNS zone. The TLS
server will, when it updates its cached TLSA authentication chain, server will replace the chain with the corresponding denial-of-existence chain w
replace the chain with the corresponding denial of existence chain. hen it updates its cached TLSA authentication chain.
The server's only obligation is continued support for this extension.</t> The server's only obligation is continued support for this extension.</t>
</section> </section>
<section anchor="sec_trustmaint"><name>Trust Anchor Maintenance</name> <section anchor="sec_trustmaint"><name>Trust Anchor Maintenance</name>
<t>The trust anchor may change periodically, e.g. when the operator of <t>The trust anchor may change periodically, e.g., when the operator of
the trust anchor zone performs a DNSSEC key rollover. TLS clients the trust anchor zone performs a DNSSEC key rollover. TLS clients
using this specification MUST implement a mechanism to keep their using this specification <bcp14>MUST</bcp14> implement a mechanism to keep their
trust anchors up to date. They could use the method defined in trust anchors up to date. They could use the method defined in
<xref target="RFC5011"></xref> to perform trust anchor updates inband in TLS, by tracking <xref target="RFC5011"></xref> to perform trust anchor updates in-band in TLS by tracking
the introduction of new keys seen in the trust anchor DNSKEY RRset. the introduction of new keys seen in the trust anchor DNSKEY RRset.
However, alternative mechanisms external to TLS may also be utilized. However, alternative mechanisms external to TLS may also be utilized.
Some operating systems may have a system-wide service to maintain and Some operating systems may have a system-wide service to maintain and
keep the root trust anchor up to date. In such cases, the TLS client keep the root trust anchor up to date. In such cases, the TLS client
application could simply reference that as its trust anchor, application could simply reference that as its trust anchor,
periodically checking whether it has changed. Some applications may periodically checking whether it has changed. Some applications may
prefer to implement trust anchor updates as part of their automated prefer to implement trust anchor updates as part of their automated
software updates.</t> software updates.</t>
</section> </section>
<section anchor="virtual"><name>Virtual Hosting</name> <section anchor="virtual"><name>Virtual Hosting</name>
<t>Delivery of application services is often provided by a third party <t>Delivery of application services is often provided by a third party
on behalf of the domain owner (hosting customer). Since the domain on behalf of the domain owner (hosting customer). Since the domain
owner may want to be able to move the service between providers, owner may want to be able to move the service between providers,
non-zero support lifetimes for this extension should only be enabled non-zero support lifetimes for this extension should only be enabled
by mutual agreement between the provider and domain owner.</t> by mutual agreement between the provider and domain owner.</t>
<t>When CNAME records are employed to redirect network connections to <t>When CNAME records are employed to redirect network connections to
the provider's network, as mentioned in <xref target="construction"></xref> the server the provider's network, as mentioned in <xref target="construction"></xref>, the server
uses the client's SNI hostname as the TLSA base domain without CNAME uses the client's SNI hostname as the TLSA base domain without CNAME
expansion. When the certificate chain for the service is managed by expansion. When the certificate chain for the service is managed by
the provider, it is impractical to coordinate certificate changes by the provider, it is impractical to coordinate certificate changes by
the provider with updates in the hosting customer's DNS. Therefore, the provider with updates in the hosting customer's DNS. Therefore,
the TLSA RRset for the hosted domain is best configured as a CNAME the TLSA RRset for the hosted domain is best configured as a CNAME
from the customer's domain to a TLSA RRset that is managed by the from the customer's domain to a TLSA RRset that is managed by the
provider as part of delivering the hosted service. For example:</t> provider as part of delivering the hosted service. For example:</t>
<artwork>; Customer DNS <sourcecode type="dns-rr">; Customer DNS
www.example.com. IN CNAME node1.provider.example. www.example.com. IN CNAME node1.provider.example.
_443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example. _443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example.
; Provider DNS ; Provider DNS
node1.provider.example. IN A 192.0.2.1 node1.provider.example. IN A 192.0.2.1
_dane443.node1.provider.example. IN TLSA 1 1 1 ... _dane443.node1.provider.example. IN TLSA 1 1 1 ...
</artwork> </sourcecode>
<t>Clients that obtain TLSA records directly from DNS, bypassing this <t>Clients that obtain TLSA records directly from DNS, bypassing this
extension, may however perform CNAME-expansion as in Section 7 of extension, may perform CNAME expansion as in <xref target="RFC7671" sectionForma
<xref target="RFC7671"></xref>, and if TLSA records are associated with the t="of" section="7"></xref>. If TLSA records are associated with the
fully-expanded name, may use that name as the TLSA base domain and fully expanded name, that name may be used as the TLSA base domain and
SNI name for the TLS handshake.</t> SNI name for the TLS handshake.</t>
<t>To avoid confusion, it is RECOMMENDED that server operators not <t>To avoid confusion, it is <bcp14>RECOMMENDED</bcp14> that server operators no t
publish TLSA RRs (_port._tcp. + base domain) based on the expanded publish TLSA RRs (_port._tcp. + base domain) based on the expanded
CNAMEs used to locate their network addresses. Instead, the server CNAMEs used to locate their network addresses. Instead, the server
operator SHOULD publish TLSA RRs at an alternative DNS node (as in operator <bcp14>SHOULD</bcp14> publish TLSA RRs at an alternative DNS node (as i n
the example above), to which the hosting customer will publish a the example above), to which the hosting customer will publish a
CNAME alias. This results in all clients (whether they obtain TLSA CNAME alias. This results in all clients (whether they obtain TLSA
records from DNS directly, or employ this extension) seeing the same records from DNS directly or employ this extension) seeing the same
TLSA records and sending the same SNI name.</t> TLSA records and sending the same SNI name.</t>
</section> </section>
<section anchor="operational-considerations"><name>Operational Considerations</n ame> <section anchor="operational-considerations"><name>Operational Considerations</n ame>
<t>When DANE is being introduced incrementally into an existing PKIX <t>When DANE is being introduced incrementally into an existing PKIX
environment, there may be scenarios in which DANE authentication for environment, there may be scenarios in which DANE authentication for
a server fails but PKIX succeeds, or vice versa. What happens here a server fails but PKIX succeeds, or vice versa. What happens here
depends on TLS client policy. If DANE authentication fails, the depends on TLS client policy. If DANE authentication fails, the
client may decide to fall back to traditional PKIX authentication. In client may decide to fall back to regular PKIX authentication. In
order to do so efficiently within the same TLS handshake, the TLS order to do so efficiently within the same TLS handshake, the TLS
server needs to have provided the full X.509 certificate chain. When server needs to have provided the full X.509 certificate chain. When
TLS servers only support DANE-EE or DANE-TA modes, they have the TLS servers only support DANE-EE or DANE-TA modes, they have the
option to send a much smaller certificate chain: just the EE option to send a much smaller certificate chain: just the EE
certificate for the former, and a short certificate chain from the certificate for the former and a short certificate chain from the
DANE trust anchor to the EE certificate for the latter. If the TLS DANE trust anchor to the EE certificate for the latter. If the TLS
server supports both DANE and traditional PKIX, and wants to allow server supports both DANE and regular PKIX and wants to allow
efficient PKIX fallback within the same handshake, they should always efficient PKIX fallback within the same handshake, they should always
provide the full X.509 certificate chain.</t> provide the full X.509 certificate chain.</t>
<t>When a TLS server operator wishes to no longer deploy this extension, <t>When a TLS server operator wishes to no longer deploy this extension,
it must properly decommission its use. If a non-zero pin lifetime is it must properly decommission its use. If a non-zero pin lifetime is
presently advertised, it must first be changed to 0. The extension presently advertised, it must first be changed to 0. The extension
can be disabled once all previously advertised pin lifetimes have can be disabled once all previously advertised pin lifetimes have
expired. Removal of TLSA records or even DNSSEC signing of the zone expired. Removal of TLSA records or even DNSSEC signing of the zone
can be done at any time, but the server MUST still be able to return can be done at any time, but the server <bcp14>MUST</bcp14> still be able to ret
the associated denial of existence proofs to any clients that have urn
the associated denial-of-existence proofs to any clients that have
unexpired pins.</t> unexpired pins.</t>
<t>TLS clients MAY reduce the received extension pin value to a maximum <t>TLS clients <bcp14>MAY</bcp14> reduce the received extension pin value to a m aximum
set by local policy. This can mitigate a theoretical yet unlikely set by local policy. This can mitigate a theoretical yet unlikely
attack where a compromised TLS server is modified to advertise a pin attack where a compromised TLS server is modified to advertise a pin
value set to the maximum of 7 years. Care should be taken not to set value set to the maximum of 7 years. Care should be taken not to set
a local maximum that is too short as that would reduce the downgrade a local maximum that is too short as that would reduce the downgrade
attack protection that the extension pin offers.</t> attack protection that the extension pin offers.</t>
<t>If the hosting provider intends to use end-entity TLSA records <t>If the hosting provider intends to use end-entity TLSA records
(certificate usage PKIX-EE(1) or DANE-EE(3)) then the simplest (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 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 given hosting node and publish "1 1 1" or "3 1 1" RRs matching the
common public key. Since key rollover cannot be simultaneous across common public key. Since key rollover cannot be simultaneous across
multiple certificate updates, there will be times when multiple "1 1 multiple certificate updates, there will be times when multiple "1 1
1" (or "3 1 1") records will be required to match all the extant 1" (or "3 1 1") records will be required to match all the extant
certificates. Multiple TLSA records are in any case needed a few certificates. Multiple TLSA records are, in any case, needed a few
TTLs before certificate updates as explained in Section 8 of TTLs before certificate updates as explained in <xref target="RFC7671" sectionFo
<xref target="RFC7671"></xref>.</t> rmat="of" section="8"></xref>.</t>
<t>If the hosting provider intends to use trust-anchor TLSA records <t>If the hosting provider intends to use trust anchor TLSA records
(certificate usage PKIX-TA(0) or DANE-TA(2)) then the same TLSA (certificate usage PKIX-TA(0) or DANE-TA(2)), then the same TLSA
record can match all end-entity certificates issues by the record can match all end-entity certificates issues by the
certification authority in question, and continues to work across certification authority in question and continues to work across
end-entity certificate updates, so long as the issuer certificate or end-entity certificate updates so long as the issuer certificate or
public keys remains unchanged. This can be easier to implement, at public keys remain unchanged. This can be easier to implement at
the cost of greater reliance on the security of the selected the cost of greater reliance on the security of the selected
certification authority.</t> certification authority.</t>
<t>The provider can of course publish separate TLSA records for each <t>The provider can, of course, publish separate TLSA records for each
customer, which increases the number of such RRsets that need to be customer, which increases the number of such RRsets that need to be
managed, but makes each one independent of the rest.</t> managed but makes each one independent of the rest.</t>
</section> </section>
<section anchor="security-considerations"><name>Security Considerations</name> <section anchor="security-considerations"><name>Security Considerations</name>
<t>The security considerations of the normatively referenced RFCs all <t>The security considerations of the normatively referenced RFCs all
pertain to this extension. Since the server is delivering a chain of 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 DNS records and signatures to the client, it <bcp14>MUST</bcp14> rebuild the cha in in
accordance with TTL and signature expiration of the chain components accordance with TTL and signature expiration of the chain components
as described in <xref target="sec_caching"></xref>. TLS clients need roughly ac curate as described in <xref target="sec_caching"></xref>. TLS clients need roughly ac curate
time in order to properly authenticate these signatures. This could be time in order to properly authenticate these signatures. This could be
achieved by running a time synchronization protocol like NTP <xref target="RFC59 05"></xref> achieved by running a time synchronization protocol like NTP <xref target="RFC59 05"></xref>
or SNTP <xref target="RFC5905"></xref>, which are already widely used today. TLS clients or SNTP <xref target="RFC5905"></xref>, which are already widely used today. TLS clients
MUST support a mechanism to track and roll over the trust anchor key, <bcp14>MUST</bcp14> 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 or be able to avail themselves of a service that does this, as described
in <xref target="sec_trustmaint"></xref>. Security considerations related to ma ndating the in <xref target="sec_trustmaint"></xref>. Security considerations related to ma ndating the
use of this extension are described in <xref target="pinning"></xref>.</t> use of this extension are described in <xref target="pinning"></xref>.</t>
<t>The received DNSSEC chain could contain DNS RRs that are not related <t>The received DNSSEC chain could contain DNS RRs that are not related
to the TLSA verification of the intended DNS name. If such a unrelated to the TLSA verification of the intended DNS name. If such an unrelated
RR is not DNSSEC signed, it MUST be disgarded. If the unrelated RRset RR is not DNSSEC signed, it <bcp14>MUST</bcp14> be discarded. If the unrelated R
is DNSSEC signed, the TLS client MAY decide to add these RRsets and Rset
their DNSSEC signatures to its cache. It MAY even pass this data to the is DNSSEC signed, the TLS client <bcp14>MAY</bcp14> decide to add these RRsets a
local system resolver for caching outside the application. However, care nd
must be taken that caching these records could be used for timing and their DNSSEC signatures to its cache. It <bcp14>MAY</bcp14> 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 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, that wants to present the strongest anonymity protection to their users
MUST refrain from using and caching all unrelated RRs.</t> <bcp14>MUST</bcp14> refrain from using and caching all unrelated RRs.</t>
</section> </section>
<section anchor="iana_requests"><name>IANA Considerations</name> <section anchor="iana_requests"><name>IANA Considerations</name>
<t>This document defines one new entry in the TLS ExtensionType Values <t>IANA has made the following assignment in the "TLS ExtensionType Values"
registry:</t> registry:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="right">Value</th> <th align="right">Value</th>
<th>Extension Name</th> <th>Extension Name</th>
<th>TLS 1.3</th> <th>TLS 1.3</th>
<th>Recommended</th> <th>Recommended</th>
<th>Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="right">TBD</td> <td align="right">59</td>
<td>dnssec_chain</td> <td>dnssec_chain</td>
<td>CH</td> <td>CH</td>
<td>No</td> <td>No</td>
<td>[this document]</td> <td>RFC 9102</td>
</tr> </tr>
</tbody> </tbody>
</table></section> </table></section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>Many thanks to Adam Langley for laying the groundwork for this
extension in <xref target="I-D.agl-dane-serializechain"></xref>. The original id
ea is his
but our acknowledgment in no way implies his endorsement. This
document also benefited from discussions with and review from the
following people: Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin,
Patrick McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri
Visweswaran, Duane Wessels, Nico Williams, and Richard Barnes.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.agl-dane-serializechain" to="SERIALIZECHAIN"/>
<displayreference target="I-D.barnes-dane-uks" to="DANE-UKS"/>
<displayreference target="I-D.ietf-dnsop-svcb-https" to="DNSOP-SVCB-HTTPS"/>
<references><name>References</name>
<references><name>Normative References</name> <references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7218. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7218. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7671. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7671. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446. xml"/>
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.a
gl-dane-serializechain.xml"/> <!-- [I-D.agl-dane-serializechain] IESG state Expired -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.b
arnes-dane-uks.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.agl-dan
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i e-serializechain.xml"/>
etf-dnsop-svcb-https.xml"/>
<reference anchor="NLNETLABS" target="https://www.nlnetlabs.nl/downloads/publica <!-- [I-D.barnes-dane-uks] IESG state Expired -->
tions/os3-2015-rp2-xavier-torrent-gorjon.pdf"> <reference anchor='I-D.barnes-dane-uks'>
<front>
<title>Unknown Key-Share Attacks on DNS-Based Authentications of Named Entities
(DANE)</title>
<author initials='R' surname='Barnes' fullname='Richard Barnes'>
<organization />
</author>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='October' day='9' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-barnes-dane-uks-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-barnes-dane-uks-00.txt
' />
</reference>
<!-- [I-D.ietf-dnsop-svcb-https] IESG state I-D Exists -->
<reference anchor='I-D.ietf-dnsop-svcb-https'>
<front>
<title>Service Binding and Parameter Specification via the DNS (DNS SVCB and HTT
PS RRs)</title>
<author initials='B' surname='Schwartz' fullname='Benjamin Schwartz'>
<organization />
</author>
<author initials='M' surname='Bishop' fullname='Mike Bishop'>
<organization />
</author>
<author initials='E' surname='Nygren' fullname='Erik Nygren'>
<organization />
</author>
<date year='2021' month='June' day='16' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-svcb-https-06'/>
<format type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-dnsop
-svcb-https-06.txt'/>
</reference>
<reference anchor="DISCOVERY" target="https://www.nlnetlabs.nl/downloads/publica
tions/os3-2015-rp2-xavier-torrent-gorjon.pdf">
<front> <front>
<title>Discovery method for a DNSSEC validating stub resolver</title> <title>Discovery method for a DNSSEC validating stub resolver</title>
<author fullname="Xavier Torrent Gorjon" initials="X." surname="Gorjon"></au thor> <author fullname="Xavier Torrent Gorjon" initials="X." surname="Gorjon"></au thor>
<author fullname="Willem Toorop" initials="W." surname="Toorop"></author> <author fullname="Willem Toorop" initials="W." surname="Toorop"></author>
<date year="2015" month="July" day="14"></date> <date year="2015" month="July" day="14"></date>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7901. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7901. xml"/>
</references> </references>
</references>
<section anchor="test-vectors"><name>Test Vectors</name> <section anchor="test-vectors"><name>Test Vectors</name>
<t>The test vectors in this appendix are representations of the content <t>The test vectors in this appendix are representations of the content
of the "opaque AuthenticationChain" field in DNS presentation format. of the "opaque AuthenticationChain" field in DNS presentation format and, except
And except for the <tt>extension_data</tt> in <xref target="hex_dump"></xref>, d for the <tt>extension_data</tt> in <xref target="hex_dump"></xref>, do not cont
o not contain ain
the "uint16 ExtSupportLifetime" field.</t> the "uint16 ExtSupportLifetime" field.</t>
<t>For brevity and reproducibility all DNS zones involved with the test <t>For brevity and reproducibility, all DNS zones involved with the test
vectors are signed using keys with algorithm 13: ECDSA Curve P-256 vectors are signed using keys with algorithm 13 (ECDSA Curve P-256
with SHA-256.</t> with SHA-256).</t>
<t>To reflect operational practice, different zones in the examples are <t>To reflect operational practice, different zones in the examples are
in different phases of rolling their signing keys:</t> in different phases of rolling their signing keys:</t>
<ul> <ul>
<li><t>All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), <li><t>All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK),
except for the example.com and example.net zones which use a except for the <tt>example.com</tt> and <tt>example.net</tt> zones, which use a
Combined Signing Key (CSK).</t> Combined Signing Key (CSK).</t>
</li> </li>
<li><t>The root and org zones are rolling their ZSK's.</t> <li><t>The root and org zones are rolling their ZSKs.</t>
</li> </li>
<li><t>The com and org zones are rolling their KSK's.</t> <li><t>The com and org zones are rolling their KSKs.</t>
</li> </li>
</ul> </ul>
<t>The test vectors are DNSSEC valid in the same period as the <t>The test vectors are DNSSEC valid in the same period as the
certificate is valid, which is in between November 28, 2018 and certificate is valid, which is between November 28, 2018 and
December 2, 2020 and with the following root trust anchor:</t> December 2, 2020 with the following root trust anchor:</t>
<artwork>. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 <sourcecode type="dns-rr">. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613 de3052e37861634
641bb568746f2ffc4d4 ) 641bb568746f2ffc4d4 )
</artwork> </sourcecode>
<t>The test vectors will authenticate the certificate used with <t>The test vectors will authenticate the certificate used with
<eref target="https://example.com/">https://example.com/</eref>, <eref target="h ttps://example.net/">https://example.net/</eref> and <eref target="https://examp le.org/">https://example.org/</eref> <tt>https://example.com/</tt>, <tt>https://example.net/</tt>, and <tt>https://ex ample.org/</tt>
at the time of writing:</t> at the time of writing:</t>
<artwork>-----BEGIN CERTIFICATE----- <sourcecode>-----BEGIN CERTIFICATE-----
MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTgxMTI4MDAwMDAwWhcN
MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju MjAxMjAyMTIwMDAwWjCBpTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3Ju
aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw aWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw
b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxEzARBgNVBAsT
ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI ClRlY2hub2xvZ3kxGDAWBgNVBAMTD3d3dy5leGFtcGxlLm9yZzCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV hvcNAQEBBQADggEPADCCAQoCggEBANDwEnSgliByCGUZElpdStA6jGaPoCkrp9vV
rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g rAzPpXGSFUIVsAeSdjF11yeOTVBqddF7U14nqu3rpGA68o5FGGtFM1yFEaogEv5g
rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80 rJ1MRY/d0w4+dw8JwoVlNMci+3QTuUKf9yH28JxEdG3J37Mfj2C3cREGkGNBnY80
skipping to change at line 810 skipping to change at line 866
l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC l0QlCzzqzvorGXyB/yd7nttYttzo8EpOAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkC
wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z wQApBo2yCJo32RMAAAFnXDGWnAAABAMARzBFAiEA5Hn7Q4SOyqHkT+kDsHq7ku7z
RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM RDuM7P4UDX2ft2Mpny0CIE13WtxJAUr0aASFYZ/XjSAMMfrB0/RxClvWVss9LHKM
MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R MA0GCSqGSIb3DQEBCwUAA4IBAQBzcIXvQEGnakPVeJx7VUjmvGuZhrr7DQOLeP4R
8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM 8CmgDM1pFAvGBHiyzvCH1QGdxFl6cf7wbp7BoLCRLR/qPVXFMwUMzcE1GLBqaGZM
v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu v1Yh2lvZSLmMNSGRXdx113pGLCInpm/TOhfrvr0TxRImc8BdozWJavsn1N2qdHQu
N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa N+UBO6bQMLCD0KHEdSGFsuX6ZwAworxTg02/1qiDu7zW7RyzHvFYA4IAjpzvkPIa
X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I X6KjBtpdvp/aXabmL95YgBjT8WJ7pqOfrqhpcmOBZa6Cg6O1l4qbIFH/Gj9hQB5I
0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN 0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN
-----END CERTIFICATE----- -----END CERTIFICATE-----
</artwork> </sourcecode>
<section anchor="tv-straight"><name>_443._tcp.www.example.com</name> <section anchor="tv-straight"><name><tt>_443._tcp.www.example.com</tt></name>
<artwork>_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 <sourcecode type="dns-rr">_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 ) 922 )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20201202000000 20181128000000 1870 example.com. 20201202000000 20181128000000 1870 example.com.
rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
z2BhaswpGLVVuoijuVdzxYjmw== ) z2BhaswpGLVVuoijuVdzxYjmw== )
example.com. 3600 IN DNSKEY ( 257 3 13 example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
skipping to change at line 872 skipping to change at line 928
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
<t>A hex dump of the <tt>extension_data</tt> of the server's <tt>dnssec_chain</t t> <t>A hex dump of the <tt>extension_data</tt> of the server's <tt>dnssec_chain</t t>
extension represention this with an ExtSupportLifetime value of 0 is:</t> extension representation of this with an ExtSupportLifetime value of 0 is:</t>
<artwork anchor="hex_dump">0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 <sourcecode anchor="hex_dump">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 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 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 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 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 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 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 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 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 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 00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35
skipping to change at line 974 skipping to change at line 1031
0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad 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 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 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 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 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 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 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 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 0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f
0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be 0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-wildcard-nsec"><name>_25._tcp.example.com NSEC wildcard</nam e> <section anchor="tv-wildcard-nsec"><name><tt>_25._tcp.example.com</tt> NSEC Wild card</name>
<artwork>_25._tcp.example.com. 3600 IN TLSA ( 3 1 1 <sourcecode type="dns-rr">_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 ) 922 )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600 _25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 1870 example.com. 20201202000000 20181128000000 1870 example.com.
BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2 BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2
rfL4DFP8rO3VMgI0v+ogrox0w== ) rfL4DFP8rO3VMgI0v+ogrox0w== )
*._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG *._tcp.example.com. 3600 IN NSEC ( smtp.example.com. RRSIG
NSEC TLSA ) NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 *._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20201202000000 20181128000000 1870 example.com. 20201202000000 20181128000000 1870 example.com.
skipping to change at line 1043 skipping to change at line 1100
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-wildcard-nsec3"><name>_25._tcp.example.org NSEC3 wildcard</n ame> <section anchor="tv-wildcard-nsec3"><name><tt>_25._tcp.example.org</tt> NSEC3 Wi ldcard</name>
<artwork>_25._tcp.example.org. 3600 IN TLSA ( 3 1 1 <sourcecode type="dns-rr">_25._tcp.example.org. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 ) 922 )
_25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 _25._tcp.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 56566 example.org. 20201202000000 20181128000000 56566 example.org.
lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL
cYzJ7vCvqb9gFCiCJjK2gAamw== ) cYzJ7vCvqb9gFCiCJjK2gAamw== )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 (
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566 NSEC3 13 3 3600 20201202000000 20181128000000 56566
skipping to change at line 1119 skipping to change at line 1176
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-cname"><name>_443._tcp.www.example.org CNAME</name> <section anchor="tv-cname"><name><tt>_443._tcp.www.example.org</tt> CNAME</name>
<artwork>_443._tcp.www.example.org. 3600 IN CNAME ( <sourcecode type="dns-rr">_443._tcp.www.example.org. 3600 IN CNAME (
dane311.example.org. ) dane311.example.org. )
_443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600 _443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600
20201202000000 20181128000000 56566 example.org. 20201202000000 20181128000000 56566 example.org.
R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx
Qb/a90O696120NsYaZX2+ebBA== ) Qb/a90O696120NsYaZX2+ebBA== )
dane311.example.org. 3600 IN TLSA ( 3 1 1 dane311.example.org. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 ) 922 )
dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600 dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20201202000000 20181128000000 56566 example.org. 20201202000000 20181128000000 56566 example.org.
skipping to change at line 1194 skipping to change at line 1251
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-dname"><name>_443._tcp.www.example.net DNAME</name> <section anchor="tv-dname"><name><tt>_443._tcp.www.example.net</tt> DNAME</name>
<artwork>example.net. 3600 IN DNAME example.com. <sourcecode type="dns-rr">example.net. 3600 IN DNAME example.com.
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000 example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20201202000000
20181128000000 48085 example.net. 20181128000000 48085 example.net.
o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx
OI/pDnjJcLSd/gBLtqR52WLMA== ) OI/pDnjJcLSd/gBLtqR52WLMA== )
; _443._tcp.www.example.net. 3600 IN CNAME ( ; _443._tcp.www.example.net. 3600 IN CNAME (
; _443._tcp.www.example.com. ) ; _443._tcp.www.example.com. )
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1 _443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b 8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
922 ) 922 )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600 _443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
skipping to change at line 1293 skipping to change at line 1350
sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
mDXqz6KEhhQjT+aQWDt6WFHlA== ) mDXqz6KEhhQjT+aQWDt6WFHlA== )
com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202 com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
f9eabb94487e658c188e7bcb52115 ) f9eabb94487e658c188e7bcb52115 )
com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e com. 86400 IN DS ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
70643bbde681db342a9e5cf2bb380 ) 70643bbde681db342a9e5cf2bb380 )
com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000
20181128000000 31918 . 20181128000000 31918 .
nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
vBKTf6pk8JRCqnfzlo2QY+WXA== ) vBKTf6pk8JRCqnfzlo2QY+WXA== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-denial-nsec"><name>_25._tcp.smtp.example.com NSEC Denial of Existence</name> <section anchor="tv-denial-nsec"><name><tt>_25._tcp.smtp.example.com</tt> NSEC D enial of Existence</name>
<artwork>smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA <sourcecode type="dns-rr">smtp.example.com. 3600 IN NSEC ( www.example.com. A AAAA
RRSIG NSEC ) RRSIG NSEC )
smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600 smtp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20201202000000 20181128000000 1870 example.com. 20201202000000 20181128000000 1870 example.com.
rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf
crlsQZmnAUlfmBNCygxAd7JNw== ) crlsQZmnAUlfmBNCygxAd7JNw== )
example.com. 3600 IN DNSKEY ( 257 3 13 example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870 /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20201202000000 20181128000000 1870 example.com. 20201202000000 20181128000000 1870 example.com.
skipping to change at line 1355 skipping to change at line 1412
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-denial-nsec3"><name>_25._tcp.smtp.example.org NSEC3 Denial o f Existence</name> <section anchor="tv-denial-nsec3"><name><tt>_25._tcp.smtp.example.org</tt> NSEC3 Denial of Existence</name>
<artwork>vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN NSEC3 ( <sourcecode type="dns-rr">vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 I N NSEC3 (
1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG ) 1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG )
vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG ( vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566 NSEC3 13 3 3600 20201202000000 20181128000000 56566
example.org. example.org.
wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh
gQeV5KgP1cdvPt1BEowKqK4Sw== ) gQeV5KgP1cdvPt1BEowKqK4Sw== )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 ( dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN NSEC3 (
1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA ) 1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG ( dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org. 3600 IN RRSIG (
NSEC3 13 3 3600 20201202000000 20181128000000 56566 NSEC3 13 3 3600 20201202000000 20181128000000 56566
skipping to change at line 1438 skipping to change at line 1495
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
<section anchor="tv-insecure-nsec3-optout"><name>_443._tcp.www.insecure.example NSEC3 opt-out insecure delegation</name> <section anchor="tv-insecure-nsec3-optout"><name><tt>_443._tcp.www.insecure.exam ple</tt> NSEC3 Opt-Out Insecure Delegation</name>
<artwork>c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 ( <sourcecode type="dns-rr">c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN NSEC3 (
1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY 1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY
NSEC3PARAM ) NSEC3PARAM )
c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG ( c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example. 43200 IN RRSIG (
NSEC3 13 2 43200 20201202000000 20181128000000 15903 NSEC3 13 2 43200 20201202000000 20181128000000 15903
example. example.
pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg
RpXUsJhZBDax2dfDhK7zOk7ow== ) RpXUsJhZBDax2dfDhK7zOk7ow== )
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 ( shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN NSEC3 (
1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG ) 1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG )
shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG ( shn05itmoa45mmnv74lc4p0nnfmimtjt.example. 43200 IN RRSIG (
skipping to change at line 1484 skipping to change at line 1541
. 86400 IN DNSKEY ( 256 3 13 . 86400 IN DNSKEY ( 256 3 13
8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW 8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635 xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
. 86400 IN DNSKEY ( 257 3 13 . 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005 Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000
20181128000000 47005 . 20181128000000 47005 .
0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m 0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
nBT1dtNjIczvLG9pQTnOKUsHQ== ) nBT1dtNjIczvLG9pQTnOKUsHQ== )
</artwork> </sourcecode>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="false"><name>Acknowledgments</name>
<t>Many thanks to <contact fullname="Adam Langley"/> for laying the groundwork f
or this
extension in <xref target="I-D.agl-dane-serializechain"></xref>. The original id
ea is his,
but our acknowledgment in no way implies his endorsement. This
document also benefited from discussions with and review from the
following people: <contact fullname="Daniel Kahn Gillmor"/>, <contact fullname
="Jeff Hodges"/>, <contact fullname="Allison Mankin"/>,
<contact fullname="Patrick McManus"/>, <contact fullname="Rick van Rein"/>, <
contact fullname="Ilari Liusvaara"/>, <contact fullname="Eric Rescorla"/>, <co
ntact fullname="Gowri Visweswaran"/>, <contact fullname="Duane Wessels"/>, <co
ntact fullname="Nico Williams"/>, and <contact fullname="Richard Barnes"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 178 change blocks. 
327 lines changed or deleted 446 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/