Before the days of personal computing — and well before the dawn of smart devices — it was easier for the relatively few users leveraging the Internet to recognize familiar IP addresses, like memorizing a home phone number in the pre-caller ID days.
While we may type URLs into search bars and click “Send” on email, computers don’t actually read text when interacting over networks.
Enter the Domain Name System (DNS), which is one of the foundations of networking as we know it. DNS translates the text-based URLs we type into search bars into the numerical IP addresses that computers use to “speak” to each other.
The goal of DNS is relatively simple — in general, words are easier for people to remember than long, confusing number sequences — but it’s role is crucial as the connected world grows. It will become even more important when IPv6 becomes prevalent, replacing 4 octets like 192.168.0.1 with something like fdf8:f53b:82e4::53.
For those who never experienced the “pre-caller ID” world, think of DNS as the contact list on a smartphone that has the “number” of every other person on the planet — multiplied by every connected device they leverage daily. But even this analogy oversimplifies DNS, as there isn’t one single directory or server acting as a rolodex for all of world’s Internet traffic.
The role of DNS servers
A single DNS directory would be massive, accounting for the more than 333.8 million domain names listed as of 2018. Like all things networking-related today, DNS is distributed across a global network of DNS servers that are constantly in communication with each other to bring users to their websites.
There are several primary reasons DNS servers are distributed in this manner, primarily related to scale.
For starters, many named websites — especially an omnipresent search engine like www.google.com — have hundreds or thousands of IP addresses that correspond with a single domain. Someone accessing Google out of Boston, for instance, isn’t likely interacting with the same DNS equipment, let alone the same Google server, as someone making the same search in London, even if they are ultimately accessing the same site when all is said and done.
Another primary reason has to do with time. If every individual user making that same google search across the globe only had access to one central DNS server, the traffic backup would be immense even with load balancing.
To that end, DNS information is also cached on individual devices, allowing computers to quickly resolve the domain name with the IP address of www.google.com with a remote server multiple times a day. In fact. The routers and servers used by ISPs to connect customers to the Internet themselves cache a great deal of high-traffic DNS information to resolve IP addresses immediately, keeping traffic moving and customers happy.
The DNS hierarchy
The entire process of accessing a website follows a path to a corresponding IP address. When this information isn’t already cached locally, there’s a hierarchy of DNS servers that the request must traverse to unlock that IP. When running smoothly, all of this is invisible to the user.
While internal DNS and caching is common in most enterprises, let’s look at the simplest form of DNS. When the request for an IP is initiated by a user by typing a URL in a browser, the request first goes to a recursive resolver — if it’s not already in the browser’s or operating system’s caches — which is a server usually managed either by the user’s ISP, a managed DNS provider or the enterprise itself. The resolver knows which DNS servers it will need to ask to unlock the IP address, and will generally forward the request to a root server that knows all of the information about top-level domains (.com, .net, .org, etc.). Because these are spread out globally, the resolver will generally access the root server closest to the geographic start of the request — that is, closest to the user accessing the web.
The next step in the hierarchy takes the request to the top-level domain (TLD) server. This server gets more specific, recognizing the secondary domain (the “google” in “www.google.com”), and then sends the request off to that domain’s authoritative name server, which ultimately holds the keys to the IP address that allows the user to visit the website.
Despite all of the stop-points in the DNS hierarchy, this whole journey should happen in the blink of an eye (read: milliseconds). Because it’s such an efficient process, the average Internet user outside of the networking realm takes DNS for granted.
Even though DNS tends to just simply work in the background, when hiccups do happen along the path to the IP address, end user experience can be impacted, which might affect business-critical apps for enterprise users. It then falls on IT to suss out the issues along the path to resolve issues within their control, which is difficult without full visibility into the network.
In our next post, we’ll unpack the importance for DNS Monitoring in greater detail and what it means for enterprise IT in ensuring critical apps aren’t impacted — and all enterprise users remain happy.