The server works, the website does not. Could it be DNS?
Separate DNS failures from application failures and prepare record changes without avoidable downtime.
You can log in to the server, the application is running and resources look normal. Visitors still cannot open the website. DNS sits between a domain name and the service, telling clients where to connect. Its failure can resemble a server outage even when the server itself is not the problem.
Check responses from different locations
Inspect A and AAAA records and any CNAME chain. Compare your resolver's answer with the authoritative DNS response. Differences may come from caching or a change that has not reached every client. Record the response type, addresses and TTL rather than just “working” or “broken”.
Do not overlook IPv6. A stale AAAA record can send some visitors to the wrong server while IPv4 works. Differences between networks do not automatically prove a fault on the customer's device.
Separate name resolution from HTTPS
Once the domain returns the expected IP address, check the connection, certificate and HTTP response. Opening the IP directly in a browser is not a reliable test: virtual hosting and TLS need the correct hostname. A diagnostic test should preserve the hostname while deliberately overriding the connection address.
Prepare TTL changes before a migration
TTL influences how long a response can remain cached. Lowering it at the exact moment of migration leaves older answers cached under their previous value. Prepare the change in advance and keep the old server available during the transition. Even a low TTL does not guarantee an immediate, uniform update for all clients.
Before switching, test the new server with the right hostname, certificate and application configuration. Prepare a rollback and remember related services. Changing nameservers or mail records has a different scope from replacing one website address.
Monitor the domain and DNSSEC too
Domain validity, nameserver delegation and DNSSEC can disrupt availability independently of the application. A mismatch between the DS record and zone signing can cause errors for validating resolvers. When changing DNS providers, check the complete procedure; disabling DNSSEC blindly is not a universal fix.
- Do authoritative nameservers respond?
- Are A, AAAA and CNAME records correct?
- Is the domain valid and its delegation correct?
- Does HTTPS work after name resolution succeeds?
What to take away
DNS checks and HTTP monitoring examine different stages of the same journey. Use them together and troubleshoot from name resolution through to the application's actual response.
