idnits 2.17.1
draft-ietf-dnsop-as112-under-attack-help-help-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 3 instances of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 3 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 29, 2011) is 4739 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-15) exists of
draft-ietf-dnsop-default-local-zones-14
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Abley
3 Internet-Draft ICANN
4 Intended status: Informational W. Maton
5 Expires: October 31, 2011 NRC-CNRC
6 April 29, 2011
8 I'm Being Attacked by PRISONER.IANA.ORG!
9 draft-ietf-dnsop-as112-under-attack-help-help-06
11 Abstract
13 Many sites connected to the Internet make use of IPv4 addresses which
14 are not globally unique. Examples are the addresses designated in
15 RFC1918 for private use within individual sites.
17 Hosts should never normally send DNS reverse mapping queries for
18 those addresses on the public Internet. However, such queries are
19 frequently observed. Authoritative servers are deployed to provide
20 authoritative answers to such queries as part of a loosely-
21 coordinated effort known as the AS112 project.
23 Since queries sent to AS112 servers are usually not intentional, the
24 replies received back from those servers are typically unexpected.
25 Unexpected inbound traffic can trigger alarms on intrusion detection
26 systems and firewalls, and operators of such systems often mistakenly
27 believe that they are being attacked.
29 This document provides background information and technical advice to
30 those firewall operators.
32 Status of this Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on October 31, 2011.
49 Copyright Notice
51 Copyright (c) 2011 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction and Target Audience . . . . . . . . . . . . . . . 3
67 2. Private-Use Addresses . . . . . . . . . . . . . . . . . . . . 4
68 3. DNS Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 5
69 4. DNS Reverse Mapping for Private-Use Addresses . . . . . . . . 6
70 5. AS112 Nameservers . . . . . . . . . . . . . . . . . . . . . . 7
71 6. Inbound Traffic from AS112 Servers . . . . . . . . . . . . . . 8
72 7. Corrective Measures . . . . . . . . . . . . . . . . . . . . . 9
73 8. AS112 Contact Information . . . . . . . . . . . . . . . . . . 10
74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
78 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
79 12.2. Informative References . . . . . . . . . . . . . . . . . 14
80 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 15
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
83 1. Introduction and Target Audience
85 Readers of this document may well have experienced an alarm from a
86 firewall or an intrusion-detection system, triggered by unexpected
87 inbound traffic from the Internet. The traffic probably appeared to
88 originate from one of several hosts discussed further below.
90 The published contacts for those hosts may well have suggested that
91 you consult this document.
93 If you are following up on such an event, you are encouraged to
94 follow your normal security procedures and take whatever action you
95 consider to be be appropriate. This document contains information
96 which may assist you.
98 2. Private-Use Addresses
100 Many sites connected to the Internet make use of address blocks
101 designated in [RFC1918] for private use. One example of such
102 addresses is 10.1.30.20.
104 Because these ranges of addresses are used by many sites all over the
105 world, each individual address can only ever have local significance.
106 For example, the host numbered 192.168.18.234 in one site almost
107 certainly has nothing to do with a host with the same address located
108 in a different site.
110 3. DNS Reverse Mapping
112 The Domain Name System (DNS) [RFC1034] can be used to obtain a name
113 for a particular network address. The process by which this happens
114 is as follows:
116 1. The network address is rearranged in order to construct a name
117 which can be looked up in the DNS. For example, the IPv4 address
118 10.1.30.20 corresponds to the DNS name 20.30.1.10.IN-ADDR.ARPA.
120 2. A DNS query is constructed for that name, requesting a DNS record
121 of the type "PTR".
123 3. The DNS query is sent to a resolver.
125 4. If a response is received in response to the query, the answer
126 will typically indicate either the hostname corresponding to the
127 network address, or the fact that no hostname can be found.
129 This procedure is generally carried out automatically by software,
130 and is hence largely hidden from users and administrators.
131 Applications might have reason to look up an IP address in order to
132 gather extra information for a log file, for example.
134 4. DNS Reverse Mapping for Private-Use Addresses
136 As noted in Section 2, private-use addresses have only local
137 significance. This means that sending queries out to the Internet is
138 not sensible: there is no way for the public DNS to provide a useful
139 answer to a question which has no global meaning.
141 Despite the fact that the public DNS cannot provide answers, many
142 sites have misconfigurations in the way they connect to the Internet
143 which results in such queries relating to internal infrastructure
144 being sent outside the site. From the perspective of the public DNS,
145 these queries are junk -- they cannot be answered usefully and result
146 in unnecessary traffic being received by the nameservers which
147 underpin the operation of the reverse DNS (the so-called reverse
148 servers [RFC5855] which serve "IN-ADDR.ARPA").
150 To isolate this traffic, and reduce the load on the rest of the
151 reverse DNS infrastructure, dedicated servers have been deployed in
152 the Internet to receive and reply to these junk queries. These
153 servers are deployed in many places in a loosely-coordinated effort
154 known as the "AS112 Project". More details about the AS112 Project
155 can be found at .
157 5. AS112 Nameservers
159 The nameservers responsible for answering queries relating to
160 private-use addresses are as follows:
162 o PRISONER.IANA.ORG (192.175.48.1)
164 o BLACKHOLE-1.IANA.ORG (192.175.48.6)
166 o BLACKHOLE-2.IANA.ORG (192.175.48.42)
168 A request sent to one of these servers will result in a response
169 being returned to the client. The response will typically be a UDP
170 datagram, although it's perfectly valid for requests to be made over
171 TCP. In both cases the source port of packets returning to the site
172 which originated the DNS request will be 53.
174 6. Inbound Traffic from AS112 Servers
176 Where firewalls or intrusion detection systems (IDS) are configured
177 to block traffic received from AS112 servers, superficial review of
178 the traffic may seem alarming to site administrators.
180 o Since requests directed ultimately to AS112 servers are usually
181 triggered automatically by applications, review of firewall logs
182 may indicate a large number of policy violations occurring over an
183 extended period of time.
185 o Where responses from AS112 servers are blocked by firewalls, hosts
186 will often retry, often with a relatively high frequency. This
187 can cause inbound traffic to be misclassified as a denial-of-
188 service (DoS) attack. In some cases the source ports used by
189 individual hosts for successive retries increase in a predictable
190 fashion (e.g. monotonically), which can cause the replies from the
191 AS112 server to resemble a port scan.
193 o A site administrator may attempt to perform active measurement of
194 the remote host in response to alarms raised by inbound traffic,
195 e.g. initiating a port scan in order to gather information about
196 the host which is apparently attacking the site. Such a scan will
197 usually result in additional inbound traffic to the site
198 performing the measurement, e.g. an apparent flood of ICMP
199 messages which may trigger additional firewall alarms and
200 obfuscate the process of identifying the original problem traffic.
202 7. Corrective Measures
204 A site which receives responses from one of the nameservers listed in
205 Section 5 is probably under no immediate danger, and the traffic
206 associated with those responses probably requires no emergency action
207 by the site concerned. However, this document cannot aspire to
208 dictate the security policy of individual sites, and it is recognised
209 that many sites will have perfectly valid policies which dictate that
210 corrective measures should be taken to stop the responses from AS112
211 servers.
213 It should be noted, however, that the operators of AS112 nameservers
214 which are generating the responses described in this document are not
215 ultimately responsible for the inbound traffic received by the site:
216 that traffic is generated in response to queries which are sent out
217 from the site, and so the only effective measures to stop the inbound
218 traffic is to prevent the original queries from being made.
220 Possible measures which might be taken to prevent these queries
221 include:
223 1. Stop hosts from making these DNS reverse mapping queries in the
224 first place. In some cases servers can be configured not to
225 perform DNS reverse mapping lookups, for example. As a general
226 site-wide approach, however, this measure is frequently difficult
227 to implement due to the large number of hosts and applications
228 involved.
230 2. Block DNS reverse mapping queries to the AS112 servers from
231 leaving the site using firewalls between the site and the
232 Internet. Although this might appear to be sensible, such a
233 measure might have unintended consequences: the inability to
234 receive an answer to DNS reverse mapping queries might lead to
235 long DNS lookup timeouts, for example, which could cause
236 applications to malfunction. (It may also lead to the belief
237 that the Internet or the local network is down.)
239 3. Configure all DNS resolvers in the site to answer authoritatively
240 for the zones corresponding to the private-use address blocks in
241 use. This should prevent resolvers from ever needing to send
242 these queries to the public DNS. Guidance and recommendations
243 for this aspect of resolver configuration can be found in
244 [I-D.ietf-dnsop-default-local-zones].
246 4. Implement a private AS112 node within the site. Guidance for
247 constructing an AS112 node may be found in
248 [I-D.ietf-dnsop-as112-ops].
250 8. AS112 Contact Information
252 More information about the AS112 project can be found at
253 .
255 9. IANA Considerations
257 The AS112 nameservers are all named under the domain IANA.ORG (see
258 Section 5). The IANA is the organisation responsible for the
259 coordination of many technical aspects of the Internet's basic
260 infrastructure. The AS112 project nameservers provide a public
261 service to the Internet which is sanctioned by and operated in loose
262 coordination with the IANA.
264 This document makes no request of the IANA.
266 10. Security Considerations
268 The purpose of this document is to help site administrators properly
269 identify traffic received from AS112 nodes, and to provide background
270 information to allow appropriate measures to be taken in response to
271 it.
273 Hosts should never normally send queries to AS112 servers: queries
274 relating to private-use addresses should be answered locally within a
275 site. Hosts which send queries to AS112 servers may well leak
276 information relating to private infrastructure to the public network,
277 which could represent a security risk.
279 11. Acknowledgements
281 The authors wish to acknowledge the assistance of S. Moonesamy in the
282 preparation of this document.
284 12. References
286 12.1. Normative References
288 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
289 STD 13, RFC 1034, November 1987.
291 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
292 E. Lear, "Address Allocation for Private Internets",
293 BCP 5, RFC 1918, February 1996.
295 12.2. Informative References
297 [I-D.ietf-dnsop-as112-ops]
298 Abley, J. and W. Maton, "AS112 Nameserver Operations",
299 October 2009.
301 [I-D.ietf-dnsop-default-local-zones]
302 Andrews, M., "Locally-served DNS Zones",
303 draft-ietf-dnsop-default-local-zones-14 (work in
304 progress), September 2010.
306 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
307 Reverse Zones", BCP 155, RFC 5855, May 2010.
309 Appendix A. Change History
311 This section to be removed prior to publication.
313 00 Initial draft, circulated as
314 draft-jabley-as112-being-attacked-help-help-00 and reviewed at the
315 DNSOP working group meeting at IETF 66.
317 00 Document adopted by the DNSOP working group and renamed
318 accordingly.
320 01 Version number bump at request of wg chair.
322 02 Updated pointer to DNSOP working group-adopted of Mark Andrew's
323 full-service resolver zones, renamed to ietf-dnsop-default-local-
324 zones.
326 02 Updated author's addresses.
328 03 Version number bump at request of dnsop chair.
330 04 Version number bump at request of dnsop chair. Contact
331 information section truncated to protect the innocent. Minor,
332 non-substantive wordsmithing. References updated.
334 05 Version number bump at request of dnsop chair. References
335 updated.
337 06 Change references to root servers to reverse servers, since IN-
338 ADDR.ARPA has been re-delegated since this document was first
339 written. Add acknowledgements section.
341 Authors' Addresses
343 Joe Abley
344 ICANN
345 4676 Admiralty Way, Suite 330
346 Marina del Rey, CA 90292
347 US
349 Phone: +1 519 670 9327
350 Email: joe.abley@icann.org
352 William F. Maton Sotomayor
353 National Research Council of Canada
354 1200 Montreal Road
355 Ottawa, ON K1A 0R6
356 Canada
358 Phone: +1 613 993 0880
359 Email: wmaton@ryouko.imsb.nrc.ca