What Is DNS and Why Your Site Sometimes Won’t Load

October 17, 2026 • NOFYI Editorial Team

You type a familiar website address, press Enter, and instead of the site you expect you see an error: This site cannot be reached, or the browser spins and gives up. The site may be perfectly fine. The problem may be DNS, the system that turns human-friendly domain names into the numbers computers use to find each other.

DNS stands for Domain Name System. It is often called the phone book of the internet, and the comparison is useful if you do not take it too literally. DNS does not store websites. It stores directions. When it works, you never notice it. When it fails, a working site can look broken.

This guide explains DNS in plain language, shows the main record types with a worked example, explains why changes take time to spread, and shows how to tell whether DNS, your connection, or the site itself is at fault. It ends with honest limitations and answers to common questions.

What DNS Actually Does

Computers on the internet find each other using IP addresses, which are numbers such as 93.184.216.34. People find it much easier to remember names such as example.com. DNS bridges that gap. When you type a domain name, your device asks a DNS resolver to look up the matching IP address, then connects to that address.

A simple way to picture it is a chain of q

The Main DNS Record Types You Will Meet

A DNS zone is a set of records for a domain. Each record has a type, a name, a value, and a time-to-live, or TTL. The TTL tells resolvers how long they may cache the answer before asking again. You do not need to memorise every record type, but three are essential for understanding why a site loads or fails.

A Record: Domain to IPv4 Address

An A record maps a domain name to an IPv4 address. For example, an A record for example.com might point to 93.184.216.34. When a browser looks up example.com, this is often the answer it needs. If the A record is missing, wrong, or points to a server that no longer hosts the site, the browser cannot reach the site, even if the domain itself is registered and paid for.

AAAA Record: Domain to IPv6 Address

An AAAA record does the same job for IPv6

How to Tell If DNS Is the Problem

When a site will not load, work through these checks in order. They help you separate a DNS problem from a broken site or a broken connection.

Check whether the problem affects one site or every site. If every site fails, the issue is more likely your connection, router, or DNS resolver settings than one site DNS records.
Try the site on another device on the same network, and then on mobile data. If it loads on mobile data but not on your home Wi-Fi, your home network or its DNS settings are a likely suspect.
Try both the plain domain and the www version, for example example.com and www.example.com. If one works and the other does not, a missing or wrong record for one of those names is a common cause.
Clear your browser cache and try again, or try a private window. A stale browser cache can keep showing an old error even after DNS has been fixed.
Flush your local DNS cache if you are comfortable doing so, or restart your device. Local caches can hold an old answer until it expires.
Ask a friend in another city or use a public DNS checker to see what the domain resolves to elsewhere. If it resolves correctly for others but not for you, the problem may be your resolver cache or network.

Do not change DNS records for a live site unless you understand the change and h

Limitations

DNS explains many loading failures, but it has limits that are worth stating plainly.

DNS only answers where to go. It does not guarantee that the destination server is running, fast, or secure.
Public checkers show what their resolvers see. Your network may see a different cached answer for a time.
TTL is a maximum, not a promise. Some resolvers ignore very short TTLs or hold answers longer than expected.
Changing DNS can affect email, verification, and subdomains. A change meant for the website can break another service that shares the same zone.
A correct DNS answer does not mean a site is trustworthy. Phishing sites can have perfectly valid DNS records.
Local problems can mimic DNS problems. A firewall, VPN, parental control, or hosts file entry can block a site even when public DNS is correct.

Because of these limits, use DNS checks as one step in a wider diagnosis. Confirm the lookup, confirm the server response, and confirm the result from more than one network before you change anything important.

Frequently Asked Questions

How long does DNS propagation take?

It depends on TTL and caching. Many changes spread within minutes to a few hours. Some can take up to 24 to 48 hours to reach every resolver, especially if the old TTL was long. Lowering the TTL before a planned change can shorten the wait, but it cannot make propagation instant.

Is DNS the same as web hosting?

No. DNS provides directions to a server. Hosting provides the server and the website files. A site needs both to work. If DNS points to the wrong server, visitors cannot reach correct hosting. If hosting is down, correct DNS still leads visitors to a server that cannot respond.

Why does a site load on my phone but not on my computer?

The two devices may use different DNS resolvers, different caches, or different networks. Your phone on mobile data may have a fresh answer, while your computer holds an old cached answer. Clearing the browser cache, restarting the device, or waiting for the TTL to expire often resolves the mismatch.

Can I fix DNS by changing my DNS resolver?

Sometimes. If your current resolver has a stale or broken answer, switching to a different reputable resolver can give you a fresh answer. This helps for your own device only. It does not fix the authoritative records for a site you own. Site owners must fix the records at the authoritative DNS provider.

Conclusion

DNS turns domain names into IP addresses so browsers can find the right server. A records point a domain to an IPv4 address, CNAME records point one name to another, and MX records direct email. When a site will not load, DNS is a common cause, but it is not the only cause. Propagation and cache explain why fixes can work in one place and fail in another.

The practical habit is simple. Check whether the problem affects one site or all sites, compare the answer from more than one network, and remember that DNS is not hosting. When you can name the layer that is broken, you can fix it faster and avoid changing settings that were never the problem.

Before a planned change, many site owners lower the TTL a day or two in advance, so that when the real change happens, old answers expire quickly. After the change has settled, they raise the TTL again. This is a common, careful pattern. It does not make propagation instant, but it reduces the window during which visitors see mixed results.

Cache also exists at other layers. Your browser may cache a DNS answer or an error page. Your operating system may cache lookups. Your router may cache them. A public resolver may cache them. When you test a fix, clear the layers you control and test from a second network. If you only test from one device, you may conclude a fix failed when it has actually worked elsewhere.

DNS Is Not Hosting, and Hosting Is Not DNS

This distinction deserves its own section because it causes so many misunderstandings. Your registrar is the company that manages your domain registration. Your DNS provider holds your DNS records. Your host stores your website files. In many setups, one company provides all three services, but the roles remain separate.

If your hosting account is suspended, your DNS records may still point correctly, yet the site will not load because the server has no working files to serve. If your DNS records are wrong, your hosting may be perfect, yet no visitor can find the server. If your domain registration expires, both can appear broken, because the domain itself stops resolving.

When you ask for help, say which layer you have checked. For example: The domain resolves to the correct IP address, but the server returns an error. That sentence tells a support team that DNS is probably fine and hosting is the next place to look. By contrast: The domain does not resolve to any address at all, even from a public checker. That points to DNS. Clear language saves hours.

When you save the A record, the change does not instantly reach everyone. Some resolvers already have an old answer cached and will keep using it until the TTL expires. Others will fetch the new answer right away. This is propagation, and it explains why a fix can work for one person and fail for another in the same hour.

To test the example, you can use a public DNS lookup tool. Enter example.com, choose A, and check the answer from several locations. In this teaching example, the expected answer is 93.184.216.34. If a tool shows a different address, that tool may be reading a cached answer, the domain may have changed, or you may have typed a different name. In a real site migration, you would compare the answers across locations and wait for the old TTL to expire before declaring the change complete.

Next, imagine you change the A record to a new server because you moved hosts. You update the record, but your own computer still shows the old site. The cause is often cache at one of three levels: your browser cache, your device DNS cache, or your resolver cache. Clearing the browser cache, restarting the device, or waiting for the TTL to expire usually resolves it. Testing on mobile data, which often uses a different resolver, can confirm whether the new record has propagated elsewhere.

Finally, add email to the example. You set an MX record that points to your email provider mail server. Website visitors still reach 93.184.216.34, while mail servers use the MX record to deliver mail. If you later change hosting providers and accidentally delete the MX record, your site may keep loading while email stops. That separation is normal, and it is why DNS changes need a checklist that covers web and mail separately.

Propagation and Cache: Why Changes Take Time

Propagation is not a single switch. It is the gradual replacement of old cached answers with new ones across many resolvers. The main factor is TTL. A record with a TTL of 3600 seconds may be cached for up to an hour. A record with a TTL of 300 seconds may be cached for up to five minutes. Shorter TTLs make changes faster but increase lookup traffic. Longer TTLs reduce traffic but make changes slower.

ave noted the old values. A small typo in an A record can take a site offline. If you manage a site, make changes during a quiet period, keep a copy of the old records, and check the site from more than one network after the change.

Worked Example: example.com to 93.184.216.34

Let us trace a well-known documentation example. The domain example.com is reserved for documentation, and its IPv4 address in many teaching examples is 93.184.216.34. This is a useful example because the numbers are stable and public, and they show the lookup pattern without exposing a real private site.

Imagine you are setting up a small site and you want visitors to reach it when they type example.com. In your DNS panel, you create an A record with the name @ or example.com, depending on how the panel labels the root, and the value 93.184.216.34. You set a TTL of 3600 seconds, which means resolvers may cache the answer for up to one hour. You also create a CNAME record for www that points to example.com, so that www.example.com follows the same address.

addresses. Many sites now publish both A and AAAA records so that visitors on IPv4 and IPv6 networks can both connect. If one is wrong, some visitors may have trouble while others load the site normally, which can make the problem look inconsistent.

CNAME Record: One Name Points to Another Name

A CNAME record maps one name to another name, rather than directly to an IP address. For example, www.example.com might be a CNAME that points to example.com. The resolver then looks up example.com to find the IP address. CNAMEs are useful because they let you change the target in one place. They can also cause confusion if they point to a name that no longer exists or that points in a circle.

MX Record: Where Email Should Go

An MX record tells mail servers which server should receive email for a domain. This record does not affect whether the website loads, but it is easy to break by accident when you change DNS providers. A site can load perfectly while email stops working, or email can work while the site fails, because web and mail use different records. When you change DNS settings, check MX records separately before you assume email is safe.

Other common records include TXT records, which hold verification and policy text, and NS records, which say which name servers are authoritative for the domain. You may also see SOA records and CAA records in advanced setups. For most troubleshooting, A, AAAA, CNAME, and MX explain the majority of cases.

uestions. Your browser asks your device, your device asks the resolver set by your network or ISP, and that resolver asks other DNS servers until it finds an authoritative answer for the domain. The answer is then sent back down the chain, and your browser can connect. The whole lookup usually takes a fraction of a second.

DNS is not hosting. Hosting is where the website files live. DNS is the signpost that points visitors to the right server. A site can have perfect hosting and still fail to load if its DNS records point to the wrong place, are missing, or have not yet spread across the internet. Conversely, DNS can point correctly to a server that is itself down, and the site will still fail. Knowing which layer is broken saves a lot of wasted effort.