DNS TTL: Investigate a Change of IP Address

A domain contacted during an incident now resolves to a different address. That difference does not invalidate your logs or prove that malicious infrastructure has moved. To explain it, place each DNS response in context: time, resolver, record type, cache and observation point.

DNS TTL helps with this reconstruction when used for the right purpose. It describes cache handling; it does not independently establish the age of infrastructure. The following method preserves a useful timeline when addresses change during an investigation.

Understand what a TTL measurement represents

TTL is expressed in seconds. A response from a recursive resolver can show the remaining lifetime of data already in its cache, while an authoritative server can return its configured lifetime. Comparing these numbers without identifying their origin creates misleading differences.

The TTL definition in RFC 1035 relates the value to caching a resource record. It does not describe a domain’s age, the date it was first used or the validity period of an indicator of compromise.

This fictional example shows two readings from the same resolver:

10:00:00Z  api.service.example. A 192.0.2.20  TTL=240
10:01:00Z  api.service.example. A 192.0.2.20  TTL=180

A decrease of sixty seconds is consistent with an aging cache entry. It does not reveal a zone change. To characterize a change, compare the response contents and collection conditions as well as the TTL.

Build a table of dated evidence

Create one row per observation, keeping the previous row when a new address appears. Record the full name, A or AAAA type, any CNAME records, every returned address and the corresponding TTLs. Include the resolver, sensor location and UTC time.

Keep the DNS query separate from the connection actually observed in your case file. A client can receive several addresses and use only one. The resolver’s answer describes available destinations; network telemetry identifies the destination the client attempted to contact or reached.

This table does not establish the exact moment when the authoritative data changed. That event falls somewhere within a period you still need to narrow. Avoid replacing the interval with an invented timestamp derived from the last known query.

Examine the whole chain as well as the final IP

A name can be an alias for a distributed service. Preserve each CNAME with its own observation. A stable alias target can lead to changing addresses; a CNAME change can also change the operator without making that clear in your initial view.

Examine IPv4 and IPv6 separately. The application might use an AAAA response while your enrichment retains only A records. An incident attributed to “the wrong IP” can result from this incomplete collection even when the DNS data itself is consistent.

Different answers from two networks can reflect geographic distribution or separately administered DNS views. Compare names, types and observation points first. For an internal name, stay within authorized views instead of sending it to a public service to simplify the test.

Account for older answers that are still being served

TTL expiration does not guarantee that every client immediately receives the new address. Application layers, intermediate resolvers or specific policies can prolong the discrepancy. Review their configuration and logs before attributing the problem to DNS publication.

RFC 8767 describes serving stale data when authoritative refresh fails. If that feature is enabled, an old answer can remain available beyond its ordinary cache lifetime. Verify the mechanism on the affected resolver instead of assuming it from the result alone.

Preserve the first answer before a flush. Record restarts, resolver changes and troubleshooting actions because they alter your test conditions. A successful test after clearing a cache shows an effect of that intervention; it does not automatically reconstruct the previous situation.

Distinguish migration, distribution and suspicious activity

Ask the service owner whether a migration or provider change coincides with the period under investigation. Compare that explanation with retained responses, destinations actually used and configuration changes. A migration ticket supplies an explanation that still needs verification.

If addresses rotate rapidly, examine their diversity and the associated activity. The fast-flux detection guide addresses that specific hypothesis. Treating every rotation as fast flux during an investigation of a single change would add an unsupported conclusion.

Review each IP’s context at the relevant time as well. A shared address can host several services and change its use. Do not automatically transfer the old address’s reputation to the new one, or a domain’s reputation to every neighboring service on its hosting infrastructure.

Choose an action and a review period

If suspicious activity follows a particular name, consider a control targeting that name where your tools support it. If containment must target an IP, document the observed relationship and schedule a review. DNS TTL is not a default blocking duration.

The article on IOC expiration explains how to reassess a rule independently of caching. End the incident record with the addresses established by evidence, the periods covered and gaps in collection. External historical observations can supplement those gaps without proving what a particular endpoint received.

To enrich the public addresses and domains selected for investigation, open an IsMalicious report. Include the lookup time in your timeline. Keep the conclusion tied to the retained events, even after the current DNS response has changed again.