This article will help network administrators determine the best DNS server settings to use for WAN lookup settings inside of a perimeter security appliance. The DNS server settings discussed here are NOT the DNS server settings that would be delivered to end users via DHCP.
Perimeter security appliances use WAN DNS in order to look up content in real time as well as on a scheduled basis. To best understand this, think about web content filtering. Every time one of your users looks up a website, a web content filtering lookup is made to the web content lookup database. That database is hosted in the cloud and found by the perimeter security appliance via DNS. You can imagine that this is a lot of lookups for the average company on an average day. Even for a small office of 5 people, their aggregated web browsing can result in tens of thousands of DNS lookups per day.
Any inefficiency in the DNS lookup process that does not increase security is simply wasted time. There are valid reasons for using things like DNS proxies or WAN DNS hosts that can provide additional security, such as OpenDNS. But using OpenDNS for DNS lookups for the security services portion of your appliance adds no value. What does add value is to find the closest, yet reliable DNS server that is accessible from ALL of your WAN interfaces.
Use WAN DNS accessible from both ISPs
Many networks use multiWAN. That means the network has two ISPs. The proper use of multiWAN is to use policy-based routing, load balancing, and automatic failover. Link status monitoring is a topic for another article, but realize that whatever the DNS is that is used for the WAN functions of the security appliance must be accessible from BOTH WAN connections. Otherwise, a situation can result where WAN DNS lookups for services can fail because the DNS server is not accessible from the remaining WAN link.
Use TraceRT to select best DNS
Tracert.exe is a trace routing command line tool. The syntax for usability is:
Tracert.exe [ip address]
Trace route will show how many network hops away from the WAN connection is the WAN DNS server. The more hops, the worse the network performance.
Check a few WAN DNS servers for hop count
Check Google’s ever popular and probably way over utilized DNS server. 16 hops is very slow network performance.
Check OpenDNS. Find that DNS server is 12 hops away.
Check Dyn.com DNS server. Find that it is 11 hops away.
Check Time Warner Cable DNS. While it is very close, if you have multiWAN, you should not use the ISP DNS because it is probably not accessible from both WAN connections. If you don’t have multiWAN, than this DNS server would be the best primary option, but use Dyn.com as the secondary.
For singleWAN, use the ISP DNS as primary DNS and Dyn.com as secondary.
For multiWAN, use Dyn.com as primary and OpenDNS as secondary.
In my testing, I found that the reduction in hops had the most noticeable results in slow connections such as satellite, microwave, or DSL. This strategy still applies to most internet connections.
Depending upon what your network's ISP is, you will need to find out what that ISP's DNS servers are and do your own testing. If you are on the west coast of the United States, you may find that 126.96.36.199 has a less hops tracert response than my results.