Hopefully by now you’ve seen the announcement that CloudFlare has opened a new DNS service at the address of 188.8.131.52. We covered a bit of it on this week’s episode of the Gestalt IT Rundown. Next to Gmail, it’s probably the best April Fool’s announcement I’ve seen. However, it would seem that the Internet isn’t quite ready for a DNS resolver service that’s easy to remember. And that’s thanks in part to the accumulation of bad address hygiene.
Not So Random Numbers
The address range of 1/8 is owned by APNIC. They’ve had it for many years now but have never announced it publicly. Nor have they ever made any assignments of addresses in that space to clients or customers. In a world where IPv4 space is at a premium, why would a RIR choose to lose 16 million addresses?
Edit: As pointed out by Dale Carder of ES.net in a comment below, APNIC has been assigning address space out of 1 /8 since 2010. However, the most commonly leaked prefixes in that subnet that are difficult to assign because of bogus announcements come from 184.108.40.206/14.
As it turns out, 1/8 is a pretty bad address space for two reasons. 220.127.116.11 and 18.104.22.168. These two addresses are responsible for most of the inadvertent announcements in the entire 1/8 space. 22.214.171.124 is easy to figure out. It’s the most common example IP address given when talking about something. Don’t believe me? Google is your friend. Instead of using 192.0.2.0/24 like we should be using, we instead use the most common PIN, password, and luggage combination in the world. But, at least 126.96.36.199 makes sense.
Why is 188.8.131.52 so popular? Well, the first reason is thanks to Airespace wireless controllers. Airespace uses 184.108.40.206 as the default virtual interface address for just about everything. Here’s a good explanation from Andrew von Nagy. When Airespace was sold to Cisco, this became a very popular address for Cisco wireless networks. Except now that it’s in use as a DNS resolver there are issues with using it. The wireless experts I’ve talked to recommend changing that address to 192.0.2.1, since that address has been marked off for examples only and will never be globally routable.
The other place where 220.127.116.11 seems to be used quite frequently is in Cisco ASA failover interfaces. Cisco documentation recommended using 18.104.22.168 for the primary ASA failover and 22.214.171.124 as the secondary interface. The heartbeats between those two interfaces were active as long as the units were paired together. But, if they were active and reachable then any traffic destined for those globally routable addresses would be black holed. Now, ASAs should probably be using 192.0.2.1 and 192.0.2.2 instead. But beware that this will likely require downtime to reconfigure.
The 126.96.36.199 address confusion doesn’t stop there. Some systems like Nomadix use them as the default logout address. Vodafone used to use it as an image caching server. ISPs are blocking it upstream in some ACLs. Some security organizations even recommend dropping traffic to 1/8 as a bogon prevention measure. There’s every chance that 188.8.131.52 is going to be dropped by something in your network or along the transit path.
Planning Not To Fail
So, how are you going to proceed if you really, really want to use CloudFlare DNS? Well, the first step is to make sure that you don’t have 184.108.40.206 configured anywhere in your network. That means checking WLAN controllers, firewalls, and example configurations. Odds are good you’re running RFC1918 space. But you should try to ping 220.127.116.11 anyway. If you can ping it, then you should traceroute the address. If the traceroute leaves your local network, you probably have a good path.
Once you’ve determined that you’re capable of reaching 18.104.22.168, you need to test it first. Configure it on a test machine or VM and make sure it’s actually resolving addresses for you. Better safe than sorry. Once you know it’s really working like you want it to work, configure it on your internal DNS servers as a forwarder. You still want internal control of DNS thanks to things like Active Directory. But configuring it as a forwarder means you can take advantage of all the features CloudFlare is building into the system while still retaining anything you’ve done locally.
I’m glad CloudFlare and APNIC are reclaiming 22.214.171.124 for some useful purpose. CloudFlare can take the traffic load of all the horribly misconfigured systems in the world. APNIC can use this setup to do some analytics work to find out exactly how screwed up things are. I wouldn’t be shocked to see something similar happen to 126.96.36.199 in the future if this bet pays off.
I’ve been using 188.8.131.52 since April 2nd and it works. It’s fast and hasn’t broken yet, which is the best that you can hope for from a DNS server. I’m sure I’ll play around with some of the advanced features as they come online but for now I’m just happy that one of the most recognizable IP addresses in the world is working for me.
Pingback: Reclaiming? I don’t think so… – Paradigm Technica
“1/8 is owned by APNIC. They’ve had it for many years now but have never announced it publicly. Nor have they ever made any assignments of addresses in that space to clients or customers.”
Where did you get that data?
I just picked one DFZ prefix from 1/8 at random and looked it up:
inetnum: 184.108.40.206 – 220.127.116.11
descr: Data Communication Business Group,
descr: Chunghwa Telecom Co.,Ltd.
descr: No.21, Sec.1, Xinyi Rd., Taipei City
descr: 10048, Taiwan
status: ALLOCATED PORTABLE
Or, a cursory google search reveals this article from 2010.
Apologies for not doing my due diligence and checking before I wrote the above statement. I should have restricted my comments to the 18.104.22.168/14 network, as this is the most commonly leaked network according to the BGPMon article you linked from 2010.
Well, take a look at a summary of the prefix history here, where one can see that there has in fact been a long history of use even inside 22.214.171.124/14:
What I hope we can all agree on is that squatting on address space not assigned to you is bad, even if it’s intended to be internal to your network.