← Notes from production
DNSSECDNSSecurity

DNSSEC: a tamper-proof seal on your DNS

By Harry Osmar Sitohang·Jun 2026·8 min

You just switched on DNSSEC for pangaea.id — Cloudflare now signs the zone, and you lodged a tiny DS record with the registrar. Here's what that actually buys you, and the exact steps you took — in plain English.

The problem: DNS trusts whatever answers

DNS is the internet's phone book: it turns pangaea.id into the IP address a browser connects to. The weak spot — plain DNS has no way to prove an answer is genuine. When a visitor's resolver asks "what's the address for pangaea.id?", it trusts whatever reply comes back. An attacker on the network — or one who poisons a resolver's cache — can forge a reply that points your domain at their server. The visitor never notices; their browser just connects to the impostor.

Under the hood: how a DNS answer gets forged

Why is forging even possible? It comes down to how a resolver gets an answer. When your recursive resolver doesn't have pangaea.id cached, it asks across the network and accepts the first reply that looks right — one matching the question, the source port, and a 16-bit transaction ID. Classic DNS rides on UDP: connectionless, no handshake, and crucially no proof of who actually sent the reply.

An attacker races that gap:

  1. They get the resolver to look up pangaea.id (or just wait for it to).
  2. They flood it with forged replies carrying a fake IP, guessing the 16-bit ID (only 65,536 values) and the source port.
  3. If a forged reply matching those fields lands before the real one, the resolver believes it — and caches it. (This is the Kaminsky-class cache-poisoning attack; source-port randomization raised the bar but never shut the door.)
  4. Now pangaea.id points at the attacker's server for everyone using that resolver, for the whole TTL — no malware, no warning.

That's the remote case. An on-path attacker — a rogue Wi-Fi hotspot, a compromised router, a hostile ISP — doesn't even need to guess: they see the query and inject a forged reply directly.

resolver: "where is pangaea.id?"nothing cached — it asks the networka forged reply arrives firstguessed 16-bit ID + spoofed source · real reply too lateUDP · no proof of senderresolver accepts it — and caches itfirst match on name · port · ID wins✗ pangaea.id → attacker's IPpoisoned for everyone, for the whole TTLevery visitor lands on the impostor
Cache poisoning without DNSSEC: a forged reply that wins the race gets cached, so the resolver — and everyone behind it — is sent to the attacker until the TTL expires. DNSSEC makes that forged reply fail signature validation, so it's rejected outright.

The common thread: plain DNS can't tell a real answer from a forged one. That's the exact gap DNSSEC closes — a forged reply can't carry a valid signature, so a validating resolver throws it away.

What DNSSEC adds: a tamper-proof seal

DNSSEC (DNS Security Extensions) puts a cryptographic wax seal on every phone-book entry. Your DNS (Cloudflare) signs each record with a private key; the matching public key is published in DNS. Now a resolver can verify the signature before trusting an answer — proving it (a) genuinely came from whoever controls pangaea.id, and (b) wasn't altered in transit. A forged answer fails the check and is thrown away.

The trick is who vouches for the key. DNSSEC is a chain of trust, one link per level: the root vouches for .id, and .id vouches for pangaea.id. Each parent publishes a small fingerprint — a DS record (Delegation Signer) — of its child's signing key. That's the record you added at the registrar: the link that joins .id's zone to yours, so a resolver can walk root → .id → pangaea.id, checking a signature at every step.

So when the same forged reply from earlier shows up, it now meets a gate — and that's the whole defense:

forged replyfake IP · no valid signaturesigned replyreal IP + RRSIG signatureDNSSEC validationverify signature: root → .id → pangaea.id✗ rejectedno valid signature —forged answer thrown away✓ acceptedcached → visitor reachesthe real server
Attack vs defense: both the forged reply and the signed real reply reach the resolver, but DNSSEC checks each signature against the chain. The forged one has none → rejected; only the signed answer is trusted and cached.

Set it up — step by step

1 · Cloudflare → DNS → enable DNSSECCloudflare starts signing your zoneshows a DS record →DS record — fingerprint of your keytag 12345 · algo 13 · digest 2 · 49FD…7C3D2 · copy it3 · Hostinger (registrar) → DNSSECpaste the DS record hereregistrar forwards →4 · the .id registry publishes the DSin the parent (.id) zone5 · chain of trust completeroot → .id → pangaea.id · signed + verified
Five steps: enable DNSSEC in Cloudflare → it signs the zone and hands you a DS record → paste that DS at the registrar (Hostinger) → the .id registry publishes it in the parent zone → the chain root → .id → pangaea.id is sealed.

  1. Cloudflare → your domain → DNS → Settings → Enable DNSSEC. Cloudflare immediately starts signing your zone and shows you a DS record.

  2. Copy the DS record Cloudflare shows you — four values (example below; your own digest is a unique 64-character hash):

    Key Tag:      12345
Algorithm:    13       (ECDSA P-256 / SHA-256)
Digest Type:  2        (SHA-256)
Digest:       49FD2A8C…E1B07C3D   (the SHA-256 hash of your key)

  3. At your registrar — Hostinger → the domain → DNS / Nameservers → DNSSEC — add a DS record and paste those four values.

  4. The registrar hands the DS to the .id registry, which publishes it in the parent zone — completing the chain.

  5. Done: "pangaea.id is protected with DNSSEC." Cloudflare signs; the registry vouches for the key; resolvers verify.

What each field means, plainly:

  • Key Tag (12345) — an ID number picking which signing key.
  • Algorithm (13) — how it's signed: ECDSA P-256 / SHA-256, modern and fast.
  • Digest Type (2) — the hash behind the fingerprint: SHA-256.
  • Digest (49FD…7C3D) — the fingerprint itself, a hash of Cloudflare's public key. This is what the .id registry stores to recognise your key.

Verify it yourself

Don't only trust the dashboard — ask the internet. From any terminal:

dig pangaea.id DNSKEY +dnssec     # your signed keys + RRSIG signatures
dig pangaea.id +dnssec            # an `ad` flag = a validating resolver checked the chain

A signed zone returns the keys plus RRSIG records, and a validating resolver sets the ad (Authenticated Data) flag on the answer. The friendly version is a DNSSEC analyzer like dnsviz.net — paste pangaea.id and look for an unbroken chain from the root down to your domain.

What DNSSEC does not do

The footgun: turn it off before you move DNS

Don't switch nameservers while DNSSEC is on

  • The DS record at the registrar is bound to Cloudflare's key. If you ever move DNS off Cloudflare without first deleting the DS record at the registrar, resolvers keep demanding signatures the new nameservers can't produce → they return SERVFAIL → the whole domain goes dark, globally. Deleting that DS is step one of any future DNS move — not an afterthought. (It's the DNSSEC cousin of the CAA footgun in the SSL article.)

Common questions

What exactly does DNSSEC protect against?

Forged DNS answers — cache poisoning and on-path tampering, where an attacker makes a resolver believe a fake address for your domain. DNSSEC's signatures let the resolver detect the forgery and reject it, so visitors can't be silently rerouted to an impostor server.

Is DNSSEC the same as HTTPS?

No — they secure different layers. DNSSEC secures the lookup (proving you got the real address); HTTPS/TLS secures the connection (encrypting what you exchange with the server). You want both: DNSSEC gets you to the real server, HTTPS protects the conversation once you're there.

Does DNSSEC make my DNS private?

No. It's about authenticity, not confidentiality — DNSSEC proves an answer is genuine but doesn't hide which names you look up. Encrypting the queries themselves is a separate thing (DNS-over-HTTPS or DNS-over-TLS).

What is the DS record I added at the registrar?

The DS (Delegation Signer) record is a fingerprint of your zone's signing key, lodged with the .id registry through your registrar. It's the link that lets the parent zone (.id) vouch for your key, completing the chain of trust from the root down to pangaea.id. Without it, resolvers have no way to trust your signatures.

What happens if I switch DNS providers later?

Delete the DS record at the registrar first. The DS is tied to your current provider's key; if you move nameservers while it's still there, resolvers demand signatures the new provider can't produce and the domain fails to resolve (SERVFAIL) everywhere. Remove the DS, move DNS, then re-enable DNSSEC on the new provider.

Where this fits

DNSSEC seals the lookup; Fast, safe SSL & security on the edge seals the connection, and Point the domain at Cloudflare is where the nameservers moved in the first place. The plain-English story of the whole hardening pass is the Make it fast and safe diary note.

Sources

  1. Cloudflare — DNSSEC
  2. Cloudflare — How DNSSEC works
  3. ICANN — DNSSEC: what it is and why it matters