Network Working Group D. Eastlake
Request for Comments: 2541 IBM
Category: Informational March 1999
Network Working Group D. Eastlake
Request for Comments: 2541 IBM
Category: Informational March 1999
DNS Security Operational Considerations
DNS安全操作注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.
安全DNS基于加密技术。这些技术的一个必要优势是仔细关注密钥和签名生成、生存期、大小和存储的操作方面。此外，必须特别注意高级别区域，特别是根区域的安全。本文档讨论与密钥和SIG DNS资源记录相关的密钥和签名的这些操作方面。
Acknowledgments
致谢
The contributions and suggestions of the following persons (in alphabetic order) are gratefully acknowledged:
感谢以下人士（按字母顺序）的贡献和建议：
John Gilmore Olafur Gudmundsson Charlie Kaufman
约翰·吉尔莫·奥拉福尔·古德蒙森·查理·考夫曼
Table of Contents
目录
Abstract...................................................1
Acknowledgments............................................1
1. Introduction............................................2
2. Public/Private Key Generation...........................2
3. Public/Private Key Lifetimes............................2
4. Public/Private Key Size Considerations..................3
4.1 RSA Key Sizes..........................................3
4.2 DSS Key Sizes..........................................4
5. Private Key Storage.....................................4
6. High Level Zones, The Root Zone, and The Meta-Root Key..5
7. Security Considerations.................................5
References.................................................6
Author's Address...........................................6
Full Copyright Statement...................................7
Abstract...................................................1
Acknowledgments............................................1
1. Introduction............................................2
2. Public/Private Key Generation...........................2
3. Public/Private Key Lifetimes............................2
4. Public/Private Key Size Considerations..................3
4.1 RSA Key Sizes..........................................3
4.2 DSS Key Sizes..........................................4
5. Private Key Storage.....................................4
6. High Level Zones, The Root Zone, and The Meta-Root Key..5
7. Security Considerations.................................5
References.................................................6
Author's Address...........................................6
Full Copyright Statement...................................7
This document describes operational considerations for the generation, lifetime, size, and storage of DNS cryptographic keys and signatures for use in the KEY and SIG resource records [RFC 2535]. Particular attention is paid to high level zones and the root zone.
本文档描述了用于密钥和SIG资源记录的DNS加密密钥和签名的生成、生存期、大小和存储的操作注意事项[RFC 2535]。特别注意高层区域和根部区域。
Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in [RFC 1750].
在任何加密安全系统中，仔细地生成所有密钥有时是一个被忽略但绝对必要的元素。如果对手能够猜出足够多的信息来降低可能的密钥空间的大小，以便对其进行彻底搜索，那么使用最长密钥的最强算法仍然没有用处。生成随机密钥的技术建议见[RFC 1750]。
Long term keys are particularly sensitive as they will represent a more valuable target and be subject to attack for a longer time than short period keys. It is strongly recommended that long term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high level secure hardware.
长期密钥特别敏感，因为它们将代表一个更有价值的目标，并且比短期密钥更容易受到攻击。强烈建议通过气隙或至少高级别的安全硬件以与网络隔离的方式离线生成长期密钥。
No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, if
任何钥匙都不应该永远使用。密钥使用的时间越长，由于疏忽、事故、间谍活动或密码分析而被泄露的可能性就越大。此外，如果
key rollover is a rare event, there is an increased risk that, when the time does come to change the key, no one at the site will remember how to do it or operational problems will have developed in the key rollover procedures.
钥匙翻车是一种罕见的事件，在更换钥匙的时候，现场没有人会记得如何操作，或者钥匙翻车程序中会出现操作问题，这是一种增加的风险。
While public key lifetime is a matter of local policy, these considerations imply that, unless there are extraordinary circumstances, no long term key should have a lifetime significantly over four years. In fact, a reasonable guideline for long term keys that are kept off-line and carefully guarded is a 13 month lifetime with the intent that they be replaced every year. A reasonable maximum lifetime for keys that are used for transaction security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In many cases, a key lifetime of somewhat over a day may be reasonable.
虽然公钥的生命周期是当地政策的问题，但这些考虑意味着，除非有特殊情况，否则任何长期密钥的生命周期都不应明显超过四年。事实上，对于长期处于离线状态并受到仔细保护的钥匙，合理的指导原则是使用寿命为13个月，并打算每年更换一次。用于交易安全或类似用途并保持在线的密钥的合理最长使用期限为36天，目的是每月或更频繁地更换密钥。在许多情况下，一天多一点的关键生命周期可能是合理的。
On the other hand, public keys with too short a lifetime can lead to excessive resource consumption in re-signing data and retrieving fresh information because cached information becomes stale. In the Internet environment, almost all public keys should have lifetimes no shorter than three minutes, which is a reasonable estimate of maximum packet delay even in unusual circumstances.
另一方面，生命周期太短的公钥会导致在重新签名数据和检索新信息时过度消耗资源，因为缓存的信息会过时。在Internet环境中，几乎所有公钥的生命周期都不应小于3分钟，这是对最大数据包延迟的合理估计，即使在异常情况下也是如此。
There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of zone key size should generally be made by the zone administrator depending on their local conditions.
有许多因素会影响在DNS安全扩展中使用的公钥大小选择。不幸的是，这些因素通常并不都指向同一个方向。区域密钥大小的选择通常应由区域管理员根据其本地条件进行。
For most schemes, larger keys are more secure but slower. In addition, larger keys increase the size of the KEY and SIG RRs. This increases the chance of DNS UDP packet overflow and the possible necessity for using higher overhead TCP in responses.
对于大多数方案，较大的密钥更安全，但速度较慢。此外，较大的键会增加键和SIG RRs的大小。这增加了DNS UDP数据包溢出的可能性，并且可能需要在响应中使用更高开销的TCP。
Given a small public exponent, verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the 1.6 power of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but may increase the work factor of breaking the key by over 2^900.
给定一个小的公共指数，MD5/RSA算法的验证（最常见的操作）将大致随模长度的平方而变化，签名将随模长度的立方而变化，密钥生成（最不常见的操作）将随模长度的四次方而变化。当前用于分解模和破坏RSA安全性的最佳算法大致随模本身的1.6次方而变化。因此，从640位模变为1280位模只会将验证时间增加4倍，但可能会将断开密钥的功因数增加2^900以上。
The recommended minimum RSA algorithm modulus size is 704 bits which is believed by the author to be secure at this time. But high level zones in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.)
推荐的最小RSA算法模数大小为704位，作者认为这是安全的。但出于安全原因，DNS树中的高级区域可能希望设置更高的最小值，可能是1000位。（由于美国国家安全局通常允许出口使用高达512位的RSA模的加密系统，因此必须考虑使用较小的模，即n。）
For an RSA key used only to secure data and not to secure other keys, 704 bits should be adequate at this time.
对于仅用于保护数据而不用于保护其他密钥的RSA密钥，此时704位应该足够了。
DSS keys are probably roughly as strong as an RSA key of the same length but DSS signatures are significantly smaller.
DSS密钥可能与长度相同的RSA密钥一样强，但DSS签名要小得多。
It is recommended that, where possible, zone private keys and the zone file master copy be kept and used in off-line, non-network connected, physically secure machines only. Periodically an application can be run to add authentication to a zone by adding SIG and NXT RRs and adding no-key type KEY RRs for subzones/algorithms where a real KEY RR for the subzone with that algorithm is not provided. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine.
建议在可能的情况下，仅在离线、非网络连接、物理安全的机器上保存和使用区域私钥和区域文件主副本。可以定期运行应用程序，通过添加SIG和NXT RRs并为子区域/算法添加无密钥类型密钥RRs向区域添加身份验证，其中未提供具有该算法的子区域的真实密钥RR。然后，可能通过sneaker net将扩充文件传输到联网区域主服务器机器。
The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication.
其想法是让信息单向流向网络，以避免网络篡改的可能性。在网络上保持区域主文件在线，并通过离线签名者简单地循环该文件不会做到这一点。如果在线版本所在的主机被破坏，在线版本仍然可能被篡改。为了最大限度地提高安全性，区域文件的主副本应为离线，并且不应基于不安全的网络中介通信进行更新。
This is not possible if the zone is to be dynamically updated securely [RFC 2137]. At least a private key capable of updating the SOA and NXT chain must be on line in that case.
如果要安全地动态更新区域，这是不可能的[RFC 2137]。在这种情况下，必须至少有一个能够更新SOA和NXT链的私钥在线。
Secure resolvers must be configured with some trusted on-line public key information (or a secure path to such a resolver) or they will be unable to authenticate. Although on line, this public key information must be protected or it could be altered so that spoofed DNS data would appear authentic.
安全解析程序必须配置一些受信任的在线公钥信息（或此类解析程序的安全路径），否则它们将无法进行身份验证。虽然是在线的，但必须保护此公钥信息，或者对其进行更改，以便伪造的DNS数据看起来是真实的。
Non-zone private keys, such as host or user keys, generally have to be kept on line to be used for real-time purposes such as DNS transaction security.
非区域私钥，如主机或用户密钥，通常必须保持在线，以便用于实时目的，如DNS交易安全。
Higher level zones are generally more sensitive than lower level zones. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, extra care should be taken with high level zones and strong keys used.
较高级别的区域通常比较低级别的区域更敏感。因此，任何控制或破坏区域安全的人都可以获得其所有子域的权限（已在本地配置子域公钥的解析程序除外）。因此，应特别注意使用高级区域和强键。
The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS name space of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off line.
根区域是所有区域中最关键的区域。控制或破坏根区域安全性的人将控制使用该根区域的所有解析程序的整个DNS名称空间（本地配置了子域公钥的解析程序除外）。因此，在保护根部区域时必须格外小心。应使用最结实、处理最仔细的钥匙。根区域私钥应始终保持脱机状态。
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating an enormous population of resolvers around the world will be extremely difficult. Yet the guidelines in section 3 above would imply that the root zone private key be changed annually or more often and if it were staticly configured at all these resolvers, it would have to be updated when changed.
许多解析程序将在根服务器上启动，以访问和验证DNS数据。安全地更新世界各地大量的解析器将是极其困难的。然而，上面第3节中的指导原则意味着根区域私钥每年或更频繁地更改一次，如果在所有这些冲突解决程序中对其进行静态配置，则必须在更改时对其进行更新。
To permit relatively frequent change to the root zone key yet minimize exposure of the ultimate key of the DNS tree, there will be a "meta-root" key used very rarely and then only to sign a sequence of regular root key RRsets with overlapping time validity periods that are to be rolled out. The root zone contains the meta-root and current regular root KEY RR(s) signed by SIG RRs under both the meta-root and other root private key(s) themselves.
为了允许对根区域密钥进行相对频繁的更改，同时最大限度地减少DNS树的最终密钥的暴露，将很少使用“元根”密钥，然后仅对具有重叠时间有效期的常规根密钥RRSET序列进行签名，这些RRSET将被推出。根区域包含由SIG RRs在元根和其他根私钥下签名的元根和当前常规根密钥RR。
The utmost security in the storage and use of the meta-root key is essential. The exact techniques are precautions to be used are beyond the scope of this document. Because of its special position, it may be best to continue with the same meta-root key for an extended period of time such as ten to fifteen years.
元根密钥的存储和使用的最高安全性至关重要。使用的确切技术和预防措施超出了本文件的范围。由于其特殊的位置，最好使用相同的元根键继续使用一段较长的时间，例如10到15年。
The entirety of this document is concerned with operational considerations of public/private key pair DNS Security.
本文档的全部内容涉及到公钥/私钥对DNS安全的操作注意事项。
References
工具书类
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035]Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 1035，1987年11月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.
[RFC 1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全的随机性要求”，RFC 1750，1994年12月。
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065]Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC 2065，1997年1月。
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC 2137]Eastlake，D.，“安全域名系统动态更新”，RFC 2137，1997年4月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
[RSA FAQ]RSADSI常见问题定期发布。
Author's Address
作者地址
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512
纽约州卡梅尔市新德干山路65号东湖第三IBM公司，邮编10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。