The Domain Name System (DNS) is a foundational part of the internet that translates hostnames (www.websitename.com) into IP addresses. The goal of transforming these human-readable URLs into machine-readable strings is to help browsers find and serve requested resources.
These translation and lookup processes ultimately enable clients to retrieve the content they want. It also saves users from memorizing complex IP addresses. This would otherwise be even more challenging due to the shift from the IPv4 protocol (example: 214.165.213.91) to IPv6, which significantly lengthened IP addresses while introducing alphanumerics (example: 2508:8e0d:7906:a18a:33dd:b931:dd18:5b15).
These IP addresses appear complex, yet DNS solves many challenges of navigating the web by offloading translation and resolution to the browser. And since each internet-connected device has an IP address, the Domain Name System fills a crucial record keeping role.
How does the Domain Name System (DNS) work?
When a user types in a web address and hits "enter," the browser begins the process of loading that page. This involves multiple servers that work in the background:
A client (usually a web browser) which identifies the domain name it needs to connect to. The client, generally via the OS network settings, is configured with which recursive DNS resolver(s) IPs to use (often set when the client gets IP addresses for DNS resolvers in the DHCP response packet).
A recursive DNS resolver. This can run on the local system (which will often cache DNS responses while relying on an external recursive DNS resolver), on the local network, or on a remote DNS server with a known IP address (such as the 8.8.8.8 resolver run by Google, 4.2.2.1 run by Level3, and others). This will take the query from the client and follow the chain of DNS servers until it gets the requested record with the IP. Generally, it'll then cache this answer in memory so other clients with the same question get an immediate answer. This server is configured with a list of root name servers (listed at IANA's root server repository) and will follow subsequent servers down (caching all answers and reusing them to avoid repeatedly hitting the major nameservers).
Next come root name servers. These servers will take a query for the top level domain like “.com”, “.org”, “.eu”, etc. and return the IP addresses of the DNS server for that top level domain (TLD).
A TLD name server manages all domains registered under the top level domain such as ".com." This returns the IP address of the authoritative name server for www.example.com when asked.
An authoritative name server for a given domain returns the actual DNS records (for example, www.example.com and 93.184.215.14).
With these servers in place, here's how the overall process looks from both the client and server perspective:
The user enters a URL in their browser (for example, /page).
The browser identifies the domain (www.example.com) and asks the OS for its A/AAAA records (‘A’ records have an IPv4 address, ‘AAAA’ records have IPv6 addresses, and ‘CNAME’ records point to other records, yet even more exist for other uses).
The OS checks for an answer related to www.example.com in its cache. The OS asks its configured recursive name server for the answer if this cache is non-existent.
The recursive name server checks its cache and answers immediately if it has the answer. Alternatively, it follows the trail by sequentially having each step first check its cache, in case it has already asked for the ".com" TLD name servers. It won’t ask again until the TTL expires. The process works as follows:
The recursive name server asks the root name server (a list it's configured with when set up) what the TLD name server for ".com" is.
It requests the authoritative name server for www.example.com from the TLD name server IP obtained from the root name server.
Next, it asks the authoritative name server for the A/AAAA records for www.example.com.
If the record it gets from the authoritative name server is a CNAME instead of an answer, it follows the CNAME using this same process to receive an answer.
The browser connects to the obtained IP address (for HTTPS on port 443) and makes the HTTP(S) request.
While this sounds complicated, this actual backend process takes mere moments. It's very important that DNS lookup and resolution happen as quickly as possible to make web apps feel responsive, and generally provide a good user experience.
How does HAProxy work with DNS?
HAProxy is a load balancer and reverse proxy, and therefore relies heavily on DNS to make IP-related routing decisions. Our products support DNS-based load balancing while offering multiple options for handling DNS resolutions, resolution delays, DNS service discovery, and more. Check out our DNS resolution documentation to dive even deeper.
