draft-ietf-tls-dnssec-chain-extension-03.txt   draft-ietf-tls-dnssec-chain-extension-04.txt 
TLS M. Shore TLS M. Shore
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: September 28, 2017 Mozilla Expires: December 3, 2017 Mozilla
S. Huque S. Huque
Salesforce Salesforce
W. Toorop W. Toorop
NLNet Labs NLNet Labs
March 27, 2017 June 1, 2017
A DANE Record and DNSSEC Authentication Chain Extension for TLS A DANE Record and DNSSEC Authentication Chain Extension for TLS
draft-ietf-tls-dnssec-chain-extension-03 draft-ietf-tls-dnssec-chain-extension-04
Abstract Abstract
This draft describes a new TLS extension for transport of a DNS This draft describes a new TLS extension for transport of a DNS
record set serialized with the DNSSEC signatures needed to record set serialized with the DNSSEC signatures needed to
authenticate that record set. The intent of this proposal is to authenticate that record set. The intent of this proposal is to
allow TLS clients to perform DANE authentication of a TLS server allow TLS clients to perform DANE authentication of a TLS server
certificate without needing to perform additional DNS record lookups. without needing to perform additional DNS record lookups. It will
It will typically not be used for general DNSSEC validation of TLS typically not be used for general DNSSEC validation of TLS endpoint
endpoint names. names.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017. This Internet-Draft will expire on December 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 4
3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4
3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4
3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5
4. Construction of Serialized Authentication Chains . . . . . . 8 4. Construction of Serialized Authentication Chains . . . . . . 7
5. Caching and Regeneration of the Authentication Chain . . . . 9 5. Caching and Regeneration of the Authentication Chain . . . . 8
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 10 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9
8. Mandating use of this extension . . . . . . . . . . . . . . . 10 8. Mandating use of this extension . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 14 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 13
Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 14 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13
Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 14 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13
Appendix D. Test vector . . . . . . . . . . . . . . . . . . . . 14 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 15
D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 17
D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 19
D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This draft describes a new TLS [RFC5246] extension for transport of a This draft describes a new TLS [RFC5246] extension for transport of a
DNS record set serialized with the DNSSEC signatures [RFC4034] needed DNS record set serialized with the DNSSEC signatures [RFC4034] needed
to authenticate that record set. The intent of this proposal is to to authenticate that record set. The intent of this proposal is to
allow TLS clients to perform DANE authentication [RFC6698] of a TLS allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671]
server certificate without performing additional DNS record lookups of a TLS server without performing additional DNS record lookups and
and incurring the associated latency penalty. It also provides the incurring the associated latency penalty. It also provides the
ability to avoid potential problems with TLS clients being unable to ability to avoid potential problems with TLS clients being unable to
look up DANE records because of an interfering or broken middlebox on look up DANE records because of an interfering or broken middlebox on
the path between the client and a DNS server. And lastly, it allows the path between the client and a DNS server. And lastly, it allows
a TLS client to validate DANE records itself without necessarily a TLS client to validate DANE records itself without necessarily
needing access to a validating DNS resolver to which it has a secure needing access to a validating DNS resolver to which it has a secure
connection. It will typically not be used for general DNSSEC connection. It will typically not be used for general DNSSEC
validation of endpoint names, but is more appropriate for validation validation of endpoint names, but is more appropriate for validation
of DANE TLSA records. of DANE TLSA records.
This mechanism is useful for TLS applications that need to address This mechanism is useful for TLS applications that need to address
the problems described above, typically web browsers or VoIP and XMPP the problems described above, typically web browsers or VoIP and XMPP
applications. It may not be relevant for many other applications. applications. It may not be relevant for many other applications.
For example, SMTP MTAs are usually located in data centers, may For example, SMTP MTAs are usually located in data centers, may
tolerate extra DNS lookup latency, are on servers where it is easier tolerate extra DNS lookup latency, are on servers where it is easier
to provision a validating resolver, or are less likely to experience to provision a validating resolver, or are less likely to experience
traffic interference from misconfigured middleboxes. Furthermore, traffic interference from misconfigured middleboxes. Furthermore,
SMTP MTAs usually employ Opportunistic Security [RFC7435], in which SMTP MTAs usually employ Opportunistic Security [RFC7672], in which
the presence of the DNS TLSA records is used to determine whether to the presence of the DNS TLSA records is used to determine whether to
enforce an authenticated TLS connection. Hence DANE authentication enforce an authenticated TLS connection. Hence DANE authentication
of SMTP MTAs [RFC7672] will typically not use this mechanism. of SMTP MTAs will typically not use this mechanism.
The extension described here allows a TLS client to request in the The extension described here allows a TLS client to request in the
ClientHello message that the DNS authentication chain be returned in ClientHello message that the DNS authentication chain be returned in
the (extended) ServerHello message. If the server is configured for the (extended) ServerHello message. If the server is configured for
DANE authentication, then it performs the appropriate DNS queries, DANE authentication, then it performs the appropriate DNS queries,
builds the authentication chain, and returns it to the client. The builds the authentication chain, and returns it to the client. The
server will usually use a previously cached authentication chain, but server will usually use a previously cached authentication chain, but
it will need to rebuild it periodically as described in Section 5. it will need to rebuild it periodically as described in Section 5.
The client then authenticates the chain using a pre-configured trust The client then authenticates the chain using a pre-configured trust
anchor. anchor.
This specification is based on Adam Langley's original proposal for This specification is based on Adam Langley's original proposal for
serializing DNSSEC authentication chains and delivering them in an serializing DNSSEC authentication chains and delivering them in an
X.509 certificate extension [I-D.agl-dane-serializechain]. It X.509 certificate extension [I-D.agl-dane-serializechain]. It
modifies the approach by using wire format DNS records in the modifies the approach by using wire format DNS records in the
serialized data (assuming that the data will be prepared and consumed serialized data (assuming that the data will be prepared and consumed
by a DNS-specific library), and by using a TLS extension to deliver by a DNS-specific library), and by using a TLS extension to deliver
the data. the data.
As described in the DANE specification [RFC6698], this procuedure As described in the DANE specification [RFC6698] [RFC7671], this
applies to the DANE authentication of X.509 certificates. Other procedure applies to the DANE authentication of X.509 certificates or
credentials may be supported, as needed, in the future. raw public keys [RFC7250].
3. DNSSEC Authentication Chain Extension 3. DNSSEC Authentication Chain Extension
3.1. Protocol, TLS 1.2 3.1. Protocol, TLS 1.2
A client MAY include an extension of type "dnssec_chain" in the A client MAY include an extension of type "dnssec_chain" in the
(extended) ClientHello. The "extension_data" field of this extension (extended) ClientHello. The "extension_data" field of this extension
MUST be empty. MUST be empty.
Servers receiving a "dnssec_chain" extension in the ClientHello, and Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, MAY return a which are capable of being authenticated via DANE, MAY return a
serialized authentication chain in the extended ServerHello message, serialized authentication chain in the extended ServerHello message,
using the format described below. If a server is unable to return an using the format described below. If a server is unable to return an
skipping to change at page 5, line 43 skipping to change at page 5, line 49
3.4. DNSSEC Authentication Chain Data 3.4. DNSSEC Authentication Chain Data
The "extension_data" field of the "dnssec_chain" extension MUST The "extension_data" field of the "dnssec_chain" extension MUST
contain a DNSSEC Authentication Chain encoded in the following form: contain a DNSSEC Authentication Chain encoded in the following form:
opaque AuthenticationChain<0..2^16-1> opaque AuthenticationChain<0..2^16-1>
The AuthenticationChain structure is composed of a sequence of The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRsig) records. The record sets and corresponding signatures (RRSIG) records.
signatures are presented in the order returned by the DNS server
queried by the TLS server, although they MAY be returned in
validation order, starting at the target DANE record, followed by the
DNSKEY and DS record sets for each intervening DNS zone up to a trust
anchor chosen by the server, typically the DNS root.
This sequence of native DNS wire format records enables easier This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library verification of the data on client by means of existing DNS library
functions. However this document describes the data structure in functions. However this document describes the data structure in
sufficient detail that implementers if they desire can write their sufficient detail that implementers if they desire can write their
own code to do this. own code to do this.
Each RRset in the chain is composed of a sequence of wire format DNS Each RRset in the chain is composed of a sequence of wire format DNS
resource records. The format of the resource record is described in resource records. The format of the resource record is described in
RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be
presented in the canonical form and ordering as described in RFC 4034 presented in the canonical form and ordering as described in RFC 4034
[RFC4034]. [RFC4034].
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
RRs within the RRset MAY be ordered canonically, by treating the RRs within the RRset MAY be ordered canonically, by treating the
RDATA portion of each RR as a left-justified unsigned octet sequence RDATA portion of each RR as a left-justified unsigned octet sequence
in which the absence of an octet sorts before a zero octet. in which the absence of an octet sorts before a zero octet.
The RRsig record is in DNS wire format as described in RFC 4034 Each RRset in the sequence is followed by its associated RRsig
[RFC4034], Section 3.1. The signature portion of the RDATA, as record. The RRsig record is in DNS wire format as described in RFC
4034 [RFC4034], Section 3.1. The signature portion of the RDATA, as
described in the same section, is the following: described in the same section, is the following:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with
the Signer's Name field in canonical form and the signature field the Signer's Name field in canonical form and the signature field
excluded. excluded.
The first RRset in the chain MUST contain the DANE records being The first RRset in the chain MUST contain the TLSA record set being
presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS presented. However, if the owner name of the TLSA record set is an
RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate alias (CNAME or DNAME), then it MUST be preceded by the chain of
the preceding RRset: alias records needed to resolve it. DNAME chains should omit
unsigned CNAME records that may have been synthesized in the response
from a DNS resolver.
o A DNSKEY RRset must include the DNSKEY RR containing the public The subsequent RRsets MUST contain the full set of DNS records needed
key used to verify the previous RRset. to authenticate the TLSA record set from the server's trust anchor.
Typically this means a set of DNSKEY and DS RRsets that cover all
zones from the target zone containing the TLSA record set to the
trust anchor zone. The TLS client should be prepared to receive this
set of RRsets in any order.
o For a DS RRset, the set of key hashes MUST overlap with the Names that are aliased via CNAME and/or DNAME records may involve
preceding set of DNSKEY records. multiple branches of the DNS tree. In this case, the authentication
chain structure needs to include DS and DNSKEY record sets that cover
all the necessary branches.
In addition, a DNSKEY RRset followed by a DS RRset MUST be self- If the TLSA record set was synthesized by a DNS wildcard, the chain
signed, in the sense that its RRSIG MUST verify under one of the keys must include the signed NSEC or NSEC3 records that prove that there
in the DNSKEY RRSET. was no explicit match of the TLSA record name and no closer wildcard
match.
The final DNSKEY RRset in the authentication chain, containing the The final DNSKEY RRset in the authentication chain corresponds to the
trust anchor may be omitted. If omitted, the client MUST verify that trust anchor (typically the DNS root). This trust anchor is also
the key tag and owner name in the final RRSIG record correspond to a preconfigured in the TLS client, but including it in the response
trust anchor. There may however be reason to include the trust from the server permits TLS clients to use the automated trust anchor
anchor RRset and signature if clients are expected to use RFC5011 rollover mechanism defined in RFC 5011 [RFC5011] to update their
compliant key rollover functions inband via the chain data. In that configured trust anchor.
case, they will need to periodically inspect flags (revocation and
secure entry point flags) on the trust anchor DNSKEY RRset.
For example, for an HTTPS server at www.example.com, where there are The following is an example of the records in the AuthenticationChain
zone cuts at "com." and "example.com.", the AuthenticationChain structure for the HTTPS server at www.example.com, where there are
structure would comprise the following RRsets and signatures (the zone cuts at "com." and "example.com." (record data are omitted here
data field of the records are omitted here for brevity): for brevity):
_443._tcp.www.example.com. TLSA _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)
Names that are aliased via CNAME and/or DNAME records may involve
multiple branches of the DNS tree. In this case the authentication
chain structure will be composed of a sequence of these multiple
intersecting branches. DNAME chains should omit unsigned CNAME
records that may have been synthesized in the response from a DNS
resolver. Wildcard DANE records will need to include the wildcard
name, and negative proof (i.e. NSEC or NSEC3 records) that no closer
name exists MUST be included.
A CNAME example:
_443._tcp.www.example.com. IN CNAME ca.example.net.
ca.example.net. IN TLSA 2 0 1 ...
Here the authentication chain structure is composed of two
consecutive chains, one for _443._tcp.www.example.com/CNAME
and one for ca.example.net/TLSA. The second chain can omit
the record sets at the end that overlap with the first.
TLS DNSSEC chain components:
_443._tcp.www.example.com. CNAME
RRSIG(_443._tcp.www.example.com. CNAME)
example.com. DNSKEY
RRSIG(example.com. DNSKEY)
example.com. DS
RRSIG(example.com. DS)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)
ca.example.net. TLSA
RRSIG(ca.example.net. TLSA)
example.net. DNSKEY
RRSIG(example.net. DNSKEY)
example.net. DS
RRSIG(example.net. DS)
net. DNSKEY
RRSIG(net. DNSKEY)
net. DS
RRSIG(net. DS)
Note as well that if a user has a specific TLSA record for port 443,
and a different wildcard covering other ports, attackers MUST NOT be
able to substitute the wildcard TLSA RRset for the more specific one
for port 443. DNSSEC wildcards must not be confused with the X.509
wildcards.
4. Construction of Serialized Authentication Chains 4. Construction of Serialized Authentication Chains
This section describes a possible procedure for the server to use to This section describes a possible procedure for the server to use to
build the serialized DNSSEC chain. build the serialized DNSSEC chain.
When the goal is to perform DANE authentication [RFC6698] of the When the goal is to perform DANE authentication [RFC6698] [RFC7671]
server's X.509 certificate, the DNS record set to be serialized is a of the server, the DNS record set to be serialized is a TLSA record
TLSA record set corresponding to the server's domain name. set corresponding to the server's domain name, protocol, and port
number.
The domain name of the server MUST be that included in the TLS The domain name of the server MUST be that included in the TLS
server_name extension [RFC6066] when present. If the server_name server_name extension [RFC6066] when present. If the server_name
extension is not present, or if the server does not recognize the extension is not present, or if the server does not recognize the
provided name and wishes to proceed with the handshake rather than to provided name and wishes to proceed with the handshake rather than to
abort the connection, the server uses the domain name associated with abort the connection, the server uses the domain name associated with
the server IP address to which the connection has been established. the server IP address to which the connection has been established.
The TLSA record to be queried is constructed by prepending the _port The TLSA record to be queried is constructed by prepending the _port
and _transport labels to the domain name as described in [RFC6698], and _transport labels to the domain name as described in [RFC6698],
where "port" is the port number associated with the TLS server. The where "port" is the port number associated with the TLS server. The
transport is "tcp" for TLS servers, and "udp" for DTLS servers. The transport is "tcp" for TLS servers, and "udp" for DTLS servers. The
port number label is the left-most label, followed by the transport, port number label is the left-most label, followed by the transport,
followed by the base domain name. followed by the base domain name.
The components of the authentication chain are built by starting at The components of the authentication chain are typically built by
the target record set and its corresponding RRSIG. Then traversing starting at the target record set and its corresponding RRSIG. Then
the DNS tree upwards towards the trust anchor zone (normally the DNS traversing the DNS tree upwards towards the trust anchor zone
root), for each zone cut, the DNSKEY and DS RRsets and their (normally the DNS root), for each zone cut, the DNSKEY and DS RRsets
signatures are added. If DNS responses messages contain any domain and their signatures are added. However, see Section 3.4 for
names utilizing name compression [RFC1035], then they must be specific processing needed for aliases and wildcards. If DNS
uncompressed. responses messages contain any domain names utilizing name
compression [RFC1035], then they must be uncompressed.
In the future, proposed DNS protocol enhancements, such as the EDNS Newer DNS protocol enhancements, such as the EDNS Chain Query
Chain Query extension [RFC7901] may offer easy ways to obtain all of extension [RFC7901] if supported, may offer easier ways to obtain all
the chain data in one transaction with an upstream DNSSEC aware of the chain data in one transaction with an upstream DNSSEC aware
recursive server. recursive server.
5. Caching and Regeneration of the Authentication Chain 5. Caching and Regeneration of the Authentication Chain
DNS records have Time To Live (TTL) parameters, and DNSSEC signatures 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 SHOULD cache and reuse it in multiple TLS connection handshakes.
However, it MUST refresh and rebuild the chain as TTLs and signature However, it MUST refresh and rebuild the chain as TTLs and signature
validity periods dictate. A server implementation could carefully validity periods dictate. A server implementation could carefully
track these parameters and requery component records in the chain track these parameters and requery component records in the chain
correspondingly. Alternatively, it could be configured to rebuild correspondingly. Alternatively, it could be configured to rebuild
the entire chain at some predefined periodic interval that does not the entire chain at some predefined periodic interval that does not
exceed the DNS TTLs or signature validity periods of the component exceed the DNS TTLs or signature validity periods of the component
records in the chain. records in the chain.
6. Verification 6. Verification
A TLS client making use of this specification, and which receives a A TLS client making use of this specification, and which receives a
DNSSEC authentication chain extension from a server, SHOULD use this DNSSEC authentication chain extension from a server, SHOULD use this
information to perform DANE authentication of the server certificate. information to perform DANE authentication of the server. In order
In order to do this, it uses the mechanism specified by the DNSSEC to do this, it uses the mechanism specified by the DNSSEC protocol
protocol [RFC4035]. This mechanism is sometimes implemented in a [RFC4035]. This mechanism is sometimes implemented in a DNSSEC
DNSSEC validation engine or library. validation engine or library.
If the authentication chain is correctly verified, the client then If the authentication chain is correctly verified, the client then
performs DANE authentication of the server according to the DANE TLS performs DANE authentication of the server according to the DANE TLS
protocol [RFC6698], and the additional protocol requirements outlined protocol [RFC6698] [RFC7671].
in [RFC7671].
7. Trust Anchor Maintenance 7. Trust Anchor Maintenance
The trust anchor may change periodically, e.g. when the operator of The trust anchor may change periodically, e.g. when the operator of
the trust anchor zone performs a DNSSEC key rollover. Managed key the trust anchor zone performs a DNSSEC key rollover. TLS clients
rollovers typically use a process that can be tracked by verifiers using this specification MUST implement a mechanism to keep their
allowing them to automatically update their trust anchors, as trust anchors up to date. They could use the method defined in
described in [RFC5011]. TLS clients using this specification are [RFC5011] to perform trust anchor updates inband in TLS, by tracking
also expected to use such a mechanism to keep their trust anchors the introduction of new keys seen in the trust anchor DNSKEY RRset.
updated. Some operating systems may have a system-wide service to However, alternative mechanisms external to TLS may also be utilized.
maintain and keep the root trust anchor up to date. In such cases, Some operating systems may have a system-wide service to maintain and
the TLS client application could simply reference that as its trust keep the root trust anchor up to date. In such cases, the TLS client
anchor, periodically checking whether it has changed. application could simply reference that as its trust anchor,
periodically checking whether it has changed. Some applications may
prefer to implement trust anchor updates as part of their automated
software updates.
8. Mandating use of this extension 8. Mandating use of this extension
A TLS server certificate MAY mandate the use of this extension by A TLS server certificate MAY mandate the use of this extension by
means of the X.509 TLS Feature Extension described in [RFC7633]. means of the X.509 TLS Feature Extension described in [RFC7633].
This X.509 certificate extension, when populated with the This X.509 certificate extension, when populated with the
dnssec_chain TLS extension identifier, indicates to the client that dnssec_chain TLS extension identifier, indicates to the client that
the server must deliver the authentication chain when asked to do so. the server must deliver the authentication chain when asked to do so.
(The X.509 TLS Feature Extension is the same mechanism used to (The X.509 TLS Feature Extension is the same mechanism used to
deliver other mandatory signals, such as OCSP "must staple" deliver other mandatory signals, such as OCSP "must staple"
assertions.) assertions.) Mandating this extension for Raw Public Key
authentication (where there are no X.509 certificates) could employ
configuration mechanisms external to the TLS protocol.
9. Security Considerations 9. Security Considerations
The security considerations of the normatively referenced RFCs (1035, The security considerations of the normatively referenced RFCs (1035,
4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this
extension. Since the server is delivering a chain of DNS records and extension. Since the server is delivering a chain of DNS records and
signatures to the client, it MUST rebuild the chain in accordance signatures to the client, it MUST rebuild the chain in accordance
with TTL and signature expiration of the chain components as with TTL and signature expiration of the chain components as
described in Section 5. TLS clients need roughly accurate time in described in Section 5. TLS clients need roughly accurate time in
order to properly authenticate these signatures. This could be order to properly authenticate these signatures. This could be
skipping to change at page 12, line 50 skipping to change at page 11, line 45
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>. 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
DOI 10.17487/RFC7901, June 2016, DOI 10.17487/RFC7901, June 2016,
<http://www.rfc-editor.org/info/rfc7901>. <http://www.rfc-editor.org/info/rfc7901>.
skipping to change at page 14, line 33 skipping to change at page 13, line 33
o Warning about not overloading X.509 wildcards on DNSSEC wildcards o Warning about not overloading X.509 wildcards on DNSSEC wildcards
(from V. Dukhovny) (from V. Dukhovny)
o Added MUST include negative proof on wildcards (from V. Dukhovny) o Added MUST include negative proof on wildcards (from V. Dukhovny)
o Removed "TODO" on allowing the server to deliver only one o Removed "TODO" on allowing the server to deliver only one
signature per RRset signature per RRset
o Added additional minor edits suggested by Viktor Dukhovny o Added additional minor edits suggested by Viktor Dukhovny
Appendix D. Test vector Appendix D. Test vectors
[data go here] The provided test vectors will authenticate the certificate used with
https://example.com/, https://example.net/ and https://example.org/
at the time of writing:
-----BEGIN CERTIFICATE-----
MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa
MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML
TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB
c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY
MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u
Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo
D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V
RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3
jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a
z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw
FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW
5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t
ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh
bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f
BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy
dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt
aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG
AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB
gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q
6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP
PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy
ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI
l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS
wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII=
-----END CERTIFICATE-----
For brevity and reproducability all DNS zones involved with the test
vectors are signed using a single key with algorithm 13: ECDSA Curve
P-256 with SHA-256.
The test vectors are DNSSEC valid at June 1 2017, with the following
root trust anchor:
. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
641bb568746f2ffc4d4 )
D.1. _443._tcp.www.example.com
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20170616000000 20170526000000 1870 example.com.
GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft
Kd8NsZJAikRr4CpaXITYQMx1w== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 1870 example.com.
sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r
8q6DBlCdlRQvzD90UKZDIAqbA== )
example.com. 900 IN DS ( 1870 13 2
e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81
e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000
20170529000000 18931 com.
rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3
5XxvbOdLIJAcxhRS1c2VITfMA== )
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000
20170529000000 18931 com.
wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk
c6Nx3HLmhidf6dmt/Hi0ePBsQ== )
com. 86400 IN DS ( 18931 13 2
20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52
115 )
com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+
jGGQccnLkQnUf7zednetSWalg== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
A hex dump of the wire format data of this content is:
0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65
0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00
0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78
0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a
0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74
0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63
0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d
0070: 05 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 07
0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 7b be 85 af
0090: 63 08 fd be 6e eb 68 df 85 c2 58 e6 41 37 2f 68
00a0: 34 4f 4f ce 91 9c 4c b0 54 bb e5 31 cd 57 0c 57
00b0: cf 10 ce 33 13 29 7a b4 81 d9 10 d0 cf f3 32 c8
00c0: 24 e8 06 12 59 8c 58 c5 15 6e ae e1 07 65 78 61
00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e
00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe
00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8
0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9
0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e
0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03
0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30
0140: 0d 02 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e
0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 db ce bb
0160: 5f 1c 4b f0 4e de 1e 36 f0 00 75 ae 79 f1 4e 7b
0170: 42 3b ff dc c0 04 b8 3c 5f 3a e7 ac a7 0c 47 0a
0180: a5 3d 70 95 28 d5 c9 65 5c 6f 7c ad 25 1e d2 77
0190: 00 2c 0a 9f f7 e9 19 a6 04 e9 cb 09 60 07 65 78
01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00
01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90
01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3
01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65
01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00
01f0: 2b 0d 02 00 00 03 84 59 34 9f 00 59 2b 64 80 49
0200: f3 03 63 6f 6d 00 18 f3 6d 66 92 89 48 73 26 3a
0210: cd 1e 35 38 a3 97 07 1b ed de d6 14 db 16 f0 f5
0220: 62 27 20 c5 eb fa 66 ac a4 a7 8e 93 33 ca 62 42
0230: 91 7a 51 b5 15 3a 83 14 3a 80 a5 f2 b6 80 00 e5
0240: 6b 92 ba 37 ec 2d 03 63 6f 6d 00 00 30 00 01 00
0250: 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b ef 7a 5d
0260: 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77 a0 42 34
0270: a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7 3c d3 d4
0280: c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64 33 70 f1
0290: 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d 00 00 2e
02a0: 00 01 00 00 03 84 00 57 00 30 0d 01 00 00 03 84
02b0: 59 34 9f 00 59 2b 64 80 49 f3 03 63 6f 6d 00 8d
02c0: 21 46 95 a5 17 ab 10 0a 49 dd 25 d3 6b 7d 88 ab
02d0: 2b 18 c9 53 da f2 76 fd a5 82 b8 ea 14 cb 7c 25
02e0: 4a 36 4a f0 48 9b e6 a3 0d aa 5b 98 15 8e 64 12
02f0: bb 1b 6e 45 3f 03 00 88 3d 48 b7 0f 78 53 2b 03
0300: 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3
0310: 0d 02 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01
0320: 59 41 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5
0330: 21 15 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00
0340: 53 00 2b 0d 01 00 01 51 80 59 3d d9 80 59 2c b6
0350: 00 b7 9d 00 33 56 6b d8 e2 80 50 7a e6 cf 68 27
0360: bb 22 5c a7 aa 41 f1 36 94 1c ae 94 9c 3f da 98
0370: c5 0f 56 b8 26 c7 57 44 05 a3 a5 11 ef d9 77 b3
0380: 49 a9 50 8d 99 76 98 78 8e 4b 30 a8 70 51 63 09
0390: a2 b6 14 05 00 00 30 00 01 00 01 51 80 00 44 01
03a0: 01 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3
03b0: ad 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c
03c0: 42 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25
03d0: bd 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8
03e0: 63 ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30
03f0: 0d 00 00 01 51 80 59 3d d9 80 59 2c b6 00 b7 9d
0400: 00 2b 43 e5 99 de 8d bd e6 e1 f0 05 2d 16 a1 7a
0410: 79 15 42 da 47 da 2f 63 0e 46 ab 7d e3 7e 9b 8a
0420: 7d 25 e2 3f 18 bf 85 4c 17 b7 d5 3c 06 c8 18 bb
0430: bd 98 44 11 72 e3 18 bc 9d 99 88 e5 00 91 58 c8
0440: 47
D.2. _25._tcp.example.com wildcard
_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20170616000000 20170526000000 1870 example.com.
dVxm88Spko03MB4pLo+zijMup2nr1Ii65yPqB/cAR/1Zg41iXer7I2sGh9KfT
ExLJC6dUMDVFUfm+1rwb+ax8Q== )
*._tcp.example.com. 3600 IN NSEC (
_443._tcp.www.example.com. RRSIG NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20170616000000 20170526000000 1870 example.com.
1lNaYYQ+FAG8YBVEx/026OGhVw5DjAyqBGrrLN9D12IZuLHtTQ4C9QPORP4na
GWNPgASvLyNR8MoN0oXV7tbnQ== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 1870 example.com.
sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r
8q6DBlCdlRQvzD90UKZDIAqbA== )
example.com. 900 IN DS ( 1870 13 2
e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81
e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000
20170529000000 18931 com.
rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3
5XxvbOdLIJAcxhRS1c2VITfMA== )
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000
20170529000000 18931 com.
wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk
c6Nx3HLmhidf6dmt/Hi0ePBsQ== )
com. 86400 IN DS ( 18931 13 2
20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52
115 )
com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+
jGGQccnLkQnUf7zednetSWalg== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
D.3. _443._tcp.www.example.org CNAME
_443._tcp.www.example.org. 3600 IN CNAME (
dane311.example.org. )
_443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600
20170616000000 20170526000000 44384 example.org.
DN+UMxh5TWL1u6Mc6ScWMU5R9C+qqIOSH4hqQmiPWhvSg0lFd71g43UqtdmBT
VRUbhk/f9WC8Fy5D0gE5lUcyA== )
dane311.example.org. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20170616000000 20170526000000 44384 example.org.
HJx59dAMQgvJSYBYtixzfodup5KRUzJ1SlRUrFJkGZz6PkpfuFdtpZwPN1vw9
SyvXq7WqRD46aaCMwR4ApUJ+w== )
example.org. 3600 IN DNSKEY ( 257 3 13
uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 44384 example.org.
MPTpfbVvPBXmh2Z4fgjy2GMgcJ8RYpXeOBOBidJDglLh4XQAiFOT6YpGRR5ig
tQGINd6gKVYdRSsEtXe1K8zxg== )
example.org. 900 IN DS ( 44384 13 2
ec307e2efc8f0117ed96ab48a513c8003e1d9121f1ff11a08b4cdd348d090
aa6 )
example.org. 900 IN RRSIG ( DS 13 2 900 20170615000000
20170525000000 12651 org.
MA3pxiap702Hvc81diwZDcRzLrkKssVzzTqCiJJoZFeNq40GuCOVGgEc+w6aq
SVgkgFJrhJISei/kvIZTx8ftw== )
org. 900 IN DNSKEY ( 257 3 13
0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
org. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000
20170525000000 12651 org.
o4L9nBQo8KXF0a7D5268U+Bq8SuW/aePtyuSfvQvP79nN/mzh9P11CsT/opmW
kg0u6pqaG9KE1T37jloes8J8w== )
org. 86400 IN DS ( 12651 13 2
3979a51f98bbf219fcaf4a4176e766dfa8f9db5c24a75743eb1e704b97a9f
abc )
org. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
Mi1c7QrpHnl1MSLJTrq/WM0V0DQKwFPGaMFmHHwm8Yb/b934CUHMXU0dR+cLT
hakZNz37edtwPxKKOzZQ6pYUw== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
D.4. _443._tcp.www.example.net DNAME
example.net. 3600 IN DNAME example.com.
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20170616000000
20170526000000 48085 example.net.
sTl9oxvpd7KxOZ9e5suevha7Fr+zPc3a0pWEUfjFE5v9Umu5js/vcp1i6hdqy
tQ2WXEQDsHeEjw9stupvMJkkg== )
_443._tcp.www.example.net. 3600 IN CNAME (
_443._tcp.www.example.com. )
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20170616000000 20170526000000 1870 example.com.
GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft
Kd8NsZJAikRr4CpaXITYQMx1w== )
example.net. 3600 IN DNSKEY ( 257 3 13
X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d
9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085
example.net. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 48085 example.net.
8jSs5O3AypurKs8JFoAYj30qlmQ9QS29IBoqbyv2ggxtdDZoKWZE0kOuQcRxx
q1pP707qRjp98THQSTVh+C0iQ== )
example.net. 900 IN DS ( 48085 13 2
7c1998ce683df60e2fa41460c453f88f463dac8cd5d074277b4a7c0450292
1be )
example.net. 900 IN RRSIG ( DS 13 2 900 20170615000000
20170525000000 485 net.
xqN9gHO5HXB+GH2x3DvjpMl6f+CdsVvON2K7G0FDVIL5iFMNLPqCAITlFofWF
Ty6VXFKPoy9TZresE/JCL/PFA== )
net. 900 IN DNSKEY ( 257 3 13
LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5
oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485
net. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000
20170525000000 485 net.
jEI8WucG9EzJ1Euv0Pq3aNFhoYbvQeLUs19r9YImkWi8QlmH76ZJuLTCGHTDh
/Il5cZWukKc3ScptxVA57uRyQ== )
net. 86400 IN DS ( 485 13 2
ab25a2941aa7f1eb8688bb783b25587515a0cd8c247769b23adb13ca234d1
c05 )
net. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
ZR/UTP2OrYwJQhsCAWsKoIs9OSiUDdBFXzFqYSrV41G1oQsKVSi/NU1tT1UZW
CENddWt90XLXZAlSYnv6s8Ceg== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 1870 example.com.
sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r
8q6DBlCdlRQvzD90UKZDIAqbA== )
example.com. 900 IN DS ( 1870 13 2
e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81
e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000
20170529000000 18931 com.
rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3
5XxvbOdLIJAcxhRS1c2VITfMA== )
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000
20170529000000 18931 com.
wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk
c6Nx3HLmhidf6dmt/Hi0ePBsQ== )
com. 86400 IN DS ( 18931 13 2
20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52
115 )
com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+
jGGQccnLkQnUf7zednetSWalg== )
Authors' Addresses Authors' Addresses
Melinda Shore Melinda Shore
Fastly Fastly
EMail: mshore@fastly.com EMail: mshore@fastly.com
Richard Barnes Richard Barnes
Mozilla Mozilla
EMail: rlb@ipv.sx EMail: rlb@ipv.sx
Shumon Huque Shumon Huque
Salesforce Salesforce
EMail: shumon.huque@gmail.com EMail: shuque@gmail.com
Willem Toorop Willem Toorop
NLNet Labs NLNet Labs
EMail: willem@nlnetlabs.nl EMail: willem@nlnetlabs.nl
 End of changes. 33 change blocks. 
152 lines changed or deleted 455 lines changed or added

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