Domain Name Resolution (DNS) is one of the services we take for granted every day. It works behind the scenes to resolve name-to-IP addresses. It works so well that we can accept the defaults without clearly understanding how it works. Most ‘computer guys’ or even IT Professionals really don’t have a good grasp on this topic. Simply ask someone to define root-hints and it will clearly demonstrate the knowledge of a technician.
The biggest reason it is overlooked is that it simply works — until it doesn’t. But beyond that, the question exists — can it work better?
This article is about public DNS name resolution — that is, for things outside of your local environment. We’ll save local domain resolution for another day — such as your Active Directory domain name resolution.
So let’s take a quick look at when you type a website name into a browser — perhaps the easiest example of this. What actually happens? Your local computer uses the following method to resolve names, going down the list until it finds a match. At each step its looking for a hit, which is typically a caches result.
- Your local computer first checks a local file called the hosts file to see if there is a static IP configured.
- Then it checks it’s local DNS cache — so it doesn’t constantly have to ask another source.
- It then uses the DNS name configured for your network interface. Which could be your DNS server for your local network (AD server), or perhaps just your home wireless router… (In some very rare cases it is skipping this and using your ISP’s DNS server.) But sticking with the local DNS server it will also check it’s cache first before going out to its upstream server, which is likely your ISP’s DNS server.
- Your local ISP is also checking its cache which if that fails, it will likely either source another upstream server, or hopefully, it will use root-hints.
- Root hints are the sort of master directory of authoritative servers, which will tell your server who to ask for authoritative information for the TLD, such as .com or .net.
- Once it gets the root zone, then it will query those servers to see specifically which DNS servers are authoritative for the next level such as microsoft.com
- Then it will query that server for the actual DNS hostname, such as http://www.microsoft.com
As you can see once you hit step 4, you’re involving talking to a lot more servers, at a distance and latency for each step — which is why we have DNS caching. Each hop along this line introduces latency… Now there is a lot of things which can be said here. But I want to talk about a few things:
- Cache is essential for timely name resolution, however, this comes at a cost of stale records. This is especially important for IT Professionals to know because there is inherent latency involved with any DNS change. While local network DNS changes can propagate quickly, especially for AD Integrated AD changes when you’re talking about the public internet, it can take 24-72 hours for a simple hostname change to propagate because each cache location is going to hold on to that data for a certain length of time, often stated as TTL or Time-To-Live.
- Public DNS Servers have extremely diverse quality… from the amount of data in their cache to response time. DNS service is really a required afterthought for most internet service providers. As long as it works, they don’t care. As a result, response times can be significant if you need to query your ISP’s DNS information. Additionally, many of the times your ISP doesn’t use a geographically near DNS server so you might be having to traverse the internet to the other side of the continent to get your simple DNS response. Regional ISPs might not have a very good cache of DNS names causing them to reach into the Root Hints, which is time consuming, to build their cache.
There can be a huge performance improvement by migrating away from your ISP’s DNS servers. I have been experiementing with many different options over the decades.
- Many years ago Verizon had some public DNS servers at 18.104.22.168 that was extremely popular, fast and reliable. However, they became flooded with a bunch of IT professionals directing their networks to 22.214.171.124 which impacted performance, so they closed it to just Verizon customers. It was such an easy IP address number to remember it was often used over ISP DNS servers just because it was easy to remember.
- In 2009 Google released their set of public DNS servers at 126.96.36.199 and 188.8.131.52 which quickly became a popular replacement for the Verizon servers. As of this writing they’re still publically available.
- Around the same time, I became introduced to OpenDNS which was recently acquired by Cisco for being awesome at DNS Resolution. Beyond just being a very fast, reliable, responsive DNS server, they also provided very basic DNS filtering. This helped IT professionals by keeping the really, really bad stuff from properly resolving. It also provides options for DNS based content filtering as well, which permitted businesses to get basic content filtering for objectionable content for low cost.
- Starting in 2018, another company which are experts at DNS resolution, CloudFlare entered the public DNS space with their DNS servers at 184.108.40.206 and 220.127.116.11. They are ANYCAST addresses and you’ll automatically be routed to the geographically closes DNS servers to you. Benchmark testings show that the 18.104.22.168 servers are significantly faster than anything else within North America. Not only for caches records but also for non-caches results.
Today when choosing a public DNS server for my clients, it comes down to either CloudFlare or OpenDNS. In environments where we have no other source of content filtering, then I prefer to use OpenDNS but if the client has some form of content filtering on their firewall then the answer is the CloudFlare 22.214.171.124 network.
One important thing to note is that after ClouldFlare started using the 126.96.36.199 address, it exposed that some hardware vendors were improperly using 188.8.131.52 as a local address, against RFC standard. So in some isolated cases 184.108.40.206 doesn’t work for some clients — but this is because the systems they’re using are actually violating the RFC standards. So this isn’t CloudFlare’s causing but rather vendors disregarding RFC standards when they built their systems to use this unregistered space for their own purposes.
As far as how I personally use this as an individual, at home we use OpenDNS with content filtering to keep a bunch of bad stuff off of our home network, it even helps by filtering ‘objectionable ads’ from popping up often.
On my mobile devices, I have a VPN Tunnel which I use on any network which will let me use a VPN, like at Starbucks, etc., and you can find more about this config at this Roadwarrior VPN Configuration article. But sometimes I cannot connect to the VPN due to firewall filtering, such as at Holiday Markets or at my kids school guest network, so in those cases, I use the 220.127.116.11 DNS Profile for my iPhone.
One other closing issue — there have been various ISPs in the past which force all DNS resolution through there servers. In fact, there is one which on each subsequent request for a record, it will artificially increase the TTL number on each request. Basically trying to get your system to cache the results. In this case, your pretty stuck if you run into this but I would suggest you complaining to your sales rep for that ISP. Also you can look into using the DNS over TLS or DNS over HTTPS but as of right now Windows doesn’t natively support it without third party software, some very modern routers might support it, and I know that the DD-WRT aftermarket wireless firmware supports it. So you might have a bit more work to do to get it working.