Chapter 38 — DNS security

How a lookup works, and where it's attackable

   your app -> STUB RESOLVER (OS) -> RECURSIVE RESOLVER (ISP / 1.1.1.1 /
               8.8.8.8 / your own) -> ROOT -> TLD (.op) -> AUTHORITATIVE
               (securesh.op's nameserver) -> answer flows back and is CACHED
               at the recursive resolver for the TTL.

   ATTACK SURFACE:
     [1] stub <-> recursive : on-path sniff/spoof; rogue DHCP sets a
                              malicious resolver; malware edits /etc/resolv.conf
     [2] recursive <-> auth : off-path CACHE POISONING (spoof the answer
                              before the real one arrives)
     [3] the recursive's cache itself, or a compromised resolver
     [4] the registrar / registry account -> DOMAIN HIJACK (change the NS
         records; game over, and it happens regularly)
     [5] the authoritative server or its zone file

Cache poisoning and the Kaminsky attack (2008)

   A spoofed DNS response is accepted if it matches:
     - the 16-bit TRANSACTION ID
     - the source/dest IP and PORT
     - the question

   Classic attack: guess the 16-bit ID (65,536 values) while the resolver
   waits for an answer. Kaminsky's insight: you don't have to win once for
   one name -- query aaa.bank.com, bbb.bank.com, ... and each attempt is a
   fresh race, and a winning spoof can inject a poisoned NS record for the
   WHOLE zone. Suddenly feasible.

   MITIGATION (deployed 2008, still essential, NOT a real fix):
     * randomise the SOURCE PORT too  -> ~32 bits of entropy
     * 0x20 encoding (randomise query-name case)
     * these make it HARDER, not impossible. DNSSEC is the actual fix.

DNSSEC — authenticating the answers

DNSSEC signs DNS records so a resolver can verify they're genuine and unmodified.

   Each zone signs its records (RRSIG) with a private key. The public key
   (DNSKEY) is vouched for by a hash (DS record) in the PARENT zone, which
   is itself signed... up to the ROOT, whose key is a well-known trust
   anchor (and whose rotation is a globally-televised ceremony).

     . (root, trust anchor)
       signs DS for  .op
         .op signs DS for  securesh.op
           securesh.op signs its own A / MX / TXT ... records

   A VALIDATING resolver rejects answers that fail the chain -> cache
   poisoning and on-path answer forgery stop working.

What DNSSEC does and doesn't do:

   DOES:  data-origin authentication + integrity for DNS records.
          Authenticated denial of existence (NSEC/NSEC3): "that name
          really doesn't exist" is provable.
   DOES NOT: encrypt anything (queries/answers are still public --
             that's DoH/DoT's job).
   DOES NOT: protect the stub <-> recursive hop unless that hop also
             validates and you trust it (or you validate locally).
   COSTS:  key management, signing, larger responses (UDP fragmentation,
           amplification-DDoS potential), operational foot-guns (an
           expired RRSIG = your domain vanishes for validating resolvers).
   ADOPTION: patchy. Most TLDs signed; a minority of second-level domains.

DNSSEC also enables DANE (TLSA records: "here's the exact cert my mail server uses") — widely used to secure SMTP between mail servers, rarely for the web (browsers didn't adopt it; they rely on the CA/CT system instead).

Encrypted DNS transport: DoT and DoH

   Plain DNS (port 53, UDP/TCP): everyone on-path sees every name you
   resolve, and can tamper (if not DNSSEC-validated).

   DoT  -- DNS over TLS, port 853. Dedicated port -> easy to see "DNS is
           happening" and to block, but content is encrypted.
   DoH  -- DNS over HTTPS, port 443. Looks like normal web traffic ->
           hard to block or distinguish; also usable from inside browsers.
   DoQ  -- DNS over QUIC, port 853. DoT's benefits without head-of-line
           blocking.

   These hide your queries from the LOCAL network and your ISP, moving
   that visibility to your chosen resolver (Cloudflare, Google, Quad9,
   NextDNS, or your own). Trade-off: you must trust that operator, and
   enterprises lose DNS-based filtering/visibility (hence "enterprise
   DoH" controls and DDR/DNR discovery).

DNSSEC and DoH/DoT are complementary: DNSSEC = is this answer authentic? DoH/DoT = who got to watch me ask? Ideally both.

Domain-level hygiene (the boring stuff that prevents disasters)

   [ ] Registrar account: unique password + phishing-resistant MFA;
       REGISTRY LOCK (a manual, out-of-band step to change NS/transfer) --
       this alone stops most domain hijacks.
   [ ] CAA records (Ch 30) so only your CA can issue certs.
   [ ] SPF, DKIM, DMARC (p=reject) so nobody spoofs your email domain;
       MTA-STS + TLS-RPT for inbound mail transport security.
   [ ] Watch for dangling records: a CNAME to a decommissioned S3
       bucket / Heroku app / Azure resource -> SUBDOMAIN TAKEOVER.
       Inventory and prune DNS regularly.
   [ ] Separate, minimal-privilege accounts for DNS management; audit logs.
   [ ] Monitor: alerts on any NS / MX / DS / A change to your zones;
       external checks that your domain still resolves and validates.
   [ ] DNSSEC if your registrar/DNS host supports easy signing + managed
       key rollover. If they don't automate it, the operational risk may
       outweigh the benefit -- decide deliberately.

# 1. Trace a resolution and see the hierarchy
dig +trace securesh.op          # root -> TLD -> authoritative
dig +norecurse @a.root-servers.net NS op.    # ask root directly

# 2. Inspect DNSSEC
dig +dnssec cloudflare.com A                 # look for the RRSIG records
dig DS cloudflare.com                        # the delegation hash in the parent
dig +dnssec dnssec-failed.org A              # a deliberately-broken domain

# 3. Validate the chain explicitly
delv cloudflare.com A                        # "fully validated" (needs a
                                             # crypto-capable delv build;
                                             # macOS's may say "no crypto support"
                                             # -- another Ch 0.4 trap; use Linux
                                             # or `dig +sigchase`, or unbound-host)

# 4. See a poisoning mitigation in action: source-port randomisation
sudo tcpdump -i any -n 'udp port 53' -c 10 &
for i in 1 2 3 4 5; do dig +short example$i.com; done
sudo pkill tcpdump
#   note the SOURCE port differs every query -- that's the anti-Kaminsky entropy.

# 5. Encrypted DNS
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com  # DoT (knot-dnsutils)
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'    # DoH (JSON)

# 6. Check your domain's email + CAA posture
dig +short TXT example.com | grep -i spf
dig +short TXT _dmarc.example.com
dig +short CAA example.com

# 7. Subdomain-takeover sweep (your domains only): list CNAMEs and check
#    each target still exists
dig +short CNAME assets.example.com

Mini-project (45 min): DNS + domain monitor

   A script (cron, every 15 min) that for each zone you own:
     1. Resolves NS, MX, DS, SOA, and key A/AAAA records.
     2. Diffs against a committed baseline; alerts loudly on any change.
     3. Runs `delv` / a validating query and alerts if DNSSEC validation
        fails (expired RRSIG is a classic 2 a.m. incident).
     4. For every CNAME, checks the target resolves (dangling -> takeover
        risk).
     5. Confirms CAA, SPF, and DMARC records are present and unchanged.
   Output: OK / WARN / CRIT, exit codes for your monitoring system.