Independent Submission B. Manning
Request for Comments: 6804 November 2012
Category: Historic
ISSN: 2070-1721
Independent Submission B. Manning
Request for Comments: 6804 November 2012
Category: Historic
ISSN: 2070-1721
DISCOVER: Supporting Multicast DNS Queries
发现：支持多播DNS查询
Abstract
摘要
This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.
本文档描述了DISCOVER操作码，它是域名系统（DNS）的一个实验性扩展，用于使用多播查询进行资源发现。该操作码在1995年和1996年为基于拓扑的域搜索（TBDS）项目运行的实验中进行了测试。此项目不再处于活动状态，当前没有重新启动该项目的计划。TBDS是已知的DNS多播传输的首次使用。客户端使用DISCOVER操作码多播DNS查询，并处理可能产生的多个响应。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6804.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6804.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
The TBDS project developed extensions to existing network services to enable software for clients and servers of an application to become more resilient to changes in topology by dynamically sensing changes and switching between client/server and peer-peer methods for both end-system-to-server and server-to-server communications.
TBDS项目开发了对现有网络服务的扩展，以使应用程序的客户端和服务器的软件能够通过动态感知变化并在客户端/服务器和对等方法之间切换，以实现终端系统到服务器和服务器到服务器通信，从而使应用程序的客户端和服务器对拓扑变化具有更强的弹性。
The first existing network service to be investigated was the Domain Name Systems (DNS), which is used to map symbolic Internet names to numeric Internet addresses. Based upon a hierarchical tree structure, the DNS relies upon uninterrupted connectivity of nodes to a special set of static, manually configured root servers. To improve the robustness and availability of the DNS service, TBDS developed and defined enhancements that enable nodes to map names to numbers without the need for uninterrupted connectivity to the Internet root servers. These techniques were automated, allowing transition between connected and unconnected operations to be done without direct human intervention.
要调查的第一个现有网络服务是域名系统（DNS），它用于将符号互联网名称映射到数字互联网地址。基于层次树结构，DNS依赖于节点到一组特殊的静态、手动配置的根服务器的不间断连接。为了提高DNS服务的健壮性和可用性，TBDS开发并定义了增强功能，使节点能够将名称映射到数字，而无需不间断地连接到Internet根服务器。这些技术是自动化的，允许在连接和未连接的操作之间进行转换，而无需直接人工干预。
These enhancements to the DNS server code are based on the open source BIND to support reception and processing of multicast packets.
DNS服务器代码的这些增强基于开源绑定，以支持多播数据包的接收和处理。
Proof-of-concept modifications to BIND 8.1.2 were made to show that multicast awareness could be added to BIND. An analysis was made of the existing DNS code deployment and the schedule of new feature deployment so that we could synchronize TBDS with a more appropriate code base. Testing identified a race condition due to overloading the semantics of the DNS opcode that was used to communicate to servers.
对BIND 8.1.2进行了概念验证修改，以表明可以将多播感知添加到BIND中。对现有DNS代码部署和新功能部署计划进行了分析，以便我们能够将TBD与更合适的代码库同步。测试发现了由于用于与服务器通信的DNS操作码的语义过载而导致的竞争条件。
This race condition was explored within the IETF regarding use of existing DNS opcodes. Discussion within the team and with others in the IETF led to the idea that we needed a new opcode that would not overload the semantics of existing opcodes. The original DNS design specification presumes that few clients exist that would share common DNS data. To correct this problem, a new opcode was designed to disambiguate TBDS requests from normal nameserver requests.
关于现有DNS操作码的使用，IETF对这种竞争条件进行了探讨。团队内部以及与IETF中的其他人的讨论产生了这样的想法，即我们需要一种不会使现有操作码的语义过载的新操作码。最初的DNS设计规范假定很少存在共享公共DNS数据的客户端。为了纠正这个问题，我们设计了一个新的操作码来消除TBDS请求与普通名称服务器请求之间的歧义。
In the standard Domain Name System (DNS) [1] [2], queries are always unicast using the QUERY opcode. The TBDS research project [5], funded under DARPA grant F30602-99-1-0523, explored the use of multicast DNS [1] [2] queries for resource discovery by autonomous, mobile nodes in disconnected networks. The operations model is covered in the TBDS documentation. Multicast queries may return multiple replies, while the standard DNS QUERY operation (see Sections 3.7, 4.3, and 5 of RFC 1034 [1]; and Section 4.1.1 of RFC 1035 [2]) expects a single reply. Instead of extending the QUERY
在标准域名系统（DNS）[1][2]中，查询始终使用查询操作码单播。由DARPA拨款F30602-99-1-0523资助的TBDS研究项目[5]探索了使用多播DNS[1][2]查询在断开连接的网络中由自主移动节点进行资源发现。TBDS文档中介绍了操作模型。多播查询可能返回多个回复，而标准DNS查询操作（参见RFC 1034[1]第3.7、4.3和5节；以及RFC 1035[2]第4.1.1节）需要一个回复。而不是扩展查询
opcode, the project developed and tested a new query operation, DISCOVER, that was designed to accommodate multiple responses from a multicast query. The ability to accept multiple replies provides a basis for discrimination of man-in-the-middle attacks, which succeed by being the first to respond. Use of DISCOVER requires the use of caching in the receiver, so the ephemeral nature of stub resolvers is precluded.
该项目开发并测试了一种新的查询操作DISCOVER，该操作旨在容纳来自多播查询的多个响应。接受多个回复的能力为区分中间人攻击提供了基础，中间人攻击通过首先响应而成功。使用DISCOVER需要在接收器中使用缓存，因此存根解析程序的短暂性被排除。
This memo documents the processing rules for DISCOVER, for possible incorporation in a future revision of the DNS specification.
本备忘录记录了DISCOVER的处理规则，以便将来可能纳入DNS规范的修订版中。
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 BCP 14, RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。
A requester will send a DISCOVER query message to a multicast destination address, with some particular multicast scope. The requester must be prepared to receive multiple replies from multiple responders, although we expect that there will be a single reply per responder.
请求者将向具有特定多播作用域的多播目标地址发送发现查询消息。请求者必须准备好接收来自多个响应者的多个响应，尽管我们预计每个响应者将有一个响应。
DISCOVER responses (i.e., response messages from DISCOVER queries) have standard Answer, Authority, and Additional sections. For example, the DISCOVER response is the same as the response to a QUERY operation. Zero-content answers should not be sent, to avoid badly formed or unfulfilled requests. Responses should be sent to the unicast address of the requester, and the source address should reflect the unicast address of the responder. DISCOVER responses may echo the request's Question section or leave it blank, just as for QUERY.
发现响应（即，来自发现查询的响应消息）具有标准答案、权限和附加部分。例如，发现响应与查询操作的响应相同。不应发送零内容的答案，以避免格式错误或未完成的请求。响应应发送到请求者的单播地址，源地址应反映响应者的单播地址。发现响应可能会回显请求的问题部分或将其留空，就像查询一样。
DISCOVER works like QUERY, with the following exceptions:
发现与查询类似，但有以下例外：
1. The Question section of a DISCOVER operation contains <QNAME=zonename,QTYPE=SOA> tuples, if the section is present.
1. 发现操作的问题部分包含元组（如果该部分存在）。
Within TBDS, this structure was augmented with: <QNAME=service,QTYPE=SRV>. While this worked, it would be cleaner to ask the SRV question in a separate pass; any future work should take this into consideration.
在TBDS中，此结构通过：<QNAME=service，QTYPE=SRV>进行了扩充。虽然这样做有效，但在单独的关卡中询问SRV问题会更干净；今后的任何工作都应考虑到这一点。
2. If QDCOUNT equals 0, then only servers willing to do recursion should answer; other servers must silently discard a DISCOVER request with QDCOUNT equals 0.
2. 如果QDCOUNT等于0，那么只有愿意执行递归的服务器才应该响应；其他服务器必须以静默方式放弃QDCOUNT等于0的发现请求。
3. If QDCOUNT is not equal to 0, then only servers that are authoritative for the zones named by some QNAME should answer.
3. 如果QDCOUNT不等于0，则只有对某些QNAME命名的区域具有权威性的服务器才应回答。
Hence, replies to DISCOVER queries will always be authoritative or else have RA (Recursion Available) set.
因此，发现查询的回复将始终是权威的，否则将设置RA（递归可用）。
To perform a hostname lookup using DISCOVER, a node could:
要使用DISCOVER执行主机名查找，节点可以：
o Compute the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain.
o 计算封闭in-addr.arpa、ip6.int或ip6.arpa域的区域名称。
o DISCOVER whether any in-scope server(s) are authoritative for this zone.
o 发现是否有任何作用域内服务器对此区域具有权威性。
If so, query these authoritative servers for local in-addr/ip6 names.
如果是，请在这些权威服务器上查询本地in addr/ip6名称。
o If not, DISCOVER whether there are recursive servers available.
o 如果没有，请发现是否有可用的递归服务器。
If so, query these recursive servers for local in-addr/ip6 names.
如果是这样，请在这些递归服务器上查询本地in addr/ip6名称。
The requester can determine from the replies whether there are any DNS servers that are authoritative (or support recursion) for the zone.
请求者可以从回复中确定是否有任何DNS服务器对该区域具有权威性（或支持递归）。
o Once the host's Fully Qualified Domain Name (FQDN) is known, repeat the process to discover the closest enclosing authoritative server for this local name.
o 已知主机的完全限定域名（FQDN）后，重复此过程以查找此本地名称最近的封闭权威服务器。
o Cache all NS and A data learned in this process, respecting Times To Live (TTLs).
o 根据生存时间（TTL），缓存在此过程中学习到的所有NS和数据。
To lookup a service name using DISCOVER, the following steps may be used:
要使用DISCOVER查找服务名称，可以使用以下步骤：
o Use DISCOVER as outlined in Section 3.1 to perform gethostbyaddr() and then gethostbyname() on one's own link-local address. This gives a list of local authoritative servers.
o 如第3.1节所述，使用DISCOVER对自己的链接本地地址执行gethostbyaddr（）和gethostbyname（）。这将提供本地权威服务器的列表。
o Assume that the closest enclosing zone for which an authoritative server responds to an in-scope DISCOVER message is this host's "parent domain", and compute the SRV name as
o 假设权威服务器响应范围内发现消息的最近封闭区域是该主机的“父域”，并将SRV名称计算为
_service._transport.*.parentdomain.
_服务._传输。*.parentdomain。
This is a change to the definition provided in RFC 1034 [1]. A wildcard label ("*") in the QNAME used in a DNS message with the opcode DISCOVER should be evaluated with special rules: the wildcard should match any label for which the DNS server data is authoritative. For example 'x.*.example.com.' would match 'x.y.example.com.' and 'x.yy.example.com.', provided that the server was authoritative for 'example.com.'
这是对RFC 1034[1]中提供的定义的更改。在带有操作码发现的DNS消息中使用的QNAME中的通配符标签（“*”）应使用特殊规则进行评估：通配符应与DNS服务器数据具有权威性的任何标签匹配。例如，“x.*.example.com.”将与“x.y.example.com.”和“x.yy.example.com.”匹配，前提是服务器是“example.com”的权威服务器
o Finally, send an SRV query for this SRV name to the discovered local authoritative servers to complete the getservbyname() call.
o 最后，将此SRV名称的SRV查询发送到发现的本地权威服务器，以完成getservbyname（）调用。
This call returns a structure that can be populated by response values, as follows:
此调用返回可由响应值填充的结构，如下所示：
s_name The name of the service, "_service" without the preceding underscore.
s_name服务的名称，“_service”不带前面的下划线。
s_aliases The names returned in the SRV Resource Records (RRs) in replies to the query.
s_在对查询的答复中为SRV资源记录（RRs）中返回的名称加上别名。
s_port The port number in the SRV RRs replies to the query. If these port numbers do not match, one of the port numbers is chosen, and only those names that correspond are returned.
s_port SRV RRs中的端口号用于答复查询。如果这些端口号不匹配，则选择其中一个端口号，并仅返回相应的名称。
s_proto The transport protocol passed from the DNS process using the "_transport" label, without the preceding underscore.
s_proto使用“_transport”标签从DNS进程传递的传输协议，前面没有下划线。
DISCOVER allows discovery of a host (for example, a printer offering LPD services) whose DNS server answers authoritatively for a domain name that hasn't been delegated to it, but is defined within some local scope. Since DISCOVER is explicitly defined to discover undelegated zones for tightly scoped queries, this behavior isn't a violation of DNS's coherency principles. Note that a responder to DISCOVER might not be traditional DNS software, it could be special-purpose software.
DISCOVER允许发现主机（例如，提供LPD服务的打印机），该主机的DNS服务器对未委托给它但在某些本地范围内定义的域名进行授权应答。由于DISCOVER是显式定义的，用于为范围严格的查询发现未授权区域，因此此行为并不违反DNS的一致性原则。请注意，要发现的响应程序可能不是传统的DNS软件，它可能是专用软件。
DISCOVER usage for disconnected networks with no authoritative servers can be achieved using the following conditions:
使用以下条件可以发现没有权威服务器的断开网络的使用情况：
o Hosts run a "stub authoritative server" that acts as though its FQDN were a zone name.
o 主机运行一个“存根权威服务器”，该服务器的FQDN是一个区域名称。
o The computed SOA gives the host's FQDN as the MNAME, "." as the ANAME, seconds-since-1Jan2000 as the SERIAL, and low constants for EXPIRE and the other SOA timers.
o 计算出的SOA将主机的FQDN作为MNAME，“.”作为ANAME，seconds-since-1Jan2000作为串行，EXPIRE和其他SOA计时器的常量为low。
o NS is used as the host's FQDN.
o NS用作主机的FQDN。
o The glue is computed as the host's link-local address, or hosts may run a "DNS stub server" that acts as though its FQDN were a zone name.
o 胶水被计算为主机的链接本地地址，或者主机可以运行一个“DNS存根服务器”，该服务器的作用就像其FQDN是一个区域名称一样。
The rules governing the behavior of this server consist of a single change to the method of use, and no change whatsoever to the current format of DNS packets. Specifically, this extension allows UDP DNS queries, as documented in RFC 1035, Sections 4.1.1, 4.1.2, and 4.2.1, to be addressed to port 53 of statically assigned relative offset -4 within the range of multicast addresses defined as "administratively scoped" by Section 9 of RFC 2365 [6]. Within the full /8 of administratively scoped addresses, this corresponds to the destination address 239.255.255.251. Until the Multicast-Scope Zone Announcement Protocol (MZAP) or a similar protocol is implemented to allow hosts to discover the extent of the local multicast scopes that enclose them, it is anticipated that implementations will simply utilize the destination address 239.255.255.251. Queries sent via multicast MUST NOT request recursion.
管理此服务器行为的规则包括对使用方法的单个更改，以及对DNS数据包的当前格式的任何更改。具体而言，此扩展允许UDP DNS查询（如RFC 1035第4.1.1、4.1.2和4.2.1节所述）在RFC 2365[6]第9节定义为“管理范围”的多播地址范围内寻址到静态分配的相对偏移量-4的端口53。在全部/8个管理作用域地址中，这对应于目标地址239.255.255.251。在实现多播作用域区域公告协议（MZAP）或类似协议以允许主机发现包含它们的本地多播作用域的范围之前，预计实现将仅利用目标地址239.255.255.251。通过多播发送的查询不能请求递归。
In order to receive multicasted queries, DNS server implementations MUST listen on the -4 offset to their local scope (as above, in the absence of a method of determining the scope, this will be assumed to be relative to the full /8 allocated for administratively scoped multicast use, or 239.255.255.251) and respond via ordinary unicast UDP to ONLY those queries for which they have a positive answer that originated within a locally-configured zone file. That is, a server MUST NOT answer a multicasted query with cached information that it received from another server, nor may it request further resolution from other servers on behalf of a multicasted query. A multicast-capable server may, however, utilize multicast queries to perform further resolution on behalf of queries received via ordinary unicast. This is referred to as "proxy" operation. Multicast-enabled DNS servers MUST answer multicasted queries non-authoritatively. That is, when responding to a query that was
为了接收多播查询，DNS服务器实现必须侦听其本地作用域的-4偏移量（如上所述，在没有确定作用域的方法的情况下，这将假定是相对于分配给管理作用域多播使用的完整/8，或239.255.255.251）并通过普通单播UDP仅对那些在本地配置的区域文件中得到肯定答案的查询进行响应。也就是说，服务器不能用从另一台服务器接收的缓存信息回答多播查询，也不能代表多播查询请求其他服务器的进一步解析。然而，支持多播的服务器可以利用多播查询来代表通过普通单播接收的查询执行进一步的解析。这称为“代理”操作。启用多播的DNS服务器必须以非授权方式回答多播查询。也就是说，当响应一个
received via multicast, they MUST NOT include an NS record that contains data that resolves back to their own IP address and MUST NOT set the AA bit.
通过多播接收，它们不得包含包含解析回其自己IP地址的数据的NS记录，并且不得设置AA位。
Resolvers MUST anticipate receiving no replies to some multicasted queries, in the event that no multicast-enabled DNS server implementations are active within the local scope, or in the event that no positive responses exist to the transmitted query. That is, a query for the MX record for host.domain.com would go unanswered if no local server was able to resolve that request, if no MX record exists for host.domain.com, or if no local servers were capable of receiving multicast queries. The resolver that initiated the query MUST treat such non-response as a non-cacheable negative response. Since this multicast transmission does not provide reliable delivery, resolvers MAY repeat the transmission of a query in order to assure themselves that is has been received by any hosts capable of answering; however, any resolvers that repeat a query MUST increase the interval by a factor of two between each repetition. It is more likely, however, that any repeated queries will be performed under the explicit direction of the application driving the query, rather than autonomously by the resolver implementation.
如果本地范围内没有启用多播的DNS服务器实现处于活动状态，或者传输的查询不存在肯定响应，则解析程序必须预期不会收到对某些多播查询的答复。也就是说，如果没有本地服务器能够解析该请求，如果没有host.domain.com的MX记录，或者如果没有本地服务器能够接收多播查询，那么对host.domain.com的MX记录的查询将无法响应。启动查询的解析程序必须将此类非响应视为不可缓存的否定响应。由于该多播传输不提供可靠的传送，解析程序可以重复查询的传输，以确保其自身已被任何能够应答的主机接收；但是，任何重复查询的解析程序都必须将每次重复之间的间隔增加两倍。然而，更可能的情况是，任何重复的查询都将在驱动查询的应用程序的明确指示下执行，而不是由解析器实现自主执行。
It will often be the case that multicast queries will result in responses from multiple servers. In the event that the multicast query was generated via a current API such as gethostbyname, or as the result of a proxy operation, the first response received must be passed to the requesting application or host, and all subsequently received responses must be discarded. Future multicast-aware APIs that use DISCOVER should anticipate receiving multiple independent RR sets in response to queries and using external heuristics for selecting the most appropriate RR set.
通常情况下，多播查询将导致来自多个服务器的响应。如果多播查询是通过当前API（如gethostbyname）生成的，或者是代理操作的结果，则必须将收到的第一个响应传递给请求的应用程序或主机，并且必须丢弃所有随后收到的响应。未来使用DISCOVER的多播感知API应该能够接收多个独立的RR集来响应查询，并使用外部启发式方法来选择最合适的RR集。
Such servers should answer DISCOVER packets for its zone, and will be found by the iterative "discover closest enclosing authority server" by DISCOVER clients, in either the gethostbyname() or SRV cases described above. Note that stub servers answer only with zone names that exactly match QNAME's, not with zone names that are owned by QNAME's.
这样的服务器应该为其区域应答DISCOVER数据包，并将由DISCOVER客户机在上述gethostbyname（）或SRV情况下通过迭代的“DISCOVER closest enclosuring authority server”找到。请注意，存根服务器只回答与QNAME完全匹配的区域名称，而不是QNAME拥有的区域名称。
At such time as this idea might be considered for a future addition to the DNS protocol, IANA would need to assign a value for the opcode.
在这个想法可能会被考虑作为DNS协议的未来补充时，IANA需要为操作码分配一个值。
The following paragraph on security considerations was written very early in the use and exploration of IP multicast and, as such, represents a fairly naive view on the type and scope of exploits that are enabled through the use of IP multicast. A more up-to-date understanding of multicast security considerations may be found in RFC 5294 [4].
以下关于安全考虑的段落是在使用和探索IP多播的早期编写的，因此，对于通过使用IP多播启用的漏洞利用的类型和范围，代表了一种相当幼稚的观点。RFC 5294[4]中提供了对多播安全注意事项的最新理解。
No new security considerations are known to be introduced with a new DNS query operation. However, using multicast for service discovery has the potential for denial of service from flooding attacks. How to scope multicast is not part of the DISCOVER processing rules. It may also be possible to enable deliberate misconfiguration of clients simply by running a malicious DNS server that falsely claims to be authoritative for delegations. One possible way to mitigate this threat is to use credentials, such as CERT resource records within an RR set. The TBDS project took this approach. TBDS did not directly utilize DNS Security (DNSSEC), so possible interactions with DNSSEC-aware/-capable servers are unknown.
已知新的DNS查询操作不会引入新的安全注意事项。但是，使用多播进行服务发现可能会导致拒绝服务攻击。如何确定多播的作用域不是发现处理规则的一部分。也有可能仅仅通过运行恶意DNS服务器（该服务器虚假地声称对委托具有权威性）来故意错误配置客户端。缓解此威胁的一种可能方法是使用凭据，例如RR集中的证书资源记录。TBDS项目采用了这种方法。TBDS没有直接利用DNS安全性（DNSSEC），因此无法与支持DNSSEC/的服务器进行交互。
This material was generated in discussions on the mdns mailing list hosted by Zocalo in March 2000 and updated by discussions in September/October 2003 on a closed mailing list. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, and Erik Guttman were active contributors. Suzanne Woolf was part of the original implementation team and an invaluable sanity checker. Funding for the RFC Editor function is currently provided by the Internet Society.
这一材料是在2000年3月由Zocalo主持的关于mdns邮件列表的讨论中产生的，并在2003年9月/10月关于封闭邮件列表的讨论中更新。大卫·劳伦斯、斯科特·罗斯、斯图尔特·切希尔、比尔·伍德科克和埃里克·古特曼都是积极的贡献者。苏珊娜·伍尔夫（Suzanne Woolf）是最初实施团队的一员，也是一位无价之宝。RFC编辑功能的资金目前由互联网协会提供。
[1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008.
[4] Savola，P.和J.Lingard，“协议独立多播（PIM）的主机威胁”，RFC 52942008年8月。
[5] Manning, B., "Topology Based Domain Search (TBDS)", Final Report, June 2002, <http://www.dtic.mil/docs/citations/ADA407598>.
[5] Manning，B.，“基于拓扑的域搜索（TBDS）”，最终报告，2002年6月<http://www.dtic.mil/docs/citations/ADA407598>.
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[6] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
Authors' Addresses
作者地址
Bill Manning PO 12317 Marina del Rey, CA. 90295 United States
比尔·曼宁邮政12317马里纳·德雷，约美国90295
EMail: bmanning@sfc.keio.ac.jp
EMail: bmanning@sfc.keio.ac.jp