draft-ietf-dnsop-edns-key-tag-01.txt   draft-ietf-dnsop-edns-key-tag-02.txt 
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft Verisign Internet-Draft Verisign
Intended status: Standards Track W. Kumari Intended status: Standards Track W. Kumari
Expires: September 10, 2016 Google Expires: January 9, 2017 Google
March 9, 2016 P. Hoffman
ICANN
July 8, 2016
The EDNS Key Tag Option Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
draft-ietf-dnsop-edns-key-tag-01 draft-ietf-dnsop-edns-key-tag-02
Abstract Abstract
The DNS Security Extensions (DNSSEC) were developed to provide origin The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be verified by building a signatures. These digital signatures can be verified by building a
chain-of-trust starting from a trust anchor and proceeding down to a chain-of-trust starting from a trust anchor and proceeding down to a
particular node in the DNS. This document specifies a way for particular node in the DNS. This document specifies two different
validating end-system resolvers to signal to a server which keys are ways for validating resolvers to signal to a server which keys are
referenced in their chain-of-trust. The extensions allow zone referenced in their chain-of-trust. The data from such signaling
administrators to monitor the progress of rollovers in a DNSSEC- allow zone administrators to monitor the progress of rollovers in a
signed zone. DNSSEC-signed zone.
Status of this Memo This document describes two independent methods for validating
resolvers to publish their referenced keys: an EDNS option and a
differnt DNS query. The reason there are two methods instead of one
is some people see significant problems with each method. Having two
methods is clearly worse than having just one, but it is probably
better for the Internet than having no way to gain the information
from the resolvers.
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 10, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Use By Queriers . . . . . . . . . . . . . . . . . . . . . . . 5 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5
5.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . 6 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5
5.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . 6 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6
5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 6 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6
5.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6
5.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 7 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6
6. Use By Responders . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . . 9 5.3.1. Interaction With Aggressive Negative Caching . . . . 9
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and
[RFC4035] were developed to provide origin authentication and [RFC4035] were developed to provide origin authentication and
integrity protection for DNS data by using digital signatures. integrity protection for DNS data by using digital signatures.
DNSSEC uses Key Tags to efficiently match signatures to the keys from 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 which they are generated. The Key Tag is a 16-bit value computed
from the RDATA portion of a DNSKEY RR using a formula not unlike a from the RDATA portion of a DNSKEY RR using a formula not unlike a
ones-complement checksum. RRSIG RRs contain a Key Tag field whose 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 value is equal to the Key Tag of the DNSKEY RR that validates the
signature. signature.
Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 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 whose value is equal to the Key Tag of the DNSKEY RR to which it
refers. refers.
This draft sets out to specify a way for validating end-system This draft sets out to specify a way for validating resolvers to tell
resolvers to tell a server in a DNS query which DNSSEC key(s) they a server in a DNS query which DNSSEC key(s) they would use to
would use to validate the expected response. This is done using the validate responses from that zone. This is done in two ways: using
new EDNS option specified below in Section 4 for use in the OPT an EDNS option for use in the OPT meta-RR [RFC6891] that contains the
meta-RR [RFC6891]. This new EDNS option code is OPTIONAL to key tags (described in Section 4), and by periodically sending
implement and use. special "key tag queries" to a server authoritative for the zone
(described in Section 5).
This proposed EDNS option serves to measure the acceptance and use of Each of these new signaling mechanisms is OPTIONAL to implement and
new trust anchors and key signing keys (KSKs). This signaling option use. These mechanisms serve to measure the acceptance and use of new
can be used by zone administrators as a gauge to measure the 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 successful deployment of new keys. This is of particular interest
for the DNS root zone in the event of key and/or algorithm rollovers for the DNS root zone in the event of key and/or algorithm rollovers
that rely on [RFC5011] to automatically update a validating end- that rely on [RFC5011] to automatically update a validating DNS
system's trust anchor. resolver's trust anchor.
[ FOR WG DISCUSSION: There is some reluctance within the working This document does not introduce new processes for rolling keys or
group to use EDNS0 to convey the key tags upstream. In particular updating trust anchors. Rather, it specifies a means by which a DNS
there is a concern that middleboxes might block messages with unknown query can signal the set of keys that a client uses for DNSSEC
option codes. Also since EDNS0 is hop-by-hop, middleboxes and un- validation.
upgraded recursives won't necessarily know whether or not the edns-
key-tag options should be forwarded. RFC6891 says: "OPTION-CODE
values not understood by a responder or requestor MUST be ignored."
draft-wkumari-dnsop-trust-management proposed encoding this
information in query names, but sufficient issues with this approach
were discovered that the authors of the above decided to abandon this
work. The authors of draft-ietf-dnsop-edns-key-tag are willing to
consider this alternative if so guided by the working group. ]
This draft does not seek to introduce another process for rolling 1.1. Design Evolution
keys or updating trust anchors. Rather, this document specifies a
means by which a client query can signal the set of keys that a Initially this document was named draft-edns-key-tag and proposed
client uses for DNSSEC validation. 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 Working Group participants that it
might be better to convey Key Tags in 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:
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 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 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 "piggy-backed" on to an
existing DNSKEY query. For this reason, this document recommends
only sending QNAME-based key tag queries for configured 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.
2. Requirements Terminology 2. Requirements Terminology
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].
3. Terminology 3. Terminology
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
skipping to change at page 4, line 31 skipping to change at page 5, line 15
Section 2) Section 2)
Key Tag: A 16-bit integer that identifies and enables efficient Key Tag: A 16-bit integer that identifies and enables efficient
selection of DNSSEC public keys. A Key Tag value can be computed 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 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 DS records can be used to help select the corresponding DNSKEY RR
efficiently when more than one candidate DNSKEY RR is available. efficiently when more than one candidate DNSKEY RR is available.
For most algorithms the Key Tag is a simple 16-bit modular sum of For most algorithms the Key Tag is a simple 16-bit modular sum of
the DNSKEY RDATA. See [RFC4034] Appendix B. the DNSKEY RDATA. See [RFC4034] Appendix B.
4. Option Format 4. Using the edns-key-tag Option
4.1. Option Format
The edns-key-tag option is encoded as follows: The edns-key-tag option is encoded as follows:
0 8 16 0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE | | OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH | | OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY-TAG | | KEY-TAG |
skipping to change at page 5, line 11 skipping to change at page 5, line 40
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where: where:
OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD].
OPTION-LENGTH: The value 2 x number of key-tag values present. 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). KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).
5. Use By Queriers 4.2. Use By Queriers
A validating end-system resolver sets the edns-key-tag option in the A validating resolver sets the edns-key-tag option in the OPT meta-RR
OPT meta-RR when sending a DNSKEY query. The validating end-system when sending a DNSKEY query. The validating resolver SHOULD also set
resolver SHOULD also set the DNSSEC OK bit [RFC4034] to indicate that the DNSSEC OK bit [RFC4034] to indicate that it wishes to receive
it wishes to receive DNSSEC RRs in the response. DNSSEC RRs in the response.
A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY
queries. queries.
The KEY-TAG value(s) included in the edns-key-tag option represent The KEY-TAG value(s) included in the edns-key-tag option represent
the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 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 validate the expected response. When the client sends a DNSKEY
query, the edns-key-tag option represents the Key Tag(s) of the 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 KSK(s) of the zone for which the server is authoritative. A
validating end-system resolver learns the Key Tag(s) of the KSK(s) validating resolver learns the Key Tag(s) of the KSK(s) from the
from the zone's DS record(s) (found in the parent), or from a zone's DS record(s) (found in the parent), or from a configured trust
configured trust anchor. anchor.
A DNS client SHOULD include the edns-key-tag option when issuing a A DNS client SHOULD include the edns-key-tag option when issuing a
DNSKEY query for a zone corresponding to a configured Trust Anchor. DNSKEY query for a zone corresponding to a configured Trust Anchor.
A DNS client MAY include the edns-key-tag option when issuing a 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 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via
DS records). Since some DNSSEC validators implement bottom-up DS records). Since some DNSSEC validators implement bottom-up
validation, non-Trust Anchor Key Tags zone might not be known at the validation, 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 time of the query. Such a validator can include the edns-key-tag
option based on previously cached data. option based on previously cached data.
A DNS client MUST NOT include Key Tag(s) for keys which are not A DNS client MUST NOT include Key Tag(s) for keys which are not
learned via either configured Trust Anchor or DS records. learned via either configured Trust Anchor or DS records.
Since the edns-key-tag option is only set in the query, if a client 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 sees these options in the response, no action needs to be taken and
the client MUST ignore the option values. the client MUST ignore the option values.
5.1. Stub Resolvers 4.2.1. Stub Resolvers
Typically, stub resolvers rely on an upstream recursive server (or Typically, stub resolvers rely on an upstream recursive server (or
cache) to provide a response. Optimal setting of the edns-key-tag cache) to provide a response. Optimal setting of the edns-key-tag
option depends on whether the stub resolver elects to perform its own option depends on whether the stub resolver elects to perform its own
validation. validation.
5.1.1. Validating Stub Resolvers 4.2.1.1. Validating Stub Resolvers
A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to
indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG
RRs) in the response. Such validating resolvers SHOULD include the RRs) in the response. Such validating resolvers SHOULD include the
edns-key-tag option in the OPT RR when sending a DNSKEY query. edns-key-tag option in the OPT RR when sending a DNSKEY query.
5.1.2. Non-validating Stub Resolvers 4.2.1.2. Non-validating Stub Resolvers
The edns-key-tag option MUST NOT be included by non-validating stub The edns-key-tag option MUST NOT be included by non-validating stub
resolvers. resolvers.
5.2. Recursive Resolvers 4.2.2. Recursive Resolvers
4.2.2.1. Validating Recursive Resolvers
5.2.1. Validating Recursive Resolvers
A validating recursive resolver is, by definition, configured with at A validating recursive resolver is, by definition, configured with at
least one trust anchor. Thus, a recursive resolver SHOULD include least one trust anchor. Thus, a recursive resolver SHOULD include
the edns-key-tag option in its DNSKEY queries as described above. the edns-key-tag option in its DNSKEY queries as described above.
In addition, the clients of a validating recursive resolver might be In addition, the clients of a validating recursive resolver might be
configured to do their own validation, with their own trust configured to do their own validation, with their own trust
anchor(s). When a validating recursive resolver receives a query anchor(s). When a validating recursive resolver receives a query
that includes the edns-key-tag option with a Key Tag list that 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 differs from its own, it SHOULD forward both the client's Key Tag
skipping to change at page 7, line 5 skipping to change at page 7, line 36
number of Key Tags to include in the outgoing edns-key-tag option. number of Key Tags to include in the outgoing edns-key-tag option.
If the client included the DO and Checking Disabled (CD) bits, but If the client included the DO and Checking Disabled (CD) bits, but
did not include the edns-key-tag option in the query, the validating 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 recursive resolver MAY include the option with its own Key Tag values
in full. in full.
Validating recursive resolvers MUST NOT set the edns-key-tag option Validating recursive resolvers MUST NOT set the edns-key-tag option
in the final response to the stub client. in the final response to the stub client.
5.2.2. Non-validating Recursive Resolvers 4.2.2.2. Non-validating Recursive Resolvers
Recursive resolvers that do not validate responses SHOULD copy the Recursive resolvers that do not validate responses SHOULD copy the
edns-key-tag option seen in received queries, as they represent the edns-key-tag option seen in received queries, as they represent the
wishes of the validating downstream resolver that issued the original wishes of the validating downstream resolver that issued the original
query. query.
6. Use By Responders 4.3. Use By Responders
An authoritative name server receiving queries with the edns-key-tag An authoritative name server receiving queries with the edns-key-tag
option MAY log or otherwise collect the Key Tag values to provide option MAY log or otherwise collect the Key Tag values to provide
information to the zone operator. information to the zone operator.
A responder MUST NOT include the edns-key-tag option in any DNS A responder MUST NOT include the edns-key-tag option in any DNS
response. response.
7. IANA Considerations 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 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.
A validating DNS resolver that has a three trust anchors for the
example.com zone with key tags 31589, 43547, 31406 (decimal) would
originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-7b65-
aa1b-7aa3.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 configured
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 represent the Key Tag(s)
of the Trust Anchor that will be used to validate the expected DNSKEY
response.
A DNS validating 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. Unless the zone operator has intentionally added
"_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN
response. 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. [ Note RFC1035 says NULL
RRs are not allowed in master files, but I believe that to be
incorrect ]
5.3.1. Interaction With Aggressive Negative Caching
Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec-
aggressiveuse] 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.
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
_ta-2222-1111 IN NULL \# 0
[ most likely someone will suggest that key tag values should be
ordered to reduce the record count from 4 to 3 ]
6. IANA Considerations
The IANA is directed to assign an EDNS0 option code for the edns-key- The IANA is directed to assign an EDNS0 option code for the edns-key-
tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: tag option from the DNS EDNS0 Option Codes (OPT) registry as follows:
+-------+--------------+----------+-----------------+ +-------+--------------+----------+-----------------+
| Value | Name | Status | Reference | | Value | Name | Status | Reference |
+-------+--------------+----------+-----------------+ +-------+--------------+----------+-----------------+
| [TBA] | edns-key-tag | Optional | [This document] | | [TBA] | edns-key-tag | Optional | [This document] |
+-------+--------------+----------+-----------------+ +-------+--------------+----------+-----------------+
8. Security Considerations 7. Security Considerations
This document specifies a way for a client to signal its trust anchor This document specifies a way for a client to signal its trust anchor
knowledge to a cache or server. The signals are optional codes knowledge to a cache or server. The goal of these optional
contained in the OPT meta-RR used with EDNS. The goal of these mechanisms is to signal new trust anchor uptake in clients to allow
options is to signal new trust anchor uptake in clients to allow zone zone administrators to know when it is possible to complete a key
administrators to know when it is possible to complete a key rollover rollover in a DNSSEC-signed zone.
in a DNSSEC-signed zone.
There is a possibility that an eavesdropper or server could infer the There is a possibility that an eavesdropper or server could infer the
validator in use by a client by the Key Tag list seen in queries. validator in use by a client by the Key Tag list seen. This may
This may allow an attacker to find validators using old, possibly allow an attacker to find validators using old, possibly broken,
broken, keys. It could also be used to identify the validator or keys. It could also be used to identify the validator or narrow down
narrow down the possible validator implementations in use by a the possible validator implementations in use by a client, which
client, which could have a known vulnerability that could be could have a known vulnerability that could be exploited by the
exploited by the attacker. attacker.
Consumers of data collected from the edns-key-tag option are advised Consumers of data collected from the mechanisms are advised that
that provided Key Tag values might be "made up" by some DNS clients provided Key Tag values might be "made up" by some DNS clients with
with malicious or at least mischievous intentions. For example, an malicious or at least mischievous intentions. For example, an
attacker with sufficient resources might try to generate large attacker with sufficient resources might try to generate large
numbers of queries including only old Key Tag values, with the numbers of queries including only old Key Tag values, with the
intention of delaying the completion of a key rollover. intention of delaying the completion of a key rollover.
DNSSEC does not require keys in a zone to have unique Key Tags. 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 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 new key will have identical Key Tag values. Zone operators relying
on the edns-key-tag mechanism SHOULD take care to ensure that new on the edns-key-tag mechanism SHOULD take care to ensure that new
keys have unique Key Tag values. keys have unique Key Tag values.
9. Privacy Considerations 8. Privacy Considerations
This proposal adds additional, optional "signaling" to DNS queries in This proposal adds additional, optional "signaling" to DNS queries in
the form of Key Tag values. While Key Tag values themselves are not the form of Key Tag values. While Key Tag values themselves are not
considered private information, it may be possible for an considered private information, it may be possible for an
eavesdropper to use Key Tag values as a fingerprinting technique to eavesdropper to use Key Tag values as a fingerprinting technique to
identify particular DNS validating clients. This may be especially identify particular DNS validating clients. This may be especially
true if the validator is configured with trust anchor for zones in true if the validator is configured with trust anchor for zones in
addition to the root zone. addition to the root zone.
A validating end-system resolver need not transmit the edns-key-tag A validating resolver need not transmit the key tags in every
option in every applicable query. Due to privacy concerns, such a applicable query. Due to privacy concerns, such a resolver MAY
resolver MAY choose to transmit the edns-key-tag option for a subset choose to transmit the key tags for a subset of queries (e.g., every
of queries (e.g., every 25th time), or by random chance with a 25th time), or by random chance with a certain probability (e.g.,
certain probability (e.g., 5%). 5%).
Implementations of this specification MAY be administratively Implementations of this specification MAY be administratively
configured to only transmit the edns-key-tag option for certain configured to only transmit the key tags for certain zones. For
zones. For example, the software's configuration file may specify a example, the software's configuration file may specify a list of
list of zones for which use of the option is allowed or denied. zones for which use of the mechanisms described here is allowed or
Since the primary motivation for this specification is to provide denied. Since the primary motivation for this specification is to
operational measurement data for root zone key rollovers, it is provide operational measurement data for root zone key rollovers, it
RECOMMENDED that implementations at least include the edns-key-tag is RECOMMENDED that implementations at least include the edns-key-tag
option for root zone DNSKEY queries. option for root zone DNSKEY queries.
10. Acknowledgments 9. Acknowledgments
This document was inspired by and borrows heavily from [RFC6975] by This document was inspired by and borrows heavily from [RFC6975] by
Scott Rose and Steve Crocker. The authors would like to thank Casey Scott Rose and Steve Crocker. The authors would like to thank Mark
Deccio, Burt Kalisky, Bob Harold, Tim Wicinski, Suzanne Woolf, and Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
other members of the dnsop working group for their input. Wicinski, Suzanne Woolf, and other members of the dnsop working group
for their input.
11. References 10. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 10.1. Normative References
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <http://www.rfc-editor.org/info/rfc4035>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ for DNS (EDNS(0))", STD 75, RFC 6891,
RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
11.2. Informative References 10.2. Informative References
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
Algorithm Understanding in DNS Security Extensions Algorithm Understanding in DNS Security Extensions
(DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
<http://www.rfc-editor.org/info/rfc6975>. <http://www.rfc-editor.org/info/rfc6975>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication] [RFC Editor: Please remove this section before publication]
From -01 to -02:
o Added QNAME-based method of signaling key tags.
o Added Paul Hoffman as coauthor.
From -00 to -01: From -00 to -01:
o Changed how a recursive should combine a stub's key tag values o Changed how a recursive should combine a stub's key tag values
with its own. Previously it was to be a union of key tag values. with its own. Previously it was to be a union of key tag values.
Now it is a separate instance of the option code for recursive and Now it is a separate instance of the option code for recursive and
stub. stub.
o Added Warren as coauthor. o Added Warren as coauthor.
Authors' Addresses Authors' Addresses
skipping to change at line 434 skipping to change at page 13, line 4
Email: dwessels@verisign.com Email: dwessels@verisign.com
URI: http://verisigninc.com URI: http://verisigninc.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
United States United States
Email: warren@kumari.net Email: warren@kumari.net
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
 End of changes. 38 change blocks. 
118 lines changed or deleted 246 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/