RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors | RFC Editor

Skip to content Primary navigationThe RFC SeriesFor AuthorsAbout UsHomeRFC 5011 View as: Plain Text, Compact HTML Info RFC 5011: STD 74: Automated Updates of DNS Security (DNSSEC) Trust AnchorsDNSSECSeptember 2007. M. StJohnsInternet StandardSubscribe24 subscribed Add to Set Added to 5 Sets Read aloud Network Working Group M. StJohns Request for Comments: 5011 Independent Category: Standards Track September 2007 Automated Updates of DNS Security (DNSSEC) Trust Anchors Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. StJohns Standards Track [Page 1] RFC 5011 Trust Anchor Update September 2007 Table of Contents 1. Introduction ....................................................2 1.1. Compliance Nomenclature ....................................3 2. Theory of Operation .............................................3 2.1. Revocation .................................................4 2.2. Add Hold-Down ..............................................4 2.3. Active Refresh .............................................5 2.4. Resolver Parameters ........................................6 2.4.1. Add Hold-Down Time ..................................6 2.4.2. Remove Hold-Down Time ...............................6 2.4.3. Minimum Trust Anchors per Trust Point ...............6 3. Changes to DNSKEY RDATA Wire Format .............................6 4. State Table .....................................................6 4.1. Events .....................................................7 4.2. States .....................................................7 5. Trust Point Deletion ............................................8 6. Scenarios - Informative .........................................9 6.1. Adding a Trust Anchor ......................................9 6.2. Deleting a Trust Anchor ....................................9 6.3. Key Roll-Over .............................................10 6.4. Active Key Compromised ....................................10 6.5. Stand-by Key Compromised ..................................10 6.6. Trust Point Deletion ......................................10 7. IANA Considerations ............................................11 8. Security Considerations ........................................11 8.1. Key Ownership vs. Acceptance Policy .......................11 8.2. Multiple Key Compromise ...................................12 8.3. Dynamic Updates ...........................................12 9. Normative References ...........................................12 10. Informative References ........................................12 1. Introduction As part of the reality of fielding DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has come to the realization that there will not be one signed name space, but rather islands of signed name spaces each originating from specific points (i.e., 'trust points') in the DNS tree. Each of those islands will be identified by the trust point name, and validated by at least one associated public key. For the purpose of this document, we'll call the association of that name and a particular key a 'trust anchor'. A particular trust point can have more than one key designated as a trust anchor. For a DNSSEC-aware resolver to validate information in a DNSSEC protected branch of the hierarchy, it must have knowledge of a trust anchor applicable to that branch. It may also have more than one StJohns Standards Track [Page 2] RFC 5011 Trust Anchor Update September 2007 trust anchor for any given trust point. Under current rules, a chain of trust for DNSSEC-protected data that chains its way back to ANY known trust anchor is considered 'secure'. Because of the probable balkanization of the DNSSEC tree due to signing voids at key locations, a resolver may need to know literally thousands of trust anchors to perform its duties (e.g., consider an unsigned ".COM"). Requiring the owner of the resolver to manually manage these many relationships is problematic. It's even more problematic when considering the eventual requirement for key replacement/update for a given trust anchor. The mechanism described herein won't help with the initial configuration of the trust anchors in the resolvers, but should make trust point key replacement/rollover more viable. As mentioned above, this document describes a mechanism whereby a resolver can update the trust anchors for a given trust point, mainly without human intervention at the resolver. There are some corner cases discussed (e.g., multiple key compromise) that may require manual intervention, but they should be few and far between. This document DOES NOT discuss the general problem of the initial configuration of trust anchors for the resolver. 1.1. Compliance Nomenclature 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 BCP 14, [RFC2119]. 2. Theory of Operation The general concept of this mechanism is that existing trust anchors can be used to authenticate new trust anchors at the same poin