How DNS works

When a browser connects to www.example.com, the Domain Name System (DNS) provides records, or entries with information about that name, including the internet address the browser needs. The device asks a DNS resolver, a server that looks up DNS information. If the resolver has no current answer in its cache, it follows the chain of DNS servers to find one.

DNS also stores records for routing email and pointing one name to another. Caching speeds up repeat lookups, so a new DNS answer does not appear everywhere at once.

How a DNS lookup finds an answer

A device’s operating system or software sends a DNS query, or request for DNS information, through a stub resolver, the small DNS client that passes the request to a recursive resolver. A recursive resolver finds an answer for the client. An internet service provider, public DNS service, or private network might provide it.

The recursive resolver first checks its cache, a store of answers from earlier queries. If it has a valid answer for the requested name and record type, it returns that answer. Otherwise, it asks other DNS servers where to find the answer.

For www.example.com, a typical lookup without a cached answer works down the hierarchy. A root server directs the resolver to the servers for .com. A .com server points it toward the authoritative name servers for example.com. An authoritative name server holds the DNS records for the DNS area it serves, called a zone, and provides the requested information.

Root servers and servers for domain endings such as .com guide the resolver to the next servers; they generally do not supply the final address for a website. The resolver returns the answer to the device and may cache it.

That root-to-domain path describes a common lookup, not every lookup. A cache can provide the answer before the resolver contacts any of those servers. A network can also configure a resolver to forward queries elsewhere, or use private DNS records for names that are meaningful only inside that network.

What DNS records contain

DNS stores resource records, entries that associate a name with a particular kind of information. The requested record type tells the resolver what information to look for. Common examples include:

• A records map names to IPv4 addresses, and AAAA records map names to IPv6 addresses.
• CNAME records that make one name an alias for another.
• MX records that identify mail servers for a domain.
• NS records that identify name servers for a zone.

A mail service uses MX records to find where to deliver email. A website lookup might return an address record, or an alias that leads to another name.

Once the browser has an address, it can try to connect to the destination. DNS provides information for that step; it does not itself load the webpage or guarantee that the destination is reachable.

Why cached answers persist

Each DNS record has a time to live, or TTL, which tells resolvers how long they may keep that record in cache. While a cached answer remains valid, a resolver can return it without asking the authoritative server again. This reduces repeated queries and helps speed up lookups.

When someone changes a DNS record, resolvers with an older cached answer can keep using it until its TTL expires. Different resolvers may have cached the record at different times, so users do not all see the change at once. DNS changes have no single propagation timer.

Resolvers can also cache a negative answer, which says that a name does not exist. If someone creates that name shortly afterward, a resolver with a cached negative answer may continue returning it until the negative cache entry expires.

Why DNS answers differ

The answer depends partly on which resolver handles the query and what information it has cached. Private networks can use DNS to direct employees to internal services, while public resolvers return records for the public internet. Local network rules and resolver policies can also affect results.

So two devices that ask about the same name do not always receive the same answer. They might use different resolvers or have different cache contents. They might also connect through networks with different DNS settings.

How DNS handles security

DNS has separate protections for the data itself and for the connection between a device and its resolver.

DNS Security Extensions (DNSSEC) let a resolver check that DNS data is authentic and has not been changed along the way. DNSSEC does not encrypt queries, so it does not hide the names a user looks up.

DNS over HTTPS (DoH) carries DNS queries and replies over an HTTPS connection between a client and a configured resolver. That protects the exchange while it travels between those two points. The resolver still receives the queries, and DoH does not by itself verify DNS data in the way DNSSEC does. The two protections address different risks and can be used together.

How DNS sends queries

DNS commonly uses the User Datagram Protocol (UDP) for queries, but it also supports Transmission Control Protocol (TCP). Modern DNS implementations need to support both. Extensions also let DNS participants handle messages larger than the original UDP limit.

Whether DNS uses UDP or TCP, the lookup works the same way: a client asks a resolver for a record, and the resolver returns an answer or looks for one through other DNS servers.