How DNS works — from basics to RoundRobin balancing, GeoDNS, LatencyDNS

Many have heard of a Load Balancer (balancing the load between application instances). But has anyone wondered: who balances the balancer?

After all, if this isn’t done, we end up with a SPOF (Single Point of Failure) system, and the entire application will stop working while the fallen balancer is being brought back up. For High Availability systems, this can be extremely critical.

So, let’s dive in and study DNS and balancing methods together, and see how it all works under the hood.

How DNS works and what it is

DNS (Domain Name System) is a distributed system that translates human-readable domain names into IP addresses understood by computers.

Before we begin, let’s familiarize ourselves with basic definitions that will help us understand DNS later on.

Don’t be intimidated right away; everything will become clear below once you start reading the diagram and the steps.

1. Root DNS server — the absolute root “.”.
2. TLD — Top-Level Domain (.ru, .com, .org, etc.).
3. Authoritative — like the domain owner: it knows which A, MX, TXT, and NS records it has and provides the final answer.
4. Non-authoritative — a caching/recursive intermediary server: it can quickly provide an answer but is not the owner of these records.
5. DNS Resolver — a server or program that handles the task of converting a domain into an IP address, hiding all the complexity of the DNS hierarchy.

Types of DNS Queries

1. Recursive — the server finds the domain’s IP addresses recursively. If it doesn’t know the IP immediately, it follows the chain and returns the final result (usually these are DNS servers from ISPs, Google, Cloudflare, etc.). It also has its own cache.
2. Iterative — the server doesn’t look for everything itself but responds: “I don’t know for sure, but here is the next server, ask them.” In practice, a typical client almost always works through a recursive resolver. It is the one that hides all the DNS complexity from the user.

In practice, a typical client almost always works through a recursive resolver. It is the one that hides all the complexity of the DNS from the user.

DNS Hierarchy

The hierarchy starts from the top down.

When we search for a domain name, each level only knows where to go next.

• Root (.) knows TLD (.com, .ru…)
• TLD knows authoritative (google.com, habr.com…)
• Authoritative knows the IP (A-records)

Why is a hierarchy needed?

No one stores all 350+ million domains in the world in one place.

• Each is responsible only for its own zone.
• This achieves the decentralization of the internet.
• There is no single point of failure and excellent scalability.

So what happens when we enter an address in the browser?

1. You enter a website in the browser.
2. The browser checks its cache, hosts file, and system DNS cache to see if the domain is already resolved and the IP address is known.
3. If the address is not found, the request goes through the OS system DNS resolver to the DNS server specified in the network settings (usually a router/modem). The router/modem checks its local DNS cache; if there is no answer, it forwards the request to a recursive DNS resolver.
4. If the recursive resolver does not know the answer (it is not in the cache):

• It asks the root DNS server.
• It receives a pointer to the TLD server.
• That server, in turn, points to the authoritative DNS server of the domain.
• The authoritative server returns the IP addresses for the website.

5. The DNS resolver caches the received IP address and returns it as a response to the browser via the router/modem.
6. The browser makes an HTTP/HTTPS request to the server’s IP address.
7. With HTTPS, a TLS connection (handshake) is established before data transmission.
8. Page loading begins.

Main DNS Record Types

A DNS record (Resource Record) is a unit of information in a domain’s database that links a domain name to specific data (IP, mail server, text, etc.).

The most frequently used ones are:

• A — IPv4 address
• AAAA — IPv6 address
• CNAME — Canonical Name (an alias where one domain points to another) www.example.com > CNAME > example.com
• MX — Mail Exchanger (mail servers)
• TXT — Text (arbitrary data, e.g., SPF, DKIM)
• NS — Name Server (whom to ask for DNS / who “knows” the records). It specifies which DNS servers are authoritative for this domain, meaning where its DNS records (A, MX, TXT, and others) are stored.

Why are there NS records if A records already exist?

— An A record answers the question: “What is the IP for this domain?”

— An NS record answers the question: “Who is authoritative for this domain?”

Why is this separation necessary, when it seems like just an A or an NS record would suffice?

1. Delegation of Responsibility.

You can buy a domain from a registrar (e.g., Reg.ru) but store your DNS records with a different provider (Cloudflare, AWS Route53).

How it works:

— You specify the NS records at your registrar: ns1.cloudflare.com, ns2.cloudflare.com.

— Cloudflare then stores your actual A, MX, and TXT records.

2. NS and DNS Fault Tolerance.

There are multiple NS records to ensure the DNS zone stays alive even if one DNS server goes down.

— A minimum of 2 NS records in different data centers/networks is the standard for a zone.

— If ns1 is unavailable, resolvers proceed to ns2, ns3, or ns4.

— This provides scaling and fault tolerance specifically at the DNS level: the ability to handle many DNS queries and survive the failure of a single server.

Popular DNS Resolvers

• Cloudflare: 1.1.1.1 (one.one.one.one)
• Google: 8.8.8.8 (dns.google)

You can configure these as the primary resolver on your router or device to obtain IP addresses directly, bypassing your ISP.

Sometimes they are convenient to use — there are specialized DNS resolvers that block ads or adult content.

Balancing and Fault Tolerance

A classic situation — many of us know about the Load Balancer.

It balances the load between instances of the same application.

But here is the dilemma: who will balance the balancer?

After all, if you set up a single LB, it becomes a single point of failure (SPOF).

If you set up two, you need a mechanism to decide which one should receive the traffic.

There are several approaches here:

• DNS Round Robin
• Weighted Round Robin
• DNS Failover (with health checks)

Round-Robin DNS

DNS Round-Robin is the simplest way to balance load at the DNS level.

A single domain has multiple A-records, and DNS rotates them in the responses in a circular queue.

How it works

The domain’s DNS records specify:

www.example.com.  IN  A  10.0.0.1
www.example.com.  IN  A  10.0.0.2
www.example.com.  IN  A  10.0.0.3

When requests arrive (for each new connection):

• Request 1 — 10.0.0.1 comes first in the response
• Request 2 — 10.0.0.2 comes first
• Request 3 — 10.0.0.3 comes first
• Request 4 — 10.0.0.1 comes first again, and so on in a circle.

The client typically takes the first IP from the list, so requests are distributed among the servers fairly evenly.

Weighted Round Robin

IPs with higher weights are served more frequently.

www.site.com.  IN  A  10.0.0.1  ; weight 3
www.site.com.  IN  A  10.0.0.2  ; weight 1

A powerful server receives 75% of the traffic.

GeoDNS

GeoDNS is an approach where the same domain returns different IP addresses depending on the client’s geolocation.

How it works:

• The DNS server looks at the IP of the requester (usually the ISP’s DNS resolver or 8.8.8.8).
• It determines the region (Europe, USA, Asia, etc.) using a geo-IP database.
• It returns different A/AAAA records for the same name:
• European user -> European data center
• American user -> American data center, etc.
• This information is then cached by the DNS resolver and passed to you.

Why is it needed:

• Reduce latency. The client connects to the nearest data center.
• Global balancing. Balances the load across regional clusters.
• Increase fault tolerance. If a region goes down, the IP of a neighboring region can be returned temporarily.

DNS providers using GeoDNS

For example: Cloudflare, AWS, Azure, Google

DNS Failover (with health checks)

DNS failover is an add-on for A-records where an external service monitors the servers and automatically updates the DNS so that users are only directed to healthy IPs.

A short TTL (60–300 sec) is used to ensure the switch happens quickly.

In short: the primary IP is always served as long as it is alive. If the health check indicates a failure, the DNS begins serving the backup IP.

Step-by-step process:

1. There is an A-record with two IPs:

• Primary: api.example.com -> 192.0.2.1
• Backup: api.example.com -> 192.0.2.2

2. A specialized service (Cloudflare, Route53, ClouDNS, etc.) monitors the health of the primary server using HTTP/ping/TCP checks every N seconds.
3. If the primary server stops responding:

• The service changes the DNS record: — Active-Passive: replaces 192.0.2.1 with 192.0.2.2. — Active-Active: removes the dead IP from the list.

4. After the cache TTL expires, resolvers begin receiving the new IP, and users are redirected to the backup.

DNS providers using Failover

Cloudflare, Route53, ClouDNS.

GSLB (Global Server Load Balancing)

GSLB is a global load balancing technology that distributes traffic between servers in different geographical locations (data centers, regions), frequently implemented via DNS. It directs users to the nearest or most performant server by considering latency, health checks, geolocation, and current load to minimize delays and ensure fault tolerance.

Balancing Methods:

• Latency-based. Routes traffic based on the fastest response time for the user.
• Geo-location. Directs users to servers in their specific region or country.
• Round-robin/Weighted. Distributes requests sequentially or based on pre-assigned server weights.
• Least connections/Load. Sends traffic to the server with the fewest active sessions or lowest CPU usage.

GSLB is ideal for high-load microservices in a multi-region environment. AWS Route 53, for example, utilizes GSLB.

Useful Commands

These commands will help you debug or check DNS and network issues.

dig

dig (Domain Information Groper) is a DNS client utility for querying DNS servers from the command line.

It is a more modern alternative to nslookup.

dig google.com +short - provides a concise list of A records.

dig +trace

dig +trace example.com - shows the full DNS resolution path from root servers down to the authoritative server.

It bypasses the local cache!

dig initiates an iterative lookup starting from the root servers:

1. Request to root servers (.)
2. Request to TLD servers (.com)
3. Request to authoritative servers for google.com
4. Receipt of the final answer.

nslookup

The command nslookup google.com queries a DNS resolver for information about the google.com domain.

nslookup -type=A google.com - retrieves all IP addresses (you can specify types like A, MX, NS, TXT, CNAME, SOA, or ANY).

ping

ping google.com - helps check server availability and network latency.

ping google.com

What the command does:

• DNS Resolution first - The system resolver converts google.com -> IP (e.g., 142.250.190.78).
• Sends ICMP Echo Request - Small “ping” packets are sent to the Google server.
• Waits for Echo Reply - It measures the round-trip time (RTT).

PING google.com (142.250.190.78) 56(84) bytes of data. 
64 bytes from 142.250.190.78: icmp_seq=1 ttl=117 time=15.2 ms 
64 bytes from 142.250.190.78: icmp_seq=2 ttl=117 time=14.8 ms 
--- google.com ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 1001ms 
rtt min/avg/max/mdev = 14.800/15.000/15.200/0.200 ms

Conclusion

Subscribe on my Telegram channels to get to know more infomation about IT

• From Junior to Architect | Yoda [RU]
• From Junior to Architect | Yoda [EN]

Usefull sources

1. My website — How DNS works [RU]
2. Book: Computer Networks — Andrew Tanenbaum A fundamental resource for understanding networking, including deep dives into DNS architecture.
3. Domain Name System (Wikipedia) Comprehensive technical overview of the protocol, history, and structure.
4. What is a DNS resolver? A clear explanation of how resolvers work, the differences between recursive and iterative queries, and security aspects like DNSSEC.