DNSSEC im Betrieb: typische Fehlerbilder, Checks und ein pragmatischer Rollout

DNSSEC gehört seit Jahren zu den empfohlenen Sicherheitsmaßnahmen für DNS-Infrastrukturen — trotzdem ist die Verbreitung nach wie vor überschaubar. In diesem Beitrag gehe ich auf die typischen Hürden beim Rollout ein und gebe konkrete Empfehlungen für den Betrieb.

DNSSEC in einem Satz

DNSSEC signiert DNS-Zonen kryptografisch, damit Resolver Antworten validieren können (Authentizität/Integrität). Wichtig: Signieren allein reicht nicht – Validation muss am Resolver stattfinden.

Typische Fehlerbilder im Betrieb

1) „SERVFAIL“ nach Key-Rollover

Der Klassiker: DS-Record im Parent passt nicht (mehr) zum KSK in der Zone.

2) Negative Antworten brechen

NSEC/NSEC3 ist falsch konfiguriert oder TTLs sind unglücklich.

3) Split-DNS + DNSSEC = Überraschung

Interne Views signieren nicht konsistent oder liefern unterschiedliche Antworten ohne passenden Chain-of-Trust.

Checks: Validiert mein Resolver wirklich?

Quick-Check mit dig

# Erwartung: "ad" (Authenticated Data) Flag, wenn Validierung aktiv ist
# (abhängig vom Resolver und Output-Format)
dig +dnssec +multi www.iana.org @1.1.1.1

Besser: delv (validiert selbst)

delv (BIND utilities) ist praktisch, weil es explizit validiert.

# "fully validated" ist das Ziel
# Je nach Distribution: apt install bind9-dnsutils

delv www.iana.org A

Monitoring-Idee: ein bewusst kaputter Test

Es gibt Domains, die absichtlich DNSSEC-falsch sind (für Tests). Wenn euer Resolver korrekt validiert, müsst ihr ein Fail sehen.

# Erwartung bei Validierung: SERVFAIL
# (Domain kann sich ändern; bekannte Testdomain: dnssec-failed.org)
dig dnssec-failed.org A

Pragmatischer Rollout: so mache ich es gerne

Phase 1: Signieren + „Silent Validation“

• Zone signieren
• DS sauber setzen
• Resolver validieren lassen
• aber: Auswirkungen beobachten (SERVFAILs, Support-Tickets)

Phase 2: Validierung breit ausrollen

• Unternehmensresolver (Unbound/BIND/Infoblox/PowerDNS) als „Gatekeeper“
• Clients nutzen nur noch diese Resolver
• Forwarder/Conditional Forwarding sauber dokumentieren

Phase 3: Automation für Key-Rollover

• Rollover-Prozess schriftlich
• Reminder/Runbook
• ideal: Automation, die DS-Updates im Parent anstößt

Takeaways

• DNSSEC ist nur dann „aktiv“, wenn am Resolver validiert wird.
• Die häufigsten Ausfälle passieren bei DS/KSK-Rollovern.
• delv ist Gold wert, weil es Validierung explizit macht.
• Testt bewusst fehlerhafte Domains, um Validierung zu verifizieren.
• Rollout in Phasen: erst beobachten, dann breit enforce.