Network Working Group                                           E. Lewis
Request for Comments: 3130                                      NAI Labs
Category: Informational                                        June 2001
        
Network Working Group                                           E. Lewis
Request for Comments: 3130                                      NAI Labs
Category: Informational                                        June 2001
        

Notes from the State-Of-The-Technology: DNSSEC

技术状态注释:DNSSEC

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 (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

Abstract

摘要

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.

这是DNSSEC(域名系统安全扩展)状态会议的备忘录。

1.0 Introduction
1.0 介绍

A meeting of groups involved in the development of the DNS Security Extensions (DNSSEC) was held in conjunction with the 49th IETF. The discussion covered the extent of current efforts, a discussion of what questions are being asked of DNSSEC, and what is needed by the IETF to progress the definition to the Draft Standard level.

参与DNS安全扩展(DNSSEC)开发的小组会议与第49届IETF一起举行。讨论涵盖了当前工作的范围,讨论了DNSSEC提出的问题,以及IETF将定义提升到标准草案水平所需的内容。

DNSSEC [RFC 2535] has been under consideration for quite a few years, with RFC 2535 being the core of the most recent definition. DNSSEC is part of the charter of two working groups, DNSEXT and DNSOP. ISC's BIND v8.2 implemented part of the specification, BIND v9 represents the first full implementation. In 1999 and 2000, more than a half dozen workshops have been held to test the concepts and the earliest versions of implementations. But to date, DNSSEC is not in common use.

DNSSEC[RFC 2535]已经考虑了好几年,RFC 2535是最新定义的核心。DNSSEC是DNSEXT和DNSOP两个工作组章程的一部分。ISC的BIND v8.2实现了规范的一部分,BIND v9代表了第一个完整的实现。在1999年和2000年,已经举办了六次以上的研讨会来测试概念和最早版本的实现。但到目前为止,DNSSEC尚未普遍使用。

The current collective wisdom is that DNSSEC is 1) important, 2) a buzzword, 3) hard, 4) immature. To capture the true state of the technology and identify where work is needed, an informal gathering of groups known to be involved in DNSSEC was held in conjunction with the 49th IETF. The attendees represented NLnet Labs, The Foundation for Internet Infrastructure, RIPE NCC, ARIN, CAIRN (ISI and NAI Labs), NIST, DISA, RSSAC, Network Associates and Verisign (COM/NET/ORG TLDs).

目前的集体智慧是,DNSSEC 1)重要,2)流行语,3)困难,4)不成熟。为了捕捉技术的真实状态并确定需要开展的工作,与第49届IETF一起举行了一次非正式的DNSSEC相关团体会议。与会者代表NLNET实验室,互联网基础设施的基础,成熟的NCC,ARIN,CAIRN(ISI和NaI实验室),NIST,DISA,RSSAC,网络协会和VRISIGN(COM/NET/ORG TLDS)。

The agenda of the meeting consisted of three items. Reports from each group on their current research goals were followed by a discussion of questions being asked of DNSSEC. Finally, with reaching Draft Standard status as a goal, what was needed to make this happen was considered.

会议议程包括三个项目。每组报告当前研究目标后,讨论DNSSEC提出的问题。最后,以达到草案标准状态为目标,考虑了实现这一目标所需的措施。

This report is not simply a transcript of the meeting, it is a summary. Some of the information presented here was obtained in direct contact with participants after the meeting.

这份报告不仅仅是一份会议记录,它是一份总结。这里介绍的一些信息是在会后与与会者直接接触后获得的。

1.1 What does the term "DNSSEC" mean?
1.1 “DNSSEC”一词是什么意思?

One of the comments made during discussions is that DNSSEC does not refer to just one monolithic technology. The term has come to refer to "toolbox" of techniques and methodologies, that when used properly can improve the integrity of the DNS. Given this observation, it can be seen that some portions of DNSSEC are evolving much more rapidly than other portions. In particular, TSIG [RFC 2845] has certainly reached a level "being deployable" for zone transfers.

在讨论中提出的一个意见是,DNSSEC并不仅仅指一种单片技术。该术语指的是技术和方法的“工具箱”,如果使用得当,可以提高DNS的完整性。鉴于这一观察,可以看出DNSSEC的某些部分比其他部分进化得更快。特别是,TSIG[RFC 2845]肯定已经达到了区域转移“可部署”的水平。

The following four components are considered to be part of DNSSEC. The concept of digital signature protection of DNS traffic as described in RFC 2535 and a few support documents (such as [RFC 3008]), which is designed to protect the transfer of data on an Internet scale. The concept of protecting queries and responses through the less-scalable but more efficient TSIG mechanism [RFC 2845], which has applicability to zone transfers, DHCP registrations, and other resolver to name server traffic. Secure dynamic updates [RFC 3007], by virtue of using TSIG, can be considered to be part of DNSSEC. Finally, the definition of the CERT resource record [RFC 2538] gives DNS the ability to become a distribution mechanism for security data.

以下四个部件被视为DNSSEC的一部分。RFC 2535和一些支持文档(如[RFC 3008])中所述的DNS流量数字签名保护概念,旨在保护互联网规模上的数据传输。通过可伸缩性较差但效率更高的TSIG机制[RFC 2845]保护查询和响应的概念,该机制适用于区域传输、DHCP注册和其他解析程序到名称服务器的通信。通过使用TSIG,安全动态更新[RFC 3007]可被视为DNSSEC的一部分。最后,证书资源记录[RFC2538]的定义使DNS能够成为安全数据的分发机制。

This definition of the components of DNSSEC is in no way definitive. To be honest, this is a somewhat artificial grouping. DNSSEC does not encompass all of the security practiced in DNS today, for example, the redefinition of when and how data is cached [RFC 2181], plays a big role in hardening the DNS system. The four elements of DNSSEC described in the previous paragraph are grouped together mostly because they do interrelate, but also they were developed at approximately the same time.

DNSSEC组件的这一定义绝不是确定的。老实说,这是一个有点人为的分组。DNSSEC并没有涵盖当今DNS中实施的所有安全性,例如,重新定义数据缓存的时间和方式[RFC 2181],在强化DNS系统方面起着重要作用。上一段中描述的DNSSEC的四个要素被组合在一起,主要是因为它们相互关联,但它们也是在几乎相同的时间开发的。

2.0 Group Reports
2.0 小组报告

The first part of the meeting consisted of reports of goals. From this a taxonomy of efforts has been made to see if there are gaps in the work.

会议的第一部分包括目标报告。根据这一点,我们对工作进行了分类,以确定工作中是否存在差距。

2.1 NLnet Labs
2.1 NLnet实验室

Efforts by NLnet Labs are directed towards yielding an understanding of the impact of DNSSEC on ccTLDs, specifically .de (Germany), .nl (The Netherlands), and .se (Sweden). Work to date has studied the problem of applying digital signatures and NXT records to a zone. The conclusion drawn is that there are no real problems regarding memory or CPU speed when signing large zones, not even for ".com." NLnet Labs has offered to work with Verisign to examine this further.

NLnet实验室的工作旨在了解DNSSEC对CCTLD的影响,特别是.de(德国),.nl(荷兰)和.se(瑞典)。迄今为止的工作研究了将数字签名和NXT记录应用于区域的问题。得出的结论是,在签署大型区域时,内存或CPU速度没有实际问题,即使是“.com”也没有。NLnet实验室已提出与Verisign合作,进一步研究这一点。

NLnet Labs is trying to define and document procedures for TLD registries, registrars and registrants to properly handle actions like zone-resigning and key-rollover at the root, TLD, and lower levels. The outcome so far is that the DNSOP Roll Over proposal seems impractical or possibly even impossible to implement at large TLDs. NLnet Labs will produce a draft on an alternative KEY+SIG handling scheme where SIGs are only kept in the zone where the corresponding zone-KEY is located. This scheme reduces the necessary actions for resigning zones from 2 levels (current zone and all children) to 1 level (current zone), and for key-rollover from 3 levels (parent, current zone and all children) to 2 levels (parent and current zone).

NLnet实验室正试图为TLD注册机构、注册机构和注册人定义和记录程序,以便在根、TLD和更低级别正确处理区域辞职和密钥转移等操作。到目前为止的结果是,DNSOP的展期建议似乎不切实际,甚至可能不可能在整个TLD上实施。NLnet实验室将起草一份备用密钥+SIG处理方案草案,其中SIG仅保存在相应区域密钥所在的区域内。此方案减少了将区域从2个级别(当前区域和所有子级)重设为1个级别(当前区域)以及将关键点从3个级别(父级、当前区域和所有子级)翻转为2个级别(父级和当前区域)所需的操作。

2.2 Verisign
2.2 威瑞信

Verisign's registry operations and corporate components have been investigating what DNSSEC means to very large zones, not just from a hardware point of view, but from an institutional point of view. With the service of providing delegations already commercialized, they are attempting to define what it would take to provide a DNSSEC service. An important issue is the parent validation of each delegated zone's keys.

Verisign的注册运营和公司组件一直在调查DNSSEC对非常大的区域意味着什么,不仅仅是从硬件的角度,而是从机构的角度。由于提供代表团的服务已经商业化,他们正试图确定提供DNSSEC服务需要什么。一个重要问题是每个委派区域密钥的父级验证。

2.3 The Foundation for Internet Infrastructure
2.3 互联网基础设施的基础

The Foundation for Internet Infrastructure, an organization in Sweden, is running a project with two parts. One part is directed at the "topology" of the participants in DNSSEC, the other part of the project is directed towards general development of tools.

互联网基础设施,一个组织在瑞典,正在运行一个项目分为两部分。一部分是针对DNSSEC参与者的“拓扑”,另一部分是针对工具的一般开发。

The study is examining the administrative issues of running DNSSEC. One issue is the possible 4-party interaction in the use of DNSSEC. The four parties are the registry, the registrar, the registrant, and the DNS operator. Of these four parties, any combination may occur within one entity, such as a registrant that operates their own DNS as part of their information technology department.

这项研究正在审查DNSSEC运行的管理问题。一个问题是DNSSEC使用过程中可能出现的四方互动。四方为注册中心、注册中心、注册人和DNS运营商。在这四方中,任何组合都可能发生在一个实体内,例如作为其信息技术部门的一部分运营其自身DNS的注册人。

The other part of the study is looking at what happens in the resolver. Goals include DNSSEC-enabling tools such as ISAKMPd (an IPSEC key negotiation software) secure NTP4, and e-mail. Part of this effort is implemented in the sigz.net experiment, information on this exists at www.sigz.net.

研究的另一部分是观察解析器中发生了什么。目标包括支持DNSSEC的工具,如ISAKMPd(IPSEC密钥协商软件)、安全NTP4和电子邮件。这项工作的一部分是在sigz.net实验中实现的,有关这方面的信息可访问www.sigz.net。

2.4 RSSAC
2.4 RSSAC

The RSSAC (Root Server System Advisory Committee) has come to the conclusion that TSIG is worthwhile and should be deployed. There is no schedule for deployment, however.

RSSAC(根服务器系统咨询委员会)得出结论,TSIG是值得的,应该部署。但是,没有部署时间表。

As for the rest of DNSSEC, there is a need to better understand the impact of the new features before being introduced into production. Currently issues regarding potential testbeds are being documented. Two fundamental assumptions are that a DNSSEC testbed involving the root servers is desirable and that such a testbed would allow for long term testing. The latter assumption is based upon the need to understand how repeated zone key validations can occur at multiple independent levels of the DNS hierarchy.

至于DNSSEC的其余部分,在投入生产之前,需要更好地了解新功能的影响。目前正在记录有关潜在试验台的问题。两个基本假设是,需要一个包含根服务器的DNSSEC测试台,并且这样的测试台可以进行长期测试。后一种假设基于需要了解在DNS层次结构的多个独立级别上如何重复进行区域密钥验证。

2.5 CAIRN
2.5 凯恩

CAIRN (Collaborative Advanced Interagency Research Network) is a DARPA-sponsored network for collaborative research. A funded activity that involves DNSSEC is FMESHD, shorthand for Fault-Tolerant Mesh of Trust in DNSSEC. The effort of this activity is to determine a means of building a resolver's chain of trust when some of the DNS tree is unavailable or unsecured. An early deliverable of this is an extension of secure shell to retrieve keys from DNSSEC. As part of this activity, the use of DNSSEC in a non-major provider zone is being implemented and studied.

CAIRN(协作高级机构间研究网络)是DARPA赞助的协作研究网络。一项涉及DNSSEC的资助活动是FMESHD,是DNSSEC中容错信任网格的缩写。此活动的目的是确定在某些DNS树不可用或不安全时构建解析程序信任链的方法。这方面的早期成果是对secure shell的扩展,用于从DNSSEC检索密钥。作为这项活动的一部分,正在实施和研究在非主要供应商区域使用DNSSEC。

2.6 NIST
2.6 NIST

NIST is collecting performance information regarding DNSSEC. One of the fears in adopting DNSSEC is the workload it adds to existing DNS machine workload. The hopes of this effort is to quantify the fear, to see if it is real or imagined.

NIST正在收集有关DNSSEC的性能信息。采用DNSSEC的一个担忧是它增加了现有DNS机器的工作负载。这一努力的希望是量化恐惧,看看它是真实的还是想象的。

If time permits, there may be an effort to implement a zone integrity checking program (implemented in Java) that will look for missteps in the use of DNSSEC. Base code exists, but needs work (beyond the current baseline).

如果时间允许,可能会实施一个区域完整性检查程序(用Java实现),以查找DNSSEC使用中的错误步骤。基本代码存在,但需要工作(超出当前基线)。

2.7 DISA
2.7 迪萨

The U.S. Defense Information Systems Agency is providing funds to have DNSSEC implemented in BIND. Of particular interest is making sure that the DNSSEC specifications are correct, that BIND adheres to the specifications, and that BIND is available on the operating systems in use by the US Department of Defense. DISA expects that every line of code developed through this effort be made publicly available as part of stock BIND releases.

美国国防信息系统局(U.S.Defense Information Systems Agency)正在提供资金,以便在BIND中实施DNSSEC。特别令人感兴趣的是确保DNSSEC规范正确,BIND符合规范,并且BIND在美国国防部使用的操作系统上可用。DISA希望通过这项工作开发的每一行代码都能作为StockBind发行版的一部分公开提供。

2.8 RIPE NCC
2.8 成熟NCC

The RIPE NCC is looking at the impact of DNSSEC on IP-registries. The RIPE NCC is planning to coordinate and assist in the deployment of DNSSEC. Because the RIPE NCC is the Regional Internet Registry for Europe the focus will be on the deployment of DNSSEC on the reverse map tree (in-addr.arpa for IPv4).

成熟的NCC正在研究DNSSEC对IP注册的影响。成熟的NCC计划协调和协助DNSSEC的部署。由于成熟的NCC是欧洲的区域互联网注册中心,因此重点将放在反向映射树(IPv4的in-addr.arpa)上的DNSSEC部署上。

2.9 ARIN
2.9 阿林

ARIN is investigating DNSSEC for use in signing its delegated zones under in-addr.arpa. It participated in a dnssec workshop following NANOG 20 held in Washington, DC in October, 2000. It also participated in an ipv6-dnssec workshop that followed IETF 49 in San Diego, California. Additionally, ARIN has stood up a server dedicated to testing various dns experimentation, including dnssec and carrying out limited testing.

ARIN正在调查DNSSEC是否用于在in-addr.arpa下签署其授权区域。它参加了2000年10月在华盛顿特区举行的NANOG 20之后的dnssec研讨会。它还参加了继IETF 49之后在加利福尼亚州圣地亚哥举行的ipv6 dnssec研讨会。此外,ARIN还建立了一个服务器,专门用于测试各种dns实验,包括dnssec和执行有限的测试。

2.10 Network Associates
2.10 网络联盟

NAI is pressing to get the tislabs.com zone running in accordance with DNSSEC. This is an example of a non-Internet service provider (neither an IP transit, IP address allocation, nor a domain name managing entity) making use of DNSSEC within the normal operations of the Information Technology department.

NAI正在敦促tislabs.com区域按照DNSSEC运行。这是一个非互联网服务提供商(既不是IP传输、IP地址分配,也不是域名管理实体)在信息技术部的正常运营中使用DNSSEC的例子。

2.11 ip6.int. domain
2.11 ip6.int。领域

The name servers authoritative for the ip6.int. domain are mostly upgraded to be able to support CERT records and TSIG. Once this is fully accomplished and proposals are approved, TSIG and CERT records will be used. Further DNSSEC work is unknown.

ip6.int的名称。域大多升级为能够支持证书记录和TSIG。一旦完全完成并批准提案,将使用TSIG和CERT记录。DNSSEC的进一步工作尚不清楚。

2.12 Topology Based Domain Search
2.12 基于拓扑的域搜索

Topology Based Domain Search (TBDS), is a DARPA funded activity investigating how DNS may continue to run in disconnected parts of the Internet. Topics of interest (either covered by this project, or

基于拓扑的域搜索(TBDS)是DARPA资助的一项活动,旨在研究DNS如何在互联网断开连接的部分继续运行。感兴趣的主题(本项目涵盖的主题,或

associated with the project) are the use of split keys, self-signed zone (keys), and multiple signing algorithms. A goal is the establishment of signed infrastructure zones, facilitating the creation of a distributed CA for activities like IPSEC and FreeSwan.

与项目相关联的是使用分割密钥、自签名区域(密钥)和多重签名算法。目标是建立签名基础设施区域,促进为IPSEC和FreeSwan等活动创建分布式CA。

3.0 Taxonomy of efforts and What is missing
3.0 努力的分类和缺失的内容

The efforts being undertaken appear to cover a broad range of work areas, from large domain registries to domain name consumers. Work has been progressing in the production of zones (signing, key management), and is starting in the use (resolver) of DNSSEC secured data.

正在进行的努力似乎涵盖了广泛的工作领域,从大型域名注册中心到域名消费者。区域(签名、密钥管理)的制作工作正在进行中,DNSSEC安全数据的使用(解析器)也正在开始。

From the discussion, there were no apparent areas lacking attention. Additional input in some areas is needed however, particularly in making use (applications and IT department) of DNSSEC.

从讨论中可以看出,没有明显缺乏关注的领域。然而,在某些领域需要额外投入,特别是在使用DNSSEC(应用和IT部门)方面。

4.0 Questions facing DNSSEC
4.0 DNSSEC面临的问题

By the 49th IETF meeting, the most pressing question on DNSSEC is "is it deployable?" From just the emphasis placed on this question, the meeting generated a list of questions and made sure that either the answer was known, or work was being done to address the question.

在第49次IETF会议上,DNSSEC最紧迫的问题是“它可部署吗?”会议仅强调了这个问题,就产生了一系列问题,并确保知道答案,或者正在努力解决这个问题。

4.1 Is it deployable? When?
4.1 它是可部署的吗?什么时候

The usual answer to this has been "not now." When is always off into the future - "about a year." To get to a deployable point, a series of workshops have been held since the spring of 1999.

通常的答案是“不是现在”。当未来总是“大约一年”时。为了达到一个可部署点,自1999年春季以来已经举办了一系列研讨会。

At this point, it is becoming clearer that longer term workshops are needed. In going through the motions of any workshop, the number of issues raised that impact the protocol's specification is diminishing, as well as implementation issues. As such, one or two day workshops have been helping less and less in reaching deployment.

在这一点上,越来越清楚的是,需要长期的讲习班。在任何研讨会上,提出的影响议定书规范的问题以及实施问题的数量都在减少。因此,一天或两天的讲习班对实现部署的帮助越来越少。

What is needed is to run longer term test configurations, possibly workshops that are help in conjunction with other events and that assume continuity. This will allow a better assessment of the issues that involve the passage of time - expirations on key validations, etc.

所需要的是运行长期测试配置,可能是与其他事件一起提供帮助并假定连续性的研讨会。这将有助于更好地评估涉及关键验证的过期时间等问题。

As was noted in section 1.1, and touched on in section 2, one component of DNSSEC, TSIG, is more advanced that the others. Use of TSIG to protect zone transfers is already matured to the "really good idea to do stage" even if other elements of DNSSEC are not. Using TSIG to protect traffic between local resolver and their "default" recursive name server still needs more work, however.

正如第1.1节所述以及第2节所述,DNSSEC的一个组件TSIG比其他组件更先进。使用TSIG保护区域转移已经成熟到“非常好的想法做阶段”,即使DNSSEC的其他元素没有。然而,使用TSIG保护本地解析器和其“默认”递归名称服务器之间的通信仍然需要更多的工作。

4.2 Does DNSSEC work? Is it the right approach?
4.2 DNSSEC有效吗?这是正确的方法吗?

Currently there is a lot of effort into making the specification as proposed work. There is some effort in assessing the specification at this point, particularly the value of the NXT records and possible replacements of it.

目前,有大量的努力,使规范作为拟议的工作。在这一点上,需要对规范进行一些评估,特别是NXT记录的价值和可能的替代品。

There seems little question on value of the KEY and SIG records. There is some research still needed on KEY validation across zone boundaries. Such work is at least scheduled.

密钥和SIG记录的价值似乎并没有什么问题。在跨区域边界的关键验证方面仍然需要进行一些研究。这样的工作至少已经安排好了。

4.3 How will client software make use of DNSSEC?
4.3 客户端软件将如何使用DNSSEC?

There are a number of efforts to take existing applications and have them make direct use of DNSSEC to carry out their functions. One such example is secure shell.

有许多工作可以利用现有的应用程序,并让它们直接使用DNSSEC来执行其功能。一个这样的例子是secureshell。

When or whether DNSSEC will be understood in the (using POSIX-like terms) operating systems "gethostbyname" and similar routines has not been addressed.

在操作系统“gethostbyname”和类似例程中(使用类似POSIX的术语)何时或是否理解DNSSEC尚未解决。

4.4 What are the remaining issues?
4.4 剩下的问题是什么?

There are still a few protocol issues. The NXT resource record is designed to provide a means to authentically deny data exists. The problem is that the solution proposed may be worse than the problem, in the eyes of some. There is an alternative proposal, the NO resource record, under consideration in the DNSEXT working group. At the present time, the DNSEXT working is considering the following question: Is there a need to authentically deny existence of data, if so, which is better, NXT (being incumbent) or NO?

还有一些协议问题。NXT资源记录旨在提供一种方法来真实地拒绝数据的存在。问题是,在一些人看来,提出的解决方案可能比问题更糟。DNSEXT工作组正在审议另一项提案,即无资源记录。目前,DNSEXT工作人员正在考虑以下问题:是否需要真实地拒绝数据的存在,如果需要,NXT(在任)与否哪个更好?

Another less defined issue is the mechanism for parent validation of children signatures. Although the protocol elements of this are becoming settled, the operational considerations are not, as evidenced by work mentioned in section 2. DNSSEC interactions have also been referenced in discussions over a standard registry-registrar protocol.

另一个定义较少的问题是子签名的父验证机制。尽管这方面的协议要素正在得到解决,但正如第2节中提到的工作所证明的那样,运营方面的考虑还没有得到解决。DNSSEC交互也在标准注册表注册协议的讨论中被引用。

5.0 Progressing to Draft Standard
5.0 向标准草案迈进

The IETF goal for DNSSEC is to progress the documents through the standards track [RFC 2026]. Currently, RFC 2535 is the second iteration at the Proposed standard level. There is a need to cycle through Proposed once more. Following this, the next goal is Draft.

DNSSEC的IETF目标是通过标准轨道[RFC 2026]推进文件。目前,RFC 2535是拟议标准水平的第二次迭代。有必要再次对提议进行循环。接下来,下一个目标是草稿。

To pass to the Draft Standard level, two main requirements must be met. There must be two or more interoperable implementations. There must also be sufficient successful operational experience.

要达到标准草案级别,必须满足两个主要要求。必须有两个或多个可互操作的实现。还必须有足够的成功运营经验。

5.1 Revision of RFC 2535 via DNSEXT
5.1 通过DNSEXT修订RFC 2535

DNSEXT will soon begin a rewrite of the RFC 2535 specification (and its support documents), rolling in updates and clarifications based upon implementation and testing experience.

DNSEXT将很快开始重写RFC2535规范(及其支持文件),并根据实施和测试经验进行更新和澄清。

5.2 Operations document(s) via DNSOP
5.2 通过DNSOP的操作文件

DNSOP will continue to be the forum for operations documents based upon DNSSEC activity. There is a need for the community to provide more documents to this group.

DNSOP将继续作为基于DNSSEC活动的运行文件论坛。社区需要向这一群体提供更多的文件。

5.3 Interoperability
5.3 互操作性

Demonstrating interoperability of DNSSEC, meaning the interaction of two different implementations when performing DNSSEC work, poses an issue because, to date, only BIND is seriously being fitted with DNSSEC. There are other partial implementations of DNSSEC functionality, so the potential for partial interoperability demonstrations may exist.

演示DNSSEC的互操作性,这意味着在执行DNSSEC工作时两种不同实现的交互,会带来一个问题,因为迄今为止,只有BIND真正安装了DNSSEC。DNSSEC功能还有其他部分实现,因此可能存在部分互操作性演示的可能性。

During the meeting, it was realized that given goals stated, a second DNSSEC implementation is needed in 18 months. Various folks in the room mentioned that they would begin see what could be done about this.

会议期间,人们意识到,鉴于所述目标,需要在18个月内第二次实施DNSSEC。房间里的许多人提到,他们将开始考虑对此可以做些什么。

6.0 Acknowledgements
6.0 致谢

The following people attended the meeting and/or provided text for this report (in no particular order): Mark Kosters (Network Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica), Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and Olafur Gudmundsson (NAI Labs).

以下人员出席了会议和/或提供了本报告的文本(无特定顺序):马克·科斯特斯(网络解决方案)、帕特里克·法尔茨特罗姆(思科)、特德·林德格林和米克·吉本(NLnet实验室)、雅普·阿克休斯(SIDN)、奥拉夫·科尔克曼(RIME NCC)、比尔·曼宁和丹·梅西(ISI)、马丁·弗雷德里克森、哈坎·奥尔森和雅各布·施莱特(Carlstedt Research&Technology)、道格·蒙哥马利(Doug Montgomery)和斯科特·罗斯(Scott Rose)(NIST)、约翰·伊伦(Johan Ihren)和拉尔斯·约翰·利曼(Lars Johan Liman)(Autonomica)、布莱恩·惠灵顿(Brian Wellington)(Nominum)、凯文·梅内尔(Kevin Meynell)(CENTR)、埃德·刘易斯(Ed。

7.0 IANA Considerations
7.0 IANA考虑

This document does not involve assigned numbers in any way.

本文件不涉及以任何方式分配的编号。

8.0 Security Considerations
8.0 安全考虑

This document, although a discussion of security enhancements to the DNS, does not itself impact security. Where security issues arise, they will be discussed in the Security Considerations of the appropriate document.

本文档虽然讨论了DNS的安全增强功能,但其本身并不影响安全性。如果出现安全问题,将在适当文件的安全考虑中讨论这些问题。

9.0 References
9.0 工具书类

The text of any RFC may be retrieved by a web browser by requesting the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is the number of the RFC.

网络浏览器可通过请求URL检索任何RFC的文本:ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt,其中“wxyz”是RFC的编号。

[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC 2026]Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", July 1997.

[RFC 2181]Elz,R.和R.Bush,“DNS规范的澄清”,1997年7月。

[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", March 1999.

[RFC 2535]Eastlake,D.,“域名系统安全扩展”,1999年3月。

[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", March 1999.

[RFC 2538]Eastlake,D.和O.Gudmundsson,“在域名系统中存储证书”,1999年3月。

[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", May 2000.

[RFC 2845]Vixie,P.,Gudmundsson,O.,Eastlake,D.和B.Wellington,“DNS秘密密钥交易认证(TSIG)”,2000年5月。

[RFC 3007] Wellington, B., "Secure Domain Name System Dynamic Update", November 2000.

[RFC 3007]惠灵顿,B.,“安全域名系统动态更新”,2000年11月。

[RFC 3008] Wellington, B., "Domain Name System Security Signing Authority", November 2000.

[RFC 3008]惠灵顿,B.,“域名系统安全签名机构”,2000年11月。

10.0 Editor's Address
10.0 编辑地址

Edward Lewis 3060 Washington Rd (Rte 97) Glenwood, MD 21738

爱德华·刘易斯美国马里兰州格伦伍德华盛顿路3060号(Rte 97),邮编21738

   Phone: +1(443)259-2352
   EMail: lewis@tislabs.com
        
   Phone: +1(443)259-2352
   EMail: lewis@tislabs.com
        
11.0 Full Copyright Statement
11.0 完整版权声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

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编辑功能的资金目前由互联网协会提供。