summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8145.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8145.txt')
-rw-r--r--doc/rfc/rfc8145.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc8145.txt b/doc/rfc/rfc8145.txt
new file mode 100644
index 0000000..a6dcd56
--- /dev/null
+++ b/doc/rfc/rfc8145.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Wessels
+Request for Comments: 8145 Verisign
+Category: Standards Track W. Kumari
+ISSN: 2070-1721 Google
+ P. Hoffman
+ ICANN
+ April 2017
+
+
+ Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
+
+Abstract
+
+ The DNS Security Extensions (DNSSEC) were developed to provide origin
+ authentication and integrity protection for DNS data by using digital
+ signatures. These digital signatures can be verified by building a
+ chain of trust starting from a trust anchor and proceeding down to a
+ particular node in the DNS. This document specifies two different
+ ways for validating resolvers to signal to a server which keys are
+ referenced in their chain of trust. The data from such signaling
+ allow zone administrators to monitor the progress of rollovers in a
+ DNSSEC-signed zone.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8145.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 1]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Design Evolution ...........................................4
+ 2. Requirements Terminology ........................................5
+ 3. Terminology .....................................................5
+ 4. Using the edns-key-tag Option ...................................5
+ 4.1. Option Format ..............................................5
+ 4.2. Use by Queriers ............................................6
+ 4.2.1. Stub Resolvers ......................................7
+ 4.2.1.1. Validating Stub Resolvers ..................7
+ 4.2.1.2. Non-validating Stub Resolvers ..............7
+ 4.2.2. Recursive Resolvers .................................7
+ 4.2.2.1. Validating Recursive Resolvers .............7
+ 4.2.2.2. Non-validating Recursive Resolvers .........8
+ 4.3. Use by Responders ..........................................8
+ 5. Using the Key Tag Query .........................................8
+ 5.1. Query Format ...............................................8
+ 5.2. Use by Queriers ............................................9
+ 5.3. Use by Responders ..........................................9
+ 5.3.1. Interaction with Aggressive Negative Caching ........9
+ 6. IANA Considerations ............................................10
+ 7. Security Considerations ........................................10
+ 8. Privacy Considerations .........................................11
+ 9. References .....................................................11
+ 9.1. Normative References ......................................11
+ 9.2. Informative References ....................................12
+ Acknowledgments ...................................................13
+ Authors' Addresses ................................................13
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 2]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035]
+ were developed to provide origin authentication and integrity
+ protection for DNS data by using digital signatures. DNSSEC uses
+ Key Tags to efficiently match signatures to the keys from which they
+ are generated. The Key Tag is a 16-bit value computed from the RDATA
+ portion of a DNSKEY resource record (RR) using a formula not unlike a
+ ones-complement checksum. RRSIG RRs contain a Key Tag field whose
+ value is equal to the Key Tag of the DNSKEY RR that validates the
+ signature.
+
+ Likewise, Delegation Signer (DS) RRs also contain a Key Tag field
+ whose value is equal to the Key Tag of the DNSKEY RR to which it
+ refers.
+
+ This document specifies how validating resolvers can tell a server,
+ in a DNS query, which DNSSEC key(s) they would use to validate the
+ server's responses. It describes two independent methods for
+ conveying Key Tag information between clients and servers:
+
+ 1. placing an EDNS option in the OPT RR [RFC6891] that contains the
+ Key Tags (described in Section 4)
+
+ 2. periodically sending special "Key Tag queries" to a server
+ authoritative for the zone (described in Section 5)
+
+ Each of these new signaling mechanisms is OPTIONAL to implement and
+ use. These mechanisms serve to measure the acceptance and use of new
+ DNSSEC trust anchors and key signing keys (KSKs). This signaling
+ data can be used by zone administrators as a gauge to measure the
+ successful deployment of new keys. This is of particular interest
+ for the DNS root zone in the event of key and/or algorithm rollovers
+ that rely on [RFC5011] to automatically update a validating DNS
+ resolver's trust anchor.
+
+ This document does not introduce new processes for rolling keys or
+ updating trust anchors. Rather, it specifies a means by which a DNS
+ query can signal the set of keys that a client uses for DNSSEC
+ validation.
+
+
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 3]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+1.1. Design Evolution
+
+ Initially, when the work on this document started, it proposed
+ including Key Tag values in a new EDNS(0) option code. It was
+ modeled after [RFC6975], which provides DNSSEC algorithm signaling.
+
+ The authors received feedback from participants in the DNSOP Working
+ Group that it might be better to convey Key Tags in the QNAME of a
+ separate DNS query, rather than as an EDNS(0) option. Mostly, this
+ is because forwarding (e.g., from stub to recursive to authoritative)
+ could be problematic. Reasons include the following:
+
+ 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not
+ be forwarded by default, as per [RFC6891].
+
+ 2. Middleboxes might block entire queries containing unknown EDNS(0)
+ option codes.
+
+ 3. A recursive resolver might need to remember Key Tag values (i.e.,
+ keep state) received from its stub clients and then forward them
+ at a later opportunity.
+
+ One advantage of the EDNS(0) option code is that it is possible to
+ see that a stub client has a different Key Tag list than its
+ forwarder. In the QNAME-based approach, this is not possible because
+ queries originated by a stub and a forwarder are indistinguishable.
+ The authors feel that this advantage is not sufficient to justify the
+ EDNS(0) approach.
+
+ One downside to the QNAME approach is that it uses a separate query,
+ whereas with EDNS(0) the Key Tag values are "piggybacked" onto an
+ existing DNSKEY query. For this reason, this document recommends
+ only sending QNAME-based Key Tag queries for trust anchors, although
+ EDNS-based Key Tags can be sent with any DNSKEY query.
+
+ Another downside to the QNAME-based approach is that since the
+ trust anchor zone might not contain labels matching the QNAME, these
+ queries could be subject to aggressive negative caching features now
+ in development by the Working Group. This could affect the amount of
+ signaling sent by some clients compared to others.
+
+ A probably minor downside to the QNAME-based approach is that it
+ cannot be used with extremely long query names if the addition of the
+ prefix would cause the name to be longer than 255 octets.
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 4]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+2. Requirements Terminology
+
+ 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 [RFC2119].
+
+3. Terminology
+
+ Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
+ A validating security-aware resolver uses this public key or hash
+ as a starting point for building the authentication chain to a
+ signed DNS response. In general, a validating resolver will have
+ to obtain the initial values of its trust anchors via some secure
+ or trusted means outside the DNS protocol. Presence of a
+ trust anchor also implies that the resolver should expect the zone
+ to which the trust anchor points to be signed. (This paragraph is
+ quoted from Section 2 of [RFC4033].)
+
+ Key Tag: A 16-bit integer that identifies and enables efficient
+ selection of DNSSEC public keys. A Key Tag value can be computed
+ over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and
+ DS records can be used to help select the corresponding DNSKEY RR
+ efficiently when more than one candidate DNSKEY RR is available.
+ For most algorithms, the Key Tag is a simple 16-bit modular sum of
+ the DNSKEY RDATA. See [RFC4034], Appendix B.
+
+4. Using the edns-key-tag Option
+
+4.1. Option Format
+
+ The edns-key-tag option is encoded as follows:
+
+ 0 8 16
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | OPTION-CODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | OPTION-LENGTH |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | KEY-TAG |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ... /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 5]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ where:
+
+ OPTION-CODE: The EDNS0 option code assigned to edns-key-tag (14).
+
+ OPTION-LENGTH: The value 2 x number of key-tag values present.
+
+ KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).
+
+4.2. Use by Queriers
+
+ A validating resolver sets the edns-key-tag option in the OPT RR when
+ sending a DNSKEY query. The validating resolver SHOULD also set the
+ DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that
+ it wishes to receive DNSSEC RRs in the response.
+
+ A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY
+ queries.
+
+ The KEY-TAG value(s) included in the edns-key-tag option represents
+ the Key Tag of the trust anchor or DNSKEY RR that will be used to
+ validate the expected response. When the client sends a DNSKEY
+ query, the edns-key-tag option represents the Key Tag(s) of the
+ KSK(s) of the zone for which the server is authoritative. A
+ validating resolver learns the Key Tag(s) of the KSK(s) from the
+ zone's DS record(s) (found in the parent) or from a trust anchor.
+
+ A DNS client SHOULD include the edns-key-tag option when issuing a
+ DNSKEY query for a zone corresponding to a trust anchor.
+
+ A DNS client MAY include the edns-key-tag option when issuing a
+ DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via
+ DS records). Since some DNSSEC validators implement bottom-up
+ validation, a non-trust anchor Key Tags zone might not be known at
+ the time of the query. Such a validator can include the edns-key-tag
+ option based on previously cached data.
+
+ A DNS client MUST NOT include Key Tag(s) for keys that are not
+ learned via either a trust anchor or DS records.
+
+ Since the edns-key-tag option is only set in the query, if a client
+ sees these options in the response, no action needs to be taken and
+ the client MUST ignore the option values.
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 6]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+4.2.1. Stub Resolvers
+
+ Typically, stub resolvers rely on an upstream recursive resolver (or
+ cache) to provide a response. Optimal setting of the edns-key-tag
+ option depends on whether the stub resolver elects to perform its own
+ validation.
+
+4.2.1.1. Validating Stub Resolvers
+
+ A validating stub resolver sets the DNSSEC OK bit [RFC4035] to
+ indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG
+ RRs) in the response. Such validating resolvers SHOULD include the
+ edns-key-tag option in the OPT RR when sending a DNSKEY query.
+
+4.2.1.2. Non-validating Stub Resolvers
+
+ The edns-key-tag option MUST NOT be included by non-validating stub
+ resolvers.
+
+4.2.2. Recursive Resolvers
+
+4.2.2.1. Validating Recursive Resolvers
+
+ A validating recursive resolver is, by definition, configured with at
+ least one trust anchor. Thus, a recursive resolver SHOULD include
+ the edns-key-tag option in its DNSKEY queries as described above.
+
+ In addition, the clients of a validating recursive resolver might be
+ configured to do their own validation, with their own
+ trust anchor(s). When a validating recursive resolver receives a
+ query that includes the edns-key-tag option with a Key Tag list that
+ differs from its own, it SHOULD forward both the client's Key Tag
+ list and its own list. When doing so, the recursive resolver SHOULD
+ transmit the two Key Tag lists using separate instances of the
+ edns-key-tag option code in the OPT RR. For example, if the
+ recursive resolver's Key Tag list is (19036, 12345) and the
+ stub/client's list is (19036, 34567), the recursive resolver
+ would include the edns-key-tag option twice: once with values
+ (19036, 12345) and once with values (19036, 34567).
+
+ A validating recursive resolver MAY combine stub/client Key Tag
+ values from multiple incoming queries into a single outgoing query.
+ It is RECOMMENDED that implementations place reasonable limits on the
+ number of Key Tags to include in the outgoing edns-key-tag option.
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 7]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ If the client included the DNSSEC OK and Checking Disabled (CD) bits
+ but did not include the edns-key-tag option in the query, the
+ validating recursive resolver MAY include the option with its own
+ Key Tag values in full.
+
+ Validating recursive resolvers MUST NOT set the edns-key-tag option
+ in the final response to the stub client.
+
+4.2.2.2. Non-validating Recursive Resolvers
+
+ Recursive resolvers that do not validate responses SHOULD copy the
+ edns-key-tag option seen in received queries, as they represent the
+ wishes of the validating downstream resolver that issued the original
+ query.
+
+4.3. Use by Responders
+
+ An authoritative name server receiving queries with the edns-key-tag
+ option MAY log or otherwise collect the Key Tag values to provide
+ information to the zone operator.
+
+ A responder MUST NOT include the edns-key-tag option in any DNS
+ response.
+
+5. Using the Key Tag Query
+
+5.1. Query Format
+
+ A Key Tag query consists of a standard DNS query of type NULL and of
+ class IN [RFC1035].
+
+ The first component of the query name is the string "_ta-" followed
+ by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
+ values. The zone name corresponding to the trust anchor is appended
+ to this first component.
+
+ For example, a validating DNS resolver that has a single root zone
+ trust anchor with Key Tag 17476 (decimal) would originate a query of
+ the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
+
+ Hexadecimal values MUST be zero-padded to four hexadecimal digits.
+ For example, if the Key Tag is 999 (decimal), it is represented in
+ hexadecimal as 03e7.
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 8]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ When representing multiple Key Tag values, they MUST be sorted in
+ order from smallest to largest. For example, a validating DNS
+ resolver that has three trust anchors for the example.com zone with
+ Key Tags 1589, 43547, 31406 (decimal) would originate a query of the
+ form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.
+
+5.2. Use by Queriers
+
+ A validating DNS resolver (stub or recursive) SHOULD originate a
+ Key Tag query whenever it also originates a DNSKEY query for a
+ trust anchor zone. In other words, the need to issue a DNSKEY query
+ is also the trigger to issue a Key Tag query.
+
+ The value(s) included in the Key Tag query represents the Key Tag(s)
+ of the trust anchor that will be used to validate the expected DNSKEY
+ response.
+
+ A validating DNS resolver SHOULD NOT originate Key Tag queries when
+ also originating DNSKEY queries for non-trust anchor zones.
+
+ A non-validating DNS resolver MUST NOT originate Key Tag queries.
+
+ DNS resolvers with caches SHOULD cache and reuse the response to a
+ Key Tag query just as it would any other response.
+
+5.3. Use by Responders
+
+ An authoritative name server receiving Key Tag queries MAY log or
+ otherwise collect the Key Tag values to provide information to the
+ zone operator.
+
+ An authoritative name server MUST generate an appropriate response to
+ the Key Tag query. A server does not need to have built-in logic
+ that determines the response to Key Tag queries: the response code is
+ determined by whether the data is in the zone file or covered by
+ wildcards. The zone operator might want to add specific Key Tag
+ records to its zone, perhaps with specific TTLs, to affect the
+ frequency of Key Tag queries from clients.
+
+5.3.1. Interaction with Aggressive Negative Caching
+
+ Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also
+ affect the quality of Key Tag signaling. When the response code for
+ a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive
+ negative caching will send fewer Key Tag queries than resolvers that
+ do not implement it.
+
+
+
+
+
+Wessels, et al. Standards Track [Page 9]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ For this reason, zone operators might choose to create records
+ corresponding to expected Key Tag queries. During a rollover from
+ Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the
+ following records:
+
+ _ta-1111 IN NULL \# 0
+ _ta-2222 IN NULL \# 0
+ _ta-1111-2222 IN NULL \# 0
+
+ Recall that when multiple Key Tags are present, the originating
+ client MUST sort them from smallest to largest in the query name.
+
+6. IANA Considerations
+
+ IANA has assigned an EDNS0 option code for the edns-key-tag option in
+ the "DNS EDNS0 Option Codes (OPT)" registry as follows:
+
+ +-------+--------------+----------+-----------+
+ | Value | Name | Status | Reference |
+ +-------+--------------+----------+-----------+
+ | 14 | edns-key-tag | Optional | RFC 8145 |
+ +-------+--------------+----------+-----------+
+
+7. Security Considerations
+
+ This document specifies two ways for a client to signal its
+ trust anchor knowledge to a cache or server. The goal of these
+ optional mechanisms is to signal new trust anchor uptake in clients
+ to allow zone administrators to know when it is possible to complete
+ a key rollover in a DNSSEC-signed zone.
+
+ There is a possibility that an eavesdropper or server could infer the
+ validator in use by a client by the Key Tag list seen. This may
+ allow an attacker to find validators using old, possibly broken,
+ keys. It could also be used to identify the validator or to narrow
+ down the possible validator implementations in use by a client; the
+ validator used by the client could have a known vulnerability that
+ could be exploited by the attacker.
+
+ Consumers of data collected from the mechanisms described in this
+ document are advised that provided Key Tag values might be "made up"
+ by some DNS clients with malicious, or at least mischievous,
+ intentions. For example, an attacker with sufficient resources might
+ try to generate large numbers of queries including only old Key Tag
+ values, with the intention of delaying the completion of a key
+ rollover.
+
+
+
+
+
+Wessels, et al. Standards Track [Page 10]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ DNSSEC does not require keys in a zone to have unique Key Tags.
+ During a rollover, there is a small possibility that an old key and a
+ new key will have identical Key Tag values. Zone operators relying
+ on the edns-key-tag mechanism SHOULD take care to ensure that new
+ keys have unique Key Tag values.
+
+8. Privacy Considerations
+
+ This proposal provides additional, optional "signaling" to DNS
+ queries in the form of Key Tag values. While Key Tag values
+ themselves are not considered private information, it may be possible
+ for an eavesdropper to use Key Tag values as a fingerprinting
+ technique to identify particular validating DNS clients. This may be
+ especially true if the validator is configured with trust anchors for
+ zones in addition to the root zone.
+
+ A validating resolver need not transmit the Key Tags in every
+ applicable query. Due to privacy concerns, such a resolver MAY
+ choose to transmit the Key Tags for a subset of queries (e.g., every
+ 25th time) or by random chance with a certain probability (e.g., 5%).
+
+ Implementations of this specification MAY be administratively
+ configured to only transmit the Key Tags for certain zones. For
+ example, the software's configuration file may specify a list of
+ zones for which the use of the mechanisms described here is allowed
+ or denied. Since the primary motivation for this specification is to
+ provide operational measurement data for root zone key rollovers, it
+ is RECOMMENDED that implementations at least include the edns-key-tag
+ option for root zone DNSKEY queries.
+
+9. References
+
+9.1. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <http://www.rfc-editor.org/info/rfc4033>.
+
+
+
+
+Wessels, et al. Standards Track [Page 11]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, DOI 10.17487/RFC4034, March 2005,
+ <http://www.rfc-editor.org/info/rfc4034>.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+ <http://www.rfc-editor.org/info/rfc4035>.
+
+ [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+ for DNS (EDNS(0))", STD 75, RFC 6891,
+ DOI 10.17487/RFC6891, April 2013,
+ <http://www.rfc-editor.org/info/rfc6891>.
+
+9.2. Informative References
+
+ [NSEC-NSEC3-Usage]
+ Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
+ DNSSEC-validated Cache", Work in Progress,
+ draft-ietf-dnsop-nsec-aggressiveuse-09, March 2017.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+ Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
+ September 2007, <http://www.rfc-editor.org/info/rfc5011>.
+
+ [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
+ Algorithm Understanding in DNS Security Extensions
+ (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
+ <http://www.rfc-editor.org/info/rfc6975>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 12]
+
+RFC 8145 DNSSEC Key Tag Signaling April 2017
+
+
+Acknowledgments
+
+ This document was inspired by and borrows heavily from [RFC6975] by
+ Scott Rose and Steve Crocker. The authors would like to thank Mark
+ Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
+ Wicinski, Suzanne Woolf, and other members of the DNSOP Working Group
+ for their input.
+
+Authors' Addresses
+
+ Duane Wessels
+ Verisign
+ 12061 Bluemont Way
+ Reston, VA 20190
+ United States of America
+
+ Phone: +1 703 948-3200
+ Email: dwessels@verisign.com
+ URI: http://verisigninc.com
+
+
+ Warren Kumari
+ Google
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ United States of America
+
+ Email: warren@kumari.net
+
+
+ Paul Hoffman
+ ICANN
+
+ Email: paul.hoffman@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wessels, et al. Standards Track [Page 13]
+