Plan DNS changes during migrations without unnecessary downtime.
Before a DNS migration, the TTL, target system, and certificates are prepared; the old and new servers remain functional during the cache transition period.
For system administrators and web developers, "DNS Migrations Without Unnecessary Downtime" demonstrates the difference between "Preparation" and "Tested Target." "Delayed TTL Reduction" is a typical warning sign.
Published: 3 min read · Author: Sebastian Geier
How do you plan DNS changes when cached responses don't disappear immediately?
The TTL is reduced well in advance of the migration so that old responses can expire. The new target is tested with real hostnames; after the change, both systems handle the transition period, and a fallback remains possible.
Tested target
Inventory all affected records, TTLs, and dependent services.
Reduce the TTL in advance and fully test the new target with real hostnames.
Modify records, monitor both targets, and only decommission the old system after convergence.
Lead Time
Test criterion
Lead Time
The old TTL can actually expire from all caches before the switchover time.
Test criterion
Tested target
TLS, host routing, applications, and external services function before the record change.
Full Zone Mail, verification, and other dependent records are handled separately.
TTL Reduction Too Late
TTL Reduction Too Late – Resolvers retain the old value long after the switchover, thus continuing to access an already outdated service.
Web record only – Mail or third-party verification fails despite the website being accessible because dependent records and acknowledgments were not inventoried together.
Decommissioned legacy target – Cached requests still encounter a shut-down server.
Use case: "TTL reduction too late"
The website switches to a new address, while some resolvers still return the old value. Both servers respond to valid HTTPS and write consistently during the transition; MX and verification records remain unchanged and are checked separately.
Full Zone
Response distribution between the old and new target during the transition period.
Errors by record type, resolver path, and remaining TTL.
What questions arise next?
Choosing PHP-FPM process models for different load profiles Expands on the "Preliminary" checkpoint. The key question is: When does PHP-FPM use static, dynamic, or on-demand settings to match the actual load profile?
A complementary perspective is offered Treat email, DNS, and website migration as separate risk areas.Answers the question: "Why should email, DNS, and website migration be planned as separate risks?"
If you want to practically implement "DNS migrations without unnecessary downtime," you can refer to Robust Website Systems . The focus here is on "DNS, TLS, and Reverse Proxy" and "pre-migration."
Conclusion: DNS migrations without unnecessary downtime
DNS migrations are controlled overlaps. Pre-migration and parallel accessibility prevent avoidable outages, while dependent records are monitored together.
Sources and Further Information
The classification of "DNS migrations without unnecessary downtime" is based on the following official documentation and standards.
NGINX Reverse Proxy – NGINX DocumentationThe official NGINX documentation describes upstream forwarding, headers, buffering, and proxy configuration. `` : ...
RFC 1034: Domain Names – Concepts and FacilitiesThe fundamental DNS standard defines zones, resolvers, caching, and the semantics of distributed name resolution.
RFC 6797: HTTP Strict Transport SecurityThe IETF standard defines HSTS behavior, scope, persistence, and security requirements.
Key Thesis
The TTL is reduced in a controlled manner in a timely manner, the new target is tested under real hostnames, and only then is the record changed. Both systems handle the transition period; fallback, mail, and other DNS records are checked separately.
What This Is Not About
DNS records don't change instantly worldwide, and a low TTL value doesn't delete a response that's been stored for a while.
What it's about
TTL lead time, a tested target, parallel operation, and separate testing of all records limit the transition phase.
Hosting, servers, CDN & caching
Configure TLS, HSTS, and redirects consistently
"DNS migrations without unnecessary downtime" includes, as a separate test step, the question: In what order are TLS, HTTPS redirects, and HSTS securely implemented?
Hosting, servers, CDN & caching
Invalidate cache contents selectively instead of constantly clearing everything.
"DNS migrations without unnecessary downtime" is supplemented by a separate decision: How do you delete only the cached content that is actually affected after changes?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Complete zone: Test assignment for practical application
A zone list with current TTL and service dependencies forms the starting point. This allows for reliable planning of the lead time, switchover, and dismantling.