• Blog
  • Was ist DNSSEC und wie funktioniert es?

Was ist DNSSEC und wie funktioniert es?

DNSSEC authentifiziert DNS-Anfragen und -Antworten mithilfe kryptografischer digitaler Signaturen. Erfahren Sie mehr darüber und wie BlueCat dazu beitragen kann, die Implementierung zu vereinfachen.

padlock and key
Die wichtigsten ErkenntnisseDie wichtigsten Erkenntnisse werden mithilfe von KI generiert. Da automatisierte Zusammenfassungen gelegentlich Fehler enthalten oder wichtige Zusammenhänge auslassen können, sollten Sie für vollständige Informationen stets den vollständigen Blogbeitrag lesen.

DNSSEC (Domain Name System Security Extensions) is a set of cryptographic specifications that authenticate DNS queries and responses to protect against Man-in-the-Middle attacks like DNS cache poisoning, which traditional DNS cannot prevent. The article explains how DNSSEC uses public-key cryptography with digital signatures stored in nameservers to create a chain of trust from root servers down to authoritative servers, enabling resolvers to verify response authenticity before returning data to clients. BlueCat simplifies DNSSEC implementation by automating complex operational tasks including key pair generation, zone signing, DS record creation, and key renewal scheduling through a centralized platform, eliminating error-prone manual configuration.

What is the fundamental security vulnerability in traditional DNS that DNSSEC addresses?

Traditional DNS was designed for scalability rather than security and lacks mechanisms to verify the authenticity of DNS responses. This inherent vulnerability makes standard DNS-Abfragen susceptible to Man-in-the-Middle-Angriffe such as DNS-Cache-Poisoning and DNS-Spoofing. An attacker can inject a gefälschte Antwort to replace the legitimate DNS response, redirecting users to a böswilligen Server while appearing legitimate. Without DNSSEC, such bösartige responses become cached in the resolver, affecting multiple devices using the same DNS-Resolver until the Time-to-Live expires.

How does DNSSEC establish a chain of trust to validate DNS responses?

DNSSEC establishes a Vertrauenskette through hierarchical cryptographic key signing. Each DNS zone contains a public-private Schlüsselpaar consisting of a Zone-Signing-Key (ZSK) and Key-Signing-Key (KSK). The private ZSK creates kryptografische Signaturen (RRSIG-Einträge) for Resource Record Sets, while the KSK validates the public ZSK. DS-Einträge in parent zones reference child zone keys, creating a chain upward to Root-Server-Vertrauensanker. Each level performs validation; if the chain breaks anywhere, the DNS-Server responds with SERVFAIL instead of returning potentially compromised data.

What specific DNSSEC automation capabilities does BlueCat provide for DNS infrastructure?

BlueCat automates critical DNSSEC management tasks through its centralized platform, including: Generierung kryptografischer Schlüsselpaare, Pflege der Proof-of-Non-Existence (PNE) chain using NSEC or NSEC3-Einträge, zone signing for all DNS-Einträge, DS-Eintrag generation for parent zones, and scheduled renewal of KSKs and ZSKs. The platform also monitors key generation success/failure and performs emergency rollovers. This automation prevents errors from manual configuration that could render zones unreachable and eliminates the complex Schlüsselwechsel and Neusignierung processes required with traditional approaches.

Da das DNS ursprünglich mit Blick auf Skalierbarkeit – und nicht auf Sicherheit – entwickelt wurde, kann DNSSEC eine wichtige Ergänzung Ihres Sicherheitsportfolios sein.

Aber was ist DNSSEC? Zunächst einmal steht die Abkürzung für „Domain Name System Security Extensions“. Es handelt sich um eine Reihe von Spezifikationen, die digitale Signaturen auf kryptografischer Basis verwenden, um DNS -Anfragen (Domain Name System) und -Antworten zu authentifizieren.

Auf den ersten Blick mag die Implementierung von DNSSEC vielleicht einschüchternd wirken. Doch jede öffentlich zugängliche Domain kann von den Vorteilen profitieren.

In diesem Beitrag wird zunächst erläutert, was DNSSEC genau ist. Anschließend wird detailliert beschrieben, wie die herkömmliche DNS-Auflösung funktioniert und warum sie so anfällig für Cyberangriffe ist. Darüber hinaus wird näher auf die Funktionsweise von DNSSEC und die dabei durchgeführten Authentifizierungsschritte eingegangen. Abschließend wird erläutert, wie BlueCat dazu beitragen kann, die DNSSEC-Implementierung zu vereinfachen.

Was ist DNSSEC?

Es ist wichtig zu beachten, dass DNSSEC und DNS-Sicherheit nicht dasselbe sind. Auch wenn ihre Bezeichnungen ähnlich klingen, ist DNSSEC keine Abkürzung für DNS-Sicherheit. (Letzteres ist ein Oberbegriff, der zahlreiche Strategien und Produkte umfasst.)

Was genau leistet DNSSEC eigentlich? Wenn DNSSEC aktiviert ist, hilft es einem DNS-Server, die folgenden Fragen zu beantworten:

  • Ist der Root- oder autoritative Nameserver berechtigt, eine Antwort auf eine Abfrage zu liefern?
  • Kann ich dem Inhalt der Abfrageantwort vertrauen?
  • Kann ich außerdem darauf vertrauen, dass die Antwort während der Übertragung nicht verändert wurde?

Je mehr Domains DNSSEC unterstützen, desto sicherer ist das Internet für alle. Laut den DNSSEC-Statistiken der Internet Society hat die Mehrheit der Top-Level-Domains DNSSEC bereits implementiert.

DNS ohne DNSSEC

Die normale DNS-Auflösung ist recht einfach: Wenn ein Gerät eine DNS-Anfrage sendet, führen Domain-Name-Server und Resolver eine DNS-Abfrage durch. Sie stellen sicher, dass die DNS-Anfrage eine Antwort mit einer IP-Adresse aus dem entsprechenden Eintrag erhält.

Leider bedeutet „einfach“ in diesem Fall auch „naiv“. Dem DNS-Protokoll innewohnende Eigenschaften können jede Organisation dem Risiko von Cyberangriffen aussetzen.

Solange der Resolver Daten empfängt, die dem Zweck seiner Anfrage dienen, setzt er die Abfrage fort, bis er eine IP-Adresse an den Client zurücksenden kann. Bei der normalen DNS-Auflösung können die erhaltenen Antworten nicht überprüft und die drei oben genannten Fragen nicht beantwortet werden.

Dadurch sind Standard-DNS-Abfragen anfällig für Man-in-the-Middle-Angriffe wie DNS-Cache-Poisoning (und das eng damit verbundene DNS-Poisoning, das auch als DNS-Spoofing bezeichnet wird). Ein Angreifer fügt eine gefälschte Antwort ein, um die legitime Antwort auf eine DNS-Anfrage zu ersetzen. Die gefälschte Antwort verweist auf einen vom Angreifer kontrollierten Server, der oft so konfiguriert ist, dass er identisch mit der legitimen Website erscheint. Dadurch kann es vorkommen, dass der Endnutzer überhaupt nicht bemerkt, dass er sich an einer Stelle befindet, an der er nicht sein sollte.

Ist DNSSEC nicht aktiviert, wird die bösartige Website ebenfalls im Resolver zwischengespeichert. Infolgedessen werden auch andere Geräte, die denselben DNS-Resolver verwenden, auf die bösartige Website weitergeleitet. Sie verbleibt so lange im Cache, bis ihre vorgegebene Gültigkeitsdauer (Time-to-Live) abläuft, was potenziell unzählige Geräte betreffen kann.

DNSSEC: So funktioniert es

Grundsätzlich überprüft DNSSEC die Antworten auf DNS-Abfragen, bevor diese an das Client-Gerät zurückgesendet werden. DNSSEC verwendet digitale Signaturen, die zusammen mit gängigen DNS-Eintragstypen in Nameservern gespeichert sind.

Im Zentrum von DNSSEC steht ein öffentlich-privates Schlüsselpaar. Jede DNS-Zone verfügt über einen öffentlichen und einen privaten Schlüssel.

Die Kryptografie mit öffentlichen Schlüsseln ist der Ausgangspunkt für die DNSSEC-Validierung. Ein öffentlicher Schlüssel steht jedem zur Verfügung und ermöglicht die Entschlüsselung von Nachrichten, die mit einem entsprechenden privaten Schlüssel signiert wurden.

Zur Klarstellung: Die DNSSEC-Sicherheit umfasst keine gängigen Maßnahmen wie die Verschlüsselung von DNS-Daten, SSL-Zertifikate oder gemeinsame Geheimnisse.

Einige wichtige Begriffe (kein Wortspiel beabsichtigt)

RRSIG-Eintrag: Die Sicherung einer DNS-Zone mit DNSSEC beginnt damit, dass DNS-Einträge desselben Namens und Typs (z. B. A-Einträge) zu einem Ressourcen-Eintragssatz (Resource Record Set, RRset) zusammengefasst werden. Das RRset – und nicht einzelne DNS-Einträge – wird tatsächlich signiert. Ein RRSIG-Eintrag enthält eine kryptografische Signatur für ein RRset.

Zone-Signing-Key-Paar (ZSK): Jede DNSSEC-fähige Zone verfügt über ein öffentlich-privates ZSK-Schlüsselpaar. Netzwerkadministratoren erstellen mit dem privaten Schlüssel kryptografische Signaturen für jeden RR-Satz in der Zone und speichern diese als RRSIG-Einträge. Der öffentliche ZSK-Schlüssel überprüft die Signatur und wird im DNSKEY-Eintrag gespeichert.

DNSKEY-Eintrag: Ein DNSKEY-Eintrag speichert den öffentlichen Schlüssel. In der Regel gibt es zwei pro Zone, einen für den Zonensignaturschlüssel (ZSK) und einen für den Schlüsselsignaturschlüssel (KSK). Resolver verwenden DNSKEY-Einträge, um zu überprüfen, ob die Signaturen in RRSIG-Einträgen legitim sind.

Schlüsselsignierungsschlüssel (KSK): Um sicherzustellen, dass der ZSK nicht kompromittiert wurde, verfügen DNS-Nameserver außerdem über einen KSK zur Validierung des öffentlichen ZSK. Dieser signiert den öffentlichen Schlüssel im ZSK und erstellt einen RRSIG für den DNSKEY-Eintrag. Der private KSK signiert öffentliche Schlüssel sowohl für ZSKs als auch für KSKs.

DS-Eintrag: Der DS-Eintrag belegt die Verknüpfung zwischen einer übergeordneten und einer untergeordneten Zone. DS-Einträge befinden sich in der übergeordneten Zone und enthalten einen Hash des DNSKEY aus der untergeordneten Zone, die den KSK enthält. DS-Einträge verweisen auf den nächsten Schlüssel in der Vertrauenskette.

Die Vertrauenskette

Da jeder kryptografische Schlüssel einen nachfolgenden kryptografischen Schlüssel signiert, wodurch jede DNS-Zone die ihr untergeordnete Ebene validieren kann, entsteht eine sogenannte Vertrauenskette. An der Spitze der Kette stehen Vertrauensanker.

Jede Ebene des Domain Name Systems führt eine Validierung durch. Nach Überprüfung der Authentizität der Antworten erhält das Client-Gerät die Antwort. Wenn die Vertrauenskette an irgendeiner Stelle unterbrochen wird und die Überprüfung der Einträge nicht erfolgen kann, antwortet der DNS-Server stattdessen mit dem DNS-Antwortcode „SERVFAIL“.

DNSSEC Schritt für Schritt erklärt

Die grundlegenden Schritte der DNSSEC-Auflösung und -Validierung laufen wie folgt ab:

  1. Zunächst fordert der Client einen A-Eintrag für example.com von seinem lokalen validierenden rekursiven Server an.
  2. Der validierende rekursive Server folgt dem normalen Rekursionspfad von der Root bis hinunter zu den autoritativen Servern der Zone für example.com.
  3. Anschließend fordert der rekursive Server den A-Eintrag vom autoritativen Server an.
  4. Der autoritative Server antwortet beispielsweise mit dem A-Eintrag und dem entsprechenden RRSIG-A-Eintrag für example.com.
  5. Anschließend fragt der rekursive Server den autoritativen Server von example.com nach dem DNSKEY-Eintrag für die Zone ab.
  6. Der autoritative Server für example.com gibt den DNSKEY-Eintrag und den entsprechenden RRSIG-DNSKEY-Eintrag für example.com zurück.
Steps 1 to 6 of DNSSEC resolution and validation
  1. Als Nächstes fragt der rekursive Server bei .com den DS-Eintrag für example.com ab.
  2. Der .com-Server antwortet beispielsweise mit dem DS-Eintrag und dem entsprechenden RRSIG-DS-Eintrag für example.com.
  3. Anschließend fordert der rekursive Server den DNSKEY-Eintrag vom .com-Server an.
  4. Der .com-Server antwortet mit dem DNSKEY-Eintrag und dem entsprechenden RRSIG-DNSKEY-Eintrag.
Steps 7 to 10 of DNSSEC resolution and validation
  1. Anschließend fordert der rekursive Server den DS-Eintrag von .com von den Root-Servern an.
  2. Die Root-Server geben den DS-Eintrag und den entsprechenden RRSIG-DS-Eintrag für .com zurück.
  3. Anschließend fragt der rekursive Server den DNSKEY-Eintrag für die Root ab.
  4. Der Root-Server gibt den DNSKEY-Eintrag und den entsprechenden RRSIG-DNSKEY-Eintrag für die Root zurück.
  5. Schließlich verwendet der rekursive Server den konfigurierten Vertrauensanker, um den DNSKEY-Eintrag und den entsprechenden RRSIG-DNSKEY-Eintrag für die Root-Zone zu validieren. DNSSEC-fähige Resolver verfügen bereits über den erforderlichen Schlüssel zur Validierung von Antworten von Root-Servern.
Steps 11 to 15 of DNSSEC resolution and validation

Zwischengespeicherte Antworten

Diese Schritte beziehen sich auf die erste Abfrage einer Zone, sofern die Antwort noch nicht im Cache gespeichert ist. Sobald sie im Cache gespeichert ist, wurden bereits alle Validierungen entlang der Kette bis zur Root-Zone durchgeführt. In diesem Fall muss ein Client, der einen anderen A-Eintrag von example.com anfordert, lediglich die Signatur des A-Eintrags validieren.

Die 10-teilige Webinar-Reihe des Internet Systems Consortium zum Thema DNSSEC beleuchtet den Prozess ausführlich. Das vierte Webinar zum Thema DNSSEC-Auflösung und -Validierung bietet hilfreiche Einblicke.

Abwehr von Man-in-the-Middle-Angriffen

Ist DNSSEC aktiviert, lehnt der validierende Resolver bei einem versuchten Man-in-the-Middle-Angriff die Antwort eines betrügerischen Servers ab, da dieser nicht über die kryptografischen Daten verfügt, die seine Herkunft bestätigen. Der Resolver leitet die gefälschte Antwort nicht an den Client weiter, sodass dieser nicht auf die betrügerische Website weitergeleitet wird.

Darüber hinaus bietet DNSSEC einen Nachweis der Nicht-Existenz (PNE). Mit PNE können DNSSEC-signierte Zonen nachweisen, dass eine NXDOMAIN-Antwort (eine Antwort vom Typ „Diese Website existiert nicht“) legitim ist. Dies verhindert, dass ein Angreifer im Rahmen eines Angriffs eine gefälschte NXDOMAIN-Antwort einfügt. Zwar wird ein Client dadurch nicht auf den böswilligen Server des Angreifers umgeleitet, doch für jeden, der sich hinter dem betroffenen Cache-Server befindet, sieht es so aus, als wären Sie offline.

BlueCat erleichtert die Implementierung von DNSSEC

Wenn es darum geht, die Implementierung von DNSSEC zu planen, unterschätzt man leicht dessen Komplexität und den erforderlichen Wissensaufwand. Ohne eine zentralisierte und automatisierte DNS-Infrastruktur ist dies eine noch größere Herausforderung.

Die manuelle Implementierung erfordert zumindest die Pflege der Einträge und den Schlüsselwechsel (regelmäßige Aktualisierung der Schlüssel, um das Risiko einer Kompromittierung zu verringern).

Darüber hinaus gibt es jedoch wichtige Schritte, wie das erneute Signieren von RRsets und Zonen, die bei jeder Änderung an einer Zone durchgeführt werden müssen. Wird einer dieser Schritte falsch ausgeführt, führt dies dazu, dass die Zone nicht mehr erreichbar ist. Die Pflege der PNE-Kette ist zudem einer der mühsamsten – und am leichtesten zu verfehlenden – Aspekte bei der manuellen Verwaltung von DNSSEC-signierten Zonen.

Wenn Sie Ihre DNS-Infrastruktur mit BlueCat zentralisieren, werden diese DNSSEC-bezogenen Aufgaben automatisch im Hintergrund ausgeführt:

  • Generierung kryptografischer Schlüsselpaare
  • Generierung und Pflege der PNE-Kette (mit NSEC- oder NSEC3-Einträgen) für jeden Eintrag in der Zone
  • Signieren von Zonen und allen zugehörigen DNS-Einträgen
  • Generierung von DS-Einträgen für übergeordnete Zonen
  • Nahtlose Erneuerung von KSKs und ZSKs nach einem festgelegten Zeitplan
  • Generierung neuer KSKs oder ZSKs im Falle eines Notfall-Rollovers
  • Überwachung des Erfolgs und des Scheiterns der Schlüsselgenerierung
  • Manuelle Generierung neuer Schlüsselpaare bei fehlgeschlagener automatischer Generierung

BlueCat vereinfacht DNSSEC, indem es Kunden ermöglicht, das System einfach über eine zentrale Plattform zu konfigurieren. Erfahren Sie, wie die BlueCat-Plattform Ihnen helfen kann.