draft-ietf-dnsop-as112-under-attack-help-help-01.txt   draft-ietf-dnsop-as112-under-attack-help-help-02.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft Afilias Internet-Draft TekSavvy
Intended status: Informational W. Maton Intended status: Informational W. Maton
Expires: May 21, 2008 NRC-CNRC Expires: September 10, 2009 NRC-CNRC
November 18, 2007 March 9, 2009
I'm Being Attacked by PRISONER.IANA.ORG! I'm Being Attacked by PRISONER.IANA.ORG!
draft-ietf-dnsop-as112-under-attack-help-help-01 draft-ietf-dnsop-as112-under-attack-help-help-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2008. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 which
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. RFC1918 for private use within individual sites.
Hosts should never normally send reverse DNS queries for those Hosts should never normally send DNS reverse mapping queries for
addresses on the public Internet. However, such queries are those addresses on the public Internet. However, such queries are
frequently observed. Authority 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Target Audience . . . . . . . . . . . . . . . 5
2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 5 2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 6
3. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 7
4. Reverse DNS for Private-Use Addresses . . . . . . . . . . . . 7 4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . 8
5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 8 5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 9
6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 9 6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 10
7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 10 7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 11
8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 11 8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 15 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 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 the following hosts: originate from one of several hosts discussed further below.
o PRISONER.IANA.ORG (192.175.48.1)
o BLACKHOLE-1.IANA.ORG (192.175.48.6)
o BLACKHOLE-2.IANA.ORG (192.175.48.42)
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 be appropriate. This document contains information
which may assist you. which 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. Examples of such addresses designated in [RFC1918] for private use. One example of such
are 10.1.30.20, 172.18.24.100 and 192.168.1.1. 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. Reverse DNS 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 which can be looked up in the DNS. For example, the IPv4 address
10.3.70.25 corresponds to the DNS name 25.70.3.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 is hence 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. Reverse DNS 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 which 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 to such queries relating to internal infrastructure which 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 public DNS (the so-called root underpin the operation of the public DNS (the so-called root servers
servers). which serve "IN-ADDR.ARPA").
To isolate this traffic, and reduce the load on the rest of the DNS To isolate this traffic, and reduce the load on the rest of the DNS
infrastructure, dedicated servers have been deployed in the Internet infrastructure, dedicated servers have been deployed in the Internet
to receive and reply to these junk queries. These servers are to receive and reply to these junk queries. These servers are
deployed in many places in a loosely-coordinated effort known as the deployed in many places in a loosely-coordinated effort known as the
"AS112 Project". More details about the AS112 Project can be found "AS112 Project". More details about the AS112 Project can be found
at <http://www.as112.net/>. at <http://www.as112.net/>.
5. AS112 Nameservers 5. AS112 Nameservers
skipping to change at page 10, line 26 skipping to change at page 11, line 26
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 not
ultimately responsible for the inbound traffic received by the site: ultimately responsible for the inbound traffic received by the site:
that traffic is generated in response to queries which are sent out that traffic is generated in response to queries which are sent out
from the site, and so the only effective measures to stop the inbound from the site, and so the only effective measures to stop the inbound
traffic is to prevent the original queries from being made. traffic is to prevent the original queries from being made.
Possible measures which might be taken to prevent these queries Possible measures which might be taken to prevent these queries
include: include:
1. Stop hosts from making these reverse DNS queries in the first 1. Stop hosts from making these DNS reverse mapping queries in the
place. In some cases servers can be configured not to perform first place. In some cases servers can be configured not to
reverse DNS lookups, for example. As a general site-wide perform DNS reverse mapping lookups, for example. As a general
approach, however, this measure is frequently difficult to site-wide approach, however, this measure is frequently difficult
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 reverse DNS queries to the AS112 servers from leaving the 2. Block DNS reverse mapping queries to the AS112 servers from
site using firewalls between the site and the Internet. Although leaving the site using firewalls between the site and the
this might appear to be sensible, such a measure might have Internet. Although this might appear to be sensible, such a
unintended consequences: the inability to receive an answer to measure might have unintended consequences: the inability to
reverse DNS queries might lead to long DNS lookup timeouts, for receive an answer to DNS reverse mapping queries might lead to
example, which could cause applications to malfunction. 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.)
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.andrews-full-service-resolvers]. [I-D.ietf-dnsop-default-local-zones].
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
[I-D.ietf-dnsop-as112-ops]. [I-D.ietf-dnsop-as112-ops].
8. AS112 Contact Information 8. AS112 Contact Information
Operational contact information for the network addresses of AS112 Operational contact information for the network addresses of AS112
servers is registered with Regional Internet Registries (RIRs). servers is registered with Regional Internet Registries (RIRs).
Readers who continue to have concerns about traffic received from Readers who continue to have concerns about traffic received from
AS112 servers after reading this document are encouraged to contact AS112 servers after reading this document are encouraged to contact
the AS112 Network Operations Centre. their local CSIRT for more information or confirmation as well as the
AS112 Network Operations Centre.
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 service to the Internet which is sanctioned by and operated in
coordination with the IANA. coordination with the IANA.
This document does not require any IANA actions.
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 which send queries to AS112 servers may well leak
skipping to change at page 14, line 18 skipping to change at page 15, line 18
[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.
11.2. Informative References 11.2. Informative References
[I-D.andrews-full-service-resolvers]
Andrews, M., "Configuration Issues Facing Full Service DNS
Resolvers In The Presence of Private Network Addressing",
draft-andrews-full-service-resolvers-02 (work in
progress), February 2006.
[I-D.ietf-dnsop-as112-ops] [I-D.ietf-dnsop-as112-ops]
Abley, J. and W. Maton, "AS112 Nameserver Operations", Abley, J. and W. Maton, "AS112 Nameserver Operations",
February 2007. March 2009.
[I-D.ietf-dnsop-default-local-zones]
Andrews, M., "Locally-served DNS Zones",
draft-ietf-dnsop-default-local-zones-08 (work in
progress), February 2009.
Appendix A. Change History Appendix A. Change History
This section to be removed prior to publication. This section to be removed prior to publication.
00 Initial draft, circulated as 00 Initial draft, circulated as
draft-jabley-as112-being-attacked-help-help-00 and reviewed at the draft-jabley-as112-being-attacked-help-help-00 and reviewed at the
DNSOP working group meeting at IETF 66. DNSOP working group meeting at IETF 66.
00 Document adopted by the DNSOP working group and renamed 00 Document adopted by the DNSOP working group and renamed
accordingly. accordingly.
01 Version number bump at request of wg chair. 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
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Canada Corp. TekSavvy Solutions, Inc.
Suite 204, 4141 Yonge Street 330 Richmond Street, Suite 205
Toronto, ON M2P 2A8 Chatham, ON N7M 1P7
Canada Canada
Phone: +1 416 673 4176 Phone: +1 519 670 9327
Email: jabley@ca.afilias.info Email: jabley@teksavvy.com
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
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 27 change blocks. 
70 lines changed or deleted 88 lines changed or added

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