draft-ietf-tls-dnssec-chain-extension-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc5011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY rfc6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc7120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY rfc7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY rfc7633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7633.xml">
<!ENTITY rfc7671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7671.xml">
<!ENTITY rfc7672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7672.xml">
<!ENTITY rfc7901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7901.xml">
]>

<!-- To do: -->
<!--   state machine diagram for the verification section? -->
<!--   pseudocode -->
<!--   test vectors -->



<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc docName="draft-ietf-tls-dnssec-chain-extension-04"
     ipr="trust200902" category="std">

<front>
  <title abbrev="TLS DNSSEC Chain Extension">
    A DANE Record and DNSSEC Authentication Chain Extension for TLS
  </title>
  <author fullname="Melinda Shore" initials="M"
          surname="Shore">
    
    <organization>Fastly</organization>
    <address>
      <email>mshore@fastly.com</email>
    </address>
  </author>

  <author fullname="Richard Barnes" initials="R"
          surname="Barnes">
    <organization>Mozilla</organization>
    <address>
      <email>rlb@ipv.sx</email>
    </address>
  </author>

  <author fullname="Shumon Huque" initials="S"
          surname="Huque">
    <organization>Salesforce</organization>
    <address>
      <email>shuque@gmail.com</email>
    </address>
  </author>

  <author fullname="Willem Toorop" initials="W"
          surname="Toorop">
    <organization>NLNet Labs</organization>
    <address>
      <email>willem@nlnetlabs.nl</email>
    </address>
  </author>

  <date year="2017" />
  <area>Security</area>
  <workgroup>TLS</workgroup>
  <abstract>
    <t>
      This draft describes a new TLS extension for
      transport of a DNS record set serialized with the DNSSEC
      signatures needed to authenticate that record set.  The
      intent of this proposal is to allow TLS clients to
      perform DANE authentication of a TLS server
      without needing to perform additional DNS
      record lookups.  It will typically not be used for
      general DNSSEC validation of TLS endpoint names.
    </t>
  </abstract>
</front>

<middle>
  <section title="Requirements Notation">
    <t>The key words "MUST", "MUST NOT", "REQUIRED",
    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" in this document
    are to be interpreted as described
    in <xref target="RFC2119" />.</t>
  </section>


  <section title="Introduction">
    <t>
      This draft describes a new <xref target="RFC5246">TLS
      </xref> extension
      for transport of a DNS record set serialized with the
      <xref target="RFC4034">DNSSEC signatures</xref> needed
      to authenticate that record set.  The intent of this
      proposal is to allow TLS clients to perform DANE
      Authentication <xref target="RFC6698" />
      <xref target="RFC7671" /> of a TLS
      server without performing
      additional DNS record lookups and incurring the
      associated latency penalty. It also provides the
      ability to avoid potential problems with TLS clients
      being unable to 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 a
      TLS client to validate DANE records itself without
      necessarily needing access to a validating DNS resolver to which
      it has a secure connection.  It will typically not be
      used for general DNSSEC validation of endpoint names,
      but is more appropriate for validation of DANE TLSA records.
    </t>

    <t>
      This mechanism is useful
      for TLS applications that need to address the problems
      described above, typically web browsers or VoIP and
      XMPP applications. It may not be relevant for many other
      applications. For example, SMTP MTAs are usually
      located in data centers, may tolerate
      extra DNS lookup latency, are on servers where it is
      easier to provision a validating resolver, or are
      less likely to experience traffic interference from
      misconfigured middleboxes. Furthermore, SMTP MTAs usually
      employ <xref target="RFC7672">Opportunistic Security</xref>,
      in which the presence of the DNS TLSA records is used to determine
      whether to enforce an authenticated TLS connection.
      Hence DANE authentication of SMTP MTAs will typically not use 
      this mechanism.
    </t>

    <t>
      The extension described here allows a TLS client to
      request in the ClientHello message that the DNS authentication
      chain be returned in the (extended) ServerHello message.
      If the server is configured for DANE authentication, then
      it performs the appropriate DNS queries, builds the authentication
      chain, and returns it to the client. The
      server will usually use a previously cached authentication chain, but
      it will need to rebuild it periodically as described in
      <xref target="sec_caching" />. 
      The client then authenticates the chain using a pre-configured 
      trust anchor.
    </t>

    <t>
      This specification is based on Adam Langley's original
      proposal for serializing DNSSEC authentication chains
      and delivering them in an X.509 certificate extension
      <xref target="I-D.agl-dane-serializechain" />. It modifies the approach by using
      wire format DNS records in the serialized data (assuming
      that the data will be prepared and consumed by a DNS-specific
      library), and by using a TLS extension to deliver the data.
    </t>

    <t>
      As described in the DANE specification <xref target="RFC6698" />
      <xref target="RFC7671" />, this
      procedure applies to the DANE authentication of X.509
      certificates or raw public keys <xref target="RFC7250" />.
    </t>
    
  </section> <!-- introduction -->

  <section title="DNSSEC Authentication Chain Extension">
    <section title="Protocol, TLS 1.2">

    <t>
      A client MAY include an extension of type
      "dnssec_chain" in the (extended) ClientHello.  The
      "extension_data" field of this extension MUST be
      empty.
    </t>

    <t>
      Servers receiving a "dnssec_chain" extension in the
      ClientHello, and which are capable of being authenticated
      via DANE, MAY return a serialized authentication chain
      in the extended ServerHello message, using the format
      described below.  If a server is unable to return an
      authentication chain, or does not wish to return an
      authentication chain, it does not include a dnssec_chain
      extension.  As with all TLS extensions, if the server
      does not support this extension it will not return any
      authentication chain.
    </t>

    <t>
      A client must not be able to force a server to
      perform lookups on arbitrary domain names using this
      mechanism.  Therefore, a server MUST NOT construct
      chains for domain names other than its own.
    </t>

    </section> <!-- protocol 1.2 -->

    <section title="Protocol, TLS 1.3">

      <t>
        A client MAY include an extension of type
        "dnssec_chain" in the ClientHello.  The
        "extension_data" field of this extension MUST be
        empty.
      </t>

      <t>
        Servers receiving a "dnssec_chain" extension in the
        ClientHello, and which are capable of being authenticated
        via DANE, SHOULD return a serialized authentication chain
        in the Certificate message associated with the end
        entity certificate being validated, using the format
        described below.  The authentication chain will be an
        extension to the certificate_list to which the
        certificate being authenticated belongs.
      </t>

      <t>
        The extension protocol behavior otherwise follows that specified
        for TLS version 1.2.
      </t>

    </section> <!-- protocol 1.3 -->

    <section title="Raw Public Keys">
      <t>
        <xref target="RFC7250" /> specifies the use of raw
        public keys for both server and client
        authentication in TLS 1.2.  It points out that in
        cases where raw public keys are being used, code for
        certificate path validation is not
        required. However, DANE, when used in conjunction
        with the dnssec_chain extension, provides a mechanism for
        securely binding a raw public key to a named entity
        in the DNS, and when using DANE for authentication a
        raw key may be validated using a path chaining back
        to a DNSSEC trust root.  This has the added benefit
        of mitigating an unknown key share attack, as
        described in <xref target="I-D.barnes-dane-uks" />,
        since it effectively augments the raw public key
        with the server's name and provides a means to
        commit both the server and the client to using that
        binding. 
      </t>

      <t>
        The UKS attack is possible in situations in which
        the association between a domain name and a public
        key is not tightly bound, as in the case in DANE in
        which a client either ignores the name in
        certificate (as specified in <xref target="RFC7671"
        /> or there is no attestation of trust outside of
        the DNS.  The vulnerability arises in the following
        situations: 
      </t>
      <t>
        <list style="symbols">
          <t>If the client does not verify the identity in the
            server's certificate (as recommended in Section
            5.1 of [RFC7671]), then an attacker can induce the
            client to accept an unintended identity for the
            server, 
          </t>

          <t>If the client allows the use of raw public keys
            in TLS, then it will not receive any
            indication of the server's identity in the TLS
            channel, and is thus unable to check that the
            server's identity is as intended.
          </t>
        </list>
      </t>

      <t>The mechanism for conveying DNSSEC validation
        chains described in this document results in a
        commitment by both parties, via the TLS
        handshake, to a domain name which has been validated
        as belonging to the owner name.</t>

      <t>The mechanism for encoding DNSSEC authentication
        chains in a TLS extension, as described in this
        document, is not limited to public keys encapsulated
        in X.509 containers but MAY be applied to raw
        public keys and other representations, as well.
      </t>
    </section>

    
    <section title="DNSSEC Authentication Chain Data"
	     anchor="auth_chain_data">

      <t>
    The "extension_data" field of the "dnssec_chain" extension 
    MUST contain a DNSSEC Authentication Chain encoded in the
    following form:
      </t>

      <figure>
        <artwork>

          opaque AuthenticationChain&lt;0..2^16-1&gt;
        </artwork>
      </figure>

      <t>
    The AuthenticationChain structure is composed of a sequence of 
    uncompressed wire format DNS resource record sets (RRset) and 
    corresponding signatures (RRSIG) records.
      </t>

      <t>
    This sequence of native DNS wire format records enables easier
    generation of the data structure on the server and easier 
    verification of the data on client by means of existing DNS library
    functions. However this document describes the data structure
    in sufficient detail that implementers if they desire can write
    their own code to do this.
      </t>

      <t>
    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 <xref target="RFC1035">RFC 1035</xref>, Section
    3.2.1. The resource records SHOULD be presented in the canonical 
    form and ordering as described in 
    <xref target="RFC4034">RFC 4034</xref>.
      </t>

      <figure>
        <artwork>

          RR(i) = owner | type | class | TTL | RDATA length | RDATA
        </artwork>
      </figure>

      <t>
    RRs within the RRset MAY be ordered canonically, by treating
    the RDATA portion of each RR as a left-justified unsigned 
    octet sequence in which the absence of an octet sorts before
    a zero octet.
      </t>

      <t>
    Each RRset in the sequence is followed by its associated
    RRsig record.
    The RRsig record is in DNS wire format as described in 
    <xref target="RFC4034">RFC 4034</xref>, Section 3.1. The 
    signature portion of the RDATA, as described in the same
    section, is the following:
      </t>

      <figure>
        <artwork>

          signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
        </artwork>
      </figure>

      <t>
    where RRSIG_RDATA is the wire format of the RRSIG RDATA
    fields with the Signer's Name field in canonical form and
    the signature field excluded.
      </t>

      <t>
        The first RRset in the chain MUST contain the TLSA record set
	being presented. However, if the owner name of the TLSA record
	set is an alias (CNAME or DNAME), then it MUST be preceded by the
	chain of 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.
      </t>

      <t>
	The subsequent RRsets MUST contain the full set
	of DNS records needed 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.
      </t>

      <t>
        Names that are aliased via CNAME and/or DNAME records may involve
	multiple branches of the DNS tree. In this case, the authentication
	chain structure needs to include DS and DNSKEY record sets that
	cover all the necessary branches.
      </t>

      <t>
	If the TLSA record set was synthesized by a DNS wildcard, the
	chain must include the signed NSEC or NSEC3 records that prove
	that there was no explicit match of the TLSA record name and no
	closer wildcard match.
      </t>

      <t>
        The final DNSKEY RRset in the authentication chain corresponds
	to the trust anchor (typically the DNS root). This trust anchor 
	is also preconfigured in the TLS client, but including it in the 
	response from the server permits TLS clients to use the automated 
	trust anchor rollover mechanism defined in RFC 5011 
	<xref target="RFC5011" /> to update their configured trust anchor.
      </t>

      <t>
	The following is an example of the records in the
	AuthenticationChain structure for the HTTPS server at
        www.example.com, where there are zone cuts at "com."
        and "example.com." (record data are omitted here for brevity):
      </t>

      <figure>
        <artwork>

          _443._tcp.www.example.com. TLSA
          RRSIG(_443._tcp.www.example.com. TLSA)
          example.com. DNSKEY
          RRSIG(example.com. DNSKEY)
          example.com. DS
          RRSIG(example.com. DS)
          com. DNSKEY
          RRSIG(com. DNSKEY)
          com. DS
          RRSIG(com. DS)
          . DNSKEY
          RRSIG(. DNSKEY)
        </artwork>
      </figure>

    </section> <!-- authentication chain data -->
  </section> <!-- dnssec authentication chain extension -->

  <section title="Construction of Serialized Authentication Chains">

    <t>
      This section describes a possible procedure for the
      server to use to build the serialized DNSSEC chain.
    </t>

    <t>When the goal is to perform DANE authentication 
       <xref target="RFC6698" /> <xref target="RFC7671" /> of the 
       server, the DNS record set to be
       serialized is a TLSA record set corresponding to the 
       server's domain name, protocol, and port number.
    </t>

    <t>
      The domain name of the server MUST be that included in
      the TLS server_name extension <xref target="RFC6066"
      /> when present. If the server_name extension is not
      present, or if the server does not recognize the
      provided name and wishes to proceed with the handshake
      rather than to abort the connection, the server uses
      the domain name associated with the server IP address
      to which the connection has been established.
    </t>

    <t>
      The TLSA record to be queried is constructed by prepending
      the _port and _transport labels to the domain name as described
      in <xref target="RFC6698" />, where "port" is the port number
      associated with the TLS server.  The transport is "tcp"
      for TLS servers, and "udp" for DTLS servers.  The port
      number label is the left-most label, followed by the
      transport, followed by the base domain name.
    </t>

    <t>
      The components of the authentication chain are typically built by
      starting at the target record set and its corresponding RRSIG.
      Then traversing the DNS tree upwards towards the trust anchor
      zone (normally the DNS root), for each zone cut, the DNSKEY and
      DS RRsets and their signatures are added. However, see
      <xref target="auth_chain_data" /> for specific processing needed for
      aliases and wildcards. If DNS responses messages contain any
      domain names utilizing name compression
      <xref target="RFC1035"/>, then they must be uncompressed.
    </t>

    <t>
      Newer DNS protocol enhancements, such as the <xref target="RFC7901">
      EDNS Chain Query extension</xref> if supported, may offer easier ways
      to obtain all of the chain data in one transaction with an upstream
      DNSSEC aware recursive server.
    </t>

  </section> <!-- construction -->


  <section title="Caching and Regeneration of the Authentication Chain"
       anchor="sec_caching">
    <t>
      DNS records have Time To Live (TTL) parameters, and DNSSEC
      signatures have validity periods (specifically signature expiration
      times). After the TLS server constructs the serialized authentication
      chain, it SHOULD cache and reuse it in multiple TLS connection
      handshakes. However, it MUST refresh and rebuild the chain as TTLs
      and signature validity periods dictate. A server implementation 
      could carefully track these parameters and requery component records
      in the chain correspondingly. Alternatively, it could be configured 
      to rebuild the entire chain at some predefined periodic interval that 
      does not exceed the DNS TTLs or signature validity periods of the 
      component records in the chain.
    </t>
  </section>


  <section title="Verification" anchor="sec_verification">

    <t>
      A TLS client making use of this specification, and
      which receives a DNSSEC authentication chain extension
      from a server, SHOULD use this information to perform
      DANE authentication of the server.  In
      order to do this, it uses the mechanism specified by
      the <xref target="RFC4035">DNSSEC protocol</xref>.
      This mechanism is sometimes implemented in a DNSSEC
      validation engine or library.
    </t>

    <!-- TODO: Add a precis of the algorithm here -->

    <t>
      If the authentication chain is 
      correctly verified, the client then performs DANE
      authentication of the server according to the
      DANE TLS protocol <xref target="RFC6698" />
      <xref target="RFC7671" />.
    </t>

  </section> <!-- verification -->


  <section title="Trust Anchor Maintenance" anchor="sec_trustmaint">

    <t>
      The trust anchor may change periodically, e.g. when the operator
      of the trust anchor zone performs a DNSSEC key rollover. TLS
      clients using this specification MUST implement a mechanism to
      keep their trust anchors up to date. They could use the method
      defined in <xref target="RFC5011" /> to perform trust anchor
      updates inband in TLS, by tracking the introduction of new keys
      seen in the trust anchor DNSKEY RRset. However, alternative
      mechanisms external to TLS may also be utilized. Some operating systems
      may have a system-wide service to maintain and keep the root trust
      anchor up to date. In such cases, the TLS client application
      could simply reference that as its trust anchor, periodically 
      checking whether it has changed. Some applications may prefer to
      implement trust anchor updates as part of their automated software
      updates.
    </t>

  </section> <!-- trust anchor maintenance  -->


  <section title="Mandating use of this extension" anchor="must_staple">

    <t>
      A TLS server certificate MAY mandate the use of this extension by means 
      of the X.509 TLS Feature Extension described in <xref target="RFC7633" />.
      This X.509 certificate extension, when populated with the dnssec_chain
      TLS extension identifier, indicates to the client that the server must
      deliver the authentication chain when asked to do so. (The X.509 TLS
      Feature Extension is the same mechanism used to deliver other mandatory 
      signals, such as OCSP "must staple" 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.
    </t>

  </section>

  <section title="Security Considerations">

    <t> 
      The security considerations of the normatively referenced RFCs 
      (1035, 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to 
      this extension. Since the server is delivering a chain of DNS 
      records and signatures to the client, it MUST rebuild the chain
      in accordance with TTL and signature expiration of
      the chain components as described in <xref target="sec_caching" />.
      TLS clients need roughly accurate time in order to properly
      authenticate these signatures. This could be achieved by running
      a time synchronization protocol like NTP <xref target="RFC5905" /> 
      or SNTP <xref target="RFC5905" />, which are already widely used 
      today. TLS clients MUST support a mechanism to track and rollover 
      the trust anchor key, or be able to avail themselves of a service 
      that does this, as described in <xref target="sec_trustmaint" />.
    </t>

  </section>


  <section title="IANA Considerations">

    <t>This extension requires the registration of a new
      value in the TLS ExtensionsType registry.  The value
      requested from IANA is 53. If the draft is adopted by
      the WG, the authors expect to make an early allocation
      request as specified in <xref target="RFC7120"  />.</t>

  </section> <!-- iana considerations -->


  <section title="Acknowledgments">

    <t>
      Many thanks to Adam Langley for laying the groundwork
      for this extension. The original idea is his but our
      acknowledgment in no way implies his endorsement.
      This document also benefited from discussions with and
      review from the following people: Viktor Dukhovni,
      Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus, 
      Rick van Rein,
      Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters.
    </t>

  </section>


</middle>

<back>

  <references title="Normative References">
    &rfc1035;
    &rfc2119;
    &rfc4034;
    &rfc4035;
    &rfc5246;
    &rfc6066;
    &rfc6698;
    &rfc7633;
    &rfc7671;
  </references>

  <references title="Informative References">
    &rfc5011;
    &rfc5905;
    &rfc7120;
    &rfc7250;
    &rfc7672;
    &rfc7901;
    <?rfc include="reference.I-D.agl-dane-serializechain.xml"?>
    <?rfc include="reference.I-D.draft-barnes-dane-uks-00.xml"?>
  </references>

  <section title="Updates from -01 and -02">
    <t>
      <list style="symbols">
        <t>Editorial updates for style and consistency</t>
        <t>Updated discussion of UKS attack</t>
      </list>
    </t>
  </section>

  <section title="Updates from -01">
    <t>
      <list style="symbols">
        <t>Added TLS 1.3 support</t>
        <t>Added section describing applicability to raw
          public keys</t>
        <t>Softened language about record order</t>
      </list>
    </t>
  </section>
  
  <section title="Updates from -00">
    <t>
      <list style="symbols">
        <t>Edits based on comments from Rick van Rein</t>
        <t>Warning about not overloading X.509 wildcards on
          DNSSEC wildcards (from V. Dukhovny) </t>
        <t>Added MUST include negative proof on
        wildcards (from V. Dukhovny) </t>
        <t>Removed "TODO" on allowing the server to deliver
          only one signature per RRset</t>
        <t>Added additional minor edits suggested by Viktor
        Dukhovny</t>
        
      </list>
    </t>
  </section> <!-- updates -->

  <section title="Test vectors">
    <t>
       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:
    </t>
    <figure>
      <artwork>
-----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-----
      </artwork>
    </figure>
    <t>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.</t>
    <t>The test vectors are DNSSEC valid at June 1 2017, with the following root trust anchor:</t>
    <figure>
      <artwork>
.  IN  DS  ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
        641bb568746f2ffc4d4 )
      </artwork>
    </figure>
    <section title="_443._tcp.www.example.com">
      <figure>
        <artwork>
_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== )
        </artwork>
      </figure>
      <t>A hex dump of the wire format data of this content is:</t>
      <figure>
        <artwork>
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
        </artwork>
      </figure>
    </section>  <!-- _443._tcp.www.example.com -->
    <section title="_25._tcp.example.com wildcard">
      <figure>
        <artwork>
_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== )
        </artwork>
      </figure>
    </section> <!-- _25._tcp.example.com wildcard -->
    <section title="_443._tcp.www.example.org CNAME">
      <figure>
        <artwork>
_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== )
        </artwork>
      </figure>
    </section> <!-- _443._tcp.www.example.org CNAME -->
    <section title="_443._tcp.www.example.net DNAME">
      <figure>
        <artwork>
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== )
        </artwork>
      </figure>
    </section> <!-- _443._tcp.www.example.net DNAME-->
  </section> <!-- test vectors -->

</back>
</rfc>