NetworkWorkingGroupB.WellingtonRequestforComments:3007NominumUpdates:2535,2136November2000Obsoletes:2137Category:StandardsTrack安全的域名系统动态更新(RFC3007SecureDomainNameSystem(DNS)DynamicUpdate)本备忘录的状态本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议进行改善。请查看“Internet正式协议标准”（STD1）了解本协议的便准化进程和状态。本备忘录的传播不受限制。版权公告Copyright(C)TheInternetSociety(2000).AllRightsReserved.摘要本文提出了一种安全地动态更新域名系统的方法。该方法的意图在于保证灵活性和可用性，同时尽可能少地改变当前的协议。在最新的DNSSEC中动态更新消息的验证已经从数据确认中分离出来。基于请求和事务验证的安全通信用来提供授权。本文所用关键字“必须”、“不得”、“要求”、“应”、“不应”、“需”、“不可”、“推荐”、“可以”和“可选”参见RFC2119的解释。目录1简介21.1DNS动态更新概述21.2–DNS事务安全概述21.3–数据验证和消息验证的比较21.4–数据和消息签名31.5–签名长度32–验证（Authentication）33–策略33.1–标准策略Standardpolicies43.1.1–用户类型（Usertypes）43.2–其他策略（Additionalpolicies）44–与DNSSEC之间的相互影响44.1–增加SIGs44.2–删除SIGs44.3–对SIGs的模糊更新54.4–对区域的影响55.安全考虑56.鸣谢57.引用58.作者地址69.版权声明61简介本文定义了一种动态更新域名系统的安全方法，只有经过授权的资源才被允许修改域的内容。当前存在的不安全的动态更新工程了本文的主要内容。熟悉DNS系统[RFC1034,RFC1035]和动态更新[RFC2136]是很有用的，本文假定读者已经熟悉这些内容。另外，建议了解DNS安全扩展[RFC2535]、SIG(0)事务安全[RFC2535,RFC2931]和TSIG事务安全[RFC2845]。本文更新了RFC2535，特别是节3.1.2，还有RFC2136。根据应用实践，本文废止了RFC2137，那是另一个安全动态更新的提议。1.1DNS动态更新概述DNS动态更新定义了新的DNS操作码和对该操作码的DNS消息的解释器。更新可以指明插入或者删除数据，先要条件是进行更新的必要性。DNS更新请求的全部测试和修改全部限定在一个单独的域，在该域的主服务器上进行。动态域的主服务器在执行更新时或者下一次访问SOA前增加域SOA序列号。1.2–DNS事务安全概述包含TSIG或者SIG（0）记录的DNS消息交换允许两个DNS实体验证彼此发出的DNS请求和响应。TSIGMAC（消息验证码）源于共享加密，而SIG（0）则出自私有密钥，其公共部分保存在DNS中。这两种情况下，DNS消息都包括一个含有消息签名/MAC的记录作为源记录的最后部分。TSIG使用的带键散列表计算和校验成本低廉。SIG（0）使用的公共密钥加密，由于公共密钥保存在DNS中因而伸缩性更大。1.3–数据验证和消息验证的比较使用TSIG或者SIG（0）的基于验证的消息，通过单个的签名或者单个的校验对整个消息提供保护，其中TSIG使用了创建和检查相对便宜的MAC。对于更新请求，可以由管理人员基于一定的策略或者密码协商来建立签名。域所有者的管理人员可以利用DNSSECSIG记录保护DNS消息中单个RRs或者Rrsets的完整性。但是这样不能保护动态更新请求。如下所述，使用SIG记录在更新请求中保护RRsets与更新的设计相矛盾，而且无论如何都需要昂贵的多重公共密钥签名和校验。由于SIG记录没有覆盖包含记录长度的消息头，因此更新请求被恶意增加或者删除了RRsets也可能不会产生校验错误。如果使用SIG记录保护首要的小节，就无法分辨SIG本身是首要的节还是仅仅用来校验。如[RFC2535]所述，在更新请求的更新小节增加一个RRset实现对请求的签名是很简单的，而且这个签名可以用来永久的保护数据。但是如果删除了一个RRset，SIG就没有保护的数据了。1.4–数据和消息签名[RFC3008]指出，执行DNSSEC验证的分析器不得处理非信任区的密码，除非本地的安全策略另有规定。执行安全动态更新时，在一个标志区内更新的所有信任区数据必须使用相应的区域密码标志。这样可以实现更新请求的验证和数据本身的验证完全分离。对于DNSSEC，主机密码和用户密码主要用于消息验证，其中包括动态更新消息...
