What is DNS and why a site does not open without it

When DNS breaks, the site looks dead

You can have a live server, a working site, and even a valid SSL certificate, and the domain still will not open. Very often the problem is not the site. It is DNS — the part of the internet that says, “this readable name actually leads to this IP address.”

Think of a house sign. People see the street name, not the coordinates of the foundation. DNS does the same for websites: it turns a domain name into an IP address.

Problem / Context

When something “does not open,” people often look at the server, hosting, or app code first. But the path is longer:

1. you type a domain name;
2. your device asks a recursive resolver;
3. that resolver queries a nameserver;
4. the server returns a DNS record;
5. the answer is stored in the DNS cache for a while;
6. the client connects to the final IP address.

If one step points the wrong way, the site looks dead. In reality it is just getting lost on the way.

Why it matters

DNS affects more than web pages. It also controls:

• websites and subdomains;
• mail delivery;
• domain verification;
• moving a site to new hosting;
• load balancing across servers;
• quick releases without changing code.

The tricky part is that a change can be correct and still not reach everyone right away because of TTL. You may have already fixed everything, while an old record is still sitting in other caches.

How it works in simple terms

DNS has a few basic roles.

A nameserver stores the records for the domain.
A recursive resolver looks up the answer for your machine.
A DNS record tells the system where the domain should go.

The most common records are:

• A record — points to an IPv4 address.
• AAAA record — points to an IPv6 address.
• CNAME record — makes one name an alias of another.

Put simply: A and AAAA point to a server, while CNAME points to another name that will then resolve to an address.

How to check DNS

Start with verification, not panic.

1. See what the internet sees right now

dig example.com NS
dig example.com A
dig example.com AAAA
dig example.com CNAME

If you want a shorter view:

dig +short example.com

What to look for in the output:

• whether a record exists at all;
• whether the IP address is correct;
• whether an old CNAME is still there;
• whether the nameservers are correct;
• what TTL is shown.

If there is no answer, the domain may simply be misconfigured or not yet updated.

2. Compare it with what should happen

Ask one simple question: where should the domain point right now?

• a new server?
• a different hosting provider?
• a separate subdomain?

For the main domain, A and AAAA are usually used. For separate subdomains, CNAME is often convenient.

3. Do not change everything at once

If you are moving a site, change one layer at a time:

1. prepare the new server;
2. add the correct records;
3. verify them with dig;
4. only then remove the old ones.

That way you do not create a “dark window” where the old setup is gone and the new one is not ready yet.

4. Remember TTL

TTL is the lifetime of a cached record. A larger TTL means changes spread more slowly. A smaller TTL means faster updates, but with more DNS traffic.

After a record change, this can happen:

• it is already correct for you;
• someone else still has the old record;
• someone else already has the new one;
• someone’s cache is stubbornly living in the past.

So sometimes you simply need to wait for TTL to expire.

5. Flush the local cache if needed

Sometimes the problem is not the server. It is the local cache. For a quick check:

Linux:

resolvectl flush-caches

macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Windows:

ipconfig /flushdns

After that, test again with dig or open the site from another network.

Common breakage scenarios

The site moved, but DNS stayed old

The most common story. The server is new, but the domain still points to the old address. The result: the site does not open, or it opens an old version.

You added A, but forgot AAAA

If your setup has IPv6 routing, some users may reach you through it. If AAAA points to the wrong place, part of the audience sees a problem and part does not. That makes the issue feel random, which is annoying in all the wrong ways.

CNAME and A on the same name

For one name, it is usually better not to mix CNAME with other record types. Otherwise behavior gets strange and debugging gets worse.

DNS changed, but cache was forgotten

You already see the new address in the control panel, while users still see the old one for another hour or two. That is not magic. That is cache.

Wrong nameservers

Sometimes the domain itself is registered correctly, but the registrar points to the wrong nameservers. Then you can edit records all day and the outside world still will not see them.

Anti-patterns

• changing records by guesswork;
• deleting old records before the new ones are verified;
• forgetting about TTL;
• checking A and AAAA only partially;
• mixing up domain, subdomain, and server;
• making a decision two minutes after the change;
• moving a site and mail as one giant messy bundle.

Conclusion / action plan

DNS is not “just another technical detail.” It is the address book of the internet. If it points to the wrong place, the site will not open even if the server is healthy.

Whenever DNS is suspected, do this:

1. check NS, A, AAAA, and CNAME;
2. compare them with the expected IP address;
3. look at TTL;
4. wait for caches or flush the local cache;
5. test again from another network.

In short: first check where the domain points, then check whether it should point there, and only then change something. That saves more nerves than any “just restart everything again” ritual.