DNS Cutovers in Blue-Green Deployments: A Practical Guide

A blue-green deployment keeps two full production environments running -- one live ("blue"), one idle but fully deployed and ready ("green") -- and cuts traffic over between them as a single, quick switch rather than a rolling update. One common way to implement that switch, especially across separate infrastructure or providers, is a DNS change: updating the domain's record to point at the green environment's address once it's verified healthy.

Where the simple version breaks down

A DNS-based cutover isn't instantaneous the way flipping a load balancer's target group usually is. Every resolver that cached the old (blue) answer keeps serving it until that record's TTL expires -- which means, for a window of time proportional to the TTL, some fraction of traffic is still landing on the environment you just tried to cut away from. For a TTL of one hour, that's potentially an hour of split traffic across both environments before the cutover is fully complete everywhere.

• Lower the TTL well ahead of the planned cutover -- ideally at least one full old-TTL cycle in advance, so by cutover time every resolver has already re-cached with the new, shorter TTL.
• Keep the old (blue) environment fully running and healthy for at least the TTL window after the cutover, not decommissioned immediately -- it's still receiving real traffic during that window.
• Verify the cutover by querying DNS directly rather than just checking application logs -- confirms the record itself changed, independent of how much traffic has caught up to it yet.
• Raise the TTL back to its normal value only after you're confident the cutover is complete and stable.

The gradual alternative: weighted DNS

Rather than flipping every resolver over at once and hoping the green environment holds up under full production load immediately, several DNS providers support weighted (or percentage-based) routing policies: 95% of answers point at blue, 5% at green, and that split shifts gradually -- 80/20, 50/50, and onward -- as confidence in the new environment grows.

It trades a clean, simple switch for the ability to catch a problem while it's only affecting a small slice of traffic, and to shift back to 100% blue in seconds if green turns out not to be ready, rather than needing to reverse a full cutover under pressure.

Verifying either approach the same way

Whichever strategy is used, the verification step is identical: resolve the domain repeatedly, from more than one vantage point, and confirm the actual observed split matches what was configured. A weighted policy that was meant to send 10% of traffic to green but is actually sending 40% -- because of a misconfigured weight, or because some resolvers cache and don't re-roll the split as often as expected -- is exactly the kind of drift that only shows up by checking the real resolved answers rather than trusting the DNS provider's dashboard to reflect reality perfectly.