Two Kinds of DNS Protection: DNSSEC for Integrity, Encrypted DNS for Privacy

DNSSEC and encrypted DNS get discussed together as if they were two stages of one thing. They defend against entirely different attacks: DNSSEC against tampering, encrypted DNS against observation. One makes a forged answer fail validation; the other keeps a correct answer away from anyone on the path. The costs differ too — one turns an expired signature into a total resolution failure, the other concentrates your query log in a handful of companies. Seeing them separately is how you work out which one your zone actually needs.

Enabling DNSSEC is one of the few DNS changes that can take an entire domain offline for every visitor at once, and do it in a way that looks like the site does not exist. The protocol is not complicated; the operational part is.

1. The chain, in four records

Your zone holds a DNSKEY record — the public key. Every record set in the zone gets an RRSIG, a signature over that data made with the matching private key. The parent zone publishes a DS record, which is a hash of your DNSKEY, and that is what links your zone into the global chain. A validating resolver walks down from the root, checks the DS against your DNSKEY, then checks each RRSIG against that key. If any link is missing or expired, the answer is refused.

Denial of existence is signed too, using NSEC or NSEC3. That is why DNSSEC also proves that a name does not exist, which sounds like a detail until you realise it makes wildcard and empty-non-terminal behaviour slightly different from what people expect.

2. Who signs matters more than what you sign

There are two places the signing can live. Your DNS host signs the zone and you publish the DS at the registrar; or your registrar does both. The failure mode is always the same: the DS at the parent does not match the key currently signing the zone. That happens when you enable signing at the host and forget the DS, when you migrate DNS providers and the old DS stays behind, or when a key rollover goes wrong on one side only.

Before you enable anything, write down which side owns the DS and who is allowed to change it. If the DNS host and the registrar are two different companies — which is the normal case — you have a two-step change that must be done in the right order, and no dashboard will do it for you.

3. Two misconfigurations that cause most outages

• DS published before the zone is actually signed. Traffic fails immediately for every validating resolver, which today means most of the internet. Do it the other way round: sign first, verify with a validator, then publish the DS.
• Signatures that expire because nobody watches them. A zone signed with a 30-day validity and no auto-renewal breaks on day 31, at whatever hour the last signature was made. Set an alert on signature expiry, not on "DNSSEC enabled".

4. What users see when it breaks

Not a helpful error page. Validating resolvers return SERVFAIL, browsers translate that into a generic connection failure, and support tickets say "the site is down" while your origin is healthy and your uptime monitor — which probably queries with validation off, or uses a cached answer — reports everything fine. Test from a resolver that validates, such as 1.1.1.1 or 8.8.8.8, and test again after every change.

5. Key rollovers, briefly

A KSK rollover means publishing a new DNSKEY, waiting at least the TTL plus the propagation window, then swapping the DS at the parent. Doing those two steps in the same minute is the classic self-inflicted outage. A ZSK rollover is cheaper and can be automated, which is why most operators automate ZSK and treat KSK as a deliberate, scheduled operation. Algorithm choice matters too: algorithm 13 (ECDSA P-256) produces much smaller signatures than algorithm 8 (RSA/SHA-256) and is widely supported, so there is little reason to pick the older one today.

6. The honest trade-off

DNSSEC protects integrity, not privacy: it proves the answer was not modified, and does nothing to stop anyone from seeing which names you look up. In exchange it adds a failure mode that is global, instant and total, and it makes a provider migration harder because the DS has to move too. For a domain whose availability matters, that is a real cost — worth paying, but only with monitoring in place.

Plain DNS is a postcard: anyone on the path can read the address on it, and the network you are attached to sees every domain you look up. Encrypting it is an obvious improvement. It is also not the privacy guarantee people assume, because the postcard is not destroyed — it is forwarded to a different reader.

7. What DoH and DoT actually change

DNS-over-TLS wraps queries in a TLS connection to port 853. DNS-over-HTTPS wraps them in HTTPS on port 443, which has the practical effect of looking like ordinary web traffic and surviving networks that block port 853. In both cases the query and response are encrypted between your device and the resolver, so the local network operator — hotel wifi, ISP, a colleague with a packet capture — can no longer read the names.

That is the whole gain, and it is a real one. What it does not change is who answers. The resolver still sees every name you ask for, still sees your IP, and can still correlate the two. You have not removed the observer; you have chosen it.

8. The concentration problem

In practice most encrypted DNS goes to a handful of large operators, because the browser defaults to them and users do not change defaults. Before encryption, your lookups were spread across whichever ISP resolver each network assigned. After encryption, a single company can see a large share of one person's browsing across every network they use — coffee shop, office, home, mobile. A query log that used to be fragmented is now consolidated, and consolidation is the thing privacy people usually worry about.

9. The breakage nobody warns you about

• Split-horizon DNS stops working. An internal name that only resolves inside the company resolves to nothing, or worse, to something public, when the browser insists on its own DoH resolver.
• Captive portals break. The portal needs to hijack DNS to show you the login page; a browser pinned to DoH will simply report that the internet is down.
• A VPN's DNS policy gets bypassed. If the OS or browser has its own encrypted resolver, traffic can exit the tunnel while lookups go elsewhere — a DNS leak in the literal sense, now caused by the feature meant to improve privacy.
• Filtering disappears. Parental controls, malware blocking and enterprise policy all operate on DNS. Encrypted DNS either defeats them or forces them to move to certificate inspection, which is worse.

10. Why the TLS handshake still gives you away

Even with the query encrypted, the SNI field in the ClientHello announces the hostname you are connecting to in most TLS connections today. Encrypted Client Hello exists and closes that hole, but support is partial and it requires both the server and the client to cooperate — and in many networks the middlebox simply resets connections that carry ECH. If the concern is "nobody should know which site I opened", encrypted DNS alone does not get you there.

11. The performance argument is real, but conditional

DoH often feels faster than plain UDP DNS, which surprises people. The reason is connection reuse: the query rides an existing HTTPS connection to the same resolver your browser already has open, so there is no extra round trip and no cold-start penalty. DoT gains the same way, but only if the client keeps the TLS session alive. On a cold start with no connection, encrypted DNS adds a handshake before it can answer anything.

12. What to actually choose

• Pick the resolver by policy, not by benchmark. Decide whether you would rather the queries go to your ISP, to a large public operator, or to a resolver you run yourself — those are different trade-offs, and the fastest one is not automatically the right one.
• Prefer a resolver with a published policy, an audit and a clear jurisdiction. Zero logs is a claim; look for the third-party audit that tested the claim.
• On a network you control, run your own DoT resolver upstream of the devices. You keep filtering and internal names, and you still encrypt the hop to the upstream.
• Leave a fallback path. A network that only permits DNS through the local resolver is not broken by design; it is usually a captive portal or a policy. Fail closed on privacy, fail open on connectivity.

ipbox.one resolves records over DNS-over-HTTPS in the tools section, and on the home page names the resolver that actually answered your queries and whether its country matches your exit. The first shows whether DNSSEC signatures are being served; the second shows who encrypted DNS handed your queries to.