Planning DNS changes during cloud deployment: cutover plan

DNS changes are deployment changes because they determine which service clients reach. Before cutover, identify the exact fully qualified domain name (FQDN), the record type, the current answer and the intended new answer.

Choose the record that directs the application name to the target. DNS management APIs can create, read and update records including A, AAAA, CNAME, MX, TXT and SRV; Azure private endpoint diagnostics specifically identify a missing or stale A record as a cause of resolution failure.

For Azure Private Link, an example endpoint FQDN is mystorageaccount.blob.core.windows.net, and an example private DNS zone is privatelink.blob.core.windows.net. The planned private endpoint answer should be a private IP; record the current answer as the old value and the target answer as the new value.

Map who queries each name before changing production: office clients, VPN users, cloud workloads and external users may use different DNS paths. For a private endpoint, check that its private DNS zone is linked to the querying VNet and that custom DNS or conditional forwarders send privatelink.* queries to Azure DNS, for example 168.63.129.16.

Record the current time-to-live (TTL) and the intended record value. A shorter TTL can make changes propagate faster, while a longer TTL lets recursive resolvers cache answers for longer; clients may therefore switch at different times, so keep the old service available during the transition.

Before moving production traffic, query the FQDN from each relevant client location with nslookup or dig. Check that private endpoint queries return the intended private IP rather than a public IP or NXDOMAIN, and investigate a missing A record, an unlinked private DNS zone or incorrect forwarding.

Schedule the change with the application owner. Write down the old and new record answers, TTL and rollback condition; if records are changed through a DNS management API, retain its change log showing who changed what.

At cutover, apply the planned record change and check name resolution, network reachability and the application operation separately. For a private endpoint, a public IP or NXDOMAIN is a reason to stop and restore the previous answer; keep the old service available while checking the DNS configuration.

If the name resolves to the expected private IP but authentication fails, changing DNS again is unlikely to help. Record the observed answer and timestamp so responders can distinguish a cached answer from a wrong configuration.

Before vs After DNS Change: Private Endpoint Example

Key DNS Cutover Metrics and Guidelines