What to do if the site stopped opening after changing DNS
What to do if the site stopped opening after changing DNS
Changing DNS is a tricky thing. The site seems to have been transferred, but the browser is empty, shows an error, or the old address. And then panic begins: hosting is blamed first, then the registrar, then oneself.
What is needed 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 on the site itself. If you need to understand what to do if the site 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 site was accessible before the DNS change and stopped working after 5 minutes, that is not proof yet. The timing coincidence is misleading.
Check how the site behaves with different symptoms: does not open at all, redirects to another domain, shows an SSL error, or just keeps loading. These are already 4 different scenarios, each with its own source. Sometimes the problem looks like a DNS issue, but in reality, the redirect to https is broken or the certificate has expired.
There is a simple test: try to open the site via its direct IP, if you know it, or through another communication channel where the old address is already saved. If the server responds to the IP but not to the domain, DNS is indeed on the list of suspects. If it doesn't respond to anything, then it's not about DNS, but about the server, virtual host, or the platform itself.
Check external factors as well. For example, if the site recently changed SSL or redirects, the browser may show a completely different error than you expect. It's useful to look not at guesses but at the exact message. One error message can sometimes save 30 minutes of unnecessary searching.
Match the new DNS with what should be opening
After changing the DNS, open the record list and compare it with what actually needs to be opened. For the root domain, an A record is usually checked, for IPv6 - AAAA, and for a subdomain, a CNAME is often needed. An error in a single 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 lead to one host, while without www — to another. And if one of the points points to an old server, users will see different results depending on how they enter the address.
It helps to check against the migration plan. If you moved the site, the new DNS should point to the address where the site is already hosted, 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 connection 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 the CNAME or an IP from a foreign network — and the site stops opening only for some requests.
Check if the transition to the new DNS provider is broken
When a domain is transferred to a new DNS provider, it is necessary 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 nice in the panel, but the old configuration still lives on the internet.
Check if the NS at the registrar matches what you entered 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. A 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 see them. Unpleasant, right?
A good way to check is to look at the response to the NS request from several sources. If part of the responses goes to the old provider, the transition is not complete. Here, not just one screenshot is important, but 2-3 independent checks.
Take into account the delay of the update worldwide and for users.
After changing the 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 delay in updates 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 operated 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 mismatched records. This behavior is especially noticeable when changing the A record to another host.
Here a simple discipline helps: do not change the 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's 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 nowhere. For some devices, this is not a minor issue, but a full stop signal. Modern browsers and networks love IPv6, and if it is broken, the site may seem inaccessible even with a working IPv4.
Check both records separately. If the domain is supposed to work only on IPv4, it is better not to accidentally leave AAAA. An empty or old IPv6 address often creates a strange picture: the site opens from one internet, but not from another.
Sometimes it's 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: two records are pointing in different directions.
If you have access to 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. And both should lead to where the site actually responds.
Ensure that the site responds at the destination address
Even the 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 not lost. Sometimes the site is still, but the virtual host is configured for an old name.
If there are several 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 be copied, but the domain name is forgotten.
Check the server 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 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 be opening'.
By the way, if you need a break for entertainment between checks, you can take a look jokes about students. Jokes for free. Short — this is 1–2 minutes, no more. Sometimes such a pause helps not to confuse the old server with the new one.
Check HTTPS and certificate after changing the record
DNS may already be pointing 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 story after moving to a new IP.
Check if the certificate was issued for this domain and subdomain. If the new address leads to a server where the certificate is issued for a different name, the browser will not allow the user to proceed. Neither cache nor reload will help here.
HSTS adds rigidity. If the site previously operated over HTTPS and a rule is pinned in the browser, attempting 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 — redirect from http to https. If it points to an 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 how to check a website for fraud. Sometimes people mistake a certificate error for an attempt at substitution, although it is simply a mismatch of records and domain.
Prepare what to send to hosting or DNS support
When your checks are done, 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 your DNS provider, please specify who had the domain before and who has it now. Sometimes help depends on the fact that the zone is already delegated, but the old server still responds in some resolvers. The more accurately you describe the route, the fewer loops the response will have.
It's good practice to immediately attach the results of checks from 2-3 sources, rather than just one screenshot from the browser. It's easier for support to see where the discrepancy lies: in the zone, with the registrar, or on the server. And the fewer assumptions, the faster they find the bottleneck.
If you want to clear your head a bit after technical routine, you can distract yourself with the most brutal experiments of psychologists — the material is not simple, but it effectively counters 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 separate the local picture from the overall one. If it's bad locally but fine outside, the problem lies closer to the device or provider.
If you have also changed the structure of the site after the transfer, do not forget about old links. A user may land on a non-existent page and conclude that the domain is completely broken. In practice, only 1 out of 20 paths 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 won't open as it should.
When everything is checked and access is still jumping, record the last 2 changes and do not make new ones until you receive a response from support. Otherwise, you hinder yourself from seeing where exactly the chain broke.
