DNS Changes Need TTL Math and an Independent Resolver

Read the TTL before planning the change

The TTL is the maximum time any resolver may keep answering from cache. A change is only fully live after the old TTL has expired everywhere, so plan the window at twice the current TTL: one interval for caches to drain, one for margin and a rollback decision.

dig +noall +answer service.example
dig +noall +answer service.example @ns1.example-host.example

Each answer line ends with the remaining TTL, which falls as the record ages in that resolver's cache. If the TTL is a day and the change is urgent, lower the TTL at least one full old interval before the switch, then raise it again once the new record is confirmed everywhere.

Query each layer separately

"Is DNS working" is three different questions: what the authoritative servers publish, what recursive resolvers return, and what the application on this host actually resolves through the system stack. Answer them with three different queries.

resolvectl status
resolvectl query service.example
dig +short service.example @192.0.2.53
getent hosts service.example

dig with an explicit @resolver tests one named layer. getent goes through NSS, so it shows what a program using the system resolver sees, including any local overrides in hosts files. When a maintenance guide and the application disagree, this distinction is usually the reason.

Negative answers cache too

A resolver that could not find the record caches the failure, keyed by the SOA minimum and negative TTL rather than the record TTL you never set. Creating a record does not evict that memory; for a while, clients may still receive NXDOMAIN for a name that now exists.

dig +noall +answer +authority service.example
sudo resolvectl flush-caches

When a freshly created record does not resolve, check the negative cache before re-checking the provider panel. The authority section shows the SOA timers that govern the failure's lifetime. On hosts running a caching stub resolver, flushing after the change makes local tests immediate — while remote clients still wait out their own caches.

Run an overlap window, not a swap

Prefer a window where both the old and the new configuration are valid: the old service stays up while the new record propagates, and rollback is pointing DNS back instead of restoring state. Confirm propagation with a resolver you do not control, such as a public resolver queried directly.

dig +short service.example @1.1.1.1
dig +short service.example @9.9.9.9
curl --resolve service.example:443:192.0.2.10 --fail https://service.example/

--resolve tests the new target before any DNS points at it, which separates "the new server works" from "DNS has moved". Keep the old record and the old service for one full TTL after the switch; only then retire them.

DNS change checklist

• Read the current TTL and plan at least twice that window.
• Lower the TTL ahead of an urgent change, then restore it.
• Query authority, recursive resolvers, and the host stack separately.
• Remember negative caching when a new record seems missing.
• Test the new target with a pinned resolution before moving DNS.
• Confirm with an independent public resolver after the switch.
• Keep the old record and service alive for one full TTL.