draft-ietf-dnsop-as112-under-attack-help-help-06.txt   rfc6305.txt 
Network Working Group J. Abley Internet Engineering Task Force (IETF) J. Abley
Internet-Draft ICANN Request for Comments: 6305 ICANN
Intended status: Informational W. Maton Category: Informational W. Maton
Expires: October 31, 2011 NRC-CNRC ISSN: 2070-1721 NRC-CNRC
April 29, 2011 July 2011
I'm Being Attacked by PRISONER.IANA.ORG! I'm Being Attacked by PRISONER.IANA.ORG!
draft-ietf-dnsop-as112-under-attack-help-help-06
Abstract Abstract
Many sites connected to the Internet make use of IPv4 addresses which Many sites connected to the Internet make use of IPv4 addresses that
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
RFC1918 for private use within individual sites. RFC 1918 for private use within individual sites.
Hosts should never normally send DNS reverse mapping queries for Hosts should never normally send DNS reverse-mapping queries for
those addresses on the public Internet. However, such queries are those addresses on the public Internet. However, such queries are
frequently observed. Authoritative servers are deployed to provide frequently observed. Authoritative servers are deployed to provide
authoritative answers to such queries as part of a loosely- authoritative answers to such queries as part of a loosely
coordinated effort known as the AS112 project. coordinated effort known as the AS112 project.
Since queries sent to AS112 servers are usually not intentional, the Since queries sent to AS112 servers are usually not intentional, the
replies received back from those servers are typically unexpected. replies received back from those servers are typically unexpected.
Unexpected inbound traffic can trigger alarms on intrusion detection Unexpected inbound traffic can trigger alarms on intrusion detection
systems and firewalls, and operators of such systems often mistakenly systems and firewalls, and operators of such systems often mistakenly
believe that they are being attacked. believe that they are being attacked.
This document provides background information and technical advice to This document provides background information and technical advice to
those firewall operators. those firewall operators.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on October 31, 2011. 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.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Target Audience . . . . . . . . . . . . . . . 3 1. Introduction and Target Audience . . . . . . . . . . . . . . . 3
2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 4 2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 5 3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . . 3
4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . 6 4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . . 4
5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 7 5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 8 6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 5
7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 9 7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . . 5
8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 10 8. AS112 Contact Information . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction and Target Audience 1. Introduction and Target Audience
Readers of this document may well have experienced an alarm from a Readers of this document may well have experienced an alarm from a
firewall or an intrusion-detection system, triggered by unexpected firewall or an intrusion-detection system, triggered by unexpected
inbound traffic from the Internet. The traffic probably appeared to inbound traffic from the Internet. The traffic probably appeared to
originate from one of several hosts discussed further below. originate from one of several hosts discussed further below.
The published contacts for those hosts may well have suggested that The published contacts for those hosts may well have suggested that
you consult this document. you consult this document.
If you are following up on such an event, you are encouraged to If you are following up on such an event, you are encouraged to
follow your normal security procedures and take whatever action you follow your normal security procedures and take whatever action you
consider to be be appropriate. This document contains information consider to be appropriate. This document contains information that
which may assist you. may assist you.
2. Private-Use Addresses 2. Private-Use Addresses
Many sites connected to the Internet make use of address blocks Many sites connected to the Internet make use of address blocks
designated in [RFC1918] for private use. One example of such designated in [RFC1918] for private use. One example of such
addresses is 10.1.30.20. addresses is 10.1.30.20.
Because these ranges of addresses are used by many sites all over the Because these ranges of addresses are used by many sites all over the
world, each individual address can only ever have local significance. world, each individual address can only ever have local significance.
For example, the host numbered 192.168.18.234 in one site almost 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 certainly has nothing to do with a host with the same address located
in a different site. in a different site.
3. DNS Reverse Mapping 3. DNS Reverse Mapping
The Domain Name System (DNS) [RFC1034] can be used to obtain a name The Domain Name System (DNS) [RFC1034] can be used to obtain a name
for a particular network address. The process by which this happens for a particular network address. The process by which this happens
is as follows: is as follows:
1. The network address is rearranged in order to construct a name 1. The network address is rearranged in order to construct a name
which can be looked up in the DNS. For example, the IPv4 address 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. 10.1.30.20 corresponds to the DNS name 20.30.1.10.IN-ADDR.ARPA.
2. A DNS query is constructed for that name, requesting a DNS record 2. A DNS query is constructed for that name, requesting a DNS record
of the type "PTR". of the type "PTR".
3. The DNS query is sent to a resolver. 3. The DNS query is sent to a resolver.
4. If a response is received in response to the query, the answer 4. If a response is received in response to the query, the answer
will typically indicate either the hostname corresponding to the will typically indicate either the hostname corresponding to the
network address, or the fact that no hostname can be found. network address, or the fact that no hostname can be found.
This procedure is generally carried out automatically by software, This procedure is generally carried out automatically by software,
and is hence largely hidden from users and administrators. and hence is largely hidden from users and administrators.
Applications might have reason to look up an IP address in order to Applications might have reason to look up an IP address in order to
gather extra information for a log file, for example. gather extra information for a log file, for example.
4. DNS Reverse Mapping for Private-Use Addresses 4. DNS Reverse Mapping for Private-Use Addresses
As noted in Section 2, private-use addresses have only local As noted in Section 2, private-use addresses have only local
significance. This means that sending queries out to the Internet is 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 not sensible: there is no way for the public DNS to provide a useful
answer to a question which has no global meaning. answer to a question that has no global meaning.
Despite the fact that the public DNS cannot provide answers, many Despite the fact that the public DNS cannot provide answers, many
sites have misconfigurations in the way they connect to the Internet sites have misconfigurations in the way they connect to the Internet;
which results in such queries relating to internal infrastructure this results in such queries relating to internal infrastructure
being sent outside the site. From the perspective of the public DNS, being sent outside the site. From the perspective of the public DNS,
these queries are junk -- they cannot be answered usefully and result these queries are junk -- they cannot be answered usefully and result
in unnecessary traffic being received by the nameservers which in unnecessary traffic being received by the nameservers which
underpin the operation of the reverse DNS (the so-called reverse underpin the operation of the reverse DNS (the so-called reverse
servers [RFC5855] which serve "IN-ADDR.ARPA"). servers [RFC5855], which serve "IN-ADDR.ARPA").
To isolate this traffic, and reduce the load on the rest of the To isolate this traffic and reduce the load on the rest of the
reverse DNS infrastructure, dedicated servers have been deployed in reverse DNS infrastructure, dedicated servers have been deployed in
the Internet to receive and reply to these junk queries. These the Internet to receive and reply to these junk queries. These
servers are deployed in many places in a loosely-coordinated effort servers are deployed in many places in a loosely coordinated effort
known as the "AS112 Project". More details about the AS112 Project known as the "AS112 project". More details about the AS112 project
can be found at <http://www.as112.net/>. can be found at <http://www.as112.net/>.
5. AS112 Nameservers 5. AS112 Nameservers
The nameservers responsible for answering queries relating to The nameservers responsible for answering queries relating to
private-use addresses are as follows: private-use addresses are as follows:
o PRISONER.IANA.ORG (192.175.48.1) o PRISONER.IANA.ORG (192.175.48.1)
o BLACKHOLE-1.IANA.ORG (192.175.48.6) o BLACKHOLE-1.IANA.ORG (192.175.48.6)
o BLACKHOLE-2.IANA.ORG (192.175.48.42) o BLACKHOLE-2.IANA.ORG (192.175.48.42)
A request sent to one of these servers will result in a response 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 being returned to the client. The response will typically be a UDP
datagram, although it's perfectly valid for requests to be made over 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 TCP. In both cases, the source port of packets returning to the site
which originated the DNS request will be 53. that originated the DNS request will be 53.
6. Inbound Traffic from AS112 Servers 6. Inbound Traffic from AS112 Servers
Where firewalls or intrusion detection systems (IDS) are configured Where firewalls or intrusion detection systems (IDSs) are configured
to block traffic received from AS112 servers, superficial review of to block traffic received from AS112 servers, superficial review of
the traffic may seem alarming to site administrators. the traffic may seem alarming to site administrators.
o Since requests directed ultimately to AS112 servers are usually o Since requests directed ultimately to AS112 servers are usually
triggered automatically by applications, review of firewall logs triggered automatically by applications, review of firewall logs
may indicate a large number of policy violations occurring over an may indicate a large number of policy violations occurring over an
extended period of time. extended period of time.
o Where responses from AS112 servers are blocked by firewalls, hosts o Where responses from AS112 servers are blocked by firewalls, hosts
will often retry, often with a relatively high frequency. This will often retry, often with a relatively high frequency. This
can cause inbound traffic to be misclassified as a denial-of- can cause inbound traffic to be misclassified as a denial-of-
service (DoS) attack. In some cases the source ports used by service (DoS) attack. In some cases, the source ports used by
individual hosts for successive retries increase in a predictable individual hosts for successive retries increase in a predictable
fashion (e.g. monotonically), which can cause the replies from the fashion (e.g. monotonically), which can cause the replies from the
AS112 server to resemble a port scan. AS112 server to resemble a port scan.
o A site administrator may attempt to perform active measurement of o A site administrator may attempt to perform active measurement of
the remote host in response to alarms raised by inbound traffic, the remote host in response to alarms raised by inbound traffic,
e.g. initiating a port scan in order to gather information about e.g. initiating a port scan in order to gather information about
the host which is apparently attacking the site. Such a scan will the host which is apparently attacking the site. Such a scan will
usually result in additional inbound traffic to the site usually result in additional inbound traffic to the site
performing the measurement, e.g. an apparent flood of ICMP performing the measurement, e.g., an apparent flood of ICMP
messages which may trigger additional firewall alarms and messages that may trigger additional firewall alarms and obfuscate
obfuscate the process of identifying the original problem traffic. the process of identifying the originally problematic traffic.
7. Corrective Measures 7. Corrective Measures
A site which receives responses from one of the nameservers listed in A site that receives responses from one of the nameservers listed in
Section 5 is probably under no immediate danger, and the traffic Section 5 is probably under no immediate danger, and the traffic
associated with those responses probably requires no emergency action associated with those responses probably requires no emergency action
by the site concerned. However, this document cannot aspire to by the site concerned. However, this document cannot aspire to
dictate the security policy of individual sites, and it is recognised dictate the security policy of individual sites, and it is recognised
that many sites will have perfectly valid policies which dictate that that many sites will have perfectly valid policies that dictate that
corrective measures should be taken to stop the responses from AS112 corrective measures should be taken to stop the responses from AS112
servers. servers.
It should be noted, however, that the operators of AS112 nameservers It should be noted, however, that the operators of AS112 nameservers,
which are generating the responses described in this document are not which are generating the responses described in this document, are
ultimately responsible for the inbound traffic received by the site: not ultimately responsible for the inbound traffic received by the
that traffic is generated in response to queries which are sent out site: that traffic is generated in response to queries that are sent
from the site, and so the only effective measures to stop the inbound out from the site, and so the only effective measures to stop the
traffic is to prevent the original queries from being made. inbound traffic is to prevent the original queries from being made.
Possible measures which might be taken to prevent these queries Possible measures that might be taken to prevent these queries
include: include:
1. Stop hosts from making these DNS reverse mapping queries in the 1. Stop hosts from making these DNS reverse-mapping queries in the
first place. In some cases servers can be configured not to first place. In some cases, servers can be configured not to
perform DNS reverse mapping lookups, for example. As a general perform DNS reverse-mapping lookups, for example. As a general
site-wide approach, however, this measure is frequently difficult site-wide approach, however, this measure is frequently difficult
to implement due to the large number of hosts and applications to implement due to the large number of hosts and applications
involved. involved.
2. Block DNS reverse mapping queries to the AS112 servers from 2. Block DNS reverse-mapping queries to the AS112 servers from
leaving the site using firewalls between the site and the leaving the site using firewalls between the site and the
Internet. Although this might appear to be sensible, such a Internet. Although this might appear to be sensible, such a
measure might have unintended consequences: the inability to measure might have unintended consequences: the inability to
receive an answer to DNS reverse mapping queries might lead to receive an answer to DNS reverse-mapping queries might lead to
long DNS lookup timeouts, for example, which could cause long DNS lookup timeouts, for example, which could cause
applications to malfunction. (It may also lead to the belief applications to malfunction. (It may also lead to the belief
that the Internet or the local network is down.) that the Internet or the local network is down.)
3. Configure all DNS resolvers in the site to answer authoritatively 3. Configure all DNS resolvers in the site to answer authoritatively
for the zones corresponding to the private-use address blocks in for the zones corresponding to the private-use address blocks in
use. This should prevent resolvers from ever needing to send use. This should prevent resolvers from ever needing to send
these queries to the public DNS. Guidance and recommendations these queries to the public DNS. Guidance and recommendations
for this aspect of resolver configuration can be found in for this aspect of resolver configuration can be found in
[I-D.ietf-dnsop-default-local-zones]. [RFC6303].
4. Implement a private AS112 node within the site. Guidance for 4. Implement a private AS112 node within the site. Guidance for
constructing an AS112 node may be found in constructing an AS112 node may be found in [RFC6304].
[I-D.ietf-dnsop-as112-ops].
8. AS112 Contact Information 8. AS112 Contact Information
More information about the AS112 project can be found at More information about the AS112 project can be found at
<http://www.as112.net/>. <http://www.as112.net/>.
9. IANA Considerations 9. IANA Considerations
The AS112 nameservers are all named under the domain IANA.ORG (see The AS112 nameservers are all named under the domain IANA.ORG (see
Section 5). The IANA is the organisation responsible for the Section 5). The IANA is the organisation responsible for the
coordination of many technical aspects of the Internet's basic coordination of many technical aspects of the Internet's basic
infrastructure. The AS112 project nameservers provide a public infrastructure. The AS112 project nameservers provide a public
service to the Internet which is sanctioned by and operated in loose service to the Internet that is sanctioned by and operated in loose
coordination with the IANA. coordination with the IANA.
This document makes no request of the IANA.
10. Security Considerations 10. Security Considerations
The purpose of this document is to help site administrators properly The purpose of this document is to help site administrators properly
identify traffic received from AS112 nodes, and to provide background identify traffic received from AS112 nodes and to provide background
information to allow appropriate measures to be taken in response to information to allow appropriate measures to be taken in response to
it. it.
Hosts should never normally send queries to AS112 servers: queries Hosts should never normally send queries to AS112 servers: queries
relating to private-use addresses should be answered locally within a relating to private-use addresses should be answered locally within a
site. Hosts which send queries to AS112 servers may well leak site. Hosts that send queries to AS112 servers may well leak
information relating to private infrastructure to the public network, information relating to private infrastructure to the public network;
which could represent a security risk. this could represent a security risk.
11. Acknowledgements 11. Acknowledgements
The authors wish to acknowledge the assistance of S. Moonesamy in the The authors wish to acknowledge the assistance of S. Moonesamy in the
preparation of this document. preparation of this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
12.2. Informative References 12.2. Informative References
[I-D.ietf-dnsop-as112-ops]
Abley, J. and W. Maton, "AS112 Nameserver Operations",
October 2009.
[I-D.ietf-dnsop-default-local-zones]
Andrews, M., "Locally-served DNS Zones",
draft-ietf-dnsop-default-local-zones-14 (work in
progress), September 2010.
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
Reverse Zones", BCP 155, RFC 5855, May 2010. Reverse Zones", BCP 155, RFC 5855, May 2010.
Appendix A. Change History [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, July 2011.
This section to be removed prior to publication.
00 Initial draft, circulated as
draft-jabley-as112-being-attacked-help-help-00 and reviewed at the
DNSOP working group meeting at IETF 66.
00 Document adopted by the DNSOP working group and renamed
accordingly.
01 Version number bump at request of wg chair.
02 Updated pointer to DNSOP working group-adopted of Mark Andrew's
full-service resolver zones, renamed to ietf-dnsop-default-local-
zones.
02 Updated author's addresses.
03 Version number bump at request of dnsop chair.
04 Version number bump at request of dnsop chair. Contact
information section truncated to protect the innocent. Minor,
non-substantive wordsmithing. References updated.
05 Version number bump at request of dnsop chair. References
updated.
06 Change references to root servers to reverse servers, since IN- [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
ADDR.ARPA has been re-delegated since this document was first RFC 6304, July 2011.
written. Add acknowledgements section.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
ICANN ICANN
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292 Marina del Rey, CA 90292
US US
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: joe.abley@icann.org EMail: joe.abley@icann.org
William F. Maton Sotomayor William F. Maton Sotomayor
National Research Council of Canada National Research Council of Canada
1200 Montreal Road 1200 Montreal Road
Ottawa, ON K1A 0R6 Ottawa, ON K1A 0R6
Canada Canada
Phone: +1 613 993 0880 Phone: +1 613 993 0880
Email: wmaton@ryouko.imsb.nrc.ca EMail: wmaton@ryouko.imsb.nrc.ca
 End of changes. 41 change blocks. 
121 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/