draft-ietf-dnsop-edns-key-tag-02.txt   draft-ietf-dnsop-edns-key-tag-03.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: January 9, 2017 Google Expires: April 8, 2017 Google
P. Hoffman P. Hoffman
ICANN ICANN
July 8, 2016 October 5, 2016
Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
draft-ietf-dnsop-edns-key-tag-02 draft-ietf-dnsop-edns-key-tag-03
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 two different particular node in the DNS. This document specifies two different
ways for validating 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 data from such signaling referenced in their chain-of-trust. The data from such signaling
allow zone administrators to monitor the progress of rollovers in a allow zone administrators to monitor the progress of rollovers in a
DNSSEC-signed zone. DNSSEC-signed zone.
This document describes two independent methods for validating This document describes two independent methods for validating
resolvers to publish their referenced keys: an EDNS option and a resolvers to publish their referenced keys: an EDNS option and a
differnt DNS query. The reason there are two methods instead of one different DNS query. The reason there are two methods instead of one
is some people see significant problems with each method. Having two is some people see significant problems with each method. Having two
methods is clearly worse than having just one, but it is probably methods is clearly worse than having just one, but it is probably
better for the Internet than having no way to gain the information better for the Internet than having no way to gain the information
from the resolvers. from the resolvers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on April 8, 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5
4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6
4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6
4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6
4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 7
4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7
4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7
4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7
5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8
5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8
5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Interaction With Aggressive Negative Caching . . . . 9 5.3.1. Interaction With Aggressive Negative Caching . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
only sending QNAME-based key tag queries for configured trust only sending QNAME-based key tag queries for configured trust
anchors, although EDNS-based key tags can be sent with any DNSKEY anchors, although EDNS-based key tags can be sent with any DNSKEY
query. query.
Another downside to the QNAME-based approach is that since the trust Another downside to the QNAME-based approach is that since the trust
anchor zone might not contain labels matching the QNAME, these anchor zone might not contain labels matching the QNAME, these
queries could be subject to aggressive negative caching features now queries could be subject to aggressive negative caching features now
in development by the Working Group. This could affect the amount of in development by the Working Group. This could affect the amount of
signaling sent by some clients compared to others. 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.
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.
A validating security-aware resolver uses this public key or hash A validating security-aware resolver uses this public key or hash
skipping to change at page 8, line 13 skipping to change at page 8, line 16
response. response.
5. Using the Key Tag Query 5. Using the Key Tag Query
5.1. Query Format 5.1. Query Format
A key tag query consists of a standard DNS query of type NULL and of A key tag query consists of a standard DNS query of type NULL and of
class IN [RFC1035]. class IN [RFC1035].
The first component of the query name is the string "_ta-" followed The first component of the query name is the string "_ta-" followed
by a hyphen-separated list of hexadecimal-encoded Key Tag values. by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
The zone name corresponding to the trust anchor is appended to this values. The zone name corresponding to the trust anchor is appended
first component. to this first component.
For example, a validating DNS resolver that has a single root zone For example, a validating DNS resolver that has a single root zone
trust anchor with key tag 17476 (decimal) would originate a query of trust anchor with key tag 17476 (decimal) would originate a query of
the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444. the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
A validating DNS resolver that has a three trust anchors for the Hexadecimal values MUST be zero-padded. For example, if the key tag
example.com zone with key tags 31589, 43547, 31406 (decimal) would is 999 (decimal), it is represented in hexadecimal as 03e7.
originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-7b65-
aa1b-7aa3.example.com. When representing multiple key tag values, they MUST be sorted in
order from smallest to largest. For example, A validating DNS
resolver that has a 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 5.2. Use By Queriers
A validating DNS resolver (stub or recursive) SHOULD originate a key A validating DNS resolver (stub or recursive) SHOULD originate a key
tag query whenever it also originates a DNSKEY query for a configured 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 Trust Anchor zone. In other words, the need to issue a DNSKEY query
is also the trigger to issue a key tag 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) 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 of the Trust Anchor that will be used to validate the expected DNSKEY
skipping to change at page 8, line 52 skipping to change at page 9, line 12
DNS resolvers with caches SHOULD cache and reuse the response to a DNS resolvers with caches SHOULD cache and reuse the response to a
key tag query just as it would any other response. key tag query just as it would any other response.
5.3. Use By Responders 5.3. Use By Responders
An authoritative name server receiving key tag queries MAY log or An authoritative name server receiving key tag queries MAY log or
otherwise collect the Key Tag values to provide information to the otherwise collect the Key Tag values to provide information to the
zone operator. zone operator.
An authoritative name server MUST generate an appropriate response to An authoritative name server MUST generate an appropriate response to
the key tag query. Unless the zone operator has intentionally added the key tag query. A server does not need to have built-in logic
"_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN that determines the response to key tag queries: the response code is
response. The zone operator might want to add specific key tag determined by whether the data is in the zone file or covered by
wildcard. The zone operator might want to add specific key tag
records to its zone, perhaps with specific TTLs, to affect the records to its zone, perhaps with specific TTLs, to affect the
frequency of key tag queries from clients. [ Note RFC1035 says NULL frequency of key tag queries from clients. [ Note RFC1035 says NULL
RRs are not allowed in master files, but I believe that to be RRs are not allowed in master files, but I believe that to be
incorrect ] incorrect ]
5.3.1. Interaction With Aggressive Negative Caching 5.3.1. Interaction With Aggressive Negative Caching
Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec- Aggressive NSEC/NSEC3 negative caching
aggressiveuse] may also affect the quality of key tag signaling. [draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of
When the response code for a key tag query is NXDOMAIN, DNS resolvers key tag signaling. When the response code for a key tag query is
that implement aggressive negative caching will send fewer key tag NXDOMAIN, DNS resolvers that implement aggressive negative caching
queries than resolvers that do not implement it. will send fewer key tag queries than resolvers that do not implement
it.
For this reason, zone operators might choose to create records For this reason, zone operators might choose to create records
corresponding to expected key tag queries. During a rollover from corresponding to expected key tag queries. During a rollover from
key tag 1111 (hex) to key tag 2222 (hex), the zone could include the key tag 1111 (hex) to key tag 2222 (hex), the zone could include the
following records: following records:
_ta-1111 IN NULL \# 0 _ta-1111 IN NULL \# 0
_ta-2222 IN NULL \# 0 _ta-2222 IN NULL \# 0
_ta-1111-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 Recall that when multiple key tags are present, the originating
ordered to reduce the record count from 4 to 3 ] client MUST sort them from smallest to largest in the query name.
6. IANA Considerations 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] |
skipping to change at page 11, line 48 skipping to change at page 12, line 7
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, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
10.2. Informative References 10.2. Informative References
[draft-ietf-dnsop-nsec-aggressiveuse]
Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016.
[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.
 End of changes. 17 change blocks. 
27 lines changed or deleted 39 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/