What Is DNS? How the Domain Name System Works

DNS (Domain Name System) is often called the "phonebook of the internet." It translates human-readable domain names like google.com into machine-readable IP addresses like 142.250.80.46. Without DNS, you would need to memorize numerical IP addresses for every website you visit.

DNS is a distributed, hierarchical system — there is no single DNS server that stores every domain name. Instead, the workload is distributed across millions of servers worldwide, each responsible for a portion of the namespace. This makes DNS incredibly resilient and fast.

When you type a URL into your browser, here is exactly what happens:

1. Browser cache check: Your browser first checks its own cache to see if it recently looked up this domain. If found, it uses the cached IP immediately.
2. OS cache check: If not in the browser cache, the request goes to your operating system's DNS resolver cache.
3. Recursive resolver: If not cached locally, the query is sent to a recursive DNS resolver (usually operated by your ISP, or a public resolver like 8.8.8.8 or 1.1.1.1).
4. Root nameserver: The recursive resolver queries one of the 13 root nameserver clusters. The root server doesn't know the IP, but it knows which TLD nameserver handles .com, .org, .net, etc.
5. TLD nameserver: The TLD (Top-Level Domain) nameserver for .com directs the resolver to the authoritative nameserver for the specific domain.
6. Authoritative nameserver: This server holds the actual DNS records for the domain and returns the IP address.
7. Response returned: The IP travels back through the chain to your browser, which opens a connection to the web server.

This entire process typically completes in under 100 milliseconds. Each server along the way caches the result according to the record's TTL (Time to Live), so subsequent lookups are much faster.

DNS is organized in a tree-like hierarchy:

Root zone (.): The top of the DNS hierarchy. There are 13 root nameserver addresses (labeled A through M), operated by organizations including ICANN, Verisign, NASA, and the US Department of Defense. In reality, there are hundreds of physical servers behind these 13 addresses, distributed globally via anycast.

Top-Level Domains (TLDs): These sit directly below the root — examples include .com, .org, .net, .uk, .io, and newer ones like .dev, .app, and .blog. Each TLD is managed by a registry organization (e.g., Verisign manages .com).

Second-level domains: These are the domains people register — like google.com, github.com, or lookmyip.com.

Subdomains: Created by the domain owner — like mail.google.com, blog.example.com, or api.lookmyip.com. Subdomains can be nested multiple levels deep.

Recursive resolvers: These do the heavy lifting. When they receive a query, they chase it through the DNS hierarchy until they get an answer. Your ISP runs recursive resolvers, and public ones include Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222).

Authoritative nameservers: These are the definitive source of DNS records for a domain. When you set DNS records at your hosting provider or domain registrar, you're configuring an authoritative nameserver.

Root nameservers: The starting point for resolving any domain name. They direct queries to the appropriate TLD nameservers.

Forwarding/caching servers: Some organizations run local DNS servers that simply forward queries to an upstream resolver and cache the results. This speeds up lookups for users on the local network.

DNS_PROBE_FINISHED_NXDOMAIN: The domain doesn't exist in DNS. Either the domain is misspelled, hasn't been registered, or its DNS records have been deleted.

DNS_PROBE_FINISHED_NO_INTERNET: Your device can't reach any DNS server. Check your network connection, restart your router, or try changing your DNS server.

Slow DNS resolution: If websites take a long time to load initially but are fast after, your DNS resolver may be slow. Switch to a faster public DNS like Cloudflare (1.1.1.1) or Google (8.8.8.8).

DNS cache poisoning: A malicious attack that inserts fake records into a DNS cache, redirecting users to malicious sites. DNSSEC (DNS Security Extensions) protects against this.

Stale DNS cache: After changing DNS records, you may still see old results. Flush your local DNS cache and wait for the TTL to expire on upstream resolvers. Use LookMyIP's DNS Propagation Checker to monitor the rollout.

Classic DNS runs over UDP port 53 in plaintext. Anyone on the path — your ISP, a network operator, someone on the same coffee-shop Wi-Fi — can read every domain you look up and, more seriously, forge replies. Three encrypted transports now address this.

DoT (DNS over TLS) wraps DNS in TLS on port 853. Because it has its own port, network operators can see that you are using encrypted DNS and can block or allow it deliberately. This makes it the preferred option for network administrators, and it is what Android's "Private DNS" setting uses.

DoH (DNS over HTTPS) sends queries as HTTPS requests on port 443, indistinguishable from ordinary web traffic. That makes it far harder to block, which is exactly why it is both popular with privacy advocates and contentious with network operators — it bypasses DNS-based content filtering, including the kind schools and enterprises rely on. Firefox and Chrome both support it, and Firefox enables it by default in several regions.

DoQ (DNS over QUIC) is the newest, standardised in RFC 9250. It gives DoT's clean separation with QUIC's lower connection latency and better behaviour on lossy mobile networks.

You can test DoH directly with curl, since it is just HTTPS:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq

Two caveats are worth stating plainly. Encrypted DNS hides your queries from the network but not from the resolver operator — you are choosing to trust Cloudflare or Google instead of your ISP, not eliminating the observer. And it does not hide which sites you visit as thoroughly as advertised, because the TLS handshake to the site itself has historically exposed the hostname in the SNI field. Encrypted Client Hello closes that gap but is still deploying.

dig is the tool worth learning properly, because it answers questions that a browser cannot. A few invocations cover most real problems.

Basic query, readable output:

dig example.com A +noall +answer

Query a specific resolver — essential for distinguishing "my record is wrong" from "my resolver is stale":

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

Ask the authoritative server directly, bypassing all caching. This tells you the truth about your zone:

dig example.com NS +short
dig @ns1.example.com example.com A +noall +answer

Trace the full delegation from the root, which shows exactly where a broken delegation lies:

dig example.com +trace

Check the negative cache TTL, the usual explanation for a newly created record still returning NXDOMAIN:

dig example.com SOA +short

The final number in that output governs how long NXDOMAIN answers are cached.

Reading the response header matters too. In the flags line, aa means the answer came from an authoritative server. Its absence means you are reading a cache. The status field distinguishes the two failure modes that people constantly conflate: NXDOMAIN means the name genuinely does not exist, while NOERROR with an empty answer section means the name exists but has no record of the type you asked for. A domain with an A record but no AAAA record returns NOERROR for the AAAA query, not NXDOMAIN.

On Windows, nslookup is the built-in equivalent, though it is markedly less capable. Installing the BIND tools to get dig is worth the five minutes.

DNS was specified with no authentication at all. A resolver accepts any reply that arrives with a matching query ID and port, which opened the door to cache poisoning: an attacker floods a resolver with forged responses for a name it is currently looking up, and if one arrives before the real answer with the right identifiers, the resolver caches the attacker's address and serves it to every user behind it until the TTL expires.

Dan Kaminsky's 2008 disclosure showed this was far more practical than previously believed, triggering a coordinated emergency patch across every major DNS implementation. The mitigation deployed then — source port randomisation — raised the difficulty substantially but did not eliminate it.

DNSSEC is the structural fix. It attaches cryptographic signatures to DNS records, so a validating resolver can verify that an answer genuinely came from the zone's owner and was not modified. The chain works upward: your zone's records are signed with a key whose fingerprint is published as a DS record in the parent zone, which is itself signed, all the way to the root zone's trust anchor.

DNSSEC has two properties people frequently misunderstand.

It provides authenticity, not confidentiality. Signed DNS is still plaintext and still readable by anyone on the path. DNSSEC and DoH solve different problems and are complementary rather than alternatives.

Misconfiguration fails closed. An expired signature or a DS record that no longer matches the DNSKEY does not degrade gracefully — validating resolvers refuse to return any answer, and the domain becomes unreachable for a large fraction of the internet. This is why DNSSEC rollouts go wrong in a spectacular rather than subtle way, and why key rollovers need care. Verify a zone with the DNSSEC checker after any key change.

What is the difference between a recursive resolver and an authoritative server?

The authoritative server holds the actual records for a zone and gives definitive answers about it. The recursive resolver holds no records of its own; it walks the hierarchy on your behalf, caches what it learns, and returns the result. Your ISP or 1.1.1.1 is a recursive resolver. Your registrar's or DNS provider's nameservers are authoritative.

Why does my computer show a different answer than an online DNS checker?

Layered caching. Your browser caches, your operating system caches, your router often caches, and your resolver caches — each with independent expiry. Online checkers query resolvers directly, skipping all four. Flush the local layers with ipconfig /flushdns on Windows or sudo resolvectl flush-caches on Linux.

Does changing DNS servers make browsing faster?

Sometimes, and less than benchmarks suggest. A faster resolver reduces the time to first byte on the first request to each new domain, typically saving 10–50ms. It does nothing for throughput or for subsequent requests. The larger benefits of switching are usually reliability and, with Quad9, malware domain filtering.

Can DNS be used to block websites?

Yes, and it is the most common censorship and filtering method precisely because it is cheap to implement. It is also the easiest to bypass, since changing resolver or using DoH sidesteps it entirely. This is why filtering that needs to be robust operates at the IP or TLS layer instead.

What is DNS hijacking?

Redirecting DNS queries to a resolver the attacker controls — by malware changing local settings, by compromising a router's DHCP configuration, or by intercepting port 53 in transit. The result is that legitimate domain names resolve to attacker-controlled servers. Encrypted DNS defeats the in-transit variant; DNSSEC validation defeats forged answers.