--- 1/draft-ietf-dnsop-edns-key-tag-04.txt 2017-02-16 15:13:09.182736822 -0800 +++ 2/draft-ietf-dnsop-edns-key-tag-05.txt 2017-02-16 15:13:09.206737394 -0800 @@ -1,50 +1,50 @@ Internet Engineering Task Force D. Wessels Internet-Draft Verisign Intended status: Standards Track W. Kumari -Expires: July 21, 2017 Google +Expires: August 20, 2017 Google P. Hoffman ICANN - January 17, 2017 + February 16, 2017 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) - draft-ietf-dnsop-edns-key-tag-04 + draft-ietf-dnsop-edns-key-tag-05 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 (see Section 1.1 for the - rationale). The data from such signaling allow zone administrators - to monitor the progress of rollovers in a DNSSEC-signed zone. + 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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 @@ -60,36 +60,35 @@ 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 4.2.1.2. Non-validating Stub 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.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.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Interaction With Aggressive Negative Caching . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 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 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and [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 RR using a formula not unlike a @@ -373,23 +373,21 @@ 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 wildcard. 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 ] + frequency of key tag queries from clients. 5.3.1. Interaction With Aggressive Negative Caching Aggressive NSEC/NSEC3 negative caching [draft-ietf-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. @@ -475,72 +474,62 @@ 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. 10. References 10.1. Normative References [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, . [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, + . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. + RFC 4034, DOI 10.17487/RFC4034, March 2005, + . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . [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, + . 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) - Trust Anchors", STD 74, RFC 5011, September 2007. + Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, + September 2007, . [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, . - [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 Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 United States Phone: +1 703 948-3200 Email: dwessels@verisign.com