DNS TTL: Cache Delay or an Incorrect Record?

After a website’s address changes, one colleague sees the new server while another still sees the old one. Before editing the records again, check the DNS TTL and establish which server is answering the query. This article uses a training scenario: an administrator has already changed the A record for www, but results differ between networks. We will gather evidence to separate a resolver’s cache from an incorrect zone without switching the domain again.

This is a diagnostic process for a public domain you manage or are authorised to check. It does not prove that the application works: the correct IP address does not establish that HTTPS, a form or a database is healthy. None of the commands below changes DNS, the system resolver or server files. Do not apply this process to an internal corporate zone without approval: its names may be private.

Prepare the exact name and the expected result

Record the complete hostname, record type, expected value and time of the approved change. The root domain and www are different names; A and AAAA records must also be checked separately. Obtain the expected address from your migration plan or provider’s control panel, not a random search result. If you do not know which record changed, clarify that with the zone administrator first.

You need a macOS or Linux terminal with dig available and permission to send DNS queries. Administrator privileges and a project directory are unnecessary: you can run the commands from any directory. The first command displays the tool’s version. If dig is missing, follow your operating system’s documentation for a normal installation; do not change network settings blindly or run third-party installation scripts.

dig -v
dig example.com. NS +noall +answer

The names example.com and ns1.example.net are illustrative, not your website’s configuration. Replace the domain with your own public zone. The second query helps obtain its NS records; compare them with the delegation at your registrar and the DNS provider’s information. The trailing dot denotes a fully qualified domain name. A separately delegated subdomain needs the servers for its own zone, not an arbitrary NS belonging to the parent domain.

Separate the authoritative answer from a cached copy

Run the next two queries, substituting the real authoritative server for ns1.example.net and the required name for www.example.com. The first contacts the selected NS without requesting recursion; the second uses the resolver selected by dig in your environment. The options and response format are documented in the official dig manual.

dig @ns1.example.net. www.example.com. A +norecurse
dig www.example.com. A +noall +answer

In the first, full response, check status, the aa flag, the ANSWER section and the SERVER field. The aa flag indicates an authoritative answer, but does not replace checking that delegation is correct. A response without it, or a refusal, is insufficient to treat the result as the zone’s reference answer. Repeat the direct query for the zone’s other authoritative servers: disagreement between them calls for checking zone publication rather than waiting for a user’s cache.

In a normal answer line, TTL follows the name, then come the IN class, type and value. TTL is measured in seconds and limits how long a record can be cached; the basic rule is defined in RFC 1034. For example, an illustrative remaining value of 120 means two minutes for that observation, not a guaranteed update deadline for every device worldwide. Lowering TTL now does not retroactively shorten the lifetime of an old copy already cached.

Check the kind of discrepancy, not just the address

If the authoritative servers consistently return the new value while the resolver returns the old one, save both responses with their times. After a reasonable interval, repeat the same query without changing networks. A decreasing remaining TTL is consistent with caching, but is not universal proof: distributed resolvers may answer from different caches. Do not poll the server in a continuous loop; a few controlled observations are enough for a support request.

dig www.example.com. A
dig www.example.com. AAAA

These two queries return full diagnostic output for IPv4 and IPv6 respectively. They deliberately omit the +noall abbreviation: an empty ANSWER in shortened output does not explain the cause. NXDOMAIN reports that a name does not exist, whereas NOERROR without the requested record may indicate that data of that type is absent. Do not describe SERVFAIL or a timeout as simply an old IP address. Save the status and responding server, not just an empty result.

The absence of a name can also be cached: creating a new record does not always immediately remove a previous negative answer. Its lifetime is determined through SOA under RFC 2308, not the TTL of the newly added A record. If you see a CNAME, consider its target name separately; do not expect a change to one record to update an entire chain of dependencies simultaneously.

Finish with a decision, not indiscriminate cache clearing

Build a short observation table: time, network, queried name, type, responding server, status, value and TTL. A useful outcome is an explained discrepancy or a specific question for the DNS provider. Do not send passwords, private zones or complete configurations. If DNS answers agree but the browser displays a different website, examine subsequent layers separately: the browser may use another resolver, while the application may use an HTTP cache.

Do not clear every cache or change DNS providers merely to obtain matching screenshots. That can destroy evidence and create a new problem. Approve any subsequent zone edit separately: preserve previous values, assign an owner, define checks after the change and a way to restore the old configuration. Restoring a record also depends on caching, so do not promise an instant rollback for every user.

In conclusion, compare the authoritative servers first, then the resolver, TTL and status, and only then move on to the website. To check the new hosting environment itself, use the separate curl –resolve method. If answers remain contradictory, AriZone can help interpret the observations and agree on the next safe step without switching the domain again blindly.