If you are using 1.1.1.1 anywhere in your firewall configuration, you'll want to read this

by Community Manager ‎04-04-2018 06:03 AM - edited ‎04-04-2018 06:40 PM (24,669 Views)

Many of us, myself included, have been tempted to be lazy when picking an 'example' IP when creating documentation or needing to use a dummy IP in a configuration somewhere. This laziness has now reared its ugly head and we're going to need to spring into action.

 

Until recently, the IP address 1.1.1.1 was not perceived as actively being 'in use' as there was no service associated to it, no website to pop up when dropped into a browser. It made its entrance in many labs, documentation, and even production configuration.

'Unfortunately' (for us lazy people), the IP has now been released to CloudFlare by APNIC (Regional Internet Registry, responsible for the Asia Pacific region out of five regions of global IP allocations), who until recently had the IP assigned to their own research group but were unable to process the immense amount of garbage traffic generated by people using this IP in production environments.

 

The good thing is CloudFlare's 'mission statement' for their newly started free DNS service, is that they will put privacy before everything else, so you can still use 1.1.1.1, but as a DNS server like the well-known Google public DNS (8.8.8.8, 8.8.4.4)

 

Another word of caution

In a related but unrelated infomercial: 4.2.2.2 to 4.2.2.6 are often used as DNS servers, but belong to Level-3 and are technically not open DNS. Although Level-3 allows non-customers to use their services, they could theoretically decide to discontinue or block outsiders at any time.

 

You'll still want to go ahead and review your configuration to make sure you're not accidentally sending out any (potentially sensitive) packets.

 

  • Having it assigned to a tunnel interface could cause routing issues when trying to reach the IP (and accidentally send DNS queries into a VPN tunnel)
  • Having the IP set in DNS sinkhole could cause malicious packets to be sent to the DNS service If the outbound connections are not being blocked by a security policy.

 

You can review how to configure DNS sinkhole here: How to Configure DNS Sinkhole

 

Best Practice will have you use one of the 3 unrouted IP subnets described in RFC1918 , better known as 'Private Address Space' and used in most business and home networks behind a NAT device:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

 

If these subnets are all being used within your wide network, it might be difficult to find a suitable subnet that does not overlap or take up space and hinder future expansion. Another 3 subnets exist for documentation purposes as decribed in RFC5737 that your ISP should not route in case you accidentally send packets out to the internet:

  • 192.0.2.0/24 TEST-NET-1
  • 198.51.100.0/24 TEST-NET-2
  • 203.0.113.0/24 TEST-NET-3

 

 

Help spread the word and educate users and admins alike.

 

Reaper out

Comments
by SamKear
on ‎04-06-2018 06:03 AM

I've been using 1.1.1.1 as a DNS sinkhole IP, I suppose its time to change that.

by rhagen
on ‎04-12-2018 06:30 AM

I've always recommended using bogon addresses for both the IPv4 and IPv6 DNS sinkhole addresses.  Bogons are reserved address spaces that are filtered out on the Internet but are not typically filtered in enterprise WAN environments and will therefore get routed to the Internet perimeter.

 

https://www.team-cymru.com/bogon-reference.html

 

The addresses I typically use are 192.0.0.1/32 and 2600:5200::1/128.

 

by Community Manager
on ‎04-12-2018 06:59 AM

Hi @rhagen, thanks for the pointer! i'll add that for more freedom of choice!

Ask Questions Get Answers Join the Live Community