How DNS Works: From Domain Name to IP Address

Every device on the internet is found by a number, an IP address. People do not remember numbers well, so we type names such as example.com instead. The Domain Name System, or DNS, is the lookup service that connects the two. Each time you open a website, send an email or use an app, your device quietly asks DNS where to go.

Understanding that lookup explains several things at once: why a site can fail to load while your connection is fine, why changing a DNS setting can make browsing feel faster or slower, and why DNS is one of the places where privacy can leak even when you use a VPN.

The problem DNS solves

Your phone cannot connect to "example.com" directly. Network equipment moves data between numeric addresses, such as 93.184.216.34 for IPv4 or a longer hexadecimal form for IPv6. DNS is the public phonebook that maps a name to one or more of those addresses.

Two properties make DNS useful. First, names are stable while addresses can change: a company can move its website to a new server and update one DNS record, and visitors never notice. Second, one name can point to many servers, which lets large sites spread traffic around. If you want background on the addresses themselves, see what a public IP address is.

Who is involved in a lookup

A lookup usually involves four kinds of server. You do not talk to all of them directly, but the roles are worth knowing.

• Stub resolver: a small piece of software in your operating system. It asks a bigger resolver for the answer and keeps a short-term memory, called a cache.
• Recursive resolver: the server that does the legwork. By default it is provided by your internet provider or by the Wi-Fi network you are on, but you can choose a public one instead. This is the server that sees your queries.
• Root and top-level domain (TLD) servers: these know who is responsible for endings such as .com, .org or .th.
• Authoritative name server: the server run by, or on behalf of, the domain owner. It holds the real records for that domain.

What happens when you type a web address

Suppose you visit www.example.com and nothing is cached yet.

1. Your browser checks its own cache, then asks the operating system's stub resolver.
2. The stub resolver sends the question to the recursive resolver configured on your device or network.
3. The recursive resolver asks a root server where to find .com. The root server points it to the .com servers.
4. The .com servers point it to the authoritative name server for example.com.
5. The authoritative server answers with the address, for example an A record (IPv4) or AAAA record (IPv6).
6. The recursive resolver returns the answer to your device and remembers it for a while.
7. Your browser connects to that IP address and the page begins to load.

All this normally takes tens of milliseconds, and the cache means repeated visits skip most of the steps. The details are defined in RFC 1034 and RFC 1035.

Common record types

Record	What it holds	Example use
A	An IPv4 address	Sends example.com to a web server
AAAA	An IPv6 address	Same, for IPv6 networks
CNAME	An alias to another name	Points www to the main name
MX	The mail servers for a domain	Tells other servers where to deliver email
TXT	Free text	Email authentication and ownership checks

Caching and TTL

Every DNS answer carries a time to live, or TTL, measured in seconds. It tells resolvers how long they may reuse the answer before asking again. A short TTL such as 60 seconds lets an owner move a site quickly. A long one such as a day reduces traffic and speeds up lookups.

This is also why "DNS propagation" takes time. When a website owner changes a record, resolvers around the world keep serving the old answer until their cached copy expires.

Where privacy comes in

A classic DNS query is sent in plain text. Anyone along the path, and the resolver itself, can see which names your device looks up. The content of the page is not visible, but the list of domains often says a lot: a banking site, a health clinic, a news outlet.

That has three practical consequences:

• On a shared network such as a café, the network operator controls which resolver you use by default and can see or even alter the answers.
• Your internet provider can usually see the domains you look up if you use its resolver.
• A public resolver you pick yourself sees your queries instead, so you are choosing whom to trust rather than removing the trust.

Encrypted DNS protocols such as DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858) hide the queries from other devices on the path. The resolver still sees them, and the IP address you then connect to is still visible to the network unless something else, such as a VPN, wraps that traffic. HTTPS protects page content but not this lookup; the difference is covered in HTTPS vs VPN.

How a VPN changes DNS

When a VPN is connected, your device is supposed to send DNS queries inside the encrypted tunnel to a resolver chosen by the VPN service. The local network then sees an encrypted stream to the VPN server and cannot read your lookups. The resolver at the other end sees the queries, so you are placing that trust in the VPN service instead of the café or the internet provider.

This only works if the app and the operating system really use the tunnel for DNS. Sometimes a query escapes through the normal route, which is called a DNS leak. A leak test while connected is a quick way to check.

A worked example

You are in a hotel using its Wi-Fi and open a news site.

• Without a VPN, your phone asks the hotel's resolver for the site's address. The hotel network sees the name, then sees your phone connect to the returned IP address.
• With a working VPN, the question travels inside the tunnel. The hotel network sees only encrypted traffic going to the VPN server. The news site sees the VPN server's address as the visitor.

In both cases the news site still knows you visited, and if you are logged in it knows who you are. DNS privacy is only one slice of the picture.

Limits and things to watch for

• DNS is not the whole story. Hiding lookups does not hide the IP addresses you connect to from the resolver or VPN operator.
• A VPN moves trust, it does not remove it. Someone operates the resolver, whichever one you use.
• Browsers can have their own DNS settings. A browser with built-in encrypted DNS may bypass the system or VPN setting, so check what your browser is configured to do.
• Cached answers can hide problems. After changing DNS settings, restart the browser or clear the system cache before you test.
• DNS errors are not always your fault. If only one site fails, the problem may be at the site's own name server.

Practical steps

1. Find out which resolver you use now. Most operating systems show the DNS servers in the network settings, and many online test pages report which resolver answered.
2. If a site will not load but others do, try another network or restart your router before changing anything else.
3. When using a VPN, run a DNS leak test and confirm the resolver shown does not belong to your local network.
4. If you want encrypted DNS without a VPN, check your browser or operating system settings for DNS over HTTPS or DNS over TLS and pick a resolver you are willing to trust.
5. Flush the DNS cache if a site you control has just changed address and you still see the old one.

Summary

DNS translates names into IP addresses through a chain of resolvers and name servers, and caching keeps it fast. Standard lookups are readable by the resolver and by anyone on the path, so DNS is a real source of metadata about what you do online. Encrypted DNS and a correctly working VPN both reduce who can see it, but neither makes lookups invisible to every party. If you would like a prepaid pass that you control without auto-renewal, you can look at XPASS pricing.