DNS CHANGE PLANNER
Estimate DNS cache expiry, propagation window and TTL change schedule.
Set the engineering assumptions and design parameters.
Review calculated capacity, limits and design checks.
The old-cache remainder is the current TTL minus the entered cache age, never below zero. The typical value is a planning heuristic using half that remainder plus authoritative update delay. The conservative window uses the larger of the old-cache remainder and negative-cache TTL, then adds the authoritative delay.
Lower TTL early enough for answers cached under the old value to expire, verify the new TTL directly at every authoritative server, make the record change, and monitor answers through multiple recursive resolvers. Restore a normal TTL only after the new service is stable and rollback is no longer likely.
For a positive TTL, the refreshes-per-day figure is a theoretical per-resolver rate for a continuously requested name: 86,400 divided by TTL. For a current TTL of zero, which RFC 1035 defines as non-cacheable beyond the current transaction, this calculator uses one refresh per second (86,400 per day) as a modeling ceiling; actual traffic follows the query rate. A lower TTL can improve change responsiveness but may increase authoritative DNS traffic.
TTL controls how long DNS resource records may normally be cached, not a universal synchronization timer. Resolver TTL clamps, client or application caches, delegation changes, DNSSEC, unreachable authoritative servers and serve-stale behavior can all affect when users observe a change.
RFC 1035 defines resource-record TTL in seconds. RFC 2308 defines negative caching for NXDOMAIN and NODATA responses using SOA information.
RFC 8767 permits serving stale data when authoritative refresh fails. RFC 9199 explains that TTL choices affect cache duration, latency, resilience and authoritative-server traffic.
The authoritative answer can change quickly, but recursive resolvers may continue returning an unexpired cached answer. The previous TTL and the age of each cache entry affect when clients observe the new record.
Lower it early enough for records cached under the old TTL to expire before the planned change. At minimum, allow the old TTL; add operational margin and verify the lower TTL at authoritative servers.
Resolvers can cache NXDOMAIN or NODATA responses. RFC 2308 derives the negative-answer TTL from the lesser of the SOA MINIMUM field and the SOA record TTL, so a newly created name may remain unavailable until that cache expires.
Yes, in exceptional conditions. RFC 8767 permits a resolver to serve stale data when it cannot refresh from authoritative servers, so TTL alone cannot guarantee an exact global cutover time.
No. It provides a planning window. Resolver policies, cache age, client and application caches, authoritative availability, DNSSEC, delegation changes and operational delays can change observed timing.
ENGINEERING WORKFLOW
Plan addressing, VLAN capacity, packet size, uplinks, optics, access policy and DNS behavior as one LAN design sequence.
