What to do if the site stopped opening after changing DNS
What to do if the site stopped opening after changing DNS
» What to do if the website stopped opening after changing DNS
Changing DNS is a tricky thing. The website seems to have been transferred, but the browser shows a blank page, an error, or the old address. And then the panic begins: the hosting is blamed first, then the registrar, and then oneself.
What you need is not noise, but a step-by-step check. Often the problem lies in a single record, one NS, or in the provider's cache, rather than in the website itself. If you need to understand what to do if the website stopped opening after changing DNS, start with the fact: what exactly was changed and at what minute it was done.
Check if the problem is indeed related to DNS
First, separate the DNS effect from everything else. If the website was opening before the DNS change and stopped 5 minutes later, that’s not proof yet. The timing coincidence can be misleading.
Look at how the website behaves with different symptoms: not opening at all, redirecting to another domain, showing an SSL error, or just spinning the loading icon. These are already 4 different scenarios, each with its own source. Sometimes the problem looks like DNS, but in reality, the redirect to https is broken or the certificate has expired.
There is a simple test: try to open the website via direct IP, if you know it, or through another connection where the old address is already saved. If the server responds via IP but not via the domain, DNS is indeed on the list of suspects. If it doesn't respond at all, then it's not about DNS, but about the server, virtual host, or the platform itself.
Match the new DNS with what should be opened
After changing the DNS, open the record list and compare it with what actually needs to be opened. For the root domain, the A record is usually checked, for IPv6 — AAAA, and for subdomains, a CNAME is often needed. A mistake in one letter turns a normal site into a dead end.
You need to look not only at the domain itself but also at the subdomain. For example, www may point to one host, while without www — to another. If one of the points points to an old server, users will see different results depending on how they enter the address.
Cross-checking with the migration plan helps a lot. If you moved the site, the new DNS should point to the address where the site is already up, not to an empty test site. The mistake here is often simple: the record was created, but the target was left old.
If you need to check the linkage deeper, compare the current values with what should be according to the task. Three things are important here: the record name, the record type, and the destination address. One extra character in a CNAME or an IP from a foreign network — and the site stops opening for only part of the requests.
Check if the transition to the new DNS provider is broken
When a domain is transferred to a new DNS provider, you need to ensure that the delegation has been completed fully. The domain should have the correct NS records, and the zone should actually be served by the new server. Otherwise, everything looks good in the panel, but the old configuration still lives on the internet.
Check if the NS records at the registrar match what you specified with the new provider. If there is still one old address left, the domain may behave unpredictably. This is especially noticeable when the record was changed at night, and in the morning the site is already 'sometimes opening, sometimes not'.
Another common trap is that the zone is created but not active. The new DNS provider may accept the domain in the panel but not serve the records. In this case, you see the settings, but the outside world does not. Unpleasant, right?
A good way to check is to look at the response to the NS query from several sources. If some of the responses go to the old provider, the transition is not complete. And here, one screenshot is not enough; 2-3 independent checks are important.
Take into account the update delay around the world and for users.
After changing DNS, some people will see the new address, while others will see the old one. This is normal. The provider, router, and device have a cache, and it does not reset at your request.
The update delay around the world can vary, so do not draw conclusions based on one phone or one office. Check the site through home internet, mobile network, and at least one external tool. When different points show different results, it is almost always a cache issue, not a site malfunction.
If the domain recently lived on old settings, some resolvers will still remember them. Then one user sees the new server, another sees the old one, and a third gets an error due to record mismatch. This behavior is especially noticeable when changing the A record to another host.
A simple discipline helps here: do not change DNS back and forth 5 times in a row. Each new edit disrupts the picture more, and then no one understands which record is the latest. It is better to fix one change and wait than to jump between three options.
Check for conflict between IPv4 and IPv6
Sometimes the A record is already correct, while the AAAA points to nowhere. For some devices, this is not a minor issue, but a full stop signal. Modern browsers and networks favor IPv6, and if it is broken, the site may appear inaccessible even with a working IPv4.
Check both records separately. If the domain is supposed to work only on IPv4, it's better not to accidentally leave an AAAA record. An empty or old IPv6 address often creates a strange picture: the site opens from one internet, but not from another.
It can be the other way around. IPv6 is already up, but the A record points to an old server. Then some users access without problems, while others experience a timeout. Externally, it looks like chaos, but the reason is usually the same: the two records point in different directions.
If you have access to the DNS settings, compare both addresses with the working site's address. There's no need to guess here. You need 2 numbers: IPv4 and IPv6. Both should lead to where the site actually responds.
Ensure that the site responds at the destination address
Even perfect DNS won't help if the server on the other side is silent. After changing the record, you need to check if the host is alive, if the web server is up, and if the binding to the required domain is intact. Sometimes the site is in place, but the virtual host is configured for an old name.
If there are multiple sites on the server, the correct virtual host solves everything. The same IP can serve 10 domains, and without precise binding, the server will deliver the wrong project or an error. This is especially noticeable after migrating to a new platform, when the config seems to have been copied, but the domain name was forgotten.
Check the server's response itself: 200, 301, 302, 404, or 500. These codes say more than any chat with support. If a 404 comes at the destination address, it means the DNS has already reached, but the site on the host does not match expectations.
Sometimes it's useful to open not the main page, but a specific path, for example /login or /admin. This way you can see if the site works as a whole or just the start page. When it comes to migration, a small check is better than a big overconfident 'it seems to open'.
By the way, if you need a fun break between checks, you can take a look at jokes about students. Jokes for free. Short ones — it's 1-2 minutes, no more. Sometimes such a break helps not to confuse the old server with the new one.
Check HTTPS and the certificate after changing the record
DNS may already point to the correct host, but the browser still complains about HTTPS. Then the problem lies in the certificate, HSTS, or redirect. This is a very common issue after migrating to a new IP.
Check if the certificate is issued specifically for this domain and subdomain. If the new address points to a server where the certificate is issued for a different name, the browser will not let the user proceed. And neither cache nor restart will help here.
HSTS adds rigidity. If the site previously worked over HTTPS and a rule is pinned in the browser, trying to open it with an old or incorrect configuration will lead to an immediate block. This is not a browser bug, but its memory, and it lasts longer than one would like.
Another small detail is the redirect from http to https. If it points to the old domain, the new DNS looks correct, but the site still goes the wrong way. Check the final address after the redirect, not just the starting point.
If after all the steps it is still unclear whether the site is accessible to others, it makes sense to check the issue against the material. on how to check a site for fraudSometimes people mistake a certificate error for an attempt at substitution, although it is just a mismatch of records and domain.
Prepare what to pass to hosting or DNS support.
When your checks are complete, gather a short package for support. You need the domain, new NS, exact time of change, a screenshot of the error, and a list of what has already been checked. These are 5 points, and they save more time than a long letter saying 'nothing is working'.
Don't forget to specify from which device and network the problem is visible. For support, this is not a formality, but a useful detail: the same domain may open from a mobile network and fail from home. It is also helpful to attach the current A, AAAA, and CNAME records if they have changed.
If you changed the DNS provider, mention who had the domain before and who has it now. Sometimes help hinges on the fact that the zone is already delegated, but the old server still responds in part to resolvers. The more accurately you describe the route, the fewer loops the response will have.
Good practice is to immediately attach the results of checks from 2-3 sources, rather than just one screenshot from the browser. It is easier for support to see where the picture diverges: in the zone, at the registrar, or on the server. And the fewer assumptions, the faster they find the bottleneck.
If you want to lighten your mind a bit after technical routine, you can distract yourself with the most brutal experiments of psychologists. — the material is not simple, but it effectively dispels the feeling that one broken DNS is holding the world in place. Then you can return to the logs and NS records.
What else to check if the problem is intermittent
If the site opens only for some users, look not at one factor, but at a combination of 3 things: DNS, cache, and server. When all three are out of sync, the symptoms change every hour. This is exactly the case when the same domain behaves differently in the morning and in the evening.
Sometimes checking through an external resolving service and a separate test in a browser without saved data helps. Not because it's magic, but because you are separating the local picture from the overall one. If it’s bad locally but fine externally, the problem lies closer to the device or provider.
If after the migration you also changed the site structure, don’t forget about old links. A user may land on a non-existent page and decide that the domain is completely broken. In practice, only 1 out of 20 paths usually breaks.
And yes, sometimes it’s useful to look at the problem as a chain. DNS leads to the server, the server delivers the site, the certificate confirms the domain, and the browser decides whether to let the user in or not. If one of the 4 elements is missing, the site will not open as it should.
When everything is checked and access is still jumping, document the last 2 changes and do not make new ones until you get a response from support. Otherwise, you hinder yourself from seeing where exactly the chain broke.
