Why a domain does not work after a DNS change
Editing a record is only the first step. Verify delegation, authoritative answers, TTL and multiple resolvers before changing DNS again.
After changing hosting, an IP address or a DNS provider, some users may see the new service while others still reach the old one. This is not automatically an outage. Recursive resolvers keep previous answers for their TTL, while nameserver delegation introduces additional dependencies.
First establish whether the source of truth—the authoritative DNS service—returns the intended data. Only then compare public and ISP resolver responses.
Start with the authoritative nameservers
Compare the nameservers configured at the registrar with the delegation returned by the parent zone. Query every authoritative server directly and confirm that all of them return the same SOA serial and current records.
One stale or unreachable server creates intermittent results because clients can be directed to any server in the delegation.
- Compare registrar NS settings with public delegation.
- Check SOA and the serial on every server.
- Validate A, AAAA, CNAME, MX and TXT records relevant to the migration.
TTL and caches: wait or repair?
A resolver can retain the previous answer until its original TTL expires. Lowering a 86400-second TTL during the migration cannot shorten copies that were already cached for 24 hours.
Missing records can be cached too. Negative caching can make a newly created hostname appear nonexistent to some resolvers for a while.
When propagation is not the problem
If resolvers already return the new address, continue at the application layer. The web server may not recognise the hostname, the certificate may not cover it, a port may be closed, or an AAAA record may point to an unconfigured IPv6 service.
- Compare IPv4 and IPv6 results.
- Check the certificate for the exact hostname.
- Verify the virtual host, reverse proxy and firewall.
- With DNSSEC, confirm that parent DS records match the current zone keys.
Post-change DNS checklist
- Confirm delegation and every authoritative server.
- Query authoritative answers without a recursive cache.
- Compare public resolvers and remaining TTL.
- Check A and AAAA, the certificate and server configuration.
Put it into practice
Check DNS propagation
Compare DNS responses from multiple locations and confirm whether the change is visible outside your network.
Check DNS propagationFrequently asked questions
How long does DNS propagation take?
Usually until the previous TTL expires, while delegation changes and negative caching can follow separate timers. There is no single fixed duration for every domain.
Why does it work on mobile but not on my computer?
The devices may use different resolvers with independent caches. The computer might also prefer a misconfigured IPv6 record.
Does flushing the local DNS cache always help?
It clears only the device cache, not an answer retained by the ISP resolver. Identify which layer still returns the old data first.