What this symptom usually tells you
Finishing a file or application migration does not move traffic by itself. Visitors continue reaching the endpoint published in DNS until the web records change. A forgotten AAAA record can keep IPv6 clients on the old server even when the new A record is already correct.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the DNS resolution and delegation diagnosis rather than as a standalone health score.
- Compare host-provided IP — Verify compare host-provided IP from the public Internet and compare it with the value the responsible provider says should be live.
- Check A/AAAA — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
- Check DNS caches/TTL — Compare independent resolvers or regional probes together with TTL. Different answers are evidence of cache/authority differences, not a reason to claim a fixed global propagation time.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for compare host-provided IP, check A/AAAA, check DNS caches/TTL and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Take the exact production target from the new host and compare it with the authoritative root/www A, AAAA or CNAME records. Update only the records used for web traffic and keep existing mail/service records unless those services also moved. Confirm the new host is ready for the domain before switching traffic.
How to confirm this specific repair
Authoritative DNS should publish the new target, and both root and www should serve the new application over HTTPS. Compare page signatures or a known deployment change rather than relying only on the IP address, especially when a CDN sits in front of the site.
A common wrong turn
Do not lower or raise TTL after the fact expecting it to change the lifetime of answers already cached under the previous TTL. Also avoid deleting mail records from the zone during a website-only migration.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed DNS resolution and delegation result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.