A phone book that never checked its sources
You now know how the Domain Name System turns a name like example.com into an address: your resolver walks down from the root to the TLD to the authoritative server, collects resource records, and caches each answer for as long as its TTL allows. It is a marvel of scale. But notice what the earlier guides quietly never mentioned: at no point did anyone prove that the answer was genuine, and at no point was the question hidden from anyone watching the wire.
That is not a bug someone forgot to fix — it is the era DNS was born in. In the early Internet, the machines on it largely trusted one another, and a plain, fast, unencrypted lookup was exactly what was wanted. So by default DNS is both unauthenticated (it does not prove who really answered) and unencrypted (anyone on the path can read your queries). Those are two different weaknesses, and they need two different fixes. Keeping them apart is the whole point of this guide.
Think of the classic DNS answer as a postcard handed to you by a stranger who says, 'Here is the address you wanted.' Two questions should bother you. First: did this stranger really get the address from the rightful owner of the name, or did they make it up? Second: who else read the postcard on its way to me, and did they see what name I was asking about? The first is a question of integrity and origin; the second is a question of privacy. We will tackle them in that order.
The attack that makes this matter: cache poisoning
Why care that answers are unauthenticated? Because caching, the very thing that makes DNS fast, also makes a forged answer dangerous. A classic DNS query goes out over UDP as a single unprotected message, and the resolver simply trusts the first reply whose fields match. An attacker who can guess or observe those fields can race to send a fake reply first — a forged record that says example.com lives at the attacker's address. This is spoofing, and when the poisoned answer lands in the resolver's cache, every user behind that resolver is silently sent to the wrong place until the TTL expires.
The damage compounds because the wrong address can lead anywhere. Sent to an attacker's server, you might hand over a password, or download something hostile, all while the name in your address bar still reads example.com. Notice the trust gap precisely: the danger is not that someone read your query — it is that you cannot tell a real answer from a forged one. No amount of speed or caching fixes that. What is missing is a way for the rightful owner of a name to put a tamper-evident seal on their records, so a resolver can refuse anything that was altered or faked. That seal is DNSSEC.
DNSSEC: signing the answers
DNSSEC (DNS Security Extensions) attacks the first problem — authenticity — and only that one. Its tool is the digital signature you met in the security rung. The owner of a zone holds a private key and uses it to sign each set of records; the matching public key is published in the zone itself. When a resolver fetches the address for example.com, it also fetches a signature, and it verifies that signature with the public key. If even one byte of the record was altered in flight, the math does not check out and the resolver throws the answer away. The seal is broken, so the answer is rejected.
But a signature is only worth as much as your trust in the key that made it. How do you know the public key for example.com is itself genuine and not also forged? DNSSEC answers this with a chain of trust that mirrors the DNS hierarchy you already know. The root zone vouches for each TLD's key, each TLD vouches for the keys of the zones beneath it, and so on down to example.com. Each level signs a small fingerprint of the child's key, so trust flows downward link by link. You only have to trust one thing at the very top — the root's key, the famous trust anchor — and everything below is verifiable from there.
- Your resolver asks the root for example.com's chain and learns the root's signed pointer to the .com zone's key — a fingerprint it can check against the trust anchor it already holds.
- The .com zone, now trusted, hands over a signed pointer to example.com's key. Each link is verified before the next is followed, so a forged key anywhere would break the chain.
- Finally example.com signs the actual address record. The resolver verifies that signature with the now-trusted key and accepts the address only if the signature holds.
Encrypted lookups: hiding the question
Now the second weakness. Even with DNSSEC sealing every answer, a classic query still travels in the clear, so your network provider, a café Wi-Fi operator, or anyone tapping the link can read a running list of every site you look up — a surprisingly revealing diary, even before you have loaded a single page. The fix is to wrap the whole conversation in encryption, and the tool is one you already met: TLS, the same protection that puts the padlock on HTTPS.
There are two standard ways to do this. DNS over HTTPS (DoH) sends your queries inside ordinary HTTPS requests, so to anyone watching they look just like normal web traffic and blend into the crowd. DNS over TLS (DoT) does the same encryption but over its own dedicated port, which is easier for a network operator to see and manage as DNS even though they still cannot read inside it. Both ride on TLS; the difference is mainly how visible the traffic is and who gets to control it. Either way, the eavesdropper now sees only an encrypted tunnel to your chosen resolver.
Two fixes, one diagram, and the honest limits
The cleanest way to hold all of this is to remember that integrity and privacy are independent axes, and a fully protected lookup wants both. DNSSEC signs the answer so you can trust it is genuine; encrypted DNS wraps the question so others cannot read it. You can have either one without the other, and historically most of the Internet had neither. The little table below lays out who solves what.
| proves answer is | hides the
| genuine? | question?
--------------------+------------------+-----------
plain DNS (default) | no | no
DNSSEC | YES | no
DNS over HTTPS/TLS | no | YES
DNSSEC + encrypted | YES | YESA few honest caveats keep this from becoming a magic wand. DNSSEC adoption is real but far from universal — many zones still publish no signatures at all, so a resolver simply has nothing to verify and falls back to trusting the plain answer. The chain also depends on registrars and zone operators configuring keys correctly, and a fumbled key rollover can take a whole domain offline. Meanwhile, even a securely resolved address only tells your browser where to connect; proving you are really talking to the right server, and encrypting the page itself, is still the job of TLS and its certificates one layer up. Securing the name is a first step, not the finish line.
That closes the DNS rung. You started by asking why we need names at all, climbed the hierarchy from root to authoritative server, traced a lookup step by step, learned how records and TTLs let caching scale the whole thing, and have now seen how to seal the answers and hide the questions. The same two-axis thinking — is this genuine, and is this private — will follow you up the rest of the ladder, into TLS, into the design of QUIC, and into every place the Internet has had to retrofit trust onto a system that was built without it.