A website stops loading after a hosting change, but email still works. Another visitor can reach the site while your laptop cannot. Both situations can involve DNS, although neither proves that the entire zone is broken. A useful investigation follows the particular name, record type and resolver involved in the failing request.
Consider a fictional business moving www.example.com to a new host while leaving email with its existing provider. The change should affect web delivery without disrupting mail authentication or delivery. This guide explains how to inspect that arrangement, separate authoritative data from cached answers and avoid replacing unrelated records simply because a control panel suggests a default zone.
Write down the exact DNS question
A DNS lookup is more specific than “check my domain.” It asks for records of a particular type at a particular name. An A lookup for www.example.com concerns IPv4 addresses at that name. An MX lookup for example.com concerns mail exchangers for the domain. The two answers can legitimately refer to different providers.
Start with the hostname from the failing URL or mail configuration. Exclude the scheme, path and query string. Preserve relevant subdomains: the apex example.com and www.example.com can have different records. Also record whether the symptom affects IPv4, IPv6 or both, because an old AAAA record can keep sending some clients toward an earlier server.
The DNS record explorer queries a public resolver through the site server. It shows that resolver’s response, including available TTL and status information. It does not reveal your laptop’s complete resolver policy or the private DNS view inside a company VPN.
Match the record type to the service
| Record | Purpose | Common migration mistake |
|---|---|---|
| A | Maps a name to an IPv4 address | Updating the apex while leaving www on the old address |
| AAAA | Maps a name to an IPv6 address | Forgetting a stale IPv6 destination |
| CNAME | Aliases one name to another | Expecting it to redirect a browser to a different URL |
| MX | Identifies mail exchangers and preferences | Replacing working mail records with the new host’s defaults |
| TXT | Publishes application-specific text such as authentication policy | Deleting verification or email-policy records during cleanup |
| NS | Identifies authoritative nameservers | Editing a zone at a provider that no longer serves the delegation |
| SOA | Provides zone administrative and timing information | Assuming one serial number proves all caches have updated |
A CNAME is a DNS alias, not an HTTP redirect. The browser still requests the original hostname unless a web response redirects it. Certificate names and virtual-host configuration must therefore support the original name. A correct alias cannot repair a web server that does not recognise the requested host.
Confirm which nameservers are authoritative
Registrars and DNS hosting providers can be different organisations. The registrar controls delegation through the parent zone, while the DNS host serves the records. Editing a beautifully presented zone at the wrong provider has no effect on the delegated service.
Compare the expected authoritative nameservers with the delegation and available NS evidence. If a nameserver change was recent, retain the previous configuration and verify that the new zone contains the complete record set before assuming the migration is finished. A copied zone that includes only web addresses can break email, certificate issuance or service verification.
When authoritative servers disagree, investigate that inconsistency before blaming recursive caches. A secondary server may not have received the new zone, or two providers may hold different versions during a migration. Resolver caches can expose that inconsistency differently, making an authoritative problem look intermittent.
Work through a stale IPv6 destination
Suppose www.example.com has a new A record and an old AAAA record. An IPv4-only client reaches the new site successfully. A client with working IPv6 can attempt the old address and encounter a certificate error or an outdated application. The users’ different experiences are compatible with both DNS answers being returned correctly.
Inspect A and AAAA together. Confirm whether the new hosting service supports the published IPv6 address and whether its certificate and virtual host are ready. If IPv6 is intended, update the address to the correct service. If it is not offered, remove the stale AAAA through the authoritative provider after checking the impact and recovery plan.
Then test the delivered web response separately. DNS only supplies addressing information; it does not show that the destination serves the correct application. Use the hostname in the URL so that TLS identity and host-based routing are exercised. A successful connection directly to an IP address is not an equivalent test.
Interpret TTL as a cache instruction
The TTL tells a cache how long it may retain a record under ordinary DNS rules. A response from a recursive resolver often shows the remaining cache lifetime rather than the value originally entered in the zone. Two resolvers can therefore return the same address with different TTLs.
Lowering a TTL at the same moment as a migration does not shorten the lifetime of answers already cached under the previous value. Lower it in advance if the change plan relies on shorter caching. Keep the old service available during the expected overlap, and remember that application connections can remain open independently of DNS cache expiry.
Negative answers can also be cached. A name queried before it existed may continue to look absent for a period governed by negative-caching rules. Repeatedly creating and deleting the name during troubleshooting can make this harder to reason about. The TTL calculator helps with timing arithmetic, but it cannot inspect every resolver’s current cache.
Separate missing data from a failed lookup
A name can exist without having the record type you requested. That differs from an answer indicating the name itself does not exist. A server failure differs again: validation trouble, upstream reachability or another resolver problem may prevent an answer without establishing that the record is absent.
Read response status and any error message alongside the answer section. An empty result should not automatically become “delete this record and recreate it.” First determine whether you asked the right name and type, whether the resolver completed the query and whether a security feature such as DNSSEC could be rejecting inconsistent data.
If a signed zone recently changed providers, inspect the DS and DNSKEY arrangement with the DNSSEC inspector. A stale parent DS can make validating resolvers reject otherwise visible records. Repairing the trust relationship requires coordinated configuration, not a longer list of unrelated A records.
Protect email records during a website migration
Keep MX records and email authentication policies in the migration inventory even if mail hosting is unchanged. SPF text may reference a sending service; DKIM uses selector-specific names; DMARC is normally published under _dmarc. These records are easy to omit when a new provider offers a simplified import screen.
After the web change, send representative test messages through the actual mail services and inspect the receiving system’s authentication results. A DNS record being present is necessary for some checks, but it does not prove that a sender uses the right domain or signs messages correctly. The email workflow deserves its own verification step.
Frequently asked questions
Should I change nameservers to move a website?
Often you can keep the existing DNS provider and update the relevant web records. Moving nameservers changes who serves the whole zone and creates a broader migration. Choose that larger change only when it is required or intentionally planned. Export the complete zone first and confirm support for the record types and DNSSEC arrangement you already use.
Why does a browser still show the old page after DNS changes?
The browser may have an existing connection, cached content or a service worker serving an earlier application version. The new destination may also be serving old files. Compare the resolved address with the actual response and application version. DNS can be correct while another delivery layer preserves the old page.
Why do public DNS tools disagree?
They may use different recursive resolvers, cached lifetimes or network locations. Authoritative servers can also disagree. Record the name, type, status, answer and time, then investigate whether the disagreement exists at the authoritative source or only in cached responses.
Does clearing my browser cache fix DNS?
Browser content caches and DNS caches are different. Operating systems, browsers, local gateways and recursive resolvers may each retain relevant state. Clearing one layer cannot guarantee that all others have refreshed. Identify the layer involved before treating a cache clear as a diagnosis.
Can a public explorer inspect an internal company hostname?
It normally sees the public resolver’s view, which may differ from private or split-horizon DNS. Use the resolver and network context required by the internal service. Do not publish confidential internal names merely to compare them with a public lookup.
What evidence should I keep before changing records?
Save the authoritative provider, complete relevant record set, original TTLs, planned change and a recovery path. Keep the observed failing response and its timestamp. That record helps distinguish a correction from an accidental change to unrelated website or email services.