RFC 6305

I'm Being Attacked by PRISONER.IANA.ORG!

📅 published July 2011, from ietf

I'm Being Attacked by PRISONER.IANA.ORG! 💖

Title block, bestie 🎀 This is RFC 6305, written by J. Abley (ICANN) and W. Maton (NRC-CNRC). It's Informational, so it's published for information rather than as a standards-track spec. The date is July 2011 and the ISSN is 2070-1721. It doesn't obsolete or update any other RFC, since none are listed.

Abstract 🦋

Lots of sites on the Internet use IPv4 addresses that aren't globally unique 🌸 The big example is the private-use blocks from RFC 1918, which each site gets to use internally.

Hosts should never normally send DNS reverse-mapping queries for those addresses out onto the public Internet. Still, these queries get seen all the time 😭 To handle them, authoritative servers are deployed to give authoritative answers as part of a loosely coordinated effort called the AS112 project.

The queries sent to AS112 servers are usually accidental, so the replies coming back are usually unexpected. That surprise inbound traffic can set off intrusion detection systems and firewalls, and the people running those systems often honestly think they're under attack 🙈

This document gives background info and technical advice for those firewall operators 💅

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's 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 every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🧐

Info about this document's current status, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6305 ✨

Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License 📝

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 🌈

Okay, so if you're reading this, you've probably gotten an alarm from a firewall or an intrusion-detection system 🚨 It got set off by unexpected inbound traffic from the Internet. That traffic probably looked like it came from one of the hosts we talk about below.

The published contacts for those hosts probably told you to check out this document 💅

If you're following up on an event like this, follow your normal security procedures and do whatever you think is right. This document has info that might help you out 🫶

2. Private-Use Addresses 🎀

Lots of sites connected to the Internet use the address blocks set aside in [RFC1918] for private use. One example of those addresses is 10.1.30.20 🧚

These ranges get used by tons of sites all over the world, so each individual address only ever means something locally. For example, the host numbered 192.168.18.234 at one site almost definitely has nothing to do with the host that has the same address at a totally different site 🙃

3. DNS Reverse Mapping 🔍

The Domain Name System (DNS) [RFC1034] can be used to get a name for a particular network address. Here's how that works:

  1. The network address gets rearranged to make 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.
  2. A DNS query gets built for that name, asking for a DNS record of the type "PTR".
  3. The DNS query gets sent to a resolver.
  4. If a response comes back for the query, the answer will usually say either the hostname that matches the network address, or that no hostname can be found.

Software usually does all of this automatically, so users and admins mostly never see it 🤫

Applications might have a reason to look up an IP address, for example to add extra info to a log file 📋

4. DNS Reverse Mapping for Private-Use Addresses 💀

As we said in Section 2, private-use addresses only have local meaning. So sending queries out to the Internet doesn't make sense 🙅‍♀️ The public DNS has no way to give a useful answer to a question that has no global meaning.

Even though the public DNS can't answer these, lots of sites have misconfigurations in how they connect to the Internet. That means queries about internal infrastructure get sent outside the site anyway 😩 From the public DNS's point of view, these queries are junk. They can't be answered usefully, and they create unnecessary traffic for the nameservers that keep the reverse DNS running (the so-called reverse servers [RFC5855], which serve "IN-ADDR.ARPA") 🗑️

To keep this traffic isolated and take some load off the rest of the reverse DNS infrastructure, dedicated servers have been set up on the Internet to receive and reply to these junk queries. They're deployed in lots of places as part of a loosely coordinated effort called the "AS112 project". You can learn more about the AS112 project at http://www.as112.net/ 🌸

5. AS112 Nameservers 🍓

These are the nameservers responsible for answering queries about private-use addresses:

  • PRISONER.IANA.ORG (192.175.48.1)
  • BLACKHOLE-1.IANA.ORG (192.175.48.6)
  • BLACKHOLE-2.IANA.ORG (192.175.48.42)

A request sent to one of these servers gets a response back to the client. The response will usually be a UDP datagram, though it's perfectly valid for requests to be made over TCP too. In both cases, the source port of packets coming back to the site that started the DNS request will be 53 ✨

6. Inbound Traffic from AS112 Servers 👀

When firewalls or intrusion detection systems (IDSs) are set up to block traffic from AS112 servers, a quick look at that traffic can look super alarming to site administrators 😱

  • Since the requests that end up at AS112 servers are usually triggered automatically by applications, a look at firewall logs may show a big pile of policy violations over a long stretch of time.
  • When firewalls block responses from AS112 servers, hosts will often retry, and often pretty frequently. This can make inbound traffic look like a denial-of-service (DoS) attack 🚩 In some cases, the source ports that individual hosts use for each retry go up in a predictable way (e.g. monotonically), which can make the replies from the AS112 server look like a port scan 👻
  • A site administrator might try active measurement of the remote host in response to alarms raised by inbound traffic, e.g. starting a port scan to learn more about the host that seems to be attacking the site. A scan like that will usually cause even more inbound traffic to the site doing the measuring, e.g., an apparent flood of ICMP messages. That can set off more firewall alarms and make it harder to figure out where the original problematic traffic came from 🌀

7. Corrective Measures 🛠️

A site that gets responses from one of the nameservers listed in Section 5 is probably not in any immediate danger, and the traffic tied to those responses probably doesn't need any emergency action from that site 🫶 That said, this document can't tell individual sites what their security policy should be, and it's recognised that lots of sites will have perfectly valid policies that call for corrective measures to stop the responses from AS112 servers.

It's worth noting, though, that the operators of AS112 nameservers, the ones generating the responses described here, aren't ultimately responsible for the inbound traffic the site receives. That traffic is generated in response to queries sent out from the site, so the only effective way to stop the inbound traffic is to stop the original queries from being made 🔐

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 do DNS reverse-mapping lookups, for example. As a general site-wide approach, though, this measure is often difficult to implement because of the large number of hosts and applications involved 😮‍💨
  2. Block DNS reverse-mapping queries to the AS112 servers from leaving the site, using firewalls between the site and the Internet. This might look like a sensible move, but it could have unintended consequences. Not being able to get an answer to DNS reverse-mapping queries might lead to long DNS lookup timeouts, for example, and those could make applications malfunction. (It may also make people think the Internet or the local network is down 📉)
  3. Configure all DNS resolvers in the site to answer authoritatively for the zones that correspond to the private-use address blocks in use. This should keep resolvers from ever needing to send these queries to the public DNS. Guidance and recommendations for this part of resolver configuration can be found in [RFC6303] 🧠
  4. Set up a private AS112 node within the site. Guidance for building an AS112 node may be found in [RFC6304] 🏗️

To be continued in Part 2! 🔮🫶

9. IANA Considerations ✨

okay so the AS112 nameservers are all named under the domain IANA.ORG (check out Section 5 if you want the details 👀). bestie, the IANA is the organisation that coordinates a bunch of the technical stuff keeping the Internet's basic infrastructure running 🌈. The AS112 project nameservers offer a public service to the Internet, and it's sanctioned by the IANA and run in loose coordination with them. iconic teamwork 🫶

10. Security Considerations 🔐

okay this section is serious but also kind of the whole point 💅 the purpose of this document is to help site admins properly identify traffic coming from AS112 nodes, and to give background info so they can take the right measures in response to it 🦋

warning, bestie: hosts should never normally send queries to AS112 servers 🚫 queries about private-use addresses should be answered locally, inside the site. 😭

ngl this matters a lot. hosts that send queries to AS112 servers may well leak information about private infrastructure out to the public network, and that could be a real security risk 💀 so keep your private stuff private, periodt 🔒

11. Acknowledgements 🫶

the authors wanna give a shoutout to S. Moonesamy for helping out with the preparation of this document 🌸

12. References 📚

12.1. Normative References

[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, November 1987.

[RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
           E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

12.2. Informative References

[RFC5855]  Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
           Reverse Zones", BCP 155, RFC 5855, May 2010.

[RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163,
           RFC 6303, July 2011.

[RFC6304]  Abley, J. and W. Maton, "AS112 Nameserver Operations",
           RFC 6304, July 2011.

Authors' Addresses 🎀

Joe Abley
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA  90292
US

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

Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca

that's the whole doc, bestie 💜 you did amazing reading all of it ✨🌈✨

📦 where this page comes from