draft-ietf-dnsop-edns-key-tag-04.txt   draft-ietf-dnsop-edns-key-tag-05.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: July 21, 2017 Google Expires: August 20, 2017 Google
P. Hoffman P. Hoffman
ICANN ICANN
January 17, 2017 February 16, 2017
Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
draft-ietf-dnsop-edns-key-tag-04 draft-ietf-dnsop-edns-key-tag-05
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 (see Section 1.1 for the referenced in their chain-of-trust. The data from such signaling
rationale). The data from such signaling allow zone administrators allow zone administrators to monitor the progress of rollovers in a
to monitor the progress of rollovers in a DNSSEC-signed zone. DNSSEC-signed zone.
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 July 21, 2017. This Internet-Draft will expire on August 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . 6
4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 11
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
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
skipping to change at page 9, line 14 skipping to change at page 9, line 11
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. A server does not need to have built-in logic 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 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 determined by whether the data is in the zone file or covered by
wildcard. The zone operator might want to add specific key tag 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.
RRs are not allowed in master files, but I believe that to be
incorrect ]
5.3.1. Interaction With Aggressive Negative Caching 5.3.1. Interaction With Aggressive Negative Caching
Aggressive NSEC/NSEC3 negative caching Aggressive NSEC/NSEC3 negative caching
[draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of [draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of
key tag signaling. When the response code for a key tag query is key tag signaling. When the response code for a key tag query is
NXDOMAIN, DNS resolvers that implement aggressive negative caching NXDOMAIN, DNS resolvers that implement aggressive negative caching
will send fewer key tag queries than resolvers that do not implement will send fewer key tag queries than resolvers that do not implement
it. it.
skipping to change at page 11, line 21 skipping to change at page 11, line 18
Scott Rose and Steve Crocker. The authors would like to thank Mark Scott Rose and Steve Crocker. The authors would like to thank Mark
Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
Wicinski, Suzanne Woolf, and other members of the dnsop working group Wicinski, Suzanne Woolf, and other members of the dnsop working group
for their input. for their input.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<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, March 2005. 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. [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, March 2005. 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 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<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, September 2007. 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 [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>.
[draft-ietf-dnsop-nsec-aggressiveuse]
Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016.
Appendix A. Changes / Author Notes.
[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:
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.
Now it is a separate instance of the option code for recursive and
stub.
o Added Warren as coauthor.
Authors' Addresses Authors' Addresses
Duane Wessels Duane Wessels
Verisign Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States United States
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
 End of changes. 18 change blocks. 
43 lines changed or deleted 30 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/