OSINT Jet · Reading DNS evidence

Does DNS TTL tell you when a record changed?

A DNS lookup shows a TTL of 300 seconds. It is tempting to turn that number into a date: perhaps the record was added five minutes ago, or perhaps a website will move in five minutes. Neither conclusion follows. TTL describes a caching interval. It does not contain the record’s creation time or its last edit time.

For a historical investigation, preserve the answer and the time you received it. Treat the TTL as context about that answer, then look for dated evidence of the change itself.

What is the number measuring?

TTL stands for time to live. In a DNS resource record it is expressed in seconds. The record format in RFC 1035 includes the name, record type, TTL and record data. A value of 3600 describes an hour-long caching interval, not a calendar time.

Also identify who answered. An authoritative nameserver supplies data for the relevant DNS zone. A recursive resolver looks up answers for clients and can reuse a cached copy. A TTL observed in a cached response normally reflects the time remaining for that copy. The caching model is described in RFC 1034. Asking a different resolver can therefore return a different TTL without showing a different record value.

A lookup website may show both “last checked” and “TTL.” The first can be the tool’s observation time; the second is a duration in a DNS answer. Record the labels exactly. If a service offers historical “first seen” data, that is another observation from that service’s collection, not a timestamp secretly decoded from TTL.

Two caches, one unchanged record

Synthetic exercise: the following is an invented sequence, not a test of a real domain. Assume a record’s data and authoritative TTL remain unchanged, the configured TTL is 3600 seconds, and each resolver caches a fresh authoritative answer directly. Ignore prefetching, eviction and stale-answer handling for this exercise.

Ten minutes is 600 seconds, so A’s remaining interval is 3600 − 600 = 3000 seconds. Under the stated assumptions, the subtraction describes time since A cached its copy. It says nothing about how long the authoritative record existed before 12:00. That record could have been unchanged for weeks.

Now remove the setup and imagine receiving only the two 12:10 responses. You no longer know when either cache was filled, what interval it originally received or whether it refreshed early. The difference is insufficient to reconstruct those events. A result headed “record changed at 12:00” would add information the observations do not supply.

Expiry is not a universal switch-over appointment

Real resolvers need not behave like the simplified exercise. RFC 8767 updates the TTL rules to allow serving stale data when an expired record cannot be refreshed authoritatively. The response can still carry a positive TTL. A small positive number is therefore not, by itself, proof that the underlying answer was recently refreshed.

Do not promise that every observer will see a changed value at one calculated instant. A screenshot from one resolver documents that resolver’s answer at the observation time. It does not sample every cache or establish when visitors reached a particular website version. DNS answers and website content are separate evidence items.

Build a change record that survives review

Start with a narrow question, such as whether the address returned for a particular hostname differed between two observations. Preserve the exact hostname, query type, full returned values, TTL beside each value, resolver or source identity, UTC retrieval time and original output. An A-record observation cannot silently stand in for an MX-record observation, and a screenshot that cuts off the source cannot establish which resolver answered.

If an earlier capture shows value X and a later capture shows value Y, write that those observations differ. To describe a change at the authoritative source, assess whether the observations are comparable, whether cached answers may be involved and whether the service intentionally supplies varying answers. Two samples alone do not identify the precise edit time, the editor, the reason, or all intervening states.

Use this small evidence form alongside the saved responses:

Question about the record:
Name and query type:
Source / resolver for each response:
Observed UTC time → returned value → TTL:
What differs between comparable observations:
Evidence for an actual edit time, if any:
What remains undated:

For the exercise above, the last line is simply “the record’s creation and modification times.” That is a useful result: it prevents a precise-looking countdown from becoming a false historical fact. Continue with the domain investigation guide when you need registration and infrastructure context, or use the website history workflow to compare dated page captures with other records.