Why Dropping DNS TTL to 60 Seconds Fails to Prevent Cutover Split-Brain

A common pre-migration checklist advises lowering the Time to Live (TTL) on your DNS records to 300 or 60 seconds roughly 24 to 48 hours before cutover. The expectation is straightforward: once the record is updated to point to the new server's IP address, all visitor traffic should shift to the new host within a minute. In practice, support teams frequently observe traffic arriving at the decommissioned origin hours or even days after the record change, resulting in split-brain data writes where transactions land on both old and new databases simultaneously. Understanding why DNS TTL fails as a precise switch requires looking past the authoritative nameserver down into recursive resolvers, ISP policies, and client connection handling. When you need to migrate stateful web applications without data divergence, you cannot rely on DNS alone. You need an architectural fallback that controls where writes land regardless of resolver compliance.

Why DNS TTL is an Advisory Hint, Not an Enforcement Contract

Authoritative DNS servers publish records with a TTL field specifying how many seconds a downstream caching resolver may hold the answer before querying upstream again. However, RFC specifications do not provide a protocol-level mechanism to force a remote resolver to discard an existing cache entry prematurely. Once an answer leaves your authoritative nameserver, cache expiration is completely out of your hands. Many consumer Internet Service Providers (ISPs), mobile carrier networks, and corporate recursive resolvers actively enforce minimum TTL limits (often called TTL clamping). To reduce bandwidth overhead and protect their recursive caching infrastructure from high query volumes, these networks ignore TTL values below a certain threshold. An authoritative TTL set to 60 seconds may be clamped up to 300, 900, or even 3,600 seconds at the resolver level. Even if your authoritative nameserver responds with A example.com 60 192.0.2.1, the client behind an ISP resolver might receive or retain that record for much longer. Client behavior introduces another layer of persistence. Web browsers and operating systems maintain their own internal DNS caches that do not always align with authoritative records. Modern browsers also maintain persistent HTTP/1.1 and HTTP/2 TCP connections (keep-alive). If a user opened a checkout session or dashboard tab prior to the DNS change, the browser reuses the existing socket connection to the old server without triggering a fresh DNS lookup at all, regardless of whether the record has technically expired. If you assume DNS cutover is instantaneous, users who have resolved the new IP address will write data to the new database, while users whose resolvers cached the old record will continue writing to the old database. Reconciling divergent database auto-increment keys, session tables, and transaction logs after the fact is painful and prone to human error. For a deeper look at how recursive caching isolates upstream record states from downstream monitors, see our analysis on why your uptime monitor stays green during an authoritative DNS outage.

The Three Cutover Paths

When planning a cutover for any system where users write data (such as e-commerce checkouts, SaaS platforms, or forum threads), you need a reliable strategy to handle straggler traffic arriving at the old IP address. There are three standard options to consider, each with different operational trade-offs.

Option 1: Hard Maintenance Window (Read-Only Mode)

This approach accepts that DNS propagation is slow and prevents split-brain by disabling write capabilities on the old origin before the DNS change is made. You place the application into read-only mode or display a static maintenance page on the old server, export and sync the final database delta to the new server, and then update the DNS record. Any user still hitting the old server simply sees an informational banner or is blocked from submitting forms until their resolver updates.

Workload match: Ideal for internal tooling, non-critical web portals, or sites where an hour of scheduled downtime has minimal financial impact.
Budget & Resources: Lowest setup cost. Requires no additional networking infrastructure or load balancers.
Risk profile: Zero risk of database split-brain. The trade-off is guaranteed user disruption during the propagation tail.

Option 2: Reverse Proxy Forwarding at the Old Origin

In this approach, you keep the old server active after syncing the database and changing DNS, but you reconfigure its local web server (such as Nginx, Apache, or LiteSpeed) to act as a reverse proxy. Any HTTP/HTTPS request that still hits the old IP address is immediately proxied over the network to the new server's IP address. Because the old origin passes incoming requests directly to the new origin, every database write lands on the new database regardless of which IP address the client reached. Users do not experience downtime, forms do not fail, and you do not need to worry about ISP TTL clamping.

Workload match: Best suited for transactional websites, dynamic WordPress or Magento stores, and REST APIs that cannot afford extended downtime during regular migrations between standard cloud providers.
Budget & Resources: Low cost, but requires solid understanding of web server proxy configuration, header preservation (Host, X-Forwarded-For, X-Forwarded-Proto), and SSL termination between nodes.
Risk profile: Prevents split-brain entirely while maintaining service availability. The main risk is increased latency for straggler requests travelling across the network hop between the old and new hosts.

Option 3: Upstream Edge or Load Balancer Origin Switching

If your architecture already routes traffic through an edge layer—such as a cloud load balancer, a managed reverse proxy service, or an Anycast CDN—you do not need to change public DNS records at cutover time. The public-facing A/AAAA records point indefinitely to the load balancer or CDN edge IP addresses. To perform the migration, you provision the new server, replicate the data, and simply update the origin IP target inside the load balancer configuration. Because the edge layer communicates directly with your origins without intermediate DNS resolvers, origin switching takes effect across edge nodes almost instantaneously.

Workload match: Enterprise platforms, high-concurrency APIs, and mission-critical applications that require sub-second cutover without relying on remote client DNS resolution.
Budget & Resources: Highest ongoing cost and architectural complexity. Requires maintaining a centralized load balancing or CDN layer in front of the infrastructure.
Risk profile: Minimal cutover latency and zero split-brain risk. The primary operational risk lies in configuration errors within the edge layer itself.

Evaluating Your Options

Choosing the right path depends on your tolerance for downtime, your application's statefulness, and the existing infrastructure.

Evaluation Factor	Hard Maintenance Window	Old-Origin Reverse Proxy	Centralized Edge Switch
Downtime Required	Full write downtime during cutover	Zero downtime	Zero downtime
Split-Brain Risk	Zero (writes are disabled)	Zero (writes routed to new host)	Zero (traffic switched at edge)
Infrastructure Complexity	Minimal	Low (standard web server config)	Moderate to High
Bandwidth Cost	None	Double egress on straggler traffic	Standard edge transit costs
Skill Level Needed	Junior sysadmin / webmaster	Support engineer / sysadmin	DevOps / Infrastructure engineer

If your application is purely static (such as documentation or a brochure website), the simplest path is changing the DNS record without extra measures, because duplicate reads cause no data divergence. But the moment an application processes transactions, orders, or comments, Option 1 or Option 2 is necessary.

Implementing Reverse Proxy Forwarding on the Old Host

For teams moving an active site between two standard VPS or dedicated servers without an edge load balancer, Option 2 provides the cleanest balance between effort and zero-downtime reliability. Once the database is migrated and running on the new host, configure the old host's web server to forward incoming HTTP traffic to the new server's IP. The old server terminates the existing SSL connection and forwards the request upstream over HTTPS. Below is an illustrative Nginx virtual host configuration deployed on the old server during cutover:

NGINX

server {
    listen 80;
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # Existing SSL certificates must remain valid on the old host
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        # Forward directly to the new server IP address
        proxy_pass https://203.0.113.50:443;
        
        # Preserve client headers and host context
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Ensure large payloads like file uploads pass through
        client_max_body_size 64m;
        
        proxy_connect_timeout 10s;
        proxy_read_timeout 60s;
    }
}

There are two critical details to check before relying on this setup: First, the old server must keep its valid SSL/TLS certificates active until traffic on the old IP drops to zero. If you delete the certificates on the old server immediately after updating DNS, clients reaching the old IP via HTTPS will encounter browser security warnings. Second, the new server's web server must accept connections arriving directly from the old server's IP address, and its firewall must allow traffic from that source. If you use IP-based access restrictions or fail2ban rules on the new host, verify that the old server's egress IP is explicitly permitted so that forwarded client requests are not accidentally blocked.

Managing the Decommissioning Phase

Lowering your DNS TTL prior to migration remains a useful preparatory step, not because it guarantees an instant switch, but because it accelerates the rate of decline in straggler traffic. However, you should treat TTL reduction as a background optimization rather than your cutover safety mechanism. Keep the old server running its reverse proxy configuration for at least 48 to 72 hours following the DNS record change. Monitor the old server's access logs periodically to observe request volume tapering off. Once incoming requests drop to negligible levels—indicating that even the most aggressively cached ISP resolvers have refreshed their records—you can safely shut down the old web server and decommission the instance without risk of losing client writes.