DNS Changes During Website Deployments: TTL, Propagation, and Cutover Planning

Overview

If your team deploys websites, APIs, or platform services behind a domain name, DNS is part of your release process whether you treat it that way or not. A record change can shift traffic between environments, point users to a new load balancer, move email to a different provider, or break a previously stable path if the details are rushed.

The good news is that most DNS cutovers are predictable when you plan them as a sequence rather than a single moment. Three ideas matter most:

• TTL defines how long resolvers and clients may cache a record before checking again.
• Propagation is not a magical global event; it is the gradual replacement of cached answers over time.
• Cutover planning is the operational work around the DNS change: validation, monitoring, rollback, and communication.

For engineering teams, that means DNS should sit alongside your CI/CD pipeline, environment strategy, and release checklist. If your deployment process already distinguishes between staging, preview, and production, DNS should map cleanly to those boundaries rather than being handled ad hoc. If you need a broader release framework, pair this guide with Staging vs Preview vs Production Environments: What Every Team Needs and Website Deployment Checklist for Production Releases.

A practical way to think about DNS during launches is this: DNS does not create zero downtime by itself. It only changes where requests go. Zero-downtime outcomes depend on whether the destination is healthy, equivalent, and ready to serve traffic before the record changes. For that wider release pattern, see Zero-Downtime Deployment Guide for Websites and Web Apps.

Before the checklists, it helps to clear up one common misconception. Lowering TTL does not instantly force the whole internet to forget old answers. It only improves how quickly future refreshes can happen after caches expire. If a record was previously cached with a higher TTL, some users may continue using the old answer until that original cache window ends.

Checklist by scenario

Use these scenario-based checklists as a pre-flight reference. The exact record types and traffic paths will vary, but the planning pattern stays consistent.

1) Launching a new website or web app on a fresh domain

For a first launch, the main goal is accuracy. There is no live production traffic to migrate, but there is still risk in misconfiguring records, certificates, redirects, or apex and subdomain behavior.

• List every hostname you intend to serve: root domain, www, app subdomains, API subdomains, and any admin or status hostnames.
• Decide which records belong at the apex and which belong on subdomains. Keep the plan simple.
• Verify the target endpoints before creating production records. Resolve load balancer names, ingress endpoints, or platform-assigned hostnames in advance.
• Confirm SSL or TLS readiness for all public hostnames before sending traffic.
• Test redirect behavior intentionally. Many launch issues come from forgetting whether example.com redirects to www.example.com or the other way around.
• Set an initial TTL that matches your confidence level. A moderate TTL is often easier to manage than an extremely high or extremely low one.
• Document the authoritative DNS provider, registrar access, and the specific records that were created.
• After launch, validate from multiple networks and devices rather than relying on a single local test.

2) Migrating a website to a new host, platform, or load balancer

This is the classic DNS cutover case. The safest migrations separate preparation from traffic shift.

• Inventory all records tied to the current deployment: A, AAAA, CNAME, TXT, MX, verification records, and any CDN or proxy settings.
• Reduce TTL on the records you expect to change well before the migration window. Do this early enough that old high-TTL caches have time to age out.
• Build and validate the new destination completely before changing DNS. Health checks, certificates, application dependencies, and static assets should already be working.
• Test the new environment using a temporary hostname or host-header-based validation so you can inspect it before public cutover.
• Capture the old record values in a rollback note that the on-call engineer can use without interpretation.
• Schedule the cutover during a window when the right people are available: DNS access, platform owner, application owner, and incident lead if needed.
• Make the DNS change in the smallest practical scope. Change only the records required for this migration.
• Monitor traffic split, error rates, latency, and certificate behavior during the TTL window after the change.
• Do not immediately decommission the old environment. Keep it available until you are confident late-arriving traffic and caches are no longer depending on it.

If your infrastructure supports it, pair DNS changes with a release strategy such as blue-green, canary, or rolling deployment rather than using DNS as the only safety mechanism. A useful companion read is Blue-Green vs Canary vs Rolling Deployments for Web Apps.

3) Moving traffic between environments during a planned cutover

Sometimes the site itself is unchanged and the DNS move is about environment promotion: for example, routing a production hostname to a new cluster, ingress controller, or edge layer.

• Confirm that configuration parity exists between the old and new environments: secrets, environment variables, database connectivity, firewall rules, and upstream service access.
• Check that logs, metrics, and alerts are already flowing from the new environment. Observability should not begin after cutover.
• Validate cache behavior. If a CDN, reverse proxy, or application cache sits in front of the site, make sure it is warmed or at least expected.
• Review session and authentication assumptions. If sessions are sticky or local, a DNS cutover can expose hidden state problems.
• Prepare explicit rollback criteria such as elevated 5xx rates, login failures, or asset loading errors.
• Record the exact time of change so later troubleshooting can line up with logs and monitoring.

4) Updating DNS during a Kubernetes deployment

In Kubernetes-backed platforms, DNS changes often sit one layer above the cluster, but cutovers still fail when ingress details are not checked.

• Verify the new ingress, service, or external load balancer endpoint before modifying public DNS.
• Make sure certificates and ingress rules are attached to the right hostnames.
• Confirm health probes and readiness checks are passing so traffic does not land on unready pods.
• Review network policy, firewall, and cloud security group rules for the new path.
• Check that external DNS automation, if used, will not overwrite or revert your planned changes unexpectedly.
• If using GitOps workflow or infrastructure as code, ensure the desired state in the repository matches the manual cutover plan.

Teams managing DNS through platform automation should treat repository state as the source of truth. A last-minute console edit can be useful in an incident, but it should be reconciled afterward so your GitOps workflow and reality match again.

5) Rolling back after a bad deployment or failed migration

A DNS rollback plan should exist before the cutover, not be invented after alerts fire. The key question is not just “can we point traffic back?” but “is the old destination still safe to receive traffic?”

• Keep the previous environment available long enough to receive traffic again if needed.
• Store old record values, provider access details, and rollback steps in the deployment note.
• Define who can authorize rollback and what threshold triggers it.
• Before rolling back, confirm the old environment still has working certificates, upstream access, and compatible data assumptions.
• Remember that rollback is also affected by TTL and cache behavior. Some users may continue reaching the newer destination for a period of time.
• After rollback, continue monitoring both paths until traffic stabilizes.

For teams that automate application releases but still handle domains manually, this is a strong candidate for process improvement. Your CI/CD pipeline does not need to own every DNS action, but your deployment system should at least surface the dependencies, timing, and human approvals around them. For broader release automation, see CI/CD Pipeline for Websites: Best Practices by Stack.

What to double-check

These are the details most likely to cause a cutover to feel random when the root problem is simply hidden in a different layer.

• Authoritative DNS access: Confirm you are editing the correct zone in the correct provider account. This sounds basic, but multi-account environments make it easy to change the wrong place.
• Registrar vs DNS host: Know whether the registrar and the authoritative DNS provider are the same service or different ones.
• Record type correctness: Make sure you are using A, AAAA, CNAME, ALIAS, or provider-specific flattening features appropriately for the hostname.
• TTL timing: Lower TTLs before the maintenance window, not during it. Lowering TTL at the moment of cutover rarely gives the benefit people expect.
• CDN or proxy layer: If a provider proxies traffic, DNS results alone may not reflect the actual origin behavior users experience.
• SSL/TLS coverage: A valid certificate for the old hostname on the old platform does not guarantee the new platform is equally ready.
• IPv6 behavior: If AAAA records exist, verify the IPv6 path is healthy too. Some outages affect only part of the audience because only one IP family was tested.
• Email and verification records: During broader domain migrations, avoid accidentally deleting MX, SPF, DKIM, DMARC, or verification TXT records that are unrelated to web traffic but critical to operations.
• Health and rollback metrics: Decide in advance what success looks like. Traffic serving, error rate, login success, and synthetic checks are better signals than a single local dig result.
• Application state: DNS can move requests, but it cannot reconcile differences in sessions, database schema, background jobs, or object storage paths.

A practical cutover note usually includes four things: current records, planned records, validation steps, and rollback steps. If that information is spread across chat, a ticket, and one person’s memory, the deployment is harder than it needs to be.

Common mistakes

Most DNS incidents during deployment are not caused by DNS itself. They come from using DNS as a shortcut around incomplete release planning.

• Treating TTL as an instant switch. TTL helps shape cache behavior over time. It does not force every resolver to update at once.
• Changing too many records together. A cutover is easier to verify when only the required hostnames change. Broad zone edits create more places to make a mistake.
• Skipping pre-cutover testing on the new destination. If the only real test happens after public DNS changes, DNS will get blamed for application readiness problems.
• Forgetting non-web records. Domain changes often affect email routing, ownership verification, SSO, and third-party integrations.
• Decommissioning the old stack too early. Keep rollback real, not theoretical.
• Using local DNS cache flushes as proof of global success. Your machine can be correct while a meaningful share of users still sees old answers.
• Not coordinating ownership. The person who can edit DNS, the person who owns the application, and the person watching production should all know the plan.
• Manual edits that bypass source of truth. If you manage zones with Terraform or another infrastructure as code workflow, reconcile emergency changes immediately afterward.

Teams that already maintain infrastructure as code best practices should extend the same discipline to domains: review changes, keep record intent documented, and avoid permanent drift between code and production. Even a lightweight terraform tutorial-style approach to DNS management can be safer than undocumented console changes, provided the operational path for urgent fixes is clear.

When to revisit

Use this guide as a living deployment reference, not a one-time read. DNS planning should be revisited whenever the traffic path, hosting model, or operational ownership changes.

Review your DNS cutover checklist:

• Before major launches, migrations, or platform moves
• Before seasonal traffic peaks or business-critical campaigns
• When changing DNS providers, registrars, CDNs, or load balancers
• When adopting Kubernetes deployment patterns, GitOps workflow, or new infrastructure as code tooling
• When the team changes and domain knowledge needs to be made explicit
• After any incident where rollback was unclear, slow, or partially effective

A simple action plan for your next cutover:

1. Create a one-page DNS deployment checklist for your production domains.
2. Add current record values and authoritative provider details.
3. Define how far in advance TTL should be lowered for migrations.
4. Add validation steps for certificates, health checks, redirects, and observability.
5. Write rollback steps that another engineer could execute under pressure.
6. Link that checklist from your standard release process and incident response notes.

If your team wants a broader production routine, combine this guide with Zero-Downtime Deployment Guide for Websites and Web Apps and Website Deployment Checklist for Production Releases. DNS is only one part of a reliable launch, but it is one of the few parts every team touches eventually. Treat it as an engineered cutover, not a last-minute setting, and launches become far less surprising.