idnits 2.17.1 draft-weiler-dnssec-dlv-iana-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 174. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2007) is 6138 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-weiler-dnssec-dlv-03 ** Downref: Normative reference to an Historic draft: draft-weiler-dnssec-dlv (ref. 'I-D.weiler-dnssec-dlv') -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Weiler 2 Internet-Draft SPARTA, Inc. 3 Expires: January 2, 2008 July 1, 2007 5 DNSSEC Lookaside Validation (DLV) IANA Registry 6 draft-weiler-dnssec-dlv-iana-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 2, 2008. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 DNSSEC Lookaside Validation (DLV) is a mechanism for publishing 40 DNSSEC trust anchors outside of the DNS delegation chain. This 41 document asks IANA to create a DLV registry containing entries for 42 TLDs as well as the reverse-tree delegations maintained by IANA. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 49 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4.1. Normative References . . . . . . . . . . . . . . . . . . . 4 51 4.2. Informative References . . . . . . . . . . . . . . . . . . 4 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 Intellectual Property and Copyright Statements . . . . . . . . . . 5 55 1. Introduction 57 This document assumes familiarity with DNSSEC Lookaside Validation 58 (DLV) [I-D.weiler-dnssec-dlv] as well as the core DNSSEC 59 specifications [RFC4033] [RFC4034] [RFC4035]. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 2. IANA Considerations 67 IANA is asked to create a DLV registry at dlv.dnssec.arpa targeting 68 the root and containing DLV records for those TLDs and reverse zones 69 delegated directly by IANA that ask to have DLV records published for 70 their own zones. 72 IANA is instructed to use its own best practices for authenticating 73 zone operators' requests to insert, modify, and delete DLV entries. 75 This DLV registry MUST itself be signed with DNSSEC. 77 To be clear, IANA is only being asked to publish DLV records for top 78 level domains and reverse zones delegated directly from IANA, thereby 79 taking advantage of the IANA's existing relationships with the these 80 zone operations and established procedures for authenticating 81 requests from these zone operators. 83 3. Security Considerations 85 General security considerations for DLV are discussed in 86 [I-D.weiler-dnssec-dlv]. 88 A DLV registry is a signed zone, much like any other. IANA is asked 89 to use ordinary operating procedures for this signed zone, as 90 described in [RFC4641]. In particular, it is suggested that IANA use 91 2048-bit RSA keys for both the KSK and ZSKs in this zone and roll the 92 KSK at least once per year for the first four years this registry is 93 in operation. (The ZSK will presumably be rolled somewhat more 94 often.) IANA is encouraged to generate several KSKs for this zone 95 immediately and publish a hash of each of those keys, perhaps in the 96 form of a DS record, at the time the registry goes into production 97 service. 99 4. References 100 4.1. Normative References 102 [I-D.weiler-dnssec-dlv] 103 Weiler, S., "DNSSEC Lookaside Validation (DLV)", 104 draft-weiler-dnssec-dlv-03 (work in progress), July 2007. 106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 107 Requirement Levels", BCP 14, RFC 2119, March 1997. 109 4.2. Informative References 111 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 112 Rose, "DNS Security Introduction and Requirements", 113 RFC 4033, March 2005. 115 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 116 Rose, "Resource Records for the DNS Security Extensions", 117 RFC 4034, March 2005. 119 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 120 Rose, "Protocol Modifications for the DNS Security 121 Extensions", RFC 4035, March 2005. 123 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 124 RFC 4641, September 2006. 126 Author's Address 128 Samuel Weiler 129 SPARTA, Inc. 130 7110 Samuel Morse Drive 131 Columbia, Maryland 21046 132 US 134 Email: weiler@tislabs.com 136 Full Copyright Statement 138 Copyright (C) The IETF Trust (2007). 140 This document is subject to the rights, licenses and restrictions 141 contained in BCP 78, and except as set forth therein, the authors 142 retain all their rights. 144 This document and the information contained herein are provided on an 145 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 146 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 147 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 148 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 149 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 152 Intellectual Property 154 The IETF takes no position regarding the validity or scope of any 155 Intellectual Property Rights or other rights that might be claimed to 156 pertain to the implementation or use of the technology described in 157 this document or the extent to which any license under such rights 158 might or might not be available; nor does it represent that it has 159 made any independent effort to identify any such rights. Information 160 on the procedures with respect to rights in RFC documents can be 161 found in BCP 78 and BCP 79. 163 Copies of IPR disclosures made to the IETF Secretariat and any 164 assurances of licenses to be made available, or the result of an 165 attempt made to obtain a general license or permission for the use of 166 such proprietary rights by implementers or users of this 167 specification can be obtained from the IETF on-line IPR repository at 168 http://www.ietf.org/ipr. 170 The IETF invites any interested party to bring to its attention any 171 copyrights, patents or patent applications, or other proprietary 172 rights that may cover technology that may be required to implement 173 this standard. Please address the information to the IETF at 174 ietf-ipr@ietf.org. 176 Acknowledgment 178 Funding for the RFC Editor function is provided by the IETF 179 Administrative Support Activity (IASA).