What Is DNS? The Domain Name System Explained Simply (2026)

What is DNS? DNS stands for Domain Name System. It’s the directory of the internet: it translates a name like getmind.io into the address where the machine actually lives, in our case 46.225.123.163. Your browser can’t do anything with the name alone. Before it loaded a single byte of this page, it asked DNS where to connect.

The usual comparison is a phone book: you know the name, the phone book knows the number. That’s true, but it skips the interesting part. There isn’t one phone book. There’s a globally distributed network of millions of servers, and none of them knows everything. Each one knows a slice and points elsewhere for the rest. That it still works in a few milliseconds comes down to a second trick: almost every answer comes out of a cache.

We run several servers and quite a few domains, and for this article we didn’t just retell the textbook. On 2 October 2026 we measured on our production server (Hetzner, Ubuntu 24.04). Three findings up front:

1. Since 13 September our server has made 308,739 DNS queries. 57.5% of them were answered from the local cache without a single packet leaving the machine.

2. The full chain from the root server to the final answer took 66 milliseconds. An answer from cache: 0 milliseconds.

3. When we looked at our own DNS zone, we found three things we hadn’t really been aware of. More on that below, honestly and without polish.

What Is DNS? The Five-Sentence Version

1. Computers on the internet find each other by IP address (for example 46.225.123.163 or 2a00:1450:4001:c0f::8a). Humans prefer names.
2. DNS is the system that turns names into addresses. It also looks up a few other things, such as which server accepts email for a domain.
3. The data is hierarchical and distributed: root servers know who runs endings like .com or .io, those TLD servers know the nameservers for every domain, and only those nameservers know the actual address.
4. A resolver (usually run by your ISP, your router, or a service like Cloudflare or Google) walks that chain for you and remembers the result for a set period, the TTL.
5. When “the internet is broken” but your connection is up, DNS is surprisingly often the culprit. Among sysadmins that’s a running joke with a lot of truth in it.

If you only wanted the short version, you can stop here. From here on it gets concrete.

Video: Fireship’s “DNS Explained in 100 Seconds” covers the whole lookup in less time than it takes to make coffee.

Why Do We Need DNS at All?

In theory you could visit every website by its IP address. In practice that fails for three reasons.

First, people can’t remember numbers. IPv4 is four blocks. IPv6 turns into strings like 2a00:1450:4001:c0f::8a. Nobody types that voluntarily.

Second, addresses change. If we move getmind.io to a different server tomorrow, we change one record. Every link, bookmark and search result keeps working, because they point at the name, not the number. Without DNS we’d have to tell every visitor about a new number.

Third, many names share one address. Our main server runs dozens of websites behind a single reverse proxy. They all have the same IP. Which site you get is decided by the server based on the name your browser sends along. The IP alone isn’t even enough.

Then there’s everything that isn’t a website: where email for a domain is delivered (MX records), who may send mail on the domain’s behalf (SPF, DKIM and DMARC in TXT records), which certificate authorities may issue certificates (CAA), and whether you actually own the domain (verification codes from Google, Microsoft and others also live in DNS). DNS isn’t just an address book. It’s every domain’s public notice board.

How Does DNS Work? Resolution Step by Step

Say you type getmind.io into your browser and nothing is cached anywhere. Here’s what happens.

Step 1: Your computer asks its resolver. The operating system checks its hosts file and its own cache first. If there’s nothing there, the question goes to the configured DNS server. At home that’s usually your router, which passes the question on to your ISP’s resolver. On our server it’s systemd-resolved at 127.0.0.53, which forwards to Hetzner’s resolvers.

Step 2: The resolver asks a root server. There are 13 root server names (a.root-servers.net to m.root-servers.net), backed by well over a thousand machines worldwide via anycast. The root server doesn’t know getmind.io. It only knows who’s responsible for .io and replies, in effect: “Ask a0.nic.io.”

Step 3: The resolver asks the TLD server. The .io server doesn’t know the address either, but it knows which nameservers are authoritative for getmind.io. For us those are two Cloudflare servers: augustus.ns.cloudflare.com and laura.ns.cloudflare.com.

Step 4: The resolver asks the authoritative nameserver. This server actually holds the zone and answers definitively: getmind.io is at 46.225.123.163, and you may cache that for 300 seconds.

Step 5: Answer returned, caches filled. The resolver hands the address to your computer and remembers everything it learned on the way. The next query for getmind.io doesn’t travel around the world, and a query for anything.io at least skips the root server.

Here’s what that looks like measured on our server. The dig tool with +trace walks the chain itself instead of asking a resolver:

dig +trace getmind.io

Output, trimmed to the timings:

;; Received 622 bytes from 193.0.14.129#53(k.root-servers.net) in 40 ms
;; Received 584 bytes from 2a01:8840:a0::17#53(c0.nic.io) in 9 ms
;; Received 55 bytes from 2a06:98c1:50::ac40:20b7#53(laura.ns.cloudflare.com) in 17 ms

Three hops, 40 + 9 + 17 = 66 milliseconds. The root server was the slowest step, and it’s exactly the one a resolver almost never needs, because the answer “.io is handled by a0.nic.io” stays valid for two days (TTL 172,800 seconds).

Recursive vs. Iterative Queries

Between your computer and the resolver runs a recursive query: “Get me the answer, whatever it takes.” The resolver takes on the work. Between the resolver and the root, TLD and authoritative servers run iterative queries: each answers only with what it knows and refers onward for the rest. Authoritative servers don’t run errands. That’s a big part of why the system scales: the work sits with the resolvers, and resolvers have caches.

The Roles in DNS: Who Knows What

These terms get mixed up constantly, including in tutorials. So here they are, cleanly separated.

The most common misconception: “I bought the domain from provider X, so I have to change records at X.” Not necessarily. At the registrar you only set which nameservers are responsible. If they point to Cloudflare, changes at the registrar do nothing and you have to edit records at Cloudflare. dig NS yourdomain.com +short tells you in two seconds who’s in charge.

DNS Servers Speed Test: Five Resolvers Timed

Which DNS server is fastest? The honest answer: the one closest to you that already has the answer cached. We queried five resolvers from our server at Hetzner, five times each, once for a known name and once for random names that were guaranteed not to be cached.

for i in 1 2 3 4 5; do dig @1.1.1.1 getmind.io +noall +stats | grep 'Query time'; done

Known name (getmind.io), five runs in milliseconds:

Random, uncached name, five runs in milliseconds:

What you can read from that and what you can’t:

• The resolver in your own data center wins as soon as it has the answer. Hetzner responded three times in under a millisecond because the answer was already cached. No public resolver can beat that; the physics of the wire won’t allow it.
• Cloudflare was the most consistent (16 to 21 ms), Google the fastest on uncached names.
• Quad9 was noticeably slow for us that morning, with outliers near 900 ms. That’s a snapshot from one location, not a verdict on Quad9 overall. We didn’t repeat the test over several days, and Quad9’s anycast routing may look very different from a data center than from your home connection.
• For a server, your host’s resolver is usually the best choice. On a home connection things look different, and a test of your own is worth it.

For comparison we sent the same question to Cloudflare via DNS over HTTPS (DoH) with curl: 64 to 81 milliseconds per request, roughly three times classic DNS over UDP. That’s mostly the TLS handshake, which curl redoes on every call. A browser keeps the connection open and only pays that cost once. DoH’s advantage isn’t speed; it’s that nobody along the way can read or tamper with the names you look up.

The Cache: Why DNS Is So Fast

Without caching, every single query would walk the whole chain, and the root servers would collapse under the load. With caching, the overwhelming majority of answers come from memory nearby.

Our server shows this very clearly. systemd-resolved keeps statistics you can pull on any current Ubuntu:

resolvectl statistics

On our machine, since the service last restarted on 13 September:

Total Transactions: 308739
        Cache Hits: 177586
      Cache Misses: 131409
    Total Timeouts:     27
Total Failure Responses: 4

A 57.5% hit rate in the local cache and only 27 timeouts in almost three weeks. And that’s just the first layer: each of the 131,409 misses went to Hetzner’s resolver, which has a big cache of its own and could answer many of them without asking further. A simple experiment shows how strong that effect is: we flushed the local cache and queried www.wikipedia.org twice in a row. First query: 1 ms, second: 0 ms. Even the “cold” lookup was practically instant, because Hetzner’s resolver obviously already knew Wikipedia.

Negative answers get cached too. Ask for a domain that doesn’t exist and you get NXDOMAIN, along with how long that “doesn’t exist” may be remembered. For .de the SOA record says 7,200 seconds. In our test, the first query for a made-up .de name took 14 ms, the second 3 ms.

What TTL Actually Means

Every DNS record has a TTL (time to live) in seconds. It tells every resolver: “You may remember this answer this long without asking again.” You can watch it count down. We queried getmind.io three times, four seconds apart:

265
261
257

The cache counts down. At zero the entry is dropped and the next query fetches it fresh from the nameserver.

That leads to the single most useful rule for anyone moving a server: lower the TTL before the move, not during it. If a record has a TTL of 86,400 seconds (one day) and you change the IP, resolvers that just cached the old answer may serve the old address for up to a day. Lower the TTL to 300 a day in advance and the switchover on moving day takes at most five minutes. Raise it again afterward.

Video: PowerCert’s animated walk-through of resolvers, root, TLD and authoritative servers. An older video, but the protocol hasn’t changed.

The Most Important DNS Record Types

A DNS zone is made up of records. Most domains get by with a handful of types.

Two restrictions almost everyone trips over once:

• A CNAME can’t coexist with other records. The bare domain (example.com without www) always carries NS and SOA records, so a CNAME isn’t allowed there. Providers like Cloudflare work around this with “CNAME flattening”: they resolve the alias themselves and serve an A record to the outside world.
• An MX must not point to a CNAME; it has to point to a name with an A or AAAA record. Many mail servers tolerate it anyway, but don’t rely on that.

What We Found in Our Own Zone

An article about DNS that only explains would be cheap. So we queried our own domain the way an outsider would, and found three things we’re naming openly here. We didn’t change anything for this article. These are decisions you make deliberately, not on the side while writing a blog post.

Finding 1: A Wildcard Catches Every Typo

dig nonexistent-123.getmind.io +short
# 46.225.123.163

Any name under getmind.io resolves to our server, even one that never existed. The reason is a wildcard record, *.getmind.io, which we could see directly on the authoritative nameserver. Another of our domains has the same setup on purpose, because we spin up new subdomains for projects all the time and don’t want to touch DNS each time.

What that means in practice: a typo like wwww.getmind.io doesn’t end in “domain not found”. It ends at our server. Over HTTP it answers with a redirect (status 308); over HTTPS the connection fails on the certificate, because none exists for the made-up name. For visitors that’s more confusing than a clean error. And any scanner brute-forcing subdomains gets a “yes” to everything. Wildcards are convenient, but you should know you have one.

Finding 2: The Reverse Record Points to Another Project

dig -x 46.225.123.163 +short

The reverse lookup (PTR) of our server’s IP doesn’t return getmind.io but a mail hostname from an older project that used to run on the same server. For websites that’s irrelevant; PTR records play no role there. For email it matters: many mail servers check whether the sender’s IP has a PTR record and whether it matches the name the server announces itself with. If you send mail from your own server, set the PTR record at your hosting provider (not your domain registrar; the IP belongs to the host).

Finding 3: No DNSSEC

dig DS getmind.io +short
# (empty)

There’s no DS record for getmind.io in the .io zone, so the domain isn’t signed with DNSSEC. The .io TLD itself is signed; the +trace above showed a DS record for io.. The chain of trust breaks exactly at us. Our local resolver doesn’t validate DNSSEC either (DNSSEC=no/unsupported in resolvectl status, all counters at 0).

What DNSSEC gives you: answers are cryptographically signed, so a resolver can detect a forged address slipped in along the way. What it costs: a botched key rollover makes the domain unreachable for every validating resolver, and that has happened to big operators. On Cloudflare, DNSSEC is one click plus one record at the registrar. That we haven’t enabled it isn’t a statement; it simply never got touched. That’s exactly the kind of thing you only find when you go and look.

Troubleshooting DNS: “It’s Always DNS”

When a website won’t load, it’s worth a quick check whether DNS is to blame. These commands cover 90% of cases.

Does the name resolve at all?

dig example.com +short          # Linux/macOS
nslookup example.com            # also on Windows

No address back means DNS. An address back but the site still won’t load points to the server, the firewall or the certificate instead.

Does the source say something different from my resolver?

dig example.com +short                                          # via your resolver (possibly cached)
dig @$(dig NS example.com +short | head -1) example.com +short  # straight from the authoritative nameserver

If the two answers differ, you just changed something and your resolver still has the old answer cached. Either wait for the TTL to expire or flush your own cache:

sudo resolvectl flush-caches     # Linux with systemd-resolved
ipconfig /flushdns               # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS

You can’t flush your ISP’s cache this way, of course. For a quick cross-check, ask a different resolver directly, e.g. dig @1.1.1.1 example.com.

What do the status codes mean?

We’ve hit one trap ourselves: a domain suddenly returned NXDOMAIN straight from the registry, even though the server ran fine and every record was correct. The cause was a registry hold over unverified owner details. If even the TLD server no longer knows the domain, the problem is at the registrar, not in your zone. dig +trace shows you at which hop the chain breaks.

Why DNS Changes “Propagate Slowly”

You’ll often read that DNS changes take “up to 48 hours to propagate”. That’s misleading. Nothing propagates. Your authoritative nameserver usually knows the new address within seconds. What takes time is old caches expiring around the world, and the upper bound for that is the TTL the old record had. At 300 seconds it’s over in five minutes. The 48 hours comes from changing the nameservers themselves, because those live in the TLD zone with long TTLs (two days for .io, as the trace above shows).

DNS and Security

DNS was designed in the 1980s, and the classic protocol shows it: queries and answers travel unencrypted and unsigned over UDP port 53. That leads to three issues.

Eavesdropping. Anyone on the path (Wi-Fi operator, ISP, someone on the same café network) can see which names you look up. DNS over HTTPS (DoH) and DNS over TLS (DoT) fix that by encrypting the query. Modern browsers support DoH directly; Android supports DoT as “Private DNS”. Note that the resolver itself still sees your queries. You’re shifting trust from the network to the resolver operator.

Forgery. Whoever can forge answers can send you to the wrong server. DNSSEC protects against that by signing answers. As described above, adoption is still patchy, including on our side.

Abuse of your own zone. Forgotten records are a real risk. If a CNAME points to a cloud service you cancelled long ago, someone else can register an account with the same name there and serve content under your subdomain (“subdomain takeover”). Reviewing all records occasionally and deleting leftovers is cheaper than any incident.

Also: DNS is public. Every name you create, and every certificate you issue for it, ends up sooner or later in databases that attackers search. In our Linux server setup article we measured that SSH attacks against our server used usernames taken from our domains, while a server without a domain only saw generic names. A subdomain like internal-test.example.com isn’t secret just because you never link to it.

Do I Need My Own DNS Server?

The short answer for almost everyone: no. Two very different things get called “your own DNS server”.

Your own authoritative nameserver (hosting the zone yourself with BIND, Knot or PowerDNS): only worth it if DNS is your core business. You need at least two servers in different locations, monitoring and clean updates, and an outage takes all your domains offline. Free offerings like Cloudflare, most registrars’ DNS hosting or Hetzner DNS are faster, globally distributed and sturdier than anything an individual can build. All of our zones live at Cloudflare.

Your own recursive resolver or filter (e.g. Pi-hole, AdGuard Home or Unbound on your home network): a popular and sensible project. You block ads and trackers for every device on the network, see which device looks up which names, and with Unbound you query the root servers directly instead of trusting someone else’s resolver. A small VPS or a Raspberry Pi is plenty. But never expose the resolver to the open internet: an open resolver gets abused for DDoS amplification within hours. Restrict port 53 to your own network with a firewall such as UFW.

Setting Up DNS for Your Own Domain: The Typical Flow

If you’ve bought a domain and want to put a website on it, the flow usually looks like this:

1. Decide where the zone lives. Either leave it with the registrar or switch the nameservers to a DNS provider like Cloudflare. Changing nameservers is the one change that really can take up to two days.
2. Set an A record (and AAAA if you have IPv6) for the bare domain pointing to your server’s IP.
3. Make www a CNAME to the bare domain, or another A record. Whether www or the bare domain is canonical is then decided by the web server with a redirect.
4. Check that it resolves: dig yourdomain.com +short directly against the nameserver and via a public resolver.
5. Only then get the certificate. Let’s Encrypt checks via DNS whether the domain really points to your server. A web server like Caddy does this automatically; more in Caddy vs. Nginx.
6. If you send email: add MX, SPF, DKIM and DMARC. Without those, your mail ends up in spam or gets rejected.
7. Optional: a CAA record to restrict which CAs may issue certificates for your domain, and DNSSEC.

A tip from experience: before you change anything in an existing zone, export it. Cloudflare and most providers offer a zone export as a text file. One wrongly deleted TXT record can disrupt mail delivery for days, and then you’ll be glad you still have the old value.

What We Didn’t Measure

So nobody reads more into our numbers than is there:

• The resolver test is a snapshot from one server in one data center on one morning, five runs each. From your home connection the numbers may look completely different.
• We only measured DoH with individual curl calls, i.e. with a TLS handshake per request. Browsers with a persistent connection are much faster.
• We couldn’t measure DNS over TLS because the server lacks a suitable tool.
• The cache statistics only cover the local stub resolver. How many misses Hetzner’s resolver answered from its own cache isn’t visible from outside.

Frequently Asked Questions

What is DNS in simple terms?

DNS (Domain Name System) is the internet’s address book. It translates names people can remember, like getmind.io, into IP addresses like 46.225.123.163 that computers use to connect. Every time you open a website or send an email, a DNS lookup happens in the background.

What is a DNS server?

“DNS server” is an umbrella term. It means either a resolver, which looks up and caches answers for you (the one you configure in your router or OS), or an authoritative nameserver, which holds a domain’s records definitively. Root and TLD servers are special authoritative servers for the upper levels.

Which DNS server should I use?

For most people, the resolver of their ISP or hosting provider is perfectly fine and often fastest, because it’s close and has a large cache. If you care about privacy or filtering, use a provider such as Cloudflare (1.1.1.1), Quad9 (9.9.9.9) or Mullvad, ideally encrypted via DoH or DoT. In our test Cloudflare, Google and Mullvad were neck and neck at 15 to 20 ms; Quad9 was markedly slower from our location that morning.

What does DNS mean on my router?

Your router lists the DNS servers every device on your network uses for lookups. Usually your ISP fills them in automatically and the router just forwards the queries. Change them there and the change applies to every device on your home network at once.

What’s the difference between DNS and an IP address?

The IP address is a computer’s actual address on the network, like a phone number. DNS is the system that finds the IP address for a name, like the phone book. No IP, no connection; no DNS, no names.

How long does a DNS change take?

The authoritative nameserver usually knows the new answer within seconds. Until every resolver worldwide serves it, at most the TTL of the old record passes. At 300 seconds that’s five minutes; at 86,400 seconds it’s a day. The often-quoted 48 hours applies to changing the nameservers themselves, not to normal records.

What is a DNS error and how do I fix it?

A DNS error means the name couldn’t be translated into an address, often shown in browsers as “DNS_PROBE_FINISHED_NXDOMAIN” or “server not found”. First steps: check for typos, flush your local DNS cache, try a different resolver such as 1.1.1.1, and use dig or nslookup to see whether the name resolves at all. If even the authoritative nameserver returns nothing, the problem is in the zone or at the registrar.

What is DNS over HTTPS?

DNS over HTTPS (DoH) wraps DNS queries in encrypted HTTPS, so nobody along the way can read or tamper with the names you look up. In our test, single DoH calls were about three times slower than classic DNS; in a browser with a persistent connection that barely matters.

What is DNSSEC?

DNSSEC adds digital signatures to DNS answers. A validating resolver can then detect whether an answer was forged in transit. It protects authenticity, not confidentiality; that’s what DoH and DoT are for. Many domains, ours included, don’t use it yet.

What’s an A record and what’s a CNAME?

An A record links a name directly to an IPv4 address. A CNAME says: this name is just another name for a different record, go look there. Use A records for your main address and CNAMEs for aliases like www or for subdomains that point to an third-party service.

Can I use DNS without my ISP?

Yes. You can enter any public resolver in your OS or router, or run your own resolver with software like Unbound that starts at the root servers. Your ISP will still see which IP addresses you connect to, but not your DNS queries, as long as they’re encrypted.

Conclusion: DNS Is Invisible Until It Breaks

What is DNS? A distributed, hierarchical directory that translates names into addresses, and one of the most robust systems on the internet. Our server made over 300,000 queries in three weeks; more than half came from cache, and only 27 timed out. The full chain from root server to answer took 66 milliseconds.

The key takeaways are few. TTL decides how quickly changes arrive, so lower it before a move. At the registrar you only set the nameservers; you manage records wherever those point. And dig tells you in seconds whether a problem really is DNS or just looks like it.

While you’re at it, query your own domain the way we did for this article. We found a wildcard we’d half forgotten about, a reverse record left over from an old project, and a missing DNSSEC signature. None of it was urgent, but all of it is something you’d otherwise end up hunting for in the middle of an outage. Better to know now.