Most network engineers have, at some point in their career, used a “dummy” IP address of 126.96.36.199 for some reason or another. Maybe it was a placeholder in a configuration template, or maybe it was used for some sort of loopback or private connection that should never see the light of day such as a firewall failover link. Most of us have made this IP faux pas at least once.
In fact, way back in 2010, when IANA allocated the 188.8.131.52/8 prefix to APNIC (the Asia-Pacific regional Internet number authority) work was done by APNIC’s research and development group to assess the feasibility of using various prefixes within the 184.108.40.206/8 block. The result of their study found that there was a substantial amount of random, garbage Internet traffic constantly flowing toward several of the prefixes within that range. Notably, IP addresses 220.127.116.11, 18.104.22.168, and 22.214.171.124 bore the brunt of this traffic barrage. The recommendation from APNIC’s R&D group at that time was not to allocate these prefixes to any Internet users due to the massive volume of background junk traffic always being directed at them.
Now, fast forward to 2018. April Fool’s Day 2018, to be exact, and everyone’s favorite dummy IP addresses 126.96.36.199 and 188.8.131.52 are now live on the Internet providing a new free, privacy-oriented public DNS service. This is no prank, though, so how did it happen? Both Cloudflare (the company behind the new DNS service) and APNIC have put up blog posts discussing this joint project. The gist is that Cloudflare wanted to provide a public DNS service that, unlike Google’s 184.108.40.206 service, was not tracking/logging user activity. Because Cloudflare is already a web-scale service that provides content delivery network (CDN) services, Distributed Denial-of-Service (DDoS) attack mitigation, and other web services they were well-suited to both deal with, and study, the flood of background traffic going 220.127.116.11 and 18.104.22.168. APNIC agreed to provide these addresses to Cloudflare (for an initial period of 5 years) to home their DNS service at, so that APNIC and Cloudflare could study and gain insight from both the aggregated DNS query data and the rest of the background traffic.
Should you start using 22.214.171.124 for your DNS resolution? The answer is that you could, but just like Google’s DNS service or Level3’s old standby of 126.96.36.199 there’s really no insight or control to be gained from the IT administrator’s perspective when using these upstream resolvers. There’s also no SLA guaranteeing uptime or performance. If you’d like to use reliable SLA-protected DNS services to provide an additional layer of security or content control for your users, H.A. strongly recommends looking at Cisco’s Umbrella DNS security service. Cisco Umbrella offers IT administrators the ability to provide security and web content filtering policy as well as protection against DNS-leakage for on-premises and remote users at the site, AD group, or user level, while providing statistics and activity reporting for the IT admin. For more information about Cisco Umbrella, contact your H.A. account manager.
While this new 188.8.131.52 DNS service is interesting and may provide valuable Internet traffic research, there are a couple of take-aways that network engineers should keep in mind:
- We really shouldn’t ever use addresses that could be allocated on the Internet, but were not issued to us to use, for any reason. For private links such as firewall failover clustering, a piece of the RFC1918 IP space is best, or using addresses in the RFC3927 (the 169.254.0.0/16 link-local “auto-configuration” range) should also be acceptable.
- Now that 184.108.40.206 and 220.127.116.11 are live, we should avoid using them for documentation or examples. Actually, we never should have done this because the addresses were always valid as “real” Internet addresses, but there’s even more reason to avoid it now.
If you need IP addresses to use in templates, or for examples or documentation, it’s best to use one of the three “TEST-NET” blocks defined in RFC5735. These include 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
- Be aware that some commercial products may have used 18.104.22.168 for some purpose, and that functionality could conflict with using the actual 22.214.171.124 DNS service now. An example of this is Cisco wireless LAN controllers which use 126.96.36.199 as the “virtual” interface address for serving guest portal splash pages. As a result of this, it’s not uncommon to see companies with DNS entries in their public DNS zones for 188.8.131.52 mapping to “guest.company.com” or something similar.
Additionally, if using a Cisco Wireless LAN Controller for DHCP on a guest wireless network, the end client’s DHCP server will appear to be 184.108.40.206. In this case you would want to avoid assigning 220.127.116.11 for the guests’ DNS server since the WLC will intercept requests to 18.104.22.168 thinking it’s intended for it.
- We continue to scrape the bottom of the barrel for IPv4 address space and the activation of certain IP blocks that were always assumed to be de facto off-limits continues to prove this out. If you have not yet begun investigating IPv6 readiness in your network, it’s time to start that process.