DNS Cutover: Check A and AAAA Records Before Switching Traffic

Imagine you’ve just moved a small business site. You open it on your laptop and see the new homepage. A colleague loads the same address and still sees the old site. Both of you typed the same name. Before copying files again or changing nameservers, check where that name sends IPv4 and IPv6 traffic.

An A record supplies an IPv4 address, and an AAAA record supplies an IPv6 address. If you changed the A record and left a direct AAAA record pointing to the old host, either site can still receive requests. Check DNS first, then make a separate HTTPS request over each address family. That gives you evidence about what each path actually serves. RFC 3596 explains the AAAA record.

Start with the exact hostname that misbehaves

Check the bare domain and www separately if you use both. A redirect can send visitors from one to the other, and each hostname can have its own records. The examples use a reserved hostname and IPv6 address. Substitute a hostname you administer and the intended address from your host.

host=www.example.com
dig "$host" A +noall +comments +answer
dig "$host" AAAA +noall +comments +answer

These commands show what your configured DNS resolver answers. If an answer contains a CNAME, follow the target and check where it ultimately resolves. Compare both address families with your host’s instructions. To distinguish a stale cache from a wrong record, identify the authoritative nameservers for the relevant zone and query them directly with dig @SERVER HOST AAAA +norecurse +noall +comments +answer. Look for the aa flag and a successful answer status. Check the A record the same way. For a CNAME into another zone, check that target with its own authoritative servers. The BIND manual describes these dig options.

If the authoritative answer is already correct and a resolver still returns the old value, monitor that resolver. Its cached answer may remain until the TTL it received expires. Lowering the TTL after the cutover won’t shorten the life of an answer it already cached. RFC 1034 describes DNS caching and TTLs.

Make two HTTPS requests and compare what comes back

Run this from a network with working IPv4 and IPv6 where a direct request is permitted. --noproxy '*' keeps a configured proxy from making the connection on your behalf. If your network requires a proxy, use an approved test host instead.

for family in -4 -6; do
  printf '%s\n' "$family"
  curl "$family" --noproxy '*' --max-time 10 --silent --show-error \
    --output /dev/null --write-out 'ip=%{remote_ip} status=%{http_code}\n' \
    "https://$host/"
done

Record the remote IP, HTTP status and any certificate error. The requests deliberately leave redirects unfollowed. If you see a redirect, inspect its Location and repeat the checks for the destination. A 200 can still come from the old site. Fetch the same read-only page over each family and compare something you expect to differ, such as a known deployment marker. If your test machine can’t reach IPv6 anywhere, a failed -6 probe tells you little about your site. Some clients try both address families, which is one reason a normal browser visit can mask a broken path. RFC 8305 describes this connection behavior.

To check an intended IPv6 endpoint before switching DNS, you can pin a single request to its address. Keep the real hostname in the URL so curl uses the right hostname for TLS and verifies its certificate. Skip this direct-origin check if your service expects requests through its proxy or CDN.

curl --noproxy '*' --max-time 10 \
  --resolve "$host:443:[2001:db8::44]" \
  "https://$host/"

If the pinned request fails certificate validation, investigate certificate provisioning and hostname configuration before sending users there. Leave certificate verification enabled. The curl manual covers IPv4, IPv6, and --resolve.

Make the smallest change the evidence supports

• Authoritative AAAA still points directly at the old host. Confirm the target with your new provider. Set the instructed IPv6 address, or remove the stale direct AAAA if the new setup calls for IPv4 only. Leave mail and verification records alone.
• Authoritative answers are correct and only recursive answers lag. Recheck after cached answers expire. Repeated edits make it harder to tell what a resolver has cached.
• DNS is correct, but one family fails HTTPS or shows the wrong page. Follow the failing endpoint into TLS, routing, or site configuration. If a proxy manages the DNS answer, consult its configuration before changing records. A proxy’s public IPv6 address can be intentional even when it reaches an IPv4 origin.

Before you retire the old site, run both probes again from an independent dual-stack network and check the page visitors should actually see. For the rest of the move, use the WordPress migration checklist.

This guide was prepared with AI assistance using the linked documentation. The cutover scenario and command inputs are illustrative.