ERR_NAME_NOT_RESOLVED: what this error means and how to fix it

ERR_NAME_NOT_RESOLVED is one of the most annoying browser errors because it looks like the site is dead, when in fact the server may be alive and kicking. You launch a project, transfer a domain to a new VPS, roll out Ingress in Kubernetes, connect a CDN, or simply want to access the admin panel, when suddenly, instead of the page, you get a response saying that the domain name is not defined.

This error is almost always about DNS, and DNS is a tricky thing because its architecture is distributed, it is cacheable, and the domain name system depends on a bunch of intermediate nodes. Therefore, one user may be able to open the site, while another user may not be able to open it, and a third user may receive an ERR_NAME_NOT_RESOLVED error from their browser.

In this article, we will try to figure out what exactly causes this error, how to quickly understand where the problem lies, with you or in the domain zone, how to diagnose NXDOMAIN/SERVFAIL, and what to do in different scenarios - from simply clearing the cache to checking your domain delegation.

 

 

 

 

The essence of the ERR_NAME_NOT_RESOLVED error

In order to understand what we are talking about, we first need to understand what DNS is and how this service works.

DNS (Domain Name System) is a service that translates human-readable domain names into IP addresses that are understandable to the network. A browser cannot go to a domain on its own; it always connects to a specific IP address. Therefore, when you enter example.comin the browser's address bar, a DNS query is first made - that is, a search for the answer to the question of which IP address corresponds to this domain name. Usually, this answer is taken from the cache (browser/operating system/provider) or requested from a recursive DNS server, which, if necessary, forwards the request to the domain's authoritative DNS servers and receives A/AAAA/CNAME records. In simple terms, the resolution chain can be represented by the following steps:

1. You enter example.comin your browser;
2. The browser checks its cache to see if there is already a saved IP;
3. If there is no record, the request is forwarded to the operating system and its local resolver;
4. If there is no response locally, the request goes to a recursive DNS server (provider, corporate, or public - 8.8.8.8 / 1.1.1.1);
5. If necessary, the recursive server goes through the DNS hierarchy: root servers → zone server (.com) → authoritative NS domain;
6. The authoritative server returns an A/AAAA or CNAME record with an IP address.
7. The browser receives the IP and only then establishes an HTTP/HTTPS connection with the server, specifically using the IP address.

And if the IP cannot be obtained at any of these stages, the browser displays ERR_NAME_NOT_RESOLVED, i.e., your browser simply does not know which server to contact.

 

In practical terms, the problem almost always boils down to one of three options:

• Local problem (cache, DNS provider, VPN, hosts file);
• DNS zone problem (no A/CNAME, incorrect NS, domain not delegated);
• DNS infrastructure problem (authoritative NS not responding, zone not loading, SERVFAIL, etc.).

 

Now that we have identified the root cause of the problem, let's take a closer look at the main reasons.

 

 

 

 

 

Main causes of ERR_NAME_NOT_RESOLVED

Below, we will divide the causes into two groups and explain why this division will be useful to us.

The main mistake in any diagnosis is chaotic behavior, such as immediately trying to access the domain control panel, even though the problem is local, or, conversely, trying to clear the cache when the domain is not delegated, or perhaps does not even exist. That is why we must divide the possible problems into the following groups.

 

Problems on the user's side (local)

The most obvious signs that the problem is on the user's side may be:

• The site does not open for one person on their computer, but opens for others;
• The site opens fine on a phone, but does not work on a laptop;
• The site does not work only through VPN, but works normally;
• The problem appeared suddenly, although no changes were made to the domain.

 

Typical causes in such cases may be as follows:

• DNS cache, when the browser, OS, or home router remembered old responses, but the domain has since been changed;
• The provider's DNS is down or for some reason is blocking certain domains (possibly blocking);
• An enabled VPN replaces the resolver with its own, thereby breaking the resolution chain;
• For Linux users - when there are outdated or blocking entries in the /etc/hosts file;
• The corporate network uses internal DNS and does not resolve external (or vice versa).

 

 

Problems on the domain/hosting side (DNS zone, delegation)

This group almost always manifests itself as follows:

• The domain does not resolve for all or most users;
• The dig command returns NXDOMAIN, SERVFAIL, or an empty ANSWER;
• Changes have been made to the domain zone recently.

 

Typical reasons in this case may be as follows:

• The domain is not delegated to the correct NS;
• There are no A/CNAME records for the domain at all;
• TTL keeps old responses and prevents fast switching;
• The domain has expired or has been blocked by the registrar;
• Authoritative NS do not respond or the zone is not loaded on them;
• Syntax or zone errors on your BIND/PowerDNS.

 

Now that we have figured out the possible causes of the error, we can self-check and quickly find out whose side the problem is on, instead of rushing around trying everything and bothering your provider's support for no reason.

 

Quick diagnosis table

Symptom	What it usually means	What to do first
Works for everyone except you	Local DNS issue, cache, VPN, or hosts file	Try from mobile internet, change DNS to 1.1.1.1 / 8.8.8.8
Doesn’t work for anyone	DNS zone or delegation problem	Run dig example.com and dig NS example.com
Works by IP but not by domain	Missing or incorrect A record	Check A/CNAME record in DNS panel
example.com works but www does not	Missing record for www	Add A/CNAME record for www
After changing records it works intermittently	DNS propagation / caching in progress	Check TTL and wait for caches to expire
Doesn’t work in office but works at home	Corporate DNS or filtering	Check resolvers, split DNS, conditional forwarding

This table will help you quickly decide which direction to dig, which will ultimately save you a lot of time.

 

 

 

ERR_NAME_NOT_RESOLVED diagnostics

Now it's time to move on to practice. Essentially, to locate the problem, you need to answer just three questions:

• Does the domain exist in DNS at all?
• To which NS is it delegated?
• Does A/CNAME return?

 

Let's look at a couple of commands and figure out what exactly to look for in the response.

 

The dig command - checks whether the IP is returned and whether there is an A/AAAA record

The syntax of this command is extremely simple:

dig example.com

 

What to look for:

• status: NOERROR- means that the domain exists, the response is correct, but the A record may be empty if not specified;
• status: NXDOMAIN- the domain does not exist in DNS at all, it is either not delegated, or there is a name or zone error;
• status: SERVFAIL - the server was unable to process the request. This often means that there are problems with authoritative NS, DNSSEC, or unavailability.
• ANSWER SECTION: are there any A/AAAA records?

If the ANSWER section is empty, this is the reason why the IP cannot be found.

 

 

2) Command dig NS - checking delegation

Again, no surprises in the syntax:

dig NS example.com

 

The response should contain NS servers. If there are no NS servers or they are clearly not the ones you expect, the problem may be with the delegation at the registrar of this domain.

The logic is simple:

• the domain is delegated to NS;
• these NS must respond;
• they must have a zone;
• the zone must have records.

 

 

Checking the authoritative response directly

If you know that the domain's NS is ns1.example.net, you can query it directly:

dig @ns1.example.net example.com A

 

 

If the public dig example.com gives strange results, and a direct query to the NS shows different information, this most likely means that somewhere along the way the information was either cached or there is an extra resolver along the way.

 

 

The command dig +trace - where exactly did it break

Type in the command line:

dig +trace example.com

 

This command shows the chain from the root to the authoritative NS. This is the best way to see where exactly the problem occurs, for example, the delegation does not match, the NS does not respond, or the zone does not return a record.

 

 

 

 

DNS propagation and TTL: why it works for some and not for others

One of the most nerve-wracking moments when working with DNS is when, after changing records, the site starts to behave differently. One user sees the new version, another sees the old one, and a third sees an error altogether. From the outside, it looks like chaos or server instability, although most often the cause is simply DNS request caching.

It is important for us to understand that DNS is not updated instantly around the world. It is a distributed system, and changes made to domain data are propagated gradually from one server to the next in the hierarchy, and from there down to others.

There is also a parameter called TTL (Time To Live), which is the lifetime of a DNS record in the cache. Essentially, this is an instruction to the resolver on how many seconds a particular query can be stored without being rechecked.

If the record has a TTL of 3600, this means that the resolver has the right to store the received IP address for one hour and not request it again from the authoritative server. Until the TTL expires, the resolver will continue to return the old response, even if you have already changed the record.

So why does this unstable performance occur? It's simple.

The problem is that caching does not occur in one place. The caching chain includes recursive DNS servers of providers, corporate DNS within companies, etc., right down to the browser's own cache. Each of them can store the old response until the TTL expires, and as a result, some users already receive the new IP, while others still see the old one. And if a mistake was made when changing the record, some resolvers may even temporarily cache a negative response (for example, NXDOMAIN).

From the outside, this looks like website instability, but in fact, it is the normal operation of the caching mechanism, which we have just begun to understand.

 

Practical rule for production projects

If you are planning to migrate your site or change your IP, you should not change the record at the last minute. It is much more correct and safer to reduce the TTL (for example, to 300 seconds) in advance, 24-48 hours in advance. Then the cache will be updated faster, and the switch will be smoother and more predictable.

After the migration is complete, the TTL can be returned to a higher value to reduce the load on the DNS servers.

 

 

 

 

Fixing the ERR_NAME_NOT_RESOLVED error

Now let's get down to specifics - what to do if the error has already occurred. Remember that in this case, it is important not to act chaotically, but based on what we have already learned: first, understand where the problem is, and then fix it at the appropriate level.

As we have already determined, all situations can be divided into two groups: a local problem (for a specific user) and a problem on the domain or DNS zone side. The approach in these cases will be different.

 

If the problem is local

A local problem means that the domain as a whole exists and is accessible to most users, but problems arise on a specific computer or in a specific network. This is the most common scenario after recent DNS changes. What to do in this case?

 

Clearing the DNS cache

The operating system and browser may store old DNS responses. Even if the record has already been updated on the server, the local resolver may continue to use the old IP. Clearing the cache on Windows:

ipconfig /flushdns

 

On Linux (systemd-resolved):

sudo resolvectl flush-caches sudo systemctl restart systemd-resolved

 

If you are using nscd:

sudo systemctl restart nscd

 

After clearing the cache, the system will stop using the outdated IP and request fresh data from the DNS server.

 

 

Checking the hosts file

The hosts file takes precedence over DNS, so if it contains an entry for your domain, the system will not refer to external DNS servers at all.

On Linux/macOS, the file is located at:

/etc/hosts 

 

On Windows:

C:\Windows\System32\drivers\etc\hosts

 

 

Look for lines with your domain and check what is written there. Pay special attention if your domain is next to either an old IP address, the local 127.0.0.1, or even 0.0.0.0.Correct this entry to the valid IP address and restart the system.

 

 

Temporary DNS server change

Sometimes the problem is not with the domain, but with the provider's DNS server. It may cache outdated data or be temporarily unstable.

To check, you can temporarily specify other public DNS servers in your computer's network settings. The most popular public DNS servers are Cloudflare servers - 1.1.1.1 and 1.0.0.1, as well as Google servers - 8.8.8.8 and 8.8.4.4.

This does not mean that public DNS servers are better in any way. In some cases, when such a public server goes down, problems are observed across most of the Internet, since many people use them. No, this is just a way to check, because if everything works with the new DNS, then the problem was on your provider's side.

 

 

Disabling VPN or proxy

VPNs often replace DNS requests and use their own resolvers. This can lead to problems such as:

• inability to resolve a domain;
• use of an outdated cache;
• problems with DNSSEC;
• filtering of certain zones.

Disable your VPN and if the site opens without it, then the problem is in the VPN settings.

 

 

 

If the problem is on the domain side

This scenario is more critical for website owners. After all, if your domain does not resolve globally, users simply cannot access the project. Here you need to check the DNS infrastructure.

 

Checking the domain status

The first thing to do is to make sure that the domain is active and its registration has not expired. If the registration period has expired, the domain may enter a holding or blocking stage, and resolution will be unstable or stop altogether.

The registrar's panel usually shows whether the domain is active, whether it is blocked, and whether delegation is disabled.

 

 

Checking delegation (NS records)

If the domain is delegated to the wrong NS servers, any changes in the correct DNS panel will be meaningless, because the Internet will refer to the registrar's specified location. Therefore, the next step is to check:

• which NS are specified by the registrar;
• whether they match those on which you actually manage the zone.

 

A very common error is when the zone is configured in one panel at one registrar, but the domain is delegated to other NS servers, for example, those that are not related to this registrar at all.

 

 

Checking the availability of authoritative NS

Even if the NS are specified correctly, they must actually respond to requests. Then you should perform a direct check:

dig @ns1.example.net example.com A

 

If the server does not respond or returns an error, then the problem is with the DNS server or the zone configuration.

 

 

Checking the presence and correctness of A/CNAME records

The most trivial but also the most common reason is when the record is simply missing or specified incorrectly.

In your domain control panel, check:

• whether there is an A record for the root domain (@);
• whether there is a record for www, if used;
• whether the record points to an old IP;
• whether an AAAA record (IPv6) has been created if the server does not support IPv6;
• whether there are any conflicts between CNAME and other records.

 

 

And once again, we remind you that when localizing and troubleshooting the ERR_NAME_NOT_RESOLVED problem, you need to proceed in a consistent manner:

• first the local level;
• then delegation;
• then authoritative NS;
• then specific records.

When you follow this chain, the likelihood of quickly finding and correcting the causes of the error increases.

 

 

 

 

Prevention of the ERR_NAME_NOT_RESOLVED error

People usually only think about DNS when something has already broken. But in practice, DNS is your gateway, even the entry point to your project. You can have a perfectly configured server, a fault-tolerant cluster, and a well-designed CI/CD, but if the domain stops resolving, users simply won't be able to access the site.

To avoid such situations, it is enough to implement just a few basic practices.

 

At least two authoritative DNS servers

For a public domain, it is considered normal to have at least two NS servers, preferably in different networks or locations. This is not redundancy for the sake of it, but protection against a situation where one server becomes unavailable.

 

 

Monitoring DNS, not just the website

A common mistake is to monitor only HTTP/HTTPS. But if DNS stops working, the web server simply won't be reached. Therefore, it makes sense to also monitor:

• whether the domain's A record resolves;
• whether wwwresolves;
• whether authoritative NS servers respond.

 

This can be configured in Zabbix, Prometheus (via blackbox_exporter), or any external monitoring service. The main thing is to check the resolution from the outside, from the Internet, and not from your own infrastructure.

 

 

Domain expiration monitoring and auto-renewal

Many sudden crashes are not related to technical problems, but to organizational ones, when the domain has expired, the letter from the registrar went to spam, or the invoice payment did not go through.

The minimum set of measures to exclude these options is:

• enable auto-renewal;
• specify a valid email address for notifications;
• have a backup payment method.

 

It's trivial, but it's often these little things that cause real downtime.

 

 

Plan migrations in advance

If you are planning to change your IP or transfer a project, do not change the record at the last minute. It is better to lower the TTL (for example, to 300 seconds) 1-2 days before the migration, so that the caches will be updated faster and the switch will go much more smoothly.

Once everything has stabilized, you can return the TTL to a higher value.

 

 

Check the zone before publishing

If you manage the zone yourself (for example, through BIND), it is useful to check it before restarting the DNS server:

named-checkzone example.com /etc/bind/zones/db.example.com

 

This way, you can catch syntax errors before they become a problem for users.

 

Ultimately, DNS prevention is not about building complex architecture, but about accuracy and control. When the zone is correct, the servers are reserved, the domain is renewed, and the resolution is monitored, ERR_NAME_NOT_RESOLVED becomes a rare exception rather than a regular headache.

 

 

 

 

FAQ

 

Why does the site open by IP, but not by domain?

Because DNS does not return the IP. The server is alive, but the domain does not point to it (there is no A record or it is incorrect).

 

Can SSL/certificate cause ERR_NAME_NOT_RESOLVED?

No. SSL starts after receiving the IP and establishing a connection. With ERR_NAME_NOT_RESOLVED, SSL does not reach.

 

How long does DNS propagation take?

It depends on TTL and caches. Usually from minutes to days. 48 hours is the upper limit for poorly managed caches, but in practice it usually happens much faster.

 

Could Cloudflare/CDN be the cause?

Yes. Especially with incorrect NS at the registrar, disabled zone, DNSSEC conflict, errors in records within the CDN.

 

Could a firewall cause ERR_NAME_NOT_RESOLVED?

No. A firewall can cause timeouts, connection refusals, and similar issues. ERR_NAME_NOT_RESOLVED occurs earlier, when the IP address has not yet been received.

 

 

 

 

 

Conclusions

The ERR_NAME_NOT_RESOLVED error is not a server crash or a browser issue. It is a stop at the very first stage - the DNS resolution stage. The browser simply did not receive the IP address and therefore cannot start the connection.

In most cases, the reason is quite mundane, such as a missing A record, incorrectly configured delegation, an expired domain, or the cache still holding old data after migration. Less often, there are deeper problems, such as authoritative NS not responding, SERVFAIL occurring, DNSSEC conflicts, split DNS incorrectly configured in the corporate network, or errors in CoreDNS within Kubernetes.

The key to a successful and quick solution is not to guess the reasons, but to take methodical steps according to a simple algorithm. A few simple commands, such as dig with parameters, allow you to quickly understand where the failure occurred, at the cache, resolver, delegation, or zone level. Once the point of failure is found, the error ceases to be a big problem and becomes a routine infrastructure task that needs to be solved.