Was ist DNSSEC und wie funktioniert es?

Vereinfachte Signaturvalidierung

Je nach Situation fügt DNSSEC einen der folgenden DNS-Datensatztypen hinzu, um die Signaturvalidierung zu erleichtern:

• Resource Record Signature (RRSIG): enthält eine kryptografische DNSSEC-Signatur für einen Datensatz

• DNSKEY: enthält einen öffentlichen Signaturschlüssel

• DS: enthält den Hash eines DNSKEY-Datensatzes

• NSEC und NSEC3: stellt einen Link zum folgenden Datensatznamen in der Zone bereit und listet außerdem Datensatztypen auf, die für den Datensatznamen verfügbar sind

• CDNSKEY und CDS: überträgt den angeforderten DS-Status von der untergeordneten Zone in die übergeordnete Zone und fordert Aktualisierungen von DS-Datensätzen in der übergeordneten Zone an 

Soll ich DNSSEC auf meiner Domain aktivieren?

DNSSEC schützt Ihre Domain vor Cache Poisoning und Fälschungen von Antworten. Es ist eine entscheidende Ergänzung für Ihre Domain, denn das heutige digitale Klima verlangt, dass die Architektur eines Website-Eigentümers von Anfang bis Ende geschützt wird. Denn ein erfolgreicher DNS-Angriff kann den Ruf einer Marke stark schädigen. Die DNS-Auflösung erfolgt, bevor ein Nutzer jemals mit der Anwendung einer Website interagiert. Wenn das DNS von einem Angreifer abgefangen wird, kann ein Nutzer, der eine Website besuchen möchte, mit einer gefälschten Website (die den Nutzer täuschen soll) anstelle der beabsichtigten Website interagieren. Die aggressive Cache-Architektur des Protokolls erschwert die schnelle Korrektur schädlicher Datensätze. 

Selbst wenn eine Website durch leistungsstarke Firewalls unterstützt wird, sind die Daten und Technologien eines Endnutzers gefährdet, wenn die DNS-Architektur einer Website durch die Verwendung von DNSSEC nicht ausreichend geschützt ist. 

Gruppieren von DNS-Datensätzen in RRSets

Die Integration von DNSSEC in Ihre Domain beginnt damit, DNS-Einträge nach Name und Datensatztyp in Resource Record Sets (RRSets) zu gruppieren. Das DNS selbst ist in DNS-Zonen aufgeteilt. Eine Zone ist ein Teil des gesamten DNS-Namespace, der von der gesamten Organisation des DNS-Besitzers oder einem Netzwerkadministrator überwacht wird. Diese Zone ermöglicht eine gründliche Wartung von DNS-Komponenten, wie z. B. autorisierenden Nameservern. 

Jede Zone wird durch Koppeln der öffentlichen und privaten Schlüssel signiert, die als Zonensignaturschlüssel (Zone Signing Key, ZSK) bezeichnet werden. Die resultierende Signatur wird als RRSIG-Datensatz in der Zonendatei selbst veröffentlicht. Beispiel: Wenn der Hostname „www.dsnsecexample.com“ sowohl einen A- als auch einen AAAA-Datensatz enthält, veröffentlicht die Zonendatei einen entsprechenden RRSIG-Datensatz für jede IP-Version.

Durch das Isolieren der DNS-Zonen voneinander werden benachbarte Zonen in dem unwahrscheinlichen Fall geschützt, dass eine Zone von einem Angreifer infiziert wird.

Resource Record Signatures

Ein RRSIG-Datensatz enthält eine digitale DNSSEC-Signatur eines RRSet. Diese digitalen Signaturen werden zur Authentifizierung aller Daten verwendet, die sich in den signierten RRSets befinden. Resolver können die Signatur mit einem öffentlichen Schlüssel verifizieren, der in einem DNSKEY-Datensatz gespeichert ist.

Diese RRSets für Datensatztypen und eigene Domainnamen werden in einer signierten DNS-Zone gespeichert. Wenn ein Domain Name Server den privaten Schlüssel eines ZSK-Paares verwendet, um RRSets innerhalb einer bestimmten Zone zu signieren, werden die digitalen Signaturen jedes RRSets in einem RRSIG-Datensatz gespeichert. Daher enthält eine signierte Zone einen RRSIG-Datensatz für jede RRSet.

Ein RRSIG-Datensatz besteht aus folgenden Komponenten:

• Abgedeckter Typ: der vom RRSIG abgedeckte DNS-Datensatztyp

• Algorithmus: ein kryptografischer Algorithmus, der die endgültige Signatur generiert

• Labelzahl: die Anzahl der Label im ursprünglichen RRSIG-Datensatznamen (zur Validierung von Platzhaltern)

• Ursprüngliche TTL: TTL-Wert des abgedeckten Datensatzes

• Signaturablauf: der Zeitpunkt, zu dem die Signatur abläuft

• Signaturstart: der Zeitpunkt, zu dem die Signatur ursprünglich erstellt wurde

• Key-Tag: ein numerischer Wert zur Identifizierung des DNSKEY-Datensatzes, der zur Validierung dieser RRSIG-Signatur verwendet wurde

• Name des Unterzeichners: der Name des DNSKEY-Datensatzes, der zur Validierung dieser Signatur verwendet wurde

• Signatur: die kryptografische Signatur, die zur Verifizierung der Übertragung verwendet wurde

Zonensignaturschlüssel

Ein Zonensignaturschlüssel (ZSK) ist ein Schlüssel zur Authentifizierung übertragener Daten. Der ZSK ist ein Aspekt des gleichen RRSet wie der Schlüsselsignaturschlüssel (Key Signing Key, KSK), der einen entsprechenden privaten Schlüssel zum Signieren dieses DNSKEY-RRSet hat. Jede Zone verfügt über ein ZSK-Paar. Eine DNSSEC-fähige Zone kündigt den öffentlichen ZSK als DNSKEY-Datensatz an, sodass Resolver RRSIG-Werte authentifizieren können. 

Die DNSSEC-Validierung unterscheidet nicht zwischen ZSK und anderen DNSSEC-Authentifizierungsschlüsseln. Dadurch ist es möglich, einen Schlüssel sowohl als Schlüsselsignaturschlüssel als auch als ZSK zu verwenden. Eine erfolgreiche Überprüfung zeigt an, dass DNS-Einträge während der Übertragung weder gefälscht noch bearbeitet wurden, da nur der Zonenadministrator Zugriff auf den privaten ZSK hat.

Der ZSK entspricht dem privaten Schlüssel, der zum Signieren einer Zone verwendet wird. Er ist in der Regel Teil desselben RRSets wie der signierende öffentliche Schlüssel, der dem privaten Schlüssel entspricht, der diese RRSet signiert. 

Schlüsselsignaturschlüssel

Der Schlüsselsignaturschlüssel (Key Signing Key, KSK) ist ein rechenintensiveres Schlüsselpaar, das implementiert wird, um die Sicherheit von DNSKEY-Datensätzen weiter zu verbessern. Er wurde eingeführt, um den Verwaltungsaufwand für Zonenadministratoren zu verringern. Der KSK entspricht einem privaten Schlüssel und wird verwendet, um andere Authentifizierungsschlüssel für eine bestimmte Zone zu signieren. Üblicherweise signiert der private Schlüssel, der einem KSK entspricht, einen ZSK. Dieser ZSK verfügt selbst über einen entsprechenden privaten Schlüssel zum Signieren anderer Daten in der DNS-Zone. Resolver authentifizieren diese digitale Signatur mit dem entsprechenden DNSKEY-Klartext-Datensatz, der den öffentlichen KSK bereitstellt. 

KSKs und ihre entsprechenden DS-Datensätze werden nur in regelmäßigen Abständen aktualisiert. ZSKs werden dazu im Gegensatz häufiger aktualisiert. Aus Sicherheitsgründen und betrieblicher Sicht besteht die ideale Architektur daher daraus, einen häufig rotierten ZSK mit einem separaten, beständigeren KSK selbst zu selbst zu signieren. Diese Implementierung schützt die DNS-Zone besser vor potenziellen Bedrohungen und minimiert gleichzeitig den Umfang der laufenden DNSSEC-Wartung.

DS-Datensätze

DNSSEC hat den DS-Datensatz (Delegation Signer) eingerichtet, um ein "Vertrauensketten"-Modell mit öffentlichen DNS-Resolvern zu erstellen. In diesen Szenarien könnten böswillige Akteure DNS-Antworten theoretisch fälschen und einen gefälschten DNSKEY-Datensatz zurückgeben, der die Integrität der Zone kompromittiert. DS-Datensätze veröffentlichen einen Fingerabdruck des öffentlichen KSK in der übergeordneten Zone.

Während der Validierung stellt der Resolver sicher, dass der DS-Datensatz der übergeordneten Zone mit dem entsprechenden DNSKEY-Datensatz der untergeordneten Zone übereinstimmt, um die Legitimität des Schlüsselpaars des untergeordneten Elements zu bestätigen. Diese Vertrauenskette wird bis zur Root-Zone aufrechterhalten, die in die meisten rekursiven Resolver integrierte Vertrauensanker enthält. 

NSEC und NSEC3

Mithilfe des NSEC-Datensatzes (Next Secure) kann festgestellt werden, ob ein Name innerhalb einer bestimmten Zone existiert. Er wurde eingeführt, um das „Denial-of-Existence“-Authentifizierungsproblem zu lösen, wenn Datensätze in einer Zone nicht existieren. Ein Angreifer kann diese Schwachstelle ausnutzen und eine Website unbrauchbar machen, indem er eine NXDOMAIN-Antwort für den Hostnamen der Website fälscht. 

NXDOMAIN behebt diese Sicherheitsanfälligkeit, indem es einen NSEC-Datensatz einschließt, der den nächsten kanonischen Datensatz in der Zone anzeigt, der existiert, wenn eine Abfrage nach einem nicht vorhandenen Namen empfangen wird, sowie den Datensatztyp, der unter diesem Namen angezeigt wird. 

Wenn beispielsweise die Zone „example.com“ sortiert würde und „beta.example.com“ der erste Datensatz wäre, würde eine Abfrage für „alpha.example.com“ zu einer NXDOMAIN-Antwort und einem NSEC-Datensatz führen, der auf „beta.example.com“ verweist. NSEC-Datensätze werden wie alle anderen Aufzeichnungen vom ZSK signiert und haben eine entsprechende RRSIG. Daher erfordert eine NXDOMAIN-Antwort einen authentifizierten RRSIG-NSEC-Datensatz, der gültig ist.

NSEC3 wurde entwickelt, um das Problem zu lösen, dass NSEC-Datensätze verwendet werden, um alle gültigen Datensätze in einer Zone aufzulisten. NSEC3 verhält sich identisch mit NSEC, außer der Tatsache, dass der nächste sichere Name in der Zone gehasht wird, anstatt ihn in Klartext anzuzeigen. Dies sichert Informationen und verhindert, dass der Zoneninhalt per Zone Walking ausgelesen wird.

DNSSEC-Betriebsmodi

Offline-Signierung von statischen Zonen

Es gibt viele DNSSEC-Betriebsmodi. Jeder davon verfügt über einen eigenen einzigartigen Ansatz, wie Daten in der DNS-Zone signiert werden. Einer dieser Modi ist die Offline-Signierung statischer Zonen. Dies ermöglicht einen starken Schutz des Signiersystems vor externen Bedrohungen. Dieses Betriebsmodell behält alle privaten Schlüssel auf einem Rechner, der derzeit nicht mit dem Netzwerk verbunden ist gefunden. Es ist wirksam in Fällen, in denen Informationen in der DNS-Zone nicht häufig geändert werden.

Zentrale Online-Signierung

Die zentrale Online-Signierung ist ein weiterer wiederkehrender Modus des DNSSEC-Betriebs. In Fällen, in denen Administratoren Daten in einem dedizierten DNS mit eingeschränktem Zugriff signieren, ermöglicht die zentrale Online-Signierung eine schnelle Änderung und Veröffentlichung von DNS-Daten in der Zone. Wie bei der Offline-Signierung statischer Zonen führt bei der zentralen Online-Signierung entweder ein einzelner oder replizierter zentraler Signaturgeber die gesamte Datensignierung durch. Anschließend werden die neu signierten Daten an die autoritativen DNS-Server weitergeleitet.

„On-the-Fly“-Signierung

Die „On-the-Fly“-Signierung von Daten ist ein DNSSEC-Betriebsmodus, der es den autoritativen DNS-Servern ermöglicht, Daten nach Bedarf zu signieren. Das Problem bei diesem Ansatz besteht darin, dass er zu einer Situation führen kann, bei der der Schlüssel auf einer Vielzahl von verschiedenen Computern mit direktem Zugang zum Internet vorhanden ist. Dadurch eröffnen sich Angreifern mehr Möglichkeiten für den externen Zugriff auf den Namespace. Die Schlüsselverteilung – wenn ein Sender einen geheimen Schlüsselwert auswählt und diesen dann sicher an den Empfänger sendet – wird auch durch die Signierung bei laufendem Betrieb komplexer und kann die Rechenanforderungen auf jedem Knoten unnötig erhöhen.

Risiken der Einbeziehung von DNSSEC

DNSSEC ist zwar wichtig, um die Netzwerksicherheit zu erhöhen, es kann aber unbeabsichtigt kritische Schwachstellen mit sich bringen. DNSSEC kann das Risiko für und die Auswirkungen von DDoS-Angriffen (Distributed Denial of Service) erhöhen, bei denen ein Server, ein Service oder ein Netzwerk durch den Traffic mehrerer Geräte auf einmal unterbrochen wird. DNSSEC erhöht die Anzahl der DNS-Abfrageantworten, da die Technologie zusätzliche Felder und kryptografische Informationen benötigt, um Datensätze ordnungsgemäß zu überprüfen. Dies bedeutet, dass Reaktionen mit hohem Volumen böswilligen Akteuren weitaus größere Angriffsvolumen gegen eine Zone ermöglichen können, als dies ohne DNSSEC möglich wäre.

Drei-Wege-Handshake erforderlich

Da das Transmission Control Protocol (TCP) ein verbindungsorientiertes Protokoll ist, ist es langsam und erfordert einen Drei-Wege-Handshake. DNS (und damit DNSSEC) verlässt sich aus diesem Grund auf das User Datagram Protocol (UDP). Dies ist ein schnelleres, aber riskanteres Protokoll, das weder über Anforderungen zum Öffnen, Warten oder Beenden einer Verbindung verfügt, noch die Lieferung signierter Daten an sein Ziel garantieren kann. UDP bietet nur die grundlegendste Fehlerermittlungsfunktion in Form von Prüfsummen. Da es keinen Handshake erfordert, können übertragene Daten zudem leicht von Angreifern abgefangen werden.

UDP-Spoofing ist, wenn Angreifer ein gültiges UDP-Anfragepaket erstellen, das die IP-Adresse ihres Ziels als UDP-IP-Quelladresse auflistet. Der Angreifer kann dann die gefälschte Quell-IP an einen Zwischenserver senden, der alle seine UDP-Antwortpakete sendet und so eine Antwort erzeugt, die weit größer ist als das Anfragepaket. Diese Antwort reicht aus, um die Menge an Angriffstraffic zu erhöhen, der an die IP-Adresse des Ziels gesendet wird.

Dadurch erhöht sich auch die Länge von DNS-Abfragen, was den Schweregrad der Angriffe verstärkt. Das Ausmaß, in dem diese Angriffe verstärkt werden, kann als Verhältnis der Antwortgröße zur Anfragegröße ausgedrückt werden. Wenn ein Angreifer beispielsweise eine Anfrage von 64 Byte an einen DNS-Server sendet, kann er mehr als 3.400 Byte schädlichen Traffic generieren, der an ein Opfer weitergeleitet wird. 

Den Ablauf des Root-Signing verstehen

Ein DNS-Root-Signing ist ein strenges Verfahren, um die öffentlichen Schlüsselinformationen der Root-DNS-Zone für die nächsten Monate zu signieren. Dieser Prozess stellt sicher, dass es äußerst unwahrscheinlich ist (kleiner als 1:1.000.000), dass eine Gruppe von Angreifern den Root-Signing-Schlüssel kompromittieren kann. Er findet an einem von zwei Standorten statt, die den Root-KSK schützen. Der bei diesem Vorgang verwendete private Signaturschlüssel ist ein Schlüssel zum Entsperren des mit DNSSEC gesicherten Internets.

Lösen von Problemen der Root-DNS-Zone ohne übergeordnetes Element

Dieser Prozess löst das Problem von Root-DNS-Zonen ohne übergeordnetes Element. Dies ist eine Zone, die im Hinblick auf die Integrität nicht von einer übergeordneten Zonen überwacht werden kann. Er erfordert eine Handvoll Teilnehmer, darunter einen Prozessadministrator, einen internen Zeugen, einen Controller für den Anmeldedaten-Safe, einen Controller für den Hardware-Safe und drei Kryptooffiziere. Jedes Mitglied ist ein Mitarbeiter der Internet Corporation for Assigned Names and Numbers (ICANN), abgesehen von den Kryptooffizieren. Diese sind ehrenamtlich aus der Internet-Community tätig.

Zugriff auf den Anmeldedaten-Safe

Es gibt zwei Safes: den Anmeldedaten-Safe und den Hardware-Safe. Für Zugriff auf den Stammschlüssel ist der Zugriff auf beide notwendig. Der Controller für den Anmeldedaten-Safe öffnet den Anmeldedaten-Safe, der Schließfächer enthält – jedes von ihnen benötigt zwei Schlüssel, die vom Prozessadministrator und einem Kryptooffizier aufbewahrt werden. Diese Schließfächer enthalten eine Bedienerkarte und eine Sicherheitsberechtigungskarte, die zum Öffnen des Hardware-Sicherheitsmoduls im Hardware-Safe erforderlich sind. Die Karten werden in Kunststoffbehältern aufbewahrt, die in manipulationssichere Beutel verpackt sind und im Anmeldedaten-Safe aufbewahrt werden.

Öffnen des Hardware-Safes

Der Hardware-Safe-Controller tritt dann in den Tresorraum ein und öffnet den Hardware-Safe mit dem Hardware-Sicherheitsmodul. Der Hardware-Safe enthält außerdem einen Laptop, der über keinen Akku und keine Festplatte verfügt und für das Senden von Befehlen an das Sicherheitsmodul vorgesehen ist. Dieser wird verwendet, um die Root-DNS-Schlüssel im Prozess zu signieren. Jeder Aspekt wird akribisch aufgezeichnet und live für die Nachwelt ins Internet gestreamt.

Einbeziehen der Kryptooffiziere

Sobald der Prozess beginnt, müssen die Kryptooffiziere ihre Bedienerkarten an den Prozessadministrator übergeben, der den Laptop von einer DVD bootet und den USB-Vorgang initialisiert, der die Prozessprotokolle aufzeichnet. Dieser Administrator aktiviert dann mithilfe der drei Bedienerkarten das Sicherheitsmodul. Dieses wird anschließend über ein Ethernet-Kabel mit dem Laptop verbunden. Die Schlüsselsignieranfrage wird in den Laptop geladen und der PGP-Hash der Schlüsselsignieranfrage wird berechnet. Dieser wird dann überprüft, um sicherzustellen, dass er mit dem bereitgestellten Hash identisch ist. An diesem Punkt signiert der Prozessadministrator die Schlüsselsignieranfrage mit dem privaten KSK, wodurch eine Sammlung digitaler Signaturen erstellt wird: der RRSIG-Datensatz. 

Implementieren Sie DNSSEC noch heute, um die Domainsicherheit zu erhöhen 

Bereits ein erfolgreicher DNS-Angriff auf Ihre Domain ist genug, um die Integrität Ihres digitalen Ökosystems und den Ruf Ihrer Marke als Ganzes dauerhaft zu schädigen. Kryptografische DNSSEC-Signaturen verstärken den DNS-Auflösungsprozess, um Ihre Domain vor Cyberbedrohungen wie Cache Poisoning und Fälschungen von Antworten zu schützen. Letztendlich ermöglicht dies End-to-End-Sicherheit für die Daten und Technologien Ihres Unternehmens und Ihrer Endnutzer. 

Entdecken Sie die verschiedenen DNS-Lösungen von Akamai

Akamai erweitert seine Plattform beständig, um eine Reihe von erstklassigen DNS-Services für Domaineigentümer bereitzustellen:

• Stabilität und Ausfallsicherheit der Domain Edge DNS

• Lastausgleich für Ihr Rechenzentren, Cloudbereitstellungen und CDNs mit Global Traffic Management

• Riesige Skalierung Ihrer Anwendung mit Application Load Balancer (ALB) Cloudlet

• Stellen Sie sicher, dass jedes Gerät in Ihrem Netzwerk ein DNS-Sicherheitstool nutzt, und aktivieren Sie Ihren DNS-Resolver, damit dieser ein Sicherheitstool wird, mit Secure Internet Access Enterprise

• Werden Sie Teil der Akamai-Community, und greifen Sie auf viele DNS-Ressourcen zu

• Sind Sie ein DevOps-Experte? Werfen Sie einen Blick auf unsere Entwickler-Community

• Sie benötigen weitere Hilfe? Nehmen Sie noch heute Kontakt auf. 

Ursprünglich veröffentlicht am 19. März 2021; aktualisiert im Juni 2022.