Imagine changing a domain's server address: the new site opens at home, while your phone still connects to the old server. Even when both devices use the same name, the results can briefly differ if they pass through different DNS caches. An HTTP cache that reuses downloaded pages and a DNS cache that helps find an address to connect to require different checks.
This article follows the fictional library host www.library.example to explore name resolution and caching. The names and timetable are explanatory examples, not measurements of a real service. The aim is to distinguish how DNS supplies addresses, why changes can appear late, and failures that occur after name resolution.
1. DNS offers different kinds of answers for each name
DNS provides information associated with domain names in records of different types. A represents an IPv4 address and AAAA an IPv6 address; a name can have several addresses. CNAME is an alias pointing to another name, MX identifies a server that receives mail, and NS identifies an authoritative nameserver for the zone. Asking about the same name can therefore produce different answers when the requested record type differs.
As Cloudflare's explanation of DNS records describes, a CNAME value is another name, not an IP address. Obtaining an address may require resolving that name too. In https://www.library.example/books, the hostname handled by DNS is www.library.example. Neither the /books path nor the page body is registered in DNS. Setting a CNAME does not automatically create an HTTP redirect that changes the browser's address bar.
2. How a recursive resolver finds authoritative servers
A device's name-resolution function usually asks its configured recursive resolver for an answer. The recursive resolver uses cached information when available; otherwise, it queries other DNS servers and returns the final answer or an error. The DNS terminology standard, RFC 9499, distinguishes this work on the client's behalf from the authoritative server's role of holding information for its own zone. Read the source of an answer in light of the server's role.
In a simplified flow without caches or intermediaries, the resolver obtains a referral to the top-level domain's servers from the root, then a referral to the target zone's authoritative servers. It obtains the required record or alias from the final authoritative server. A single root server does not store every website's IP address. In practice, resolution can start from cached delegation information or be forwarded to another resolver, so every visit need not repeat this entire sequence.
3. TTL is remaining cache lifetime, not a worldwide clock
A record's TTL communicates cache-lifetime information in seconds. In an ordinary cached response, the remaining time decreases while the record is stored. For example, if a resolver stores an address with a TTL of 300 seconds at 10:00, the remaining TTL when it answers from the same copy at 10:02 is about 180 seconds. The timetable below assumes one resolver that does not requery, refresh early, or serve stale answers.
| Fictional time | Address at the authoritative server | What this resolver does |
|---|---|---|
| 10:00 | Old address | Stores the old address with a TTL of 300 seconds |
| 10:01 | Changed to the new address | The stored copy still has 240 seconds left |
| 10:03 | New address | May reuse the old address for the remaining 120 seconds |
| First query after 10:05 | New address | Assumed to query again instead of using the expired copy and obtain the new address |
Other resolvers may have stored the record later or never seen it. Their refresh times differ, so a single TTL cannot determine when all users worldwide switch simultaneously. A cache can discard data before expiry, and refreshing a webpage does not clear a shared resolver's copy. TTL helps explain reuse of DNS responses; it is not a time limit for the entire web connection or screen update.
4. When to lower TTL and how an absence is cached
A cache that received the old address with a TTL of 3,600 seconds is not immediately informed when the operator lowers the TTL to 60 seconds. For a planned address change, adjust TTL beforehand and allow for responses stored under the previous, longer lifetime. Lower TTLs can prompt more frequent checks for changes, but also increase query load and reliance on authoritative servers. Consider the change plan and outage response together instead of applying the same short value to every service.
NXDOMAIN, meaning that a name does not exist, and NODATA, meaning that the name exists but lacks records of the requested type, can also be cached. The negative-caching standard, RFC 2308, defines the negative answer's cache lifetime using the smaller of the authoritative server's SOA record TTL and its SOA MINIMUM field. Thus, an earlier answer saying “absent” can remain immediately after a host is added. Assuming its lifetime matches the new A record's TTL can hide the cause.
5. Keep the name, type, and server fixed when checking
Record the exact queried name, the type such as A or AAAA, the DNS server queried, and the time. Where dig is installed, you can specify a name and type with dig example.com A. When investigating a real problem, replace example.com with the host you want to check. This command illustrates a procedure; it was not actually run or used to measure response times for this article.
Read the response status together with the names, types, values, and TTLs in ANSWER. When repeating the same query to the same resolver, check whether TTL decreases, but do not immediately call an increase an error. The record may have been refreshed early, or a different cache node may have answered. Keeping A and AAAA results separate helps identify which address family differs.
As an operator, you can compare your recursive resolver's answer with the authoritative server's answer for the same name and type in your zone. If they differ, check remaining cache time, consistency among authoritative servers, and delegation settings in turn. Do not generalize one public resolver's answer to all users. Internal corporate DNS or a browser's separate DNS settings can change the lookup path, so also record the connection environment.
6. Separate DNS errors, connection errors, and exceptions
NXDOMAIN is an answer that the name does not exist; NODATA indicates that the requested record type is absent. SERVFAIL instead means the server failed to process the query, while a timeout means no answer arrived within the waiting period. Do not interpret all of these as “the domain was deleted.” First preserve whether there was a response code and which server you queried, so you can decide what to check next.
An old answer after TTL expiry is not always a rule violation. The serve-stale method in RFC 8767 defines how expired information can improve availability in the exceptional situation where it cannot be refreshed from authoritative servers. This does not mean all resolvers use the same configuration. Check the behavior of the resolver actually used rather than inferring a definite change-propagation time from a single TTL.
Finally, successful address resolution does not guarantee successful website access. The network route to that address, TLS certificate, webserver, and application are separate stages. If DNS returns the expected address but the page will not open, move the investigation to the subsequent connection stage. Recording name-resolution answers and web responses separately helps locate the failure before blindly clearing page caches or changing DNS settings.