DNSSEC Operational Practices
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, dnsop mailing list <firstname.lastname@example.org>, dnsop chair <email@example.com> Subject: Document Action: 'DNSSEC Operational Practices' to Informational RFC The IESG has approved the following document: - 'DNSSEC Operational Practices ' <draft-ietf-dnsop-dnssec-operational-practices-09.txt> as an Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-operational-practices-09.txt
Technical Summary This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues as key generation, key storage, signature generation, key rollover and related policies. Working Group Summary The draft has been reviewed by many members of the community, including operators and crypto experts. It was last called in the WG twice. The earlier WGLC lead to a long list of open issues which were dealt with in detail on the WG mailing list. The chairs do not have any concerns about either depth or breadth of the review. Protocol Quality David Kessens reviewed this document for the IESG. Note to RFC Editor 1) 3.4. Key Algorithm, 4th paragraph OLD: We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing (theoretical) cracks, we recommend the usage of SHA-1. NEW: We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing cracks, we recommend the usage of SHA-1. 2) 1. Introduction, last paragraph before 1.1 OLD: This document obsoletes RFC 2541 . NEW: This document obsoletes RFC 2541  to reflect the evolution of the underlying DNSSEC protocol since then. Changes in the choice of cryptographic algorithms, DNS record types and type names, and the parent-child key and signature exchange demanded a major rewrite and additional information and explanation.