Ein Plus an Sicherheit bieten DNSSEC die sich leider nur schwer durchsetzen.
Dabei ist die Technik verschiedene Serverdienste zusätzlich abzusichern eine interessante Lösungsmöglichkeit.
 
Bei der Suche nach DNSSEC findet man häufig zwei Kernaussagen:
1. Einsatz mit SMTP Diensten
 
2. mangelnde Unterstützung
 
Um so mehr ein Grund den Nutzen dieser Protokolle bzw. den Nutzen des DANE Protokolls einmal genauer zu beschreiben und auch die damit verbundenen Probleme zu beleuchten.
 
1. DNSSEC (Domain Name System Security Extension)
 
DNSSEC ist eine Erweiterung zum DNS Protokoll mit dem Ziel die Umleitung und Manipulation von DNS Informationen zu erschweren. Es hat nichts mit Verschlüsselung zu tun sondern ausschließlich mit der Signatur.
Es soll hier nur gewährleistet werden, dass der übermittelte DNS Eintrag auch tatsächllich den echten Einträgen entspricht und nicht auf dem Weg manipuliert und verändert wurde.
 
Auch das andere Protokolle wie IP bereits angegriffen wurden, wird dadurch nicht ausgeschlossen. Denn die Daten werden unverschlüsselt von DNS zu Resolver oder Client übertragen.
 
Probleme:
 
a) Obwohl das Protokoll aus den 90er Jahren stammt, wird es bisher kaum unterstützt und genutzt.
b) Um das Protokoll zu nutzen müssen viele Stellen mitspielen. Dazu gehört als Erstes der Top-Level wie ".de" und viele weitere. Zahlreiche Top-Level Domains unterstützen DNSSEC aber längst nicht alle.
c) Der Top-Level-Domain Verwalter muss DNSSEc ebenso unterstützen, wie der Domain-Handler und Provider selber, was insbesondere in Deutschland ein Problem ist.
d) Nameserver müssen das Protokoll ebenfalls unterstützen.
 
Warum so komplex?
 
Von SSL-Zertifikaten kennt nahezu jeder das System. Es gibt eine Zertifizierungsstelle, der das CSR (Certificate Request) eingereicht und an dessen Ende das Zertifikat ausgestellt wird. Es gibt hier also eine Hirarchie.
 
Im Fall von DNSSEC ist es ganz ähnlich. Die eigene Domain wird auf den Nameservern signiert. Die oberste "Ebene" des DNS-Baums wird ebenfalls signiert. Die jeweiligen öffentlichen Schlüssel werden im DNS veröffentlicht. Anschließend wird der eigene, oberste Schlüssel in der Zone eingetragen und von dort signiert.
 
Es entsteht dadurch ein sogenannter "Chain of Trust" bei dem im Idealfall von oben (z.B. .de) bis zu letzten Subdomain jede Signatur durch die nächste bestätigt wird. So muss die auswertende Anwendung nur der "obersten Zone" vertrauen und dessen öffentlicher Schlüssel bekannt sein.
 
Ein Resolver ist dabei für die Auswertung der Informationen zuständig und verweigert die Verbindung, wenn der "Chain of Trust" zum Beispiel durch einen Angriff unterbrochen wurde. Das bedeutet, dass bei Attacken wie DNS-Spoofing die Verbindung verweigert werden würde, weil die Signatur ganz fehlt oder falsch ist.
 
Wer kann Resolver sein?
 
Der Resolver könnte beim Provider stehen, was allerdings nicht unbedingt sehr sinnvoll ist. Bei einem Angriff über Ihr WLAN Netz ist der Resolver beim Provider nutzlos. Doch kann ein Resolver durchaus auch auf dem Client (z.B. Webbrowser) sein.