{安全生产管理}安全的域名系统动态更新

上传人:管****问 文档编号:138133834 上传时间:2020-07-13 格式:DOCX 页数:5 大小:15.59KB
返回 下载 相关 举报
{安全生产管理}安全的域名系统动态更新_第1页
第1页 / 共5页
{安全生产管理}安全的域名系统动态更新_第2页
第2页 / 共5页
{安全生产管理}安全的域名系统动态更新_第3页
第3页 / 共5页
{安全生产管理}安全的域名系统动态更新_第4页
第4页 / 共5页
{安全生产管理}安全的域名系统动态更新_第5页
第5页 / 共5页
亲,该文档总共5页,全部预览完了,如果喜欢就下载吧!
资源描述

《{安全生产管理}安全的域名系统动态更新》由会员分享,可在线阅读,更多相关《{安全生产管理}安全的域名系统动态更新(5页珍藏版)》请在金锄头文库上搜索。

1、Network Working Group B. WellingtonRequest for Comments: 3007 NominumUpdates: 2535, 2136 November 2000Obsoletes: 2137Category: Standards Track安全的域名系统动态更新(RFC 3007 Secure Domain Name System (DNS) Dynamic Update)本备忘录的状态本文为Internet社区描述了一种Internet标准跟踪协议,还需要讨论和建议进行改善。请查看“Internet正式协议标准”(STD 1)了解本协议的便准化进程

2、和状态。本备忘录的传播不受限制。版权公告 Copyright (C) The Internet Society (2000). All Rights Reserved.摘要本文提出了一种安全地动态更新域名系统的方法。该方法的意图在于保证灵活性和可用性,同时尽可能少地改变当前的协议。在最新的DNSSEC中动态更新消息的验证已经从数据确认中分离出来。基于请求和事务验证的安全通信用来提供授权。本文所用关键字“必须”、“不得”、“要求”、“应”、“不应”、“需”、“不可”、“推荐”、“可以”和“可选”参见RFC 2119的解释。目录1 简介21.1 DNS动态更新概述21.2 DNS事务安全概述21.

3、3 数据验证和消息验证的比较21.4 数据和消息签名31.5 签名长度32 验证(Authentication)33 策略33.1 标准策略Standard policies43.1.1 用户类型(User types)43.2 其他策略(Additional policies)44 与DNSSEC之间的相互影响44.1 增加 SIGs44.2 删除 SIGs44.3 对SIGs的模糊更新54.4 对区域的影响55. 安全考虑56.鸣谢57.引用58. 作者地址69. 版权声明61 简介本文定义了一种动态更新域名系统的安全方法,只有经过授权的资源才被允许修改域的内容。当前存在的不安全的动态更新

4、工程了本文的主要内容。熟悉DNS系统RFC1034, RFC1035和动态更新RFC2136是很有用的,本文假定读者已经熟悉这些内容。另外,建议了解DNS安全扩展RFC2535、SIG(0)事务安全RFC2535, RFC2931和TSIG事务安全RFC2845。本文更新了RFC2535,特别是节3.1.2,还有RFC 2136。根据应用实践,本文废止了RFC2137,那是另一个安全动态更新的提议。 1.1 DNS动态更新概述DNS动态更新定义了新的DNS操作码和对该操作码的DNS消息的解释器。更新可以指明插入或者删除数据,先要条件是进行更新的必要性。DNS更新请求的全部测试和修改全部限定在一

5、个单独的域,在该域的主服务器上进行。动态域的主服务器在执行更新时或者下一次访问SOA前增加域SOA序列号。1.2 DNS事务安全概述包含TSIG或者SIG(0)记录的DNS消息交换允许两个DNS实体验证彼此发出的DNS请求和响应。TSIG MAC(消息验证码)源于共享加密,而SIG(0)则出自私有密钥,其公共部分保存在DNS中。这两种情况下,DNS消息都包括一个含有消息签名/MAC的记录作为源记录的最后部分。TSIG使用的带键散列表计算和校验成本低廉。SIG(0)使用的公共密钥加密,由于公共密钥保存在DNS中因而伸缩性更大。1.3 数据验证和消息验证的比较使用TSIG或者SIG(0)的基于验证

6、的消息,通过单个的签名或者单个的校验对整个消息提供保护,其中TSIG使用了创建和检查相对便宜的MAC。对于更新请求,可以由管理人员基于一定的策略或者密码协商来建立签名。域所有者的管理人员可以利用DNSSEC SIG记录保护DNS消息中单个RRs或者Rrsets的完整性。但是这样不能保护动态更新请求。如下所述,使用SIG记录在更新请求中保护RRsets 与更新的设计相矛盾,而且无论如何都需要昂贵的多重公共密钥签名和校验。由于SIG记录没有覆盖包含记录长度的消息头,因此更新请求被恶意增加或者删除了RRsets也可能不会产生校验错误。如果使用SIG记录保护首要的小节,就无法分辨SIG本身是首要的节还

7、是仅仅用来校验。 如RFC2535所述,在更新请求的更新小节增加一个RRset实现对请求的签名是很简单的,而且这个签名可以用来永久的保护数据。但是如果删除了一个RRset,SIG就没有保护的数据了。1.4 数据和消息签名RFC3008指出,执行DNSSEC验证的分析器不得处理非信任区的密码,除非本地的安全策略另有规定。执行安全动态更新时,在一个标志区内更新的所有信任区数据必须使用相应的区域密码标志。这样可以实现更新请求的验证和数据本身的验证完全分离。对于DNSSEC,主机密码和用户密码主要用于消息验证,其中包括动态更新消息验证。因此,主机密码和用户密码可以用来生成更新验证的SIG(0)记录,或

8、者在TKEYRFC2930过程中生成TSIG共享加密。这两种情况都不会使用非信任区密码生成的SIG记录进行DNSSEC验证,除非本地的安全策略另有规定。出现在DNSSEC中的数据验证仅仅包括DNSSEC信任区密码和由此生成的签名。1.5 签名长度 RFC2535, 节3.1.2把密码的签名者字段定义为标志字段的最后4位,但没有指明该域的值。 本建议没有定义该字段。作为对RFC2535的修正,密码记录中的该字段应设为0,而且必须被忽略。2 验证(Authentication)所有的动态更新消息都必须包含TSIG或者SIG(0)记录,这样服务器才能证实消息的发出方。如果消息包含有SIG(0)形式的

9、验证信息,发送方(主体)的身份就是生成SIG(0)的KEY RR的所有者。如果消息包含了静态配置共享加密生成的TSIG验证信息,主体就与进行TKEY验证的主体相同;如果没有验证TKEY,就无法了解主体的信息,这样的TSIG共享加密就不能用于安全动态更新。SIG(0)签名不应由区域密码产生,因为初始化事务的是主机和用户而不是安全区。更新消息可以包含DNSSEC SIG记录(不是SIG(0),但该记录不能用于更新请求验证。如果由于使用未授权的密码造成更新失败,服务器需返回RCODE REFUSED消息通知更新失败。其他的TSIG、SIG(0)或者动态更新错误根据相应的协议规定返回提示。3 策略区域

10、管理员设置所有的安全策略,由区域的主名服务器执行。安全策略规定了授权主体可以执行的授权活动。策略检查取决于授权主体和需要的授权行为,主体来自消息签署密码并用于使用该密码签字的动态更新消息。服务器的安全策略定义了密码确认的标准,决定请求的更新能否执行。缺省条件下,不允许主体改变区域数据,否则必须在配置中设定。策略仅仅在主域服务器的配置中完全实现有几个理由。首先避免了把策略编成固定长度的码的限制;其次策略仅与应用它的服务器有关,避免了泄漏;最后,策略改变或者启用新类型的策略不会影响DNS协议和数据格式,因而不会引起协同工作的问题。3.1 标准策略Standard policies具体运用应允许访问

11、控制策略把主体作为授权信令使用,也可以允许策略授权许可带有签字的消息而不考略主体。限制对域名主体的许可是一项通用的惯例。这些许可包括追加、删除和修改与一个或者多个域名对应的项。具体实现应允许针对名的访问控制,并且应该提供关于主体的所有名、子域和区域内全部名的精确表示。另外,服务器应该允许对RR类型更新的限制,这样主体就可以追加、删除和更新特定名的指定记录类型。实现中应允许针对类型的访问控制,并且应该提供对全部类型和“用户”类型的精确表示,其中用户类型被定义为不会影响DNS操作本身。3.1.1 用户类型(User types)用户类型包括除SOA、NS、SIG和NXT之外的所有类型。SOA和NA

12、记录用于创建和修改授权点,因而普通用户不应修改这些类型。追加SIG记录将增加分析器的工作量并可能导致攻击,删除SIG记录会给删除区域SIG的服务器带来额外的工作。注意,尽管不是强制性的,这些记录建议不要提供给普通用户。动态更新不得创建、修改或者删除NXT记录,因为这样的更新会导致协议内的不稳定。这一点是对RFC2136的改进。关于KEY记录的更新在安全考虑一节讨论。3.2 其他策略(Additional policies)用户可以自由地使用任何策略。策略既可以根据需要或详尽和简略,也可以根据需要非常复杂,这取决于主体或者签名消息的其它特性。4 与DNSSEC之间的相互影响尽管本协议没有改变安全

13、区域的更新方式,还有几点需要澄清。4.1 增加 SIGs授权的更新请求可能在每个RRset中都包含SIG记录。由于SIG记录(不包括SIG(0)记录)不能用于更新消息的验证因而是不需要的。如果主体被授权可以更新SIG记录而且更新中存在SIG记录,这些SIG记录就会在未经验证的情况下追加。服务器可以检查SIG记录并删除以前的具有临时有效期的SIG记录。4.2 删除 SIGs如果一个主体被授权更新SIG记录,而且更新要求删除SIG记录,服务器可以推翻这一授权并拒绝更新。比如,服务器可以允许删除所有非区域码生成的SIG记录。4.3 对SIGs的模糊更新如果更新的区域是可靠的,受到更新操作影响的RRs

14、et必须在更新完成时根据区域的签名策略进行签名。这样通常会由一个或者多个区域码其私有成分必须是在线的RFC3008生成一个或者多个SIG记录。如果改变了RRset的内容,服务器可以删除所有相关的SIG记录,因为它们不再有效了。4.4 对区域的影响如果需要,无论作了什么样的改变服务器都必须产生新的SOA记录和新的NXT记录,并把这些记录签署给相应的区域码。安全的动态更新对NXT记录的改变是明确禁止的。SOA更新是允许的,因为SOA参数的维护是在DNS协议的范围之外。5. 安全考虑本文要求应在一台在线的联网主机最可能是一个名服务器上保存区域密码以及其他可能的经过加密的机密资料。这些资料的机密性完全取决于主机的安全性。如果泄露了这一秘密将会使DNS数据面临冒名攻击的危险。该机器以及由该机器授权的机器所服务的区域的数据都会受到威胁。6.鸣谢作者感谢下列人士对本文的审阅和有价值的建议(按字母顺序): Harald Alvestrand Donald Eastlake Olafur Gudmundsson Andreas Gustafsson Bob Halley Stuart Kwan

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 企业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号