Network Working Group B. Wellington
Request for Comments: 3007 Nominum
Updates: 2535, 2136 November 2000
Obsoletes: 2137
Category: Standards Track
Network Working Group B. Wellington
Request for Comments: 3007 Nominum
Updates: 2535, 2136 November 2000
Obsoletes: 2137
Category: Standards Track
Secure Domain Name System (DNS) Dynamic Update
安全域名系统（DNS）动态更新
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization.
本文档提出了一种执行安全域名系统（DNS）动态更新的方法。这里描述的方法旨在灵活且有用，同时需要对协议进行尽可能少的更改。动态更新消息的身份验证与数据的后期DNSSEC验证是分开的。基于经过身份验证的请求和事务的安全通信用于提供授权。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
1 - Introduction
1-导言
This document defines a means to secure dynamic updates of the Domain Name System (DNS), allowing only authorized sources to make changes to a zone's contents. The existing unsecured dynamic update operations form the basis for this work.
本文档定义了一种保护域名系统（DNS）动态更新的方法，仅允许授权来源对区域内容进行更改。现有的不安全动态更新操作构成了这项工作的基础。
Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update [RFC2136] is helpful and is assumed by this document. In addition, knowledge of DNS security extensions [RFC2535], SIG(0) transaction security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] is recommended.
熟悉DNS系统[RFC1034，RFC1035]和动态更新[RFC2136]是很有帮助的，本文档假设了这一点。此外，建议了解DNS安全扩展[RFC2535]、SIG（0）事务安全[RFC2535、RFC2931]和TSIG事务安全[RFC2845]。
This document updates portions of RFC 2535, in particular section 3.1.2, and RFC 2136. This document obsoletes RFC 2137, an alternate proposal for secure dynamic update, due to implementation experience.
本文件更新了RFC 2535的部分内容，特别是第3.1.2节和RFC 2136。由于实施经验，本文件淘汰了RFC 2137，这是安全动态更新的替代方案。
DNS dynamic update defines a new DNS opcode and a new interpretation of the DNS message if that opcode is used. An update can specify insertions or deletions of data, along with prerequisites necessary for the updates to occur. All tests and changes for a DNS update request are restricted to a single zone, and are performed at the primary server for the zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA.
DNS动态更新定义了一个新的DNS操作码和DNS消息的新解释（如果使用了该操作码）。更新可以指定数据的插入或删除，以及进行更新所需的先决条件。DNS更新请求的所有测试和更改仅限于单个区域，并在该区域的主服务器上执行。动态区域的主服务器必须在发生更新时或在下次检索SOA之前增加区域SOA序列号。
Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS requests and responses sent between them. A TSIG MAC (message authentication code) is derived from a shared secret, and a SIG(0) is generated from a private key whose public counterpart is stored in DNS. In both cases, a record containing the message signature/MAC is included as the final resource record in a DNS message. Keyed hashes, used in TSIG, are inexpensive to calculate and verify. Public key encryption, as used in SIG(0), is more scalable as the public keys are stored in DNS.
包括TSIG[RFC2845]或SIG（0）[RFC2535，RFC2931]记录的DNS消息交换允许两个DNS实体对它们之间发送的DNS请求和响应进行身份验证。TSIG MAC（消息认证码）源自共享密钥，SIG（0）源自私钥，私钥的公共副本存储在DNS中。在这两种情况下，包含消息签名/MAC的记录作为最终资源记录包含在DNS消息中。TSIG中使用的键控散列计算和验证成本较低。在SIG（0）中使用的公钥加密由于公钥存储在DNS中而更具可扩展性。
Message based authentication, using TSIG or SIG(0), provides protection for the entire message with a single signing and single verification which, in the case of TSIG, is a relatively inexpensive MAC creation and check. For update requests, this signature can establish, based on policy or key negotiation, the authority to make the request.
使用TSIG或SIG（0）的基于消息的身份验证通过单个签名和单个验证为整个消息提供保护，在TSIG的情况下，这是一种相对便宜的MAC创建和检查。对于更新请求，此签名可以基于策略或密钥协商建立发出请求的权限。
DNSSEC SIG records can be used to protect the integrity of individual RRs or RRsets in a DNS message with the authority of the zone owner. However, this cannot sufficiently protect the dynamic update request.
在区域所有者的授权下，DNSSEC SIG记录可用于保护DNS消息中单个RRs或RRSET的完整性。但是，这不能充分保护动态更新请求。
Using SIG records to secure RRsets in an update request is incompatible with the design of update, as described below, and would in any case require multiple expensive public key signatures and verifications.
在更新请求中使用SIG记录保护RRSET与如下所述的更新设计不兼容，并且在任何情况下都需要多个昂贵的公钥签名和验证。
SIG records do not cover the message header, which includes record counts. Therefore, it is possible to maliciously insert or remove RRsets in an update request without causing a verification failure.
SIG记录不包括包含记录计数的消息头。因此，有可能在更新请求中恶意插入或删除RRSET，而不会导致验证失败。
If SIG records were used to protect the prerequisite section, it would be impossible to determine whether the SIGs themselves were a prerequisite or simply used for validation.
如果SIG记录用于保护先决条件部分，则无法确定SIG本身是先决条件还是仅用于验证。
In the update section of an update request, signing requests to add an RRset is straightforward, and this signature could be permanently used to protect the data, as specified in [RFC2535]. However, if an RRset is deleted, there is no data for a SIG to cover.
在更新请求的更新部分，对添加RRset的请求进行签名非常简单，并且该签名可永久用于保护数据，如[RFC2535]中所述。但是，如果删除了RRset，SIG将无法覆盖任何数据。
As specified in [RFC3008], the DNSSEC validation process performed by a resolver MUST NOT process any non-zone keys unless local policy dictates otherwise. When performing secure dynamic update, all zone data modified in a signed zone MUST be signed by a relevant zone key. This completely disassociates authentication of an update request from authentication of the data itself.
按照[RFC3008]中的规定，由解析器执行的DNSSEC验证过程不得处理任何非区域密钥，除非本地策略另有规定。执行安全动态更新时，在已签名区域中修改的所有区域数据必须由相关区域密钥签名。这将使更新请求的身份验证与数据本身的身份验证完全分离。
The primary usefulness of host and user keys, with respect to DNSSEC, is to authenticate messages, including dynamic updates. Thus, host and user keys MAY be used to generate SIG(0) records to authenticate updates and MAY be used in the TKEY [RFC2930] process to generate TSIG shared secrets. In both cases, no SIG records generated by non-zone keys will be used in a DNSSEC validation process unless local policy dictates.
关于DNSSEC，主机和用户密钥的主要用途是对消息进行身份验证，包括动态更新。因此，主机密钥和用户密钥可用于生成SIG（0）记录以认证更新，并可在TKEY[RFC2930]过程中用于生成TSIG共享机密。在这两种情况下，除非当地政策规定，否则DNSSEC验证过程中不会使用非区域密钥生成的SIG记录。
Authentication of data, once it is present in DNS, only involves DNSSEC zone keys and signatures generated by them.
一旦数据出现在DNS中，数据的身份验证只涉及DNSSEC区域密钥及其生成的签名。
[RFC2535, section 3.1.2] defines the signatory field of a key as the final 4 bits of the flags field, but does not define its value. This proposal leaves this field undefined. Updating [RFC2535], this field SHOULD be set to 0 in KEY records, and MUST be ignored.
[RFC2535，第3.1.2节]将密钥的签名字段定义为标志字段的最后4位，但未定义其值。此建议未定义此字段。更新[RFC2535]时，此字段在密钥记录中应设置为0，并且必须忽略。
2 - Authentication
2-认证
TSIG or SIG(0) records MUST be included in all secure dynamic update messages. This allows the server to verifiably determine the originator of a message. If the message contains authentication in the form of a SIG(0), the identity of the sender (that is, the principal) is the owner of the KEY RR that generated the SIG(0). If the message contains a TSIG generated by a statically configured
TSIG或SIG（0）记录必须包含在所有安全动态更新消息中。这允许服务器以可验证的方式确定消息的发起人。如果消息包含SIG（0）形式的身份验证，则发送方（即主体）的身份是生成SIG（0）的密钥RR的所有者。如果消息包含由静态配置的
shared secret, the principal is the same as or derived from the shared secret name. If the message contains a TSIG generated by a dynamically configured shared secret, the principal is the same as the one that authenticated the TKEY process; if the TKEY process was unauthenticated, no information is known about the principal, and the associated TSIG shared secret MUST NOT be used for secure dynamic update.
共享机密，主体与共享机密名称相同或派生自共享机密名称。如果消息包含由动态配置的共享密钥生成的TSIG，则主体与验证TKEY进程的主体相同；如果TKEY进程未经身份验证，则不知道有关主体的任何信息，并且关联的TSIG共享机密不得用于安全动态更新。
SIG(0) signatures SHOULD NOT be generated by zone keys, since transactions are initiated by a host or user, not a zone.
SIG（0）签名不应由区域密钥生成，因为事务是由主机或用户而不是区域发起的。
DNSSEC SIG records (other than SIG(0)) MAY be included in an update message, but MUST NOT be used to authenticate the update request.
DNSSEC SIG记录（SIG（0）除外）可以包含在更新消息中，但不得用于验证更新请求。
If an update fails because it is signed with an unauthorized key, the server MUST indicate failure by returning a message with RCODE REFUSED. Other TSIG, SIG(0), or dynamic update errors are returned as specified in the appropriate protocol description.
如果更新因使用未经授权的密钥进行签名而失败，则服务器必须返回一条RCODE REJECTED的消息来指示失败。其他TSIG、SIG（0）或动态更新错误将按照相应协议描述中的指定返回。
3 - Policy
3-政策
All policy is configured by the zone administrator and enforced by the zone's primary name server. Policy dictates the authorized actions that an authenticated principal can take. Policy checks are based on the principal and the desired action, where the principal is derived from the message signing key and applied to dynamic update messages signed with that key.
所有策略由区域管理员配置，并由区域的主名称服务器强制实施。策略指定经过身份验证的主体可以执行的授权操作。策略检查基于主体和所需操作，其中主体从消息签名密钥派生，并应用于使用该密钥签名的动态更新消息。
The server's policy defines criteria which determine if the key used to sign the update is permitted to perform the requested updates. By default, a principal MUST NOT be permitted to make any changes to zone data; any permissions MUST be enabled though configuration.
服务器的策略定义了确定用于签署更新的密钥是否允许执行请求的更新的条件。默认情况下，不得允许委托人对区域数据进行任何更改；必须通过配置启用任何权限。
The policy is fully implemented in the primary zone server's configuration for several reasons. This removes limitations imposed by encoding policy into a fixed number of bits (such as the KEY RR's signatory field). Policy is only relevant in the server applying it, so there is no reason to expose it. Finally, a change in policy or a new type of policy should not affect the DNS protocol or data format, and should not cause interoperability failures.
由于几个原因，该策略在主区域服务器的配置中完全实现。这消除了将策略编码为固定位数（如密钥RR的签名字段）所施加的限制。策略只与应用它的服务器相关，因此没有理由公开它。最后，策略的更改或新类型的策略不应影响DNS协议或数据格式，也不应导致互操作性故障。
Implementations SHOULD allow access control policies to use the principal as an authorization token, and MAY also allow policies to grant permission to a signed message regardless of principal.
实现应该允许访问控制策略将主体用作授权令牌，还可以允许策略向已签名消息授予权限，而不管主体是什么。
A common practice would be to restrict the permissions of a principal by domain name. That is, a principal could be permitted to add, delete, or modify entries corresponding to one or more domain names. Implementations SHOULD allow per-name access control, and SHOULD provide a concise representation of the principal's own name, its subdomains, and all names in the zone.
通常的做法是通过域名限制主体的权限。也就是说，可以允许主体添加、删除或修改与一个或多个域名对应的条目。实现应该允许每个名称的访问控制，并且应该提供主体自己的名称、其子域和区域中所有名称的简明表示。
Additionally, a server SHOULD allow restricting updates by RR type, so that a principal could add, delete, or modify specific record types at certain names. Implementations SHOULD allow per-type access control, and SHOULD provide concise representations of all types and all "user" types, where a user type is defined as one that does not affect the operation of DNS itself.
此外，服务器应允许按RR类型限制更新，以便主体可以添加、删除或修改特定名称的特定记录类型。实现应允许每种类型的访问控制，并应提供所有类型和所有“用户”类型的简明表示，其中用户类型定义为不影响DNS本身操作的类型。
User types include all data types except SOA, NS, SIG, and NXT. SOA and NS records SHOULD NOT be modified by normal users, since these types create or modify delegation points. The addition of SIG records can lead to attacks resulting in additional workload for resolvers, and the deletion of SIG records could lead to extra work for the server if the zone SIG was deleted. Note that these records are not forbidden, but not recommended for normal users.
用户类型包括除SOA、NS、SIG和NXT之外的所有数据类型。普通用户不应修改SOA和NS记录，因为这些类型创建或修改委托点。添加SIG记录可能会导致攻击，从而增加解析程序的工作负载，如果删除区域SIG，则删除SIG记录可能会导致服务器的额外工作。请注意，这些记录不是禁止的，但不建议普通用户使用。
NXT records MUST NOT be created, modified, or deleted by dynamic update, as their update may cause instability in the protocol. This is an update to RFC 2136.
动态更新不得创建、修改或删除NXT记录，因为其更新可能会导致协议不稳定。这是对RFC 2136的更新。
Issues concerning updates of KEY records are discussed in the Security Considerations section.
有关密钥记录更新的问题将在“安全注意事项”一节中讨论。
Users are free to implement any policies. Policies may be as specific or general as desired, and as complex as desired. They may depend on the principal or any other characteristics of the signed message.
用户可以自由实施任何策略。政策可以根据需要具体或一般，也可以根据需要复杂。它们可能取决于签名消息的主体或任何其他特征。
4 - Interaction with DNSSEC
4-与DNSSEC的互动
Although this protocol does not change the way updates to secure zones are processed, there are a number of issues that should be clarified.
尽管该协议不会改变安全区域更新的处理方式，但仍有许多问题需要澄清。
An authorized update request MAY include SIG records with each RRset. Since SIG records (except SIG(0) records) MUST NOT be used for authentication of the update message, they are not required.
授权更新请求可能包括每个RRset的SIG记录。由于SIG记录（SIG（0）记录除外）不能用于更新消息的身份验证，因此不需要它们。
If a principal is authorized to update SIG records and there are SIG records in the update, the SIG records are added without verification. The server MAY examine SIG records and drop SIGs with a temporal validity period in the past.
如果委托人被授权更新SIG记录，且更新中存在SIG记录，则添加SIG记录时不进行验证。服务器可以检查SIG记录，并删除过去具有时间有效期的SIG。
If a principal is authorized to update SIG records and the update specifies the deletion of SIG records, the server MAY choose to override the authority and refuse the update. For example, the server may allow all SIG records not generated by a zone key to be deleted.
如果主体被授权更新SIG记录，并且更新指定删除SIG记录，则服务器可以选择覆盖该权限并拒绝更新。例如，服务器可能允许删除非由区域密钥生成的所有SIG记录。
If the updated zone is secured, the RRset affected by an update operation MUST, at the completion of the update, be signed in accordance with the zone's signing policy. This will usually require one or more SIG records to be generated by one or more zone keys whose private components MUST be online [RFC3008].
如果更新的区域是安全的，则受更新操作影响的RRset必须在更新完成时根据区域的签名策略进行签名。这通常需要一个或多个SIG记录由其私有组件必须在线的一个或多个区域密钥生成[RFC3008]。
When the contents of an RRset are updated, the server MAY delete all associated SIG records, since they will no longer be valid.
当RRset的内容更新时，服务器可能会删除所有相关的SIG记录，因为这些记录将不再有效。
If any changes are made, the server MUST, if necessary, generate a new SOA record and new NXT records, and sign these with the appropriate zone keys. Changes to NXT records by secure dynamic update are explicitly forbidden. SOA updates are allowed, since the maintenance of SOA parameters is outside of the scope of the DNS protocol.
如果进行了任何更改，服务器必须在必要时生成新的SOA记录和新的NXT记录，并使用适当的区域密钥对这些记录进行签名。明确禁止通过安全动态更新更改NXT记录。允许进行SOA更新，因为SOA参数的维护不在DNS协议的范围内。
5 - Security Considerations
5-安全考虑
This document requires that a zone key and possibly other cryptographic secret material be held in an on-line, network-connected host, most likely a name server. This material is at the mercy of host security to remain a secret. Exposing this secret puts DNS data at risk of masquerade attacks. The data at risk is that in both zones served by the machine and delegated from this machine.
本文件要求在联机、网络连接的主机（最可能是名称服务器）中保存区域密钥和其他可能的加密机密材料。此材料将由主机安全部门决定是否保密。暴露此秘密会使DNS数据面临伪装攻击的风险。处于风险中的数据是由机器提供服务并从此机器委派的两个区域中的数据。
Allowing updates of KEY records may lead to undesirable results, since a principal may be allowed to insert a public key without holding the private key, and possibly masquerade as the key owner.
允许更新密钥记录可能会导致不希望的结果，因为可能允许主体在不持有私钥的情况下插入公钥，并且可能伪装成密钥所有者。
6 - Acknowledgements
6-致谢
The author would like to thank the following people for review and informative comments (in alphabetical order):
作者感谢以下人士的评论和信息性评论（按字母顺序排列）：
Harald Alvestrand Donald Eastlake Olafur Gudmundsson Andreas Gustafsson Bob Halley Stuart Kwan Ed Lewis
哈拉尔·阿尔维斯特兰·唐纳德·伊斯特莱克·奥拉弗尔·古德蒙德森、安德烈亚斯·古斯塔夫松、鲍勃·哈雷·斯图亚特·关·埃德·刘易斯
7 - References
7-参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136]Vixie（Ed.），P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新”，RFC 21361997年4月。
[RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137]Eastlake，D.，“安全域名系统动态更新”，RFC2137，1997年4月。
[RFC2535] Eastlake, G., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，G.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.和B.Wellington，“DNS的密钥交易签名（TSIG）”，RFC 28452000年5月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake，D.，“DNS密钥建立（TKEY RR）”，RFC 29302000年9月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931]Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]惠灵顿，B.，“域名系统安全（DNSSEC）签名机构”，RFC3008，2000年11月。
8 - Author's Address
8-作者地址
Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063
Brian Wellington Nominum，Inc.加利福尼亚州红木市Charter Street 950号，邮编94063
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。