Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6305 ICANN
Category: Informational W. Maton
ISSN: 2070-1721 NRC-CNRC
July 2011
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6305 ICANN
Category: Informational W. Maton
ISSN: 2070-1721 NRC-CNRC
July 2011
I'm Being Attacked by PRISONER.IANA.ORG!
我被囚犯攻击了。IANA.ORG！
Abstract
摘要
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.
许多连接到Internet的站点使用的IPv4地址不是全局唯一的。例如，RFC 1918中指定的地址，供各个站点内的私人使用。
Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.
主机通常不应发送公共Internet上这些地址的DNS反向映射查询。然而，这种查询经常被观察到。权威服务器的部署是为了为此类查询提供权威答案，这是AS112项目松散协调工作的一部分。
Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.
由于发送到AS112服务器的查询通常不是有意的，因此从这些服务器收到的回复通常是意外的。意外的入站流量可能会触发入侵检测系统和防火墙上的警报，而这类系统的操作员往往错误地认为他们正在受到攻击。
This document provides background information and technical advice to those firewall operators.
本文档为这些防火墙操作员提供背景信息和技术建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6305.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6305.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Target Audience . . . . . . . . . . . . . . . 3
2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . . 3
4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . . 4
5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 5
7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . . 5
8. AS112 Contact Information . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction and Target Audience . . . . . . . . . . . . . . . 3
2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . . 3
4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . . 4
5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 5
7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . . 5
8. AS112 Contact Information . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . . 7
Readers of this document may well have experienced an alarm from a firewall or an intrusion-detection system, triggered by unexpected inbound traffic from the Internet. The traffic probably appeared to originate from one of several hosts discussed further below.
本文档的读者可能已经体验到来自防火墙或入侵检测系统的警报，该警报由来自Internet的意外入站流量触发。流量可能来自下面进一步讨论的几个主机之一。
The published contacts for those hosts may well have suggested that you consult this document.
这些主机的已发布联系人可能建议您查阅此文档。
If you are following up on such an event, you are encouraged to follow your normal security procedures and take whatever action you consider to be appropriate. This document contains information that may assist you.
如果你正在跟进这样的事件，鼓励你遵循你的正常安全程序，采取任何你认为合适的行动。本文档包含可能对您有所帮助的信息。
Many sites connected to the Internet make use of address blocks designated in [RFC1918] for private use. One example of such addresses is 10.1.30.20.
许多连接到互联网的站点使用[RFC1918]中指定的地址块供私人使用。此类地址的一个示例是10.1.30.20。
Because these ranges of addresses are used by many sites all over the world, each individual address can only ever have local significance. For example, the host numbered 192.168.18.234 in one site almost certainly has nothing to do with a host with the same address located in a different site.
由于世界各地的许多网站都在使用这些地址范围，因此每个地址只能具有本地意义。例如，在一个站点中编号为192.168.18.234的主机几乎肯定与位于不同站点中具有相同地址的主机无关。
The Domain Name System (DNS) [RFC1034] can be used to obtain a name for a particular network address. The process by which this happens is as follows:
域名系统（DNS）[RFC1034]可用于获取特定网络地址的名称。发生这种情况的过程如下：
1. The network address is rearranged in order to construct a name that can be looked up in the DNS. For example, the IPv4 address 10.1.30.20 corresponds to the DNS name 20.30.1.10.IN-ADDR.ARPA.
1. 重新排列网络地址，以便构造可在DNS中查找的名称。例如，IPv4地址10.1.30.20对应于DNS名称20.30.1.10.IN-ADDR.ARPA。
2. A DNS query is constructed for that name, requesting a DNS record of the type "PTR".
2. 为该名称构造DNS查询，请求类型为“PTR”的DNS记录。
3. The DNS query is sent to a resolver.
3. DNS查询被发送到解析程序。
4. If a response is received in response to the query, the answer will typically indicate either the hostname corresponding to the network address, or the fact that no hostname can be found.
4. 如果接收到响应查询的响应，则答案通常会指示与网络地址对应的主机名，或者表明找不到主机名。
This procedure is generally carried out automatically by software, and hence is largely hidden from users and administrators.
此过程通常由软件自动执行，因此在很大程度上对用户和管理员隐藏。
Applications might have reason to look up an IP address in order to gather extra information for a log file, for example.
例如，应用程序可能有理由查找IP地址以收集日志文件的额外信息。
As noted in Section 2, private-use addresses have only local significance. This means that sending queries out to the Internet is not sensible: there is no way for the public DNS to provide a useful answer to a question that has no global meaning.
如第2节所述，专用地址仅具有本地意义。这意味着向互联网发送查询是不明智的：公共DNS无法为没有全球意义的问题提供有用的答案。
Despite the fact that the public DNS cannot provide answers, many sites have misconfigurations in the way they connect to the Internet; this results in such queries relating to internal infrastructure being sent outside the site. From the perspective of the public DNS, these queries are junk -- they cannot be answered usefully and result in unnecessary traffic being received by the nameservers which underpin the operation of the reverse DNS (the so-called reverse servers [RFC5855], which serve "IN-ADDR.ARPA").
尽管公共DNS无法提供答案，但许多网站在连接互联网的方式上存在错误配置；这会导致将与内部基础结构相关的查询发送到站点外部。从公共DNS的角度来看，这些查询是垃圾——它们无法得到有效的回答，并导致支持反向DNS操作的名称服务器（所谓的反向服务器[RFC5855]，服务于“in-ADDR.ARPA”）接收到不必要的流量。
To isolate this traffic and reduce the load on the rest of the reverse DNS infrastructure, dedicated servers have been deployed in the Internet to receive and reply to these junk queries. These servers are deployed in many places in a loosely coordinated effort known as the "AS112 project". More details about the AS112 project can be found at <http://www.as112.net/>.
为了隔离此流量并减少反向DNS基础设施其余部分的负载，在Internet中部署了专用服务器来接收和回复这些垃圾查询。这些服务器部署在许多地方，这是一项松散协调的工作，称为“AS112项目”。有关AS112项目的更多详细信息，请访问<http://www.as112.net/>.
The nameservers responsible for answering queries relating to private-use addresses are as follows:
负责回答与私人使用地址有关的查询的名称服务器如下：
o PRISONER.IANA.ORG (192.175.48.1)
o Captile.IANA.ORG（192.175.48.1）
o BLACKHOLE-1.IANA.ORG (192.175.48.6)
o 黑洞-1.IANA.ORG（192.175.48.6）
o BLACKHOLE-2.IANA.ORG (192.175.48.42)
o 黑洞-2.IANA.ORG（192.175.48.42）
A request sent to one of these servers will result in a response being returned to the client. The response will typically be a UDP datagram, although it's perfectly valid for requests to be made over TCP. In both cases, the source port of packets returning to the site that originated the DNS request will be 53.
发送到这些服务器之一的请求将导致响应返回到客户端。响应通常是UDP数据报，尽管它对通过TCP发出的请求完全有效。在这两种情况下，返回发起DNS请求的站点的数据包的源端口都是53。
Where firewalls or intrusion detection systems (IDSs) are configured to block traffic received from AS112 servers, superficial review of the traffic may seem alarming to site administrators.
当防火墙或入侵检测系统（IDS）配置为阻止从AS112服务器接收的流量时，对流量的肤浅审查可能会让站点管理员感到震惊。
o Since requests directed ultimately to AS112 servers are usually triggered automatically by applications, review of firewall logs may indicate a large number of policy violations occurring over an extended period of time.
o 由于最终定向到AS112服务器的请求通常由应用程序自动触发，因此查看防火墙日志可能表明在较长时间内发生大量违反策略的情况。
o Where responses from AS112 servers are blocked by firewalls, hosts will often retry, often with a relatively high frequency. This can cause inbound traffic to be misclassified as a denial-of-service (DoS) attack. In some cases, the source ports used by individual hosts for successive retries increase in a predictable fashion (e.g. monotonically), which can cause the replies from the AS112 server to resemble a port scan.
o 当AS112服务器的响应被防火墙阻止时，主机通常会重试，重试频率通常相对较高。这可能导致入站流量被错误分类为拒绝服务（DoS）攻击。在某些情况下，个别主机用于连续重试的源端口以可预测的方式（例如单调地）增加，这可能导致来自AS112服务器的回复类似于端口扫描。
o A site administrator may attempt to perform active measurement of the remote host in response to alarms raised by inbound traffic, e.g. initiating a port scan in order to gather information about the host which is apparently attacking the site. Such a scan will usually result in additional inbound traffic to the site performing the measurement, e.g., an apparent flood of ICMP messages that may trigger additional firewall alarms and obfuscate the process of identifying the originally problematic traffic.
o 站点管理员可能会尝试对远程主机执行主动测量，以响应入站流量引发的警报，例如，启动端口扫描，以收集有关显然正在攻击站点的主机的信息。这种扫描通常会导致执行测量的站点出现额外的入站流量，例如，ICMP消息的明显泛滥，可能会触发额外的防火墙警报，并混淆识别最初有问题流量的过程。
A site that receives responses from one of the nameservers listed in Section 5 is probably under no immediate danger, and the traffic associated with those responses probably requires no emergency action by the site concerned. However, this document cannot aspire to dictate the security policy of individual sites, and it is recognised that many sites will have perfectly valid policies that dictate that corrective measures should be taken to stop the responses from AS112 servers.
从第5节中列出的一个名称服务器接收响应的站点可能没有立即的危险，与这些响应相关的流量可能不需要相关站点采取紧急行动。然而，本文件不能要求规定各个站点的安全策略，并且认识到许多站点将具有完全有效的策略，规定应采取纠正措施来停止来自AS112服务器的响应。
It should be noted, however, that the operators of AS112 nameservers, which are generating the responses described in this document, are not ultimately responsible for the inbound traffic received by the site: that traffic is generated in response to queries that are sent out from the site, and so the only effective measures to stop the inbound traffic is to prevent the original queries from being made.
但是，应注意的是，生成本文档中所述响应的AS112名称服务器的操作员对站点接收到的入站流量不负最终责任：该流量是响应从站点发出的查询而生成的，因此，阻止入站流量的唯一有效措施是阻止原始查询的产生。
Possible measures that might be taken to prevent these queries include:
可能采取的防止这些查询的措施包括：
1. Stop hosts from making these DNS reverse-mapping queries in the first place. In some cases, servers can be configured not to perform DNS reverse-mapping lookups, for example. As a general site-wide approach, however, this measure is frequently difficult to implement due to the large number of hosts and applications involved.
1. 首先停止主机进行这些DNS反向映射查询。例如，在某些情况下，可以将服务器配置为不执行DNS反向映射查找。但是，作为一种通用的站点范围方法，由于涉及大量主机和应用程序，此措施通常很难实施。
2. Block DNS reverse-mapping queries to the AS112 servers from leaving the site using firewalls between the site and the Internet. Although this might appear to be sensible, such a measure might have unintended consequences: the inability to receive an answer to DNS reverse-mapping queries might lead to long DNS lookup timeouts, for example, which could cause applications to malfunction. (It may also lead to the belief that the Internet or the local network is down.)
2. 使用站点和Internet之间的防火墙阻止对AS112服务器的DNS反向映射查询离开站点。尽管这似乎是合理的，但这样的措施可能会产生意外的后果：例如，无法接收DNS反向映射查询的答案可能会导致长时间的DNS查找超时，这可能会导致应用程序出现故障。（这也可能导致人们认为互联网或本地网络已关闭。）
3. Configure all DNS resolvers in the site to answer authoritatively for the zones corresponding to the private-use address blocks in use. This should prevent resolvers from ever needing to send these queries to the public DNS. Guidance and recommendations for this aspect of resolver configuration can be found in [RFC6303].
3. 将站点中的所有DNS解析程序配置为对与正在使用的专用地址块相对应的区域进行授权应答。这将防止解析程序需要将这些查询发送到公共DNS。在[RFC6303]中可以找到有关分解器配置这方面的指导和建议。
4. Implement a private AS112 node within the site. Guidance for constructing an AS112 node may be found in [RFC6304].
4. 在站点内实现专用AS112节点。可在[RFC6304]中找到构建AS112节点的指南。
More information about the AS112 project can be found at <http://www.as112.net/>.
有关AS112项目的更多信息，请访问<http://www.as112.net/>.
The AS112 nameservers are all named under the domain IANA.ORG (see Section 5). The IANA is the organisation responsible for the coordination of many technical aspects of the Internet's basic infrastructure. The AS112 project nameservers provide a public service to the Internet that is sanctioned by and operated in loose coordination with the IANA.
AS112命名服务器均在域名IANA.ORG下命名（见第5节）。IANA是负责协调互联网基础设施许多技术方面的组织。AS112项目名称服务器向互联网提供公共服务，该服务由IANA批准，并与IANA进行松散协调。
The purpose of this document is to help site administrators properly identify traffic received from AS112 nodes and to provide background information to allow appropriate measures to be taken in response to it.
本文档的目的是帮助站点管理员正确识别从AS112节点接收到的通信量，并提供背景信息，以便采取适当的措施响应。
Hosts should never normally send queries to AS112 servers: queries relating to private-use addresses should be answered locally within a site. Hosts that send queries to AS112 servers may well leak information relating to private infrastructure to the public network; this could represent a security risk.
主机通常不应向AS112服务器发送查询：与专用地址相关的查询应在站点内本地回答。向AS112服务器发送查询的主机很可能会将与私有基础设施相关的信息泄漏到公共网络；这可能会带来安全风险。
The authors wish to acknowledge the assistance of S. Moonesamy in the preparation of this document.
作者希望感谢S.Moonesamy在编写本文件过程中提供的帮助。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", BCP 155, RFC 5855, May 2010.
[RFC5855]Abley，J.和T.Manderson，“IPv4和IPv6反向区域的名称服务器”，BCP 155，RFC 5855，2010年5月。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011.
[RFC6303]Andrews，M.，“本地服务DNS区域”，BCP 163，RFC 6303，2011年7月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304]Abley，J.和W.Maton，“AS112名称服务器操作”，RFC6304，2011年7月。
Authors' Addresses
作者地址
Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US
Joe Abley ICANN 4676金钟路330号套房马里纳德雷，美国加利福尼亚州90292
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
William F. Maton Sotomayor National Research Council of Canada 1200 Montreal Road Ottawa, ON K1A 0R6 Canada
William F.Maton Sotomayor加拿大国家研究委员会，位于加拿大K1A 0R6的渥太华蒙特利尔路1200号
Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca
Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca