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 22.214.171.124/14.
As it turns out, 1/8 is a pretty bad address space for two reasons. 126.96.36.199 and 188.8.131.52. These two addresses are responsible for most of the inadvertent announcements in the entire 1/8 space. 184.108.40.206 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 220.127.116.11 makes sense.
Why is 18.104.22.168 so popular? Well, the first reason is thanks to Airespace wireless controllers. Airespace uses 22.214.171.124 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 126.96.36.199 seems to be used quite frequently is in Cisco ASA failover interfaces. Cisco documentation recommended using 188.8.131.52 for the primary ASA failover and 184.108.40.206 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 220.127.116.11 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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52, 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.
Do you have any ѵideo of that? I’d ⅼove to find out more details.
Sorry. I am unaware of any video regarding this post.