DNSSEC (Domain Name System Security Extensions) umfasst sicherheitsbezogene Erweiterungen des DNS-Standards. Spezifiziert wird DNSSEC u.a. in folgenden RFCs:

• RFC4033
• RFC4034
• RFC4035

DNSSEC ermöglicht es, DNS-Daten (ganze Zonen und Antworten auf einzelne Anfragen) digital zu signieren. Die Signatur beruht auf Public-Key-Kryptographie, welche auf öffentlichen Schlüsseln (public key) und geheimen Schlüsseln (private key) basiert. Anhand des öffentlichen Schlüssels können solche Signaturen beim Empfänger der Daten verifiziert werden. Die jeweils übergeordneten Zonen (z.B. die zugehörige TLD-Zone oder die Root-Zone für die TLDs) können den verwendeten Schlüssel mit ihrem Schlüssel unterschreiben und auf diese Weise eine Vertrauenskette erstellen, die im Idealfall mit der Signatur der Root-Zone beginnt. Der public-Key ist öffentlich zugänglich und kann zur Verifizierung der Signatur verwendet werden. Die Signatur selbst kann nur mit Kenntnis des private-Keys erstellt werden.

DNSSEC bewirkt zwei Verbesserungen in Bezug auf die Sicherheit des DNS:

• Quellenauthentifizierung: Bei korrekter Signierung und vorhandener Vertrauenskette ist sichergestellt, dass die Quelle der DNS-Daten den geheimen Schlüssel kennt und die Daten mit diesem Schlüssel signiert wurden. Der Empfänger weiß somit, dass der Domaininhaber oder der zuständige Provider die Daten signiert haben und die Quelle vertrauenswürdig ist.
• Datenintegrität: Aufgrund der Signatur ist sichergestellt, dass die Daten auf dem Weg zwischen Quelle und Ziel nicht von Dritten manipuliert werden können.

Lediglich nach Kompromittierung des Schlüssels (Zugänglichkeit des privaten Schlüssels durch Dritte oder die mathematisch komplexe Kryptoanalyse der Daten bei der der private Schlüssel ermittelt wird) sind beide Vorteile nicht mehr gegeben. Aus diesem Grunde werden in regelmäßigen Abständen Schlüsselwechsel vollzogen.

Das DNS-System ohne DNSSEC besitzt die beiden o.g. Sicherheitsmerkmale (Quellenauthentifizierung und Datenintegrität) nicht. Es gibt zwar rudimentäre Verfahren um möglichst sicherzustellen, dass Nameserver auf ihre Anfragen eine authentische Antwort erhalten, allerdings ist deren Wirksamkeit mindestens seit Bekanntwerden der [Kaminski-Attacke] überaus fraglich. Zwar wurden die entsprechenden Verfahren (Zufalls-Query-IDs und Zufalls-Anfrage-Portnummer) verstärkt, so dass die Wahrscheinlichkeit eines erfolgreichen Angriffs reduziert wird, allerdings bietet nur eine digitale Signatur der Daten einen theoretisch fundierten und ausreichend sicheren Schutz. Die genaue Funktionsweise und die Hintergründe von Kaminskis DNS-Angriff sind beispielsweise unter http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html umfassend dargestellt.

Weitere Informationen:

• http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

DNSSEC stellt sicher, dass die Quelle der DNS-Daten korrekt ist und dass die Daten während der Übertragung nicht modifiziert wurden. Es hilft also sicher zu stellen, dass z.B. die Namensauflösung im DNS korrekt durchgeführt wird und zu einem angefragten Domainnamen die korrekte IP-Adresse zurückgeliefert wird. Auch alle weiteren via DNS verbreiteten Daten (z.B. Mailexchange-Records, Domainkeys/DKIM) werden auf diese Weise vor Manipulation geschützt.

Folgendes einfache Beispiel: Geben Sie den Domainnamen Ihres Online-Banking-Portals im Browser ein, so kann DNSSEC sicherstellen, dass Ihr Rechner sich mit der korrekten, von der Bank veröffentlichten IP-Adresse für den Webserver der Banking-Portals zu verbinden versucht. Es kann nicht mehr von Dritten eine falsche IP-Adresse eingeschleust werden, hinter der sich dann eine täuschend echte Immitation des Online-Banking-Portals verbirgt. Wird von Dritten eine Manipulation versucht, so schlägt die DNSSEC Validierung fehl und das Online-Banking-Portal kann nicht erreicht werden, da sich keine verifizierbar korrekte IP-Adresse ermitteln lässt.

DNSSEC wirkt lediglich auf Basis des DNS und sichert nicht die der DNS-Anfrage vorausgehenden und darauf folgenden Kommunikationsschritte ab. Es werden z.B. keine Vertipper bei der Eingabe von Domainnamen verhindert, was ein hohes Risiko darstellt. Auch wird nach der DNS Namensauflösung nicht der Verbindungsaufbau mit der via DNS erhaltenen IP-Adresse gesichert oder verifiziert (fehlerhaftes Routing/absichtliches Manipulieren von Routen kann weiterhin zu einem falschen Webserver führen), es wird nicht sichergestellt, dass die Daten der Kommunikation mit der erhaltenen IP-Adresse geschützt werden (Aufgabe von SSL).

Randbemerkung: Es kann allerdings im DNS die Signatur des SSL-Zertifikats abgelegt werden. Wenn diese Information wiederum DNSSEC signiert ist, lässt sich beim Empfänger sicherstellen, dass der korrekte Webserver kontaktiert wurde und das dort verwendete SSL-Zertifikat gültig und korrekt ist.

DNSSEC ist also kein "Rumdum-Sicher-Paket" was die Kommunikation im Internet angeht, sondern trägt lediglich im Bereich DNS einen Teil dazu bei.

DNSSEC existiert bereits seit 1997 als RFC (RFC2065, überarbeitet 1999 als RFC2535); die Spezifikation erwies sich aber nicht als praxistauglich und wurde 2005 in überarbeiteter Version fertiggestellt (RFC4033 RFC4034 und RFC4035). RFC4034-4035 erwiesen sich als problematisch, da in der damaligen Fassung das Auflisten aller Zoneneinträge möglich war, was durch die Einführung von NSEC3 (RFC5155) behoben wird. Bisher wurde DNSSEC grundsätzlich als sinnvolle und gute Idee betrachtet, aber die Komplexität und das damit einhergehende Risiko für Administrationsfehler, die zur Nicht-Erreichbarkeit von Domains führen lönnen, führte dazu, dass nur extrem wenige TLDs sich mit DNSSEC befassten oder es sogar einführten. Dies hat sich spätestens seit Bekanntwerden der von Kaminsky entdeckten Schwachstelle im Protokoll geändert.

Inzwischen ist DNSSEC für eine Reihe von Topleveldomains produktiv verfügbar, bei anderen in Vorbereitung oder im Testbetrieb. Im Detail (Stand 05/2010) sind dies die folgenden TLDs:

ccTLDs

• .bg: produktiv (https://www.register.bg/)
• .br: produktiv (http://registro.br/info/dnssec-policy-en.html)
• .ch/.li: produktiv (http://www.nic.ch/)
• .cz: produktiv (http://www.nic.cz/dnssec/)
• .de: Testbed von 03/2010 bis 12/2010. Danach wird anhand der Ergebnisse über eine Einführung entschieden. (http://www.denic.de/domains/dnssec.html)
• .pr: produktiv (http://dnssec.nic.pr/)
• .se: produktiv (http://www.iis.se/en/domaner/dnssec/)
• .eu: Testbed (http://www.eurid.eu/en/content/eu-plans-support-dnssec)

gTLDs

• .com: In Planung (http://www.verisign.com/domain-name-services/domain-information-center/dnssec-resource-center/)
• .org: Produktiv (http://www.pir.org/dnssec)
• .gov: Produktiv (http://www.dotgov.gov/dnssecinfo.aspx)
• .museum: Produktiv (http://www.nic.museum/) (http://www.icann.org/en/registries/rsep/musedoma-request-2008009-17oct08.pdf)
• . (Root): In Planung (http://www.root-dnssec.org/)
• in-addr.arpa: Das RIPE sowie die ARIN signieren die an sie delegierten Reverse Zonen (http://www.ripe.net/rs/reverse/dnssec/) (http://www.arin.net/resources/dnssec/)

Weitere Informationen / Links zu einzelnen Projekten: http://www.dnssec.net/projects

Im Rahmen des Testbeds wird DNSSEC für .de in einer Testumgebung zur Verfügung gestellt und DNSSEC signierte .de-Zonen können ihre DNSKEY-Einträge in diese Testumgebung veröffentlichen. Ziel ist es, auf Seiten der DENIC, der Domainprovider sowie der Zugangsprovider DNSSEC zu testen, die Kompatiblität von Hard- und Software zu erproben und Aufwand und Nutzen einer Produktiveinführung von DNSSEC abzuschätzen. Die DENIC führt das DNSSEC-Testbed in Verbindung mit dem BSI (Bundesamt für Sicherheit in der Informationstechnik) und dem eco (Verband der deutschen Internetwirtschaft) durch.

Weitere Informationen:

• Dokument zum Testbed: DNSSEC_Testbed_fuer_Deutschland.pdf
• Aktueller Stand sowie weitere Informationen auf den Seiten der DENIC: DENIC_DNSSEC

DNSSEC fügt dem DNS weitere Arten von Einträgen (Resource-Records) hinzu, mit denen Signaturen, Schlüssel und Schlüsselverweise im DNS veröffentlicht werden können. Die Absicherung einer Zone geschieht dann durch das "Signieren" der ursprünglichen Zonendaten sowie dem Publizieren des öffentlichen Schlüssels entweder zur übergeordneten Zone oder als Eintrag in einem separaten Repository, das bei validierenden Resolvern als Vertrauensbasis hinterlegt ist. Grundsätzlich wird jeder Eintrag einer DNS-Zone mit einer entsprechenden Signatur versehen.

Stellt ein DNS-Client, der DNSSEC-Signaturen verifizieren kann (ein sogenannter "validierender Resolver") eine Anfrage an einen DNS-Server einer DNSSEC-gesicherten Zone, liefert der DNS-Server nicht nur die angefragten Informationen sondern auch deren Signatur zurück. Der validierende Resolver kann dann mit Hilfe des öffentlichen Schlüssels die Integrität der Daten und die Authentizität des DNS-Servers überprüfen.

Die verwendeten Schlüssel für die Signierung sollten regelmäßig getauscht werden, um die Sicherheit der Zone zu gewährleisten. Die Notwendigkeit eines solchen sog. Key-Rollovers ist vor allem bei kürzeren Schlüssellängen gegeben, längere Schlüssellängen sind möglich, verursachen aber größeren Rechenaufwand auf Seite der validierenden Resolver. Somit existiert ein Trade-Off zwischen Sicherheit und Rechenzeit, der durch die Unterteilung in zwei Schlüsselarten unterschiedlicher Länge entschärft wird.

Der ZSK (Zone Signing Key) hat eine kürzere Schlüssellänge und dient zum Signieren der einzelnen Zoneneinträge. Der öffentliche Teil des ZSK wird innerhalb der Zone als DNSKEY-Entry publiziert und mit dem KSK (Key Signing Key) signiert, der im Gegensatz zum ZSK eine größere Schlüssellänge besitzt. Der öffentliche Teil des KSK wird ebenfalls in der Zone als DNSKEY-Entry publiziert. Des weiteren wird für den KSK ein Hash-Wert ermittelt, der in einem DS-Record der übergeordneten Zone oder einem DLV-Repository (siehe "Was ist ein DLV?") zur Verfügung gestellt werden kann und durch den dortigen ZSK signiert wird. Auf diese Weise bildet sich eine Vertrauenskette, die im Idealfall bis zur Root-Zone reicht.

Eine Vertrauenskette besteht bei DNSSEC aus einer hierarchischen Abfolge von DNSKEY-Records und DS-Records (Delegation Signer). Die Kette beginnt mit einem DNSKEY, dem der Resolver vertraut. Dieser kann entweder fest konfiguriert werden oder aus einem Repository bezogen werden, dem vertraut wird. Mit diesem DNSKEY ist auf dem Weg zur nächsten Hierarchieebene ein DS-Record signiert, der einen Hashwert des untergeordneten DNSKEYs enthält. Durch den Hashwert kann verifiziert werden, dass der von der untergeordneten Zone bezogene DNSKEY korrekt ist und die übergeordnete Zone diesen DNSKEY als vertrauenswürdig einstuft. Auf diese Weise setzt sich eine Vertrauenskette fort, bis die angefragte Ebene/Zone im DNS-Baum erreicht ist.

Nein, Vertauensketten können auch in Unterzonen beginnen wenn deren DNSKEYs im Resolver hinterlegt sind oder aus einem vertrauenswürdigen Repository bezogen werden. So könnte beispielsweise in der Konfiguration eines Resolvers der von der DENIC für die .de-Zone verwendete DNSKEY als vertrauenswürdig hinterlegt sein. Damit wäre für alle signierten .de Zonen und deren Subzonen eine Validierung möglich, da die Vertrauenskette bei einem DNSKEY beginnt, der als vertrauenswürdig eingestuft ist. Ein Wechsel des Schlüssels bei der DENIC würde in diesem Beispiel allerdings auch ein Update der Konfiguration des Resolvers erfordern, da er ansonsten den neuen Schlüssel nicht als vertrauenswürdig einstuft und somit keine Validierung möglich ist oder im schlimmsten Fall eine Nichterreichbarkeit von signierten Zonen entsteht. Falls die DeNic ihren DNSKEY über ein DLV-Repository verfügbar macht, ist sie selbst für die Aktualität des Schlüssels und dessen Austausch verantwortlich.

DLV steht für "DNSSEC Look-aside Validation" und bezeichnet ein Repository für Schlüssel, die als vertrauenswürdig eingestuft werden. Ein solches DLV-Repository kann beliebige Startpunkte im DNS-Baum als vertrauenswürdig einstufen und validierende Resolver können diese Information nutzen, wenn die Vertrauensketten nicht bis zur Root-Zone reichen, weil diese z.B. gar nicht signiert wird.

Beispiele für produktive DNSSEC-DLVs sind:

• ISC DLV (grundsätzlich für alle Zonen geeignet)
• IANA ITAR (nur für TLDs)

DNSSEC muss sowohl auf Seiten der Anbieter (Domaininhaber, Provider, Registry) als auch auf Seite des Kunden (DSL-Kunde / ISP, validierende Resolver beim ISP oder Kunden) unterstützt werden. Eine DNSSEC-signierte Zone wird nur von einem validierenden Resolver geprüft, nicht-validierende Resolver würden die DNSSEC-Informationen ignorieren bzw. fragen diese erst gar nicht an. Eine nicht signierte Zone kann logischerweise grundsätzlich nicht validiert werden.

• DNSKEY (DNSSEC Key): Dient zur Veröffentlichung des öffentlichen Teils eines DNSSEC-Schlüssels. Dies kann sowohl der Zone-Signing-Key als auch der Key-Signing-Key sein.
• RRSIG (RRSET Signature): Enthält die Signatur eines DNS Resource-Record-Sets, also einer Menge von DNS-Einträgen gleichen Typs und Namens. Die Signatur kann anhand des entsprechenden DNSKEY-Eintrags überprüft werden.
• DS (Delegation Signer): Ein von der übergeordneten Zone unterschriebener Hashwert des DNSKEY-Eintrags des Key-Signing-Keys. Dient zur Bildung einer Vertrauenskette (Chain of Trust). Der Schüsselinhaber der übergeordneten Zone signiert den Schlüssel der untergeordneten Zone. Falls der übergeordneten Zone vertraut wird, kann auch dem Schlüssel der untergeordneten Zone vertraut werden.
• NSEC/NSEC3: Ein Eintrag mit dem die in der Zone vorhandenen Einträge verkettet werden, um auch eine signierte Antwort bei Nicht-Existenz eines Eintrags zu erhalten (was sonst nicht möglich wäre). Da die Namen bei NSEC im Klartext verkettet waren, war das Auflisten aller Einträge einer Zone möglich (Zone Walking), was durch die Einführung von Hash-Werten statt Klartext durch NSEC3 behoben wurde.

Weitere Informationen:

• DNSSEC http://de.wikipedia.org/wiki/DNSSEC
• DNSKEY-RR: http://de.wikipedia.org/wiki/DNSKEY_Resource_Record
• RRSIG-RR: http://de.wikipedia.org/wiki/RRSIG_Resource_Record
• DS-RR: http://de.wikipedia.org/wiki/DS_Resource_Record
• NSEC3-RR: http://de.wikipedia.org/wiki/NSEC3

Ein ZSK (Zone-Signing-Key) ist ein DNSSEC-Schlüssel, der verwendet wird, um die Einträge innerhalb einer DNS-Zone zu signieren. Der KSK (Key-Signing-Key) ist ein DNSSEC-Schlüssel, der ausschließlich verwendet wird, um den ZSK zu signieren.

Die Schlüssellänge des ZSK ist kürzer als beim KSK, was den ZSK kryptografisch schwächer macht als den KSK. Aus diesem Grund wird der ZSK üblicherweise häufiger gewechselt als der KSK. Eine signierte Zone enthält somit mindestens einen KSK und mindestens einen ZSK, der durch den KSK signiert ist, und wiederum alle Zoneneinträge signiert.

Falls eine Vertrauenskette mit einer übergeordneten Zone gebildet werden soll, wird der öffentliche Teil des KSK durch die übergeordnete Zone signiert und die Signatur dort veröffentlicht.

Nein, grundsätzlich nicht. Eine Zonensignierung funktioniert auch nur mit einem Schlüssel ohne weitere Unterteilung in KSK und ZSK. Allerdings entspräche das Vorgehen nicht den Empfehlungen (RFC4641 DNSSEC Operational Practices) und auch nicht dem üblichen Vorgehen. Grund für die Unterteilung ist der Wunsch nach einer längeren Gültigkeit des KSK, was eine größere Schlüssellänge notwendig macht. Eine größere Schlüssellänge erhöht allerdings die Rechenzeit bei Signierung und Validierung und vergrößert die Signaturen, die mittels des DNS Protokolls ausgetauscht werden müssen. Für UDP Pakete besteht aber ab einer gewissen Größe die Gefahr, dass sie nicht von allen momentan eingesetzten Hardwarekomponenten fehlerfrei behandelt werden.

Aus diesen Gründen ist es sinnvoll, die einzelnen DNS-Einträge der Zone mit einem kürzeren Schlüssel, dem ZSK, zu signieren und nur den ZSK selbst mit dem KSK zu unterschreiben. Eine kürzere Schlüssellänge erfordert dementsprechend einen häufigeren Schlüsselwechsel. Dies ist beim ZSK weniger problematisch als beim KSK, da bei einem ZSK-Schlüsselwechsel keine neuen Informationen in der übergeordneten Zone veröffentlicht werden müssen.

Wie bei allen Verschlüsselungsverfahren gibt es auch bei der im DNSSEC verwendeten Public-Key-Kryptografie Angriffsszenarien. Diese Angriffe benötigen abhängig von der Schlüssellänge eine meist immense Rechenleistung und dementsprechend viel Zeit und Geld um einen solchen Angriff durchzuführen. Daher stellt sich bei jeder Schlüssellänge nicht die Frage, ob ein Angriff Erfolg haben wird sondern lediglich wie lange es dauert und wieviele Ressourcen dafür aufgewendet werden müssen.

Aus diesen Gründen ist ein regelmäßiger Schlüsselwechsel sinnvoll obwohl nicht zwingend erforderlich.

Über sinnvolle Schlüssellängen und deren entsprechende Gültigkeitsdauer gibt es unterschiedliche Meinungen. So wird z.B. von RFC4641 (DNSSEC Operational Practices) eine Schlüssellänge zwischen 1024 und 2048 für den KSK (Gültigkeit: 1 Jahr) vorgeschlagen und eine etwas geringere (nicht mehr als 100Bit weniger) für den ZSK (Gültigkeit: 1 Monat). Der "DNSSEC Good Practices Guide" gibt eine KSK-Schlüssellänge von 1280Bit mit einer Gültigkeit von maximal 4 Jahren und eine ZSK-Schlüssellänge von 1024Bit mit einer Gültigkeit von maximal einem Monat als empfehlenswert an.

Beim ZSK sollte bzgl. der Schlüssellänge auch in Betracht gezogen werden, dass die daraus resultierenden Länge der UDP-Pakete momentan eine Größe von 512 Byte nicht überschreiten sollten, da nicht jede aktuelle Hardware mit EDNS0 (RFC2671) umgehen kann.

Weitere Informationen:

• RFC4641
• ENISA "DNSSEC Good Practices Guide"

Ja, jeder RRSIG Record beinhaltet ein Feld, das angibt, bis wann die Signatur gültig sein soll. Eine Neusignierung der Zone ist vor Ablauf dieser Gültigkeit zwingend erforderlich, da die Zone ansonsten nicht mehr erfolgreich validiert werden kann. Auch sollte eine ausreichende Zeitspanne vor Ablauf der Gültigkeit neu signiert werden, damit ausreichend Zeit bleibt, auf Fehler im Signierungsprozess reagieren zu können.

RFC4641 ("DNSSEC Operational Practices") beschreibt zwei verschiedene Strategien:

Pre-Publish

In der Zone wird ein neuer DNSKEY bereits einige Zeit vor Benutzung veröffentlicht. Zu einem Umschaltzeitpunkt können dann die Signaturen des alten Keys durch jene des neuen Keys ersetzt werden. Anschließend kann der alten DNSKEY nach Ablauf der Caching-Wartezeit aus der Zone gelöscht werden. Dieses Verfahren bietet den Vorteil, dass nicht gleichzeitig mit mehreren Schlüsseln signiert werden muss, wodurch die Größe der Zonendaten deutlich erhöhen würde. Zudem ist dieses Verfahren besser für Notfall-Schlüsselwechsel geeignet, da ggf. bereits ein neuer Key veröffentlicht ist, mit dem sofort signiert werden kann.

Double-Signature

In der Zone wird ein neuer DNSKEY zugleich mit der Signierung der Zone durch diesen Schlüssel veröffentlicht. Für eine gewisse Zeit muss die Zone mit beiden Schlüsseln signiert bleiben, bevor der alte Schlüssel entfernt werden kann. Diese Verfahren erhöht die Zonengröße, da gleichzeitig mit zwei Schlüsseln signiert werden muss. Allerdings ist der Ablauf des Verfahrens weniger komplex als das Pre-Publish-Verfahren.

RRSIG (RRSET Signature): Enthält die Signatur eines DNS-Resource-Record-Sets, also einer Menge von DNS-Einträgen gleichen Typs und Namens. Die Signatur kann anhand des entsprechenden DNSKEY-Eintrags überprüft werden.

Weitere Informationen:

• http://de.wikipedia.org/wiki/RRSIG_Resource_Record

Mithilfe von NSEC sind auch Negativ-Antworten (Eintrag x gibt es nicht) validierbar. Ohne NSEC könnten böswillig Teile eines DNS-Antwortpaketes gelöscht werden, so dass es für den Empfänger aussähe, als gäbe es den angefragten Eintrag nicht. NSEC verkettet die Einträge einer Zone in alphabetischer Reihenfolge. Beispiel: Sind Eintrag a und c in einem NSEC-Record verknüpft, kann es keinen Eintrag b geben.

Da die NSEC-Records ebenfalls durch RRSIG-Records signiert werden, ist eine DNSSEC-Validierung dieser Einträge und somit eine kryptografisch gesicherte Aussage über die Nichtexistenz eines Eintrags möglich.

Nachteil der NSEC-Verkettung ist die Möglichkeit, die Zoneneinträge aufzulisten (Zone Walking), da die Zoneneinträge im Klartext in den NSEC Records gelistet sind. Da dies üblicherweise nicht gewünscht ist, wurde mit NSEC3 eine Variante geschaffen, die dieses Problem umgeht.

Weitere Informationen:

• http://de.wikipedia.org/wiki/NSEC_Resource_Record

NSEC3 stellt eine Weiterentwicklung von NSEC dar, die das ungewünschte Auflisten kompletter Zonen (Zone Walking) umgeht, da die Einträge nicht mehr im Klartext sondern als Hash-Wert gelistet sind. Eine Anfrage nach einem nicht existenten Eintrag liefert den alphabetisch davorliegenden nächsten Eintrag der Zone zurück inklusive des Hashwertes des darauf folgenden Eintrags. Ist der Hashwert des angefragten Eintrags ungleich dem Hashwert im NSEC3 Record, so existiert der Eintrag nicht. Aus dem Hashwert kann aber nicht auf den alphabetisch folgenden Klartext-Eintrag geschlossen werden, was das Zone Walking verhindert.

Üblicherweise verwenden Betriebssysteme die vom Zugangsprovider mitgeteilten DNS-Server oder einen Zugangsrouter, der wiederum einen DNS Proxy zur Verfügung stellt und die Anfragen an die vom Zugangsprovider mitgeteilten DNS-Server weiterleitet. Die Validierung von DNSSEC signierten DNS-Daten findet daher nicht auf dem Rechner eines Internetnutzers statt. Liefert ein vorgeschalteter validierender Resolver eine Fehlermeldung beim Auflösen eines Domainnamens, so kann dies - neben vielen anderen Gründen - an einer fehlerhaften DNSSEC-Validierung und somit an gefälschten DNS Daten liegen. Die direkte Auswirkung für den Nutzer stellt sich in der Nicht-Erreichbarkeit der Domain dar.

Jedem Internetnutzer ist es freigestellt, die DNS Server des Zugangsprovider oder aber einen eigenen Resolver zu verwenden. Dieser kann entweder auf dem Zugangsrouter oder dem benutzten Rechner selbst realisiert werden. Diese Resolver können dann DNSSEC-Antworten direkt und eigenständig validieren.

Eine direkte Unterstützung für DNSSEC durch Client-Programme u.a. Browser ist nicht notwendig, allerdings ist sie durchaus möglich. Normalerweise kümmert sich das Betriebssystem um die Namensauflösung und somit auch um die Validierung von DNSSEC signierten Zonen, falls das Betriebssystem DNSSEC Validierung unterstützt. Ein DNSSEC-Icon im Browser - ähnlich wie bei SSL-gesicherten Websites - wäre allerdings durchaus wünschenswert und wird mit steigender Bedeutung und Verbreitung von DNSSEC sicherlich implementiert werden.

Da allerdings eine echte DNSSEC-Unterstützung durch das Betriebssystem noch nicht zum Standard geworden ist (erst der "Windows 7"-Nachfolger wird wohl DNSSEC validierend unterstützen), kann es für die Übergangszeit sinnvoll sein, die DNSSEC-Validierung nicht dem Betriebssystem zu überlassen.

Für den Mozilla Firefox Browser existiert z.B. ein experimentelles Plugin, das den Browser um DNSSEC-Validierung ergänzt. Zu diesem Zweck ist das Plugin allerdings auf externe validierende Resolver angewiesen.

Weitere Informationen:

• http://labs.nic.cz/page/691/dnssec-add-on-for-firefox/

Für alle Windows-Versionen bis inkl. Windows XP gilt: sie unterstützen DNSSEC nicht. DNSSEC-Validierung kann in diesem Fall nur durch validierende Resolver des Zugangsproviders erreicht werden. Windows 7 implementiert einen nicht-validierenden aber sicherheitbewußten Resolver (non-validating security-aware stub resolver). http://blogs.technet.com/sseshad/archive/2008/10/30/dnssec-in-windows-7.aspx

Das Betriebssystem des Rechners kann bei der Anfrage angeben, ob es die DNSSEC-Erweiterungen des DNS-Protokolls versteht und auswerten kann (zu diesem Zweck wird in der Anfrage das DNSSEC OK = DO-Bit gesetzt). Dieses DO-Bit sollte idealerweise durchgängig beginnend mit der ersten Anfrage gesetzt sein. Diese Verhalten lässt sich bei Windows 7 für einzelne Zonen separat einschalten. Das Betriebssystem erkennt danach für diese Zone sowie alle hierarchisch untergeordneten Zonen nur noch Antworten als korrekt an, bei denen das AD-Flag gesetzt ist.

Dies mag für einzelne Zonen (z.B. in einem Intranet) möglich sein, nicht allerdings für übergeordnete Zonen. Würde beispielsweise DNSSEC für .de aktiviert, so würden nicht signierte .de-Domains nicht mehr korrekt aufgelöst. Somit ist DNSSEC in Windows 7 zwar vorhanden, die Verwendung ist aber wohl als nicht praktikabel zu bezeichnen.

DNSSEC-Unterstützung für Linux ist distributionsabhängig und bisher nicht per Default aktiviert. Für eine genauere Übersicht der unterstützten Betriebssysteme siehe:

Weitere Informationen:

• http://www.DENIC.de/fileadmin/Domains/DNSSEC/22090702/DNSSEC_20090702_Dietrich.pdf

Im Rahmen des DENIC-DNSSEC-Testbeds wurde vom BSI eine Routerstudie durchgeführt. Ergebnis der Studie war, dass DNSSEC von nur wenigen aktuellen Geräten vollkommen ohne Probleme unterstützt wird, allerdings ist DNSSEC dennoch in den meisten Fällen ohne Probleme nutzbar, wenn der Zugangsprovider die Validierung übernimmt.

Weitere Informationen:

• http://www.DENIC.de/fileadmin/Domains/DNSSEC/22090702/DNSSEC_20090702_Dietrich.pdf

Wie weiter oben bereits ausgeführt, ist DNSSEC vorrangig Aufgabe der DNS-Resolver, an die das Betriebssystem die DNS-Anfragen sendet. Für Software XY ist es somit nicht von Bedeutung, ob im Hintergrund DNSSEC geprüft wird. Bei erfolgreicher DNSSEC-Validierung funktioniert alles wie bisher, bei einer fehlerhaften DNSSEC-Validierung sieht es für die Anwendung so aus, als ob die Namensauflösung fehlgeschlagen sei.

Neuerer Software, die explizit DNSSEC unterstützt oder darauf angewiesen ist, steht es natürlich frei, DNS-Abfragen selbst durchzuführen und DNSSEC-Antworten selbst zu validieren. Vorerst ist allerdings für derartige Unterscheidungen des DNS-Abfrageergebnisses keinerlei Hilfe des Betriebssystems verfügbar.

Im Rahmen des Testbeds in Deutschland werden von vielen Zugangsprovidern Tests mit validierenden Resolvern durchgeführt. Über eine Teilnahme am Testbed kann der Benutzer entscheiden, falls der Zugangsprovider ihm die IP-Adressen der validierenden Resolver zur Verfügung stellt.

Für den Produktivbetrieb sind validierende Resolver allenfalls nach Beendigung des Testbeds zu erwarten. Kunden, die selbst rekursive DNS-Server zur Namensauflösung betreiben, können diese so konfigurieren, dass sie DNSSEC-Validierung durchführen. Die Schlüssel denen explizit vertraut werden soll (Trust Anchor) können entweder manuell gepflegt oder aus einem DLV-Repository bezogen werden.

Grundsätzlich kann eine DNSSEC-Signierung nicht schaden, da nur so sichergestellt werden kann, dass die DNS-Informationen Ihrer Domain signiert werden und vom Empfänger auf Korrektheit der Signatur geprüft werden können.

Ob eine DNSSEC-Signierung wichtig oder notwendig ist, lässt sich zum aktuellen Zeitpunkt daran entscheiden, wie hoch das Risiko eines gezielten Angriffs auf die DNS-Daten dieser Domain ist. Bietet die Domain ein Ziel für Phishing-Aktivitäten, werden dort Login-Daten von Benutzeraccounts abgefragt oder sonstige Daten eingegeben, die für Dritte von Interesse sein könnten, so ist eine DNSSEC-Signierung sicherlich sinnvoll.

Nein, es ist auch möglich die Schlüssel für seine Domain zu veröffentlichen, selbst wenn die übergeordnete Zone nicht DNSSEC-signiert ist. Diese Möglichkeit wird von DLV-Repositories (DLV = DNSSEC Look-aside Validation) angeboten, in denen die Schlüssel hinterlegt werden und die von validierenden Resolvern befragt werden können. Da in DLVs aber das Hinterlegen des Schlüssels ggf. ein händischer Prozess ist, muss bei einem Schlüsselwechsel auch der Schlüssel im DLV-Repository gewechselt werden.

Eine vollautomatische Nutzung von DNSSEC für Domains aller Endungen wird nur dann möglich sein, wenn alle Registries DNSSEC unterstützen und der Domainprovider alle DNSSEC-Schnittstellen der Registries für die Schlüsselveröffentlichung verwenden. Alternativ können alle validierenden Resolver ihre Informationen aus einem DLV-Repository beziehen, was aber wiederum der Konzeption des DNS-Systems widersprechen würde, da dieses System nicht hierarchisch und dezentral organisiert ist.

Wenn Ihr Domainprovider DNSSEC unterstützt und Sie für Ihre Domain DNSSEC-Signierung beauftragen, wird sich der Domainprovider in den meisten Fällen um Schlüsselerzeugung, Signierung der Zonendaten, Neusignierung vor Ablauf der Signaturgültigkeit sowie den Schlüsselwechsel für beide Schlüsselarten kümmern.

Alternativ können Sie die Schlüssel selbst verwalten und auf Ihren eigenen Nameservern signierte Zonen veröffentlichen. Der Domainprovider erhält die fertig signierten Zonen von Ihren Nameserven. Sie müssen dem Domainprovider allerdings den öffentlichen Teil des Key-Signing-Keys zur Verfügung stellen, damit er ihn bei der entsprechenden Registry einstellen kann. Da ein Key-Signing-Key-Wechsel eine gewissen Abfolge und anschließende Wartezeiten vor dem Entfernen des alten Schlüssels erfordert, wird dieser Prozess durch die Trennung zwischen Schlüsselverwaltung und Registry-Schnittstelle auf mindestens zwei Parteien aufgeteilt, somit komplexer und fehleranfälliger. Schlüsselwechsel sind zwar nicht zwingend erforderlich, gehören aber zur gängigen Praxis im DNSSEC.

Wenn der Kunde die DNSSEC-Schlüssel selbst verwaltet, wird er an Dritte nur den öffentlichen Schlüssel herausgeben. Der Kunde muss dementsprechend seine Zonen selbst signieren muss und diese dann entweder auf seinen Nameservern veröffentlicht oder diese an seinen Domain- oder DNS-Provider weitergibt. Zusätzlich muss er seinem Domainprovider den öffentlichen Teil des Key-Signing-Keys mitteilen, damit dieser die DNSSEC-Delegation in der übergeordneten Zone durchführen kann.

Bei allen Schlüsselwechseln sollte sich der Kunde an die in RFC4641 DNSSEC Operational Practices beschriebenen Abläufe zum Schlüsselwechsel halten, da ansonsten die Gefahr besteht, Validierungsfehler zu erzeugen. Grundsätzlich ist die manuelle Betreuung von Schlüsselwechseln mit einem hohen Risiko verbunden, eine fehlerhafte Konfiguration zu erzeugen. Im Idealfall sollte der Kunde die DNSSEC-Schlüsselverwaltung sowie die Eintragung bei der Registry einem automatisierten Prozess beim DNS-Provider oder beim Domainprovider überlassen.

Es gibt zwei Komponenten die ein Domainprovider leisten kann: Erstens den DNS-Betrieb und die damit verbundene Signierung der Zonen. Diese Tätigkeit lässt sich entweder selbst übernehmen (eigene DNS-Server) oder an einen DNS-Provider auslagern, der DNSSEC unterstützt. Zweitens muss der Domainprovider den öffentlichen Teil des Key-Signing-Keys in der übergeordneten Zone veröffentlichen, vorausgesetzt diese unterstützt DNSSEC. Die DNSSEC-Schnittstellen der Registries geben überlichenweise nur dem verwaltenden Domainprovider Zugriff auf die Möglichkeit, die notwendigen DNSSEC Delegations-Informationen zu hinterlegen, so dass man für diese Tätigkeit einen Domainprovider wählen muss, der Zugriff auf die Registry-Schnittstelle hat. Im Normalfall sollte ein Provider, der bei der Registry DNSSEC-Delegationen vornehmen kann, aber auch die eigentlichen Signierung der Zonen unterstützen.

Sollte dies nicht möglich sein, bleibt ein Wechsel zu einem Provider, der DNSSEC unterstützt.

Falls die Schlüssel vom Kunden selbst erzeugt werden, so muss jeder erzeugte Schlüssel zuerst dem DNS-Provider mitgeteilt werden, damit er diesen sowohl als DNSKEY-Record als auch für die Signierung der Zone verwendet. Sobald dies geschehen ist, kann der öffentliche Teil des Schlüssels bei der Registry für die entsprechende Zone veröffentlicht werden. Der alte Schlüssel und dessen Signaturen können nach Ablauf der Caching-Zeit (TTL) zuerst bei der Registry entfernt werden und anschließend aus der Zone selbst. Dieser Prozess wird für Key-Signing-Keys wahrscheinlich 1-2 mal pro Jahr anfallen - je nachdem wie lange ein KSK gültig sein soll.

Falls der DNS-Provider die Schlüssel erzeugt und verwaltet, muss der Kunde den öffentlichen Teil des KSKs über den Domainprovider bei der Registry veröffentlichen lassen bzw. alte Schlüssel dort entfernen. In diesem Fall ist sicherzustellen, dass der Prozess beim DNS-Provider in jedem Fall auf die Eintragungen wartet (entweder manuell oder per automatischem Test), bevor alte Schlüssel entfernt werden.

Es gibt verschiedene Möglichkeiten eine Zone zu signieren. Grundsätzlich sollte unterschieden werden, ob die Zone auf dem Nameserver signiert wird oder im Vorhinein erzeugt, signiert und erst anschließend auf den Nameserver übertragen wird. Eine Signierung auf dem Nameserver setzt das Vorhandensein des privaten Schlüsses auf dem Nameserver voraus, was aus Sicherheitsgründen ggf. nicht erwünscht ist.

Die einfachste Lösung besteht in der Nutzung existierender Commandline-Tools, die sowohl zur Schlüsselerzeugung als auch zur Signierung eines bestehenden Zonenfiles eingesetzt werden können. Bind bringt die entsprechenden Tools (dnssec-keygen und dnssec-signzone) mit.

Eine weitere Lösung bieten DNSSEC-Libraries, die Schlüsselerzeugung und Signierung als API für bestimmte Programmiersprachen anbieten. Es existieren Libraries u.a. für Phyton, Java, Perl, C. Eine Auflistung entsprechender Tools findet sich unter http://www.dnssec.net/software . Abschließend ist es natürlich immer möglich, die Schlüsselerzeugung und/oder Zonensignierung anhand der entsprechenden RFCs in der Programmierumgebung seiner Wahl zu entwickeln. Bestimmte Anforderungen oder Gegebenheiten können eine solche Eigenentwicklung notwendig machen. In diesem Fall kommt dem Test der erzeugten Zonensignaturen auf Korrektheit und Kompatiblität eine große Bedeutung zu.

Es wird empfohlen ("Good Practices Guide for Deploying DNSSEC"), das signierende System sowie das System zur Aufbewahrung der Schlüssel vom Netz zu trennen oder zumindest durch eine Security-Lösung abzusichern. Eine Zonensignierung direkt auf den Nameservern hat zwar durchaus Vorteile, allerdings müssen dann die privaten Schlüssel auf den jeweiligen Nameservern verfügbar sein, was aus Sicherheitsgründen vermieden werden sollte.

Alle angeführten Lösungen müssen auch eine (teil-)automatisierte Lösung für den Schlüsselwechsel realisieren, dies kann in der einfachsten Form durch entsprechende Skripte erreicht werden oder indem ein dafür vorgesehenes Tool eingesetzt wird. Eine Liste der existierenden Tools findet sich unter http://www.dnssec.net/software .

Zu beachten ist des weiteren, dass bei der KSK-Rollover-Prozedur unter Einhaltung der wichtigen zeitlichen Abstände die Publizierung der DS-Records an die übergeordnete Zone oder in ein DLV-Repository erfolgen muss. Die Entfernung des bisherigen KSKs aus der Zone darf erst dann erfolgen, wenn sichergestellt ist, dass der DS-Record des neuen Schlüssels bereits publiziert ist und er sich auch bereits unter allen noch validen gecachten DS-Einträgen auf den Resolvern befindet.

Die Schlüsselerzeugung sollte von der von Ihnen verwendeten DNSSEC-Software geleistet werden. Eine händische Schlüsselerzeugung ist möglich, es wird aber davon abgeraten, solange man nicht über tiefergehendes Detailwissen im DNSSEC-Bereich verfügt. Grundsätzlich wird empfohlen, für DNSSEC RSA/SHA-1- oder RSA/SHA-256-Schlüssel mit entsprechender Schlüssellänge (siehe Schlüssellängen) zu erzeugen. DNSKEY-Einträge enthalten den verwendeten Algorithmus für die Schlüsselerzeugung, näheres siehe RFC4034 bzw. RFC5702 RFC4641 empfiehlt SHA-256 zu verwenden, sobald die aktuell verwendete Hardware/Software SHA-256 unterstützt.

DENIC hat sich für das .de-DNSSEC-Testbed entschieden, SHA-256 zu verwenden, um spätere Migrationsprobleme ggf. in produktivem Betrieb vorwegzunehmen. Eine zum aktuellen Zeitpunkt konservative und auf Kompatiblität fokussierte Empfehlung würde SHA-1 den Vorzug geben, und zu SHA-256 zu wechseln, sobald es flächendeckend erprobt und verfügbar ist, da SHA-1 inzwischen als anfällig betrachtet werden muss.

Der Betreiber der übergeordneten Zone, in der die DS-Records publiziert werden sollen, muss eine entsprechende Möglichkeit zur Verfügung stellen. Falls die übergeordnete Zone eine TLD-Zone ist, fällt diese Zuständigkeit in den Bereich der betreibenden Registry. In den meisten Fällen wird die Möglichkeit, DS-Records für Domains zu publizieren, von den Registries zur existierenden Registry-Registrar-Schnittstelle hinzugefügt. Daher ist es abhängig von der Registry, auf welche Art und Weise DS-Records publiziert werden.

Es gibt zwei unterschiedliche Arten, der Registry die notwendigen Informationen zu übergeben: entweder es wird der DNSKEY-Eintrag übergeben, und die Registry errechnet den DS-Eintrag eigenständig aus den DNSKEY Informationen, oder die Registry gibt verschiedene mögliche DS Formate vor und belässt die Zuständigkeit für die DS-Berechnung dem Zoneninhaber.

Dies hängt von der Implementierung der Registry ab. Zonen-Reloads der DNSSEC-signierten TLD-Zone finden üblicherweise nicht sofort nach Änderung eines DS-Eintrags statt, sondern zu festgelegten Zeiten in festgelegten Intervallen. Für das .de-Testbed ist beispielsweise ein Zonenreload pro Tag vorgesehen.

Da bei einem KSK-Rollover auf die Veröffentlichung des DS-Entries in der TLD-Zoneg gewartet werden muss, ist es durchaus von Interesse, wann eine Registry die Einträge veröffentlicht. Eine einfache Lösung in diesem Beispiel wäre es, mindestens 24 Stunden plus Karenzzeit zu warten, damit der Reload in jedem Fall durchgeführt wird.

Es gibt diverse Tools, um DNSSEC-signierte Zonen zu testen. Einige davon sind auf Webseiten von Registries verfügbar, andere sind als Command-Line Tool z.B. unter Linux verfügbar.

DNSSEC-Website-Tools

• http://dnscheck.iis.se/
• http://www.dnssec-tester.cz/
• http://www.dnssec.org.mx/checkdnssec.html
• http://www.DENIC.de/hintergrund/nast.html (bisher keine DNSSEC Unterstützung)

DNSSEC-Commandline-Tools

• Dig: http://www.isc.org
• Drill: http://www.nlnetlabs.nl/ldns/

• Sammlung vorhandener Tools: https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources

DNSSEC-Online Tests bieten eine erste Möglichkeit Fehlern auf die Spur zu kommen. So bietet http://dnscheck.iis.se/ eine detailierte Ausgabe von Testergebnisse. Allerdings werden dort die für das .de DNSSEC Testbed bereitgestellten DNSSEC .de Nameserver nicht einbezogen, so dass die Vertrauenskette nicht bis in die .de Zone fortgesetzt werden kann.

Für eine manuelle und detailierte Untersuchung bieten sich Command-Line Tools an. Dig und drill verfügen über Debug-Level-Einstellungen mit denen die DNSSEC-Auflösung und -Validierung schrittweise nachvollzogen werden kann:

• Dig:
  • http://www.isc.org
  • http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-560007

• Drill:
  • http://www.nlnetlabs.nl/ldns/
  • http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-550006

Beispiele (Dig):

Hinweis: Einige Beispiele verwenden die DNSSEC signierte Zone dnssec-faq.de unter der diese FAQ zu erreichen ist.

• Abfrage von Zoneneinträgen inkl. DNSSEC Signierung. Falls die Domain DNSSEC signiert ist, werden auch RRSIG, NSEC und DNSKEY Records ausgegeben: 'dig dnssec-faq.de. any'
• Abfrage von DS-Einträgen in der übergeordneten Zone: 'dig @a.nic.de -t DS dnssec-faq.de'
  Während des .de DNSSEC Testbeds muss an dieser Stelle ein .de Nameserver des Testbeds befragt werden:
  'dig @auth-fra.dnssec.denic.de -t DS dnssec-faq.de.'

Beispiele (Drill):

• Verfolgen der Signaturkette einer Domain bis zu einem ggf. vertrauenswürdigen Schlüssel: 'drill -DS dnssey-faq.de'
  Während des .de DNSSEC Testbeds enthalten die per DNS veröffentlichten .de Nameserver keine DS Records. Dementsprechend findet Drill bei Frage nach den DS Records für dnssec-faq.de keinen Einträge und bricht die Verfolgung ab. Drill verwendet zur Abfrage der Daten die für das Betriebssystem eingetragenen DNS Resolver. Falls diese Resolver zur Verwendung des .de DNSSEC Testbeds konfiguriert sind, ist eine Verfolgung der Signierung bis zu .de möglich.
• Verfolgen der Signaturkette in voll funktionalen DNSSEC Deployments: 'drill -DS dnssec.se'
  Drill kann in diesem Fall die Signaturen bis zu .se verfolgen. Die public keys für .se müssten für eine vollständige Validierung explizit als vertraute Schlüssel hinterlegt werden.
• Erstellen eines trusted-Key files für drill:
  Achtung: Das format der Datei unterscheidet sich z.B. vom Format der für Bind verwendeten trusted keys. Auf exakte Einhaltung des Formats ist zu achten, da drill ansonsten angibt, keine trusted-keys in der Datei zu finden.
  Format: 'zone. IN DNSKEY 257 3 5 key', wobei keine Zeilenumbrüche erlaubt sind.
  Beispiel für .se:
  se. IN DNSKEY 257 3 5 AwEAAbaxTum9L7z1DmPiXPk0QZ2/qUM3to210Caey/ycZuvQ8Mh/dgGpwBmyZB9xZSkaCLa2Mw6pmDLrjK9hWOffq5PXRVm9RrcA/eIEBEvbQzkY5sFkWAczNAs58Oscxi+/Gd5KfuVi3lJpYgJwwa2JB4doZ00IXywcCn0VTz0Hsl/lqpA2Bqj+e+ATzA5hWyiNyHPjiYvyMCkSXTiGgFVVuG8H3N6Us8uSABuO2UoFQeQi6YikIiCbf1FfCzr4vBIRXW6MaDs8kqAAadKjLk3i39dviL/YeyGUvq9Dan9PsvkwQejKN/7J0yCr2nYXfwGGCHkcBKkagv79EaRlZigUCp8=

Sollte sich herausstellen, dass ein Angriff auf eine Zone stattfindet, bei der offenbar korrekt signierte aber gefälschte Daten in Umlauf gebracht werden, ist von einer öffentlichen Kenntnis der verwendeten Schlüssel auszugehen. Auch wenn ein Schlüssel verwendet wurde, dessen privater Teil aus anderen Gründen öffentlich bekannt ist, muss ein sofortiger Schlüsselwechsel erfolgen. Hierbei sind allerdings - wie bei allen Rollover-Prozeduren - sowohl die zeitliche Abfolge als auch Wartezeiten für Veröffentlichung und Cache-Timeouts zu beachten. Eine vorschnelle Löschung alter Signaturen kann zu einer Nichterreichbarkeit der Zone für neue Besucher führen. Für Besucher denen bereits gefälschte DNS-Daten ausgeliefert wurden, ist die gefälschte Zone solange gültig, bis die Einträge im Cache des validierenden Resolvers ungültig geworden sind.

Ein Notfall-Keyrollover kann durch Verwendung eines "pre-publish rollover"-Verfahrens beschleunigt werden, wenn bereits ein neuer Schlüssel veröffentlicht ist aber noch nicht für die Signierung verwendet wird. Allerdings ist es denkbar, dass - je nachdem durch welche Sicherheitslücke die privaten Schlüssel bekannt geworden sind - auch der private Teil des neuen Schlüssels bereits bekannt ist.

Der sicherste Weg besteht in der Erzeugung von neuen Schlüsseln auf einem unabhängigen neuen System und der anschließenden Verwendung dieser neuen Schlüssel im Rahmen eines koordinierten Key-Rollovers.

Dies ist vom DLV-Repository abhängig. Einträge in das DLV-Repository der ISC können per Webinterface von Hand durchgeführt werden. Der mitgeteilte DNSKEY-Eintrag wird angenommen und zur Sicherstellung der Kontrolle der Zone wird von ISC ein DNS-TXT-Eintrag erzeugt, den der Zonenadiministrator in der Zone veröffentlichen muss. Sobald das DLV-Repository die Zone erfolgreich auf diesen Eintrag testet, wird sie aufgenommen. Der TXT-Eintrag kann anschließend wieder gelöscht werden.

Weitere Informationen:

• https://dlv.isc.org/

Diese Information ist Registraren der DENIC vorbehalten und kann dort erfragt werden.

Eine gute Sammlung vorhandener Tools findet sich unter: https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources

Exemplarisch seien drei Tools/Libraries hier genannt:

Bind 9

Die aktuelle Version des Bind von ISC liefert Tools für DNSSEC-Schlüsselgenerierung und Zonen-Signierung mit.

Command-Line-Interface

• http://www.isc.org/software/bind/dnssec
• http://www.isc.org/files/DNSSEC_in_6_minutes.pdf

ZKT (OpenSource-DNSSEC-Tools)

Command-Line-Interface, Cron-Automatisierung für Re-Signing der Zonendaten

• http://www.DENIC.de/fileadmin/Domains/DNSSEC/DNSSEC_20100126_Zuleger.pdf

Verisign jDNSSEC-Tools

Auf Java basierende Library, baut das aus Bind bekannte Command-Line-Interface nach.

Der Quellcode kann als Basis für eine Integration in die eigene Zonengenerierung und Signierung dienen, allerdings ist der zu betreibende Aufwand im Vergleich zu Command-Line-Tools ungleich höher.

• http://www.verisignlabs.com/dnssec-tools/

Beispiel: ISC Bind

• http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-60002

Beispiel: Unbound

• http://www.unbound.net/documentation/howto_setup.html
• http://www.unbound.net/documentation/howto_anchor.html
• http://www.ripe.net/ripe/meetings/ripe-56/presentations/Wijngaards-Unbound_DNSSEC_Validating_Resolver.pdf

Ein validierender Resolver wird bei einer fehlerhaften Validierung SERVFAIL zurückliefern. Diese Antwort ist nicht DNSSEC spezifisch und kann in vielen anderen Fällen ebenfalls zurückgeliefert werden, allerdings gibt es aktuell für fehlgeschlagene DNSSEC Validierung keine sinnvollere Antwort. SERVFAIL bedeutet, dass die Anfrage aufgrund eines Serverproblems nicht beantwortet werden konnte. Jegliche Software, die diese DNS Antwort erhält, wird verstehen, dass die Namensauflösung aufgrund eines Fehlers gescheitert ist. Vor allem erhält sie keine Antwort derart: Die IP-Adresse lautet a.b.c.d, aber DNSSEC konnte nicht validiert werden. SERVFAIL stellt sicher, dass keinerlei Antwortdaten enthalten sind, wenn die Validierung fehlschlägt.

Für den Benutzer dürfte das Ergebnis in den meisten Fällen so aussehen, als ob die Domain nicht existiert, was aber im Hintergrund daran liegt, dass die Namensauflösung nicht durchgeführt werden kann. Diese strikte Art der Fehlerbehandlung ist Gegenstand von Diskussionen, allgemein wird aber SERVFAIL als sinnvolle Antwort gesehen, solange nicht im DNS Protokoll eine weitere spezifischere Fehlermeldung eingeführt wurde und flächendeckend unterstützt wird.

Einer Software, welche die Validierung selbst durchführt, ist es natürlich möglich und freigestellt, selbst darauf zu reagieren und dem Benutzer eine andersartige Fehlermeldung anzuzeigen.

Siehe "Welche Debug-Möglichkeiten gibt es?"

Siehe http://www.DENIC.de/domains/dnssec/status/resolver-konfiguration.html

Die einfachste Möglichkeit ist das vorübergehende Abschalten der Validierung im Resolver, falls der Resolver lediglich zum Test eingesetzt wird. Wird der Resolver im Produktivbetrieb eingesetzt, ist zu klären, welche Zonen von der Problematik betroffen sind und welche Auswirkungen dies für die Nutzer hat. Eine Nichterreichbarkeit der .de Zone hätte deutlich größere Auswirkungen als Probleme bei der Validierung einzelner .de-Domains.

Grundsätzlich kann der Fehler mit Hilfe von DNSSEC-Debugging-Tools (dig, drill, o.ae.) genauer eingegrenzt und behoben werden.