What Is DNS?

The basic idea

Every device connected to the internet has an IP address — a numerical label that identifies it on the network. Humans are bad at remembering long strings of numbers, so the Domain Name System was created to bridge the gap. DNS maps friendly domain names like github.com to the IP addresses that servers actually use to route traffic.

Think of it like a phonebook: you know a person's name, you look them up, and you get their number. With DNS, your browser knows the domain name, it looks it up, and it gets the IP address it needs to open a connection.

How a DNS lookup works

When you type a URL into your browser, a lookup happens in milliseconds:

1. 1Browser cache: Your browser checks whether it already has the IP address stored locally from a recent visit.
2. 2Operating system cache: If not cached in the browser, the OS checks its own DNS cache.
3. 3Recursive resolver: Your ISP (or a public resolver like 1.1.1.1) receives the query and does the heavy lifting on your behalf.
4. 4Root nameservers: The resolver asks the root nameservers which authoritative server is responsible for the top-level domain (e.g. .com).
5. 5Authoritative nameserver: The resolver queries the authoritative DNS server for the domain, which returns the actual IP address.
6. 6Connection: Your browser receives the IP address and opens a connection to the web server.

DNS record types

DNS isn't just one record — it's a set of different record types, each serving a different purpose:

What happens when DNS fails

DNS failures are a surprisingly common cause of websites appearing "down" even though the web server is perfectly healthy. If a DNS record is misconfigured, expired, or the DNS provider is experiencing an outage, browsers simply cannot resolve the domain to an IP address — and the site becomes unreachable.

The error you'll typically see in your browser is DNS_PROBE_FINISHED_NXDOMAIN (Chrome) or "Server Not Found" (Firefox). These errors mean the DNS lookup returned no result — either because the domain doesn't exist, the record has expired, or the resolver can't reach the authoritative nameserver.

DNS propagation and TTL

Every DNS record has a TTL (Time To Live) value — a number in seconds that tells resolvers how long to cache the result before looking it up again. A TTL of 3600 means the record is cached for one hour. When a website changes its IP address (e.g. moving to a new server), the old cached records may keep users pointing at the old IP until the TTL expires. This is why DNS changes can take minutes to hours to take effect globally — a process called DNS propagation.

Why caching makes DNS feel instant (and sometimes confusing)

A full lookup from the root servers down to the authoritative server can take 50 to 200 milliseconds. That doesn't sound like much, but a single modern web page can pull assets from a dozen different hostnames. If every one of them needed a fresh lookup, pages would feel sluggish. Caching at every layer is what keeps it fast. Most of the time your resolver already knows the answer, and you get it back in a couple of milliseconds.

The flip side is that caches can hold on to stale answers. If you've ever changed a record, refreshed the page and still landed on the old server, that's caching at work. Your browser, your operating system, your router and your ISP's resolver can each keep their own copy. Clearing the browser cache alone often isn't enough. On Windows, ipconfig /flushdns clears the system cache. On macOS it's sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

Choosing a resolver: ISP vs public DNS

By default your device uses whatever resolver your ISP hands out. Those are usually fine, but they're not always the fastest, and some ISPs have a habit of redirecting failed lookups to their own search pages. Public resolvers like Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9) are popular alternatives. Quad9 also blocks domains known to host malware.

Switching resolvers is a handy troubleshooting trick. If a site won't load on your ISP's DNS but works fine after you switch to 1.1.1.1, the problem is almost certainly a bad or stale record at your ISP, not the website itself.

Real-world DNS outages

DNS problems rarely stay small. In October 2016 a large botnet flooded Dyn, a major DNS provider, with traffic. Twitter, Netflix, Reddit and GitHub became unreachable across large parts of the US and Europe, even though their own servers were running normally. People simply couldn't find them.

In October 2021, Facebook, Instagram and WhatsApp disappeared for roughly six hours. A routing change withdrew the paths to Facebook's own DNS servers, so the rest of the internet had no way of looking up their domains. Engineers reportedly struggled to get into the buildings, because the internal tools they needed also depended on the same DNS.

The lesson for site owners is simple: DNS is a single point of failure unless you plan around it. Larger companies often use two separate DNS providers so that one going down doesn't take everything with it.

Common mistakes site owners make

• Letting the domain expire. It happens to big companies too. When the registration lapses, the nameservers stop answering and the whole site, including email, goes dark.
• Putting a CNAME on the root domain. The DNS standard doesn't allow a CNAME at example.com alongside other records. Many providers offer "ALIAS" or "CNAME flattening" to get around this.
• Forgetting to lower the TTL before a migration. If your TTL is 24 hours and you move servers, some visitors can be stuck on the old IP for a full day. Lowering it to 300 seconds a day or two ahead makes the switch much smoother.
• Editing records at the wrong provider. If your nameservers point to Cloudflare, changes made at your registrar won't do anything. Check the NS records first.
• Breaking email by accident. Deleting an MX or SPF record while cleaning up can quietly stop email from arriving, and you may not notice for days.

DNS and security

Classic DNS was designed in the 1980s and sends queries in plain text. Anyone on the same network, like a coffee shop Wi-Fi operator, can see which domains you look up. Newer options such as DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt those queries. Most modern browsers support DoH, and you can usually turn it on in the privacy settings.

There's also DNSSEC, which adds cryptographic signatures to records. It doesn't hide your queries, but it lets a resolver verify that an answer really came from the domain owner and wasn't tampered with along the way. That protects against attacks like cache poisoning, where a resolver is tricked into storing a fake IP address for a real domain.

How to check if DNS is the problem

When a site won't load, a few quick checks will tell you whether DNS is to blame:

1. Run a DNS lookup on the domain. If you get no A or AAAA record back, the site can't be reached by name.
2. Try the lookup from your terminal with nslookup example.com 1.1.1.1. If a public resolver returns an answer but your default one doesn't, your local resolver is the issue.
3. Use a DNS propagation check to see whether resolvers around the world agree. Mixed answers usually mean a recent change is still rolling out.
4. If DNS resolves fine, the problem is further along the chain. Try a ping test or check the current outages page.