Runbook: DNSSEC-Validierung im Resolver aktivieren (BIND/Unbound) – inkl. Monitoring

Ein DNSSEC-validierender Resolver ist die Basis für sichere DNS-Auflösung im eigenen Netz. Doch die Einrichtung hat einige Fallstricke, die in der Praxis gerne übersehen werden. Dieses Runbook zeigt, wie es richtig geht. DNSSEC bringt nur dann Sicherheitsgewinn, wenn deine Resolver validieren. Dieses Runbook zeigt die Aktivierung (BIND oder Unbound), die wichtigsten Tests mit dig, Monitoring-Signale und ein schnelles Troubleshooting bei SERVFAIL.

Voraussetzungen

• Du betreibst rekursive Resolver (on-prem oder in einer VPC/VNet).
• Clients nutzen diese Resolver (DHCP/MDM/VPN Profil).
• Zeit ist korrekt (NTP) – DNSSEC ist zeitabhängig.

Check:

timedatectl status | sed -n '1,6p'

Schritt-für-Schritt: BIND (named) als validierender Resolver

1) named.conf.options anpassen

Beispiel (Distribution abhängig):

options {
  recursion yes;
  dnssec-validation auto;

  # Optional: aggressive NSEC (Performance, aber Vorsicht bei Edge-Cases)
  # aggressive-nsec yes;

  listen-on { 10.0.0.53; 127.0.0.1; };
  allow-query { 10.0.0.0/8; 127.0.0.1; };
};

2) Service reloaden und Logs prüfen

sudo named-checkconf
sudo systemctl restart named || sudo systemctl restart bind9
sudo journalctl -u named -u bind9 -n 100 --no-pager

Schritt-für-Schritt: Unbound als validierender Resolver

1) Trust Anchor sicherstellen

Meist reicht auto-trust-anchor-file:

server:
  interface: 10.0.0.54
  access-control: 10.0.0.0/8 allow

  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  val-permissive-mode: no

2) Root Key initialisieren und Dienst starten

sudo unbound-anchor -a /var/lib/unbound/root.key
sudo unbound-checkconf
sudo systemctl restart unbound
sudo journalctl -u unbound -n 100 --no-pager

Validierung: Tests, die du wirklich brauchst

1) Positiver Test (valid)

dig @10.0.0.53 dnssec-failed.org A +dnssec

Erwartung: SERVFAIL (Domain ist absichtlich kaputt signiert).

2) Negativer Test (unsigned sollte funktionieren)

dig @10.0.0.53 example.com A +dnssec

Erwartung: normale Antwort (NOERROR).

3) AD-Flag prüfen (Authenticated Data)

dig @10.0.0.53 cloudflare.com A +dnssec +multi | grep -E "\bad\b|flags"

Erwartung: flags: ... ad; (je nach Query/Antwort).

Monitoring & Alarmierung

Was du messen solltest

• Anzahl SERVFAIL gesamt
• SERVFAIL nach Domain (Top N)
• Resolver latency (p50/p95)
• Root Key/Trust Anchor Updates (Unbound/BIND Logs)

Schneller SERVFAIL-Report aus Query Logs

Wenn du Query Logs im JSON-Format nach Elasticsearch/Loki schickst, filtere:

jq -r 'select(.rcode=="SERVFAIL") | .qname' resolver.log | sort | uniq -c | sort -nr | head

Troubleshooting: Wenn plötzlich alles SERVFAIL ist

1) Zeit/Clock Skew

• NTP ok?

timedatectl status | grep -E "System clock synchronized|NTP service"

2) UDP Fragmentation / MTU / Firewall

DNSSEC-Antworten sind größer → EDNS0/Fragmentierung. Test:

dig @10.0.0.53 org DNSKEY +dnssec +bufsize=1232

Wenn das hängt:

• erlaubst du UDP/53 + Fragmentierung?
• TCP fallback erlaubt?

3) Upstream/Forwarder validiert nicht sauber

Wenn du forwardest (z. B. an ISP-Resolver), kann Validierung kaputt sein. Besser: selbst rekursiv auflösen oder an zuverlässige Validierer forwarden.

4) Trust Anchor veraltet

Unbound:

sudo unbound-anchor -a /var/lib/unbound/root.key -v

BIND (auto) → Log prüfen.

Rollout-Strategie

• Erst 1 Resolver-Cluster „canary“
• 24–48h beobachten (SERVFAIL-Spikes?)
• Dann DHCP/VPN/MDM umstellen
• Parallel: Exception-Prozess für echte kaputte Signaturen (temporär, dokumentiert)

Takeaways

• DNSSEC ist ein Resolver-Thema: Ohne Validierung kein Sicherheitsgewinn.
• Teste immer mit dnssec-failed.org (muss SERVFAIL liefern).
• Häufigste Fehlerursachen: Zeit, MTU/Fragmentierung, schlechte Forwarder.
• Monitoring auf SERVFAIL und Latenz macht Rollouts sicher.
• Canary-Rollout reduziert den Impact von Edge-Cases drastisch.