12. Security Considerations (Sicherheitsüberlegungen)

Dieses Dokument führt DNS-Sicherheitserweiterungen ein und beschreibt die Dokumentensammlung, die die neuen Sicherheitseinträge und DNS-Protokolländerungen enthält. Die Erweiterungen bieten Datenursprungsauthentifizierung und Datenintegrität unter Verwendung digitaler Signaturen über Ressourceneintragssätzen. Dieser Abschnitt diskutiert die Einschränkungen dieser Erweiterungen.

Damit ein sicherheitsbewusster Resolver eine DNS-Antwort validieren kann, müssen alle Zonen entlang des Pfades vom vertrauenswürdigen Ausgangspunkt zur Zone, die die Antwortzonen enthält, signiert sein, und alle am Auflösungsprozess beteiligten Nameserver und Resolver müssen sicherheitsbewusst sein, wie in dieser Dokumentensammlung definiert. Ein sicherheitsbewusster Resolver kann Antworten, die von einer unsignierten Zone stammen, von einer Zone, die nicht von einem sicherheitsbewussten Nameserver bedient wird, oder für alle DNS-Daten, die der Resolver nur über einen rekursiven Nameserver erhalten kann, der nicht sicherheitsbewusst ist, nicht überprüfen. Wenn es eine Unterbrechung in der Authentifizierungskette gibt, sodass ein sicherheitsbewusster Resolver die benötigten Authentifizierungsschlüssel nicht erhalten und validieren kann, dann kann der sicherheitsbewusste Resolver die betroffenen DNS-Daten nicht validieren.

Dieses Dokument diskutiert kurz andere Methoden zum Hinzufügen von Sicherheit zu einer DNS-Abfrage, wie die Verwendung eines durch IPsec gesicherten Kanals oder die Verwendung eines DNS-Transaktionsauthentifizierungsmechanismus wie TSIG ([RFC2845]) oder SIG(0) ([RFC2931]), aber Transaktionssicherheit ist per se nicht Teil von DNSSEC.

Ein nicht validierender sicherheitsbewusster Stub-Resolver führt per Definition selbst keine DNSSEC-Signaturvalidierung durch und ist daher sowohl anfällig für Angriffe auf (und von) die sicherheitsbewussten rekursiven Nameserver, die diese Überprüfungen in seinem Namen durchführen, als auch für Angriffe auf seine Kommunikation mit diesen sicherheitsbewussten rekursiven Nameservern. Nicht validierende sicherheitsbewusste Stub-Resolver sollten eine Form von Kanalsicherheit verwenden, um sich gegen die letztere Bedrohung zu verteidigen. Die einzige bekannte Verteidigung gegen die erstere Bedrohung wäre, dass der sicherheitsbewusste Stub-Resolver seine eigene Signaturvalidierung durchführt, an welchem Punkt er per Definition kein nicht validierender sicherheitsbewusster Stub-Resolver mehr wäre.

DNSSEC schützt nicht vor Denial-of-Service-Angriffen. DNSSEC macht DNS anfällig für eine neue Klasse von Denial-of-Service-Angriffen, die auf kryptografischen Operationen gegen sicherheitsbewusste Resolver und sicherheitsbewusste Nameserver basieren, da ein Angreifer versuchen kann, DNSSEC-Mechanismen zu verwenden, um die Ressourcen eines Opfers zu verbrauchen. Diese Angriffsklasse nimmt mindestens zwei Formen an. Ein Angreifer kann möglicherweise Ressourcen im Signaturvalidierungscode eines sicherheitsbewussten Resolvers verbrauchen, indem er RRSIG-RRs in Antwortnachrichten manipuliert oder unnötig komplexe Signaturketten konstruiert. Ein Angreifer kann auch möglicherweise Ressourcen in einem sicherheitsbewussten Nameserver verbrauchen, der DNS Dynamic Update unterstützt, indem er einen Strom von Update-Nachrichten sendet, die den sicherheitsbewussten Nameserver zwingen, einige RRsets in der Zone häufiger neu zu signieren, als dies sonst notwendig wäre.

Aufgrund einer bewussten Designentscheidung bietet DNSSEC keine Vertraulichkeit.

DNSSEC führt die Fähigkeit für eine feindliche Partei ein, alle Namen in einer Zone aufzuzählen, indem sie der NSEC-Kette folgt. NSEC-RRs behaupten, welche Namen in einer Zone nicht existieren, indem sie von existierendem Namen zu existierendem Namen entlang einer kanonischen Ordnung aller Namen innerhalb einer Zone verlinken. Somit kann ein Angreifer diese NSEC-RRs nacheinander abfragen, um alle Namen in einer Zone zu erhalten. Obwohl dies kein Angriff auf das DNS selbst ist, könnte es einem Angreifer ermöglichen, Netzwerk-Hosts oder andere Ressourcen durch Aufzählung des Inhalts einer Zone zu kartieren.

DNSSEC führt erhebliche zusätzliche Komplexität in das DNS ein und führt daher viele neue Möglichkeiten für Implementierungsfehler und falsch konfigurierte Zonen ein. Insbesondere kann die Aktivierung der DNSSEC-Signaturvalidierung in einem Resolver dazu führen, dass ganze legitime Zonen aufgrund von DNSSEC-Konfigurationsfehlern oder Fehlern praktisch unerreichbar werden.

DNSSEC schützt nicht vor Manipulation unsignierter Zonendaten. Nicht-autoritative Daten an Zonenschnitten (Glue- und NS-RRs in der Elternzone) sind nicht signiert. Dies stellt kein Problem dar, wenn die Authentifizierungskette validiert wird, bedeutet aber, dass die nicht-autoritativen Daten selbst während Zonentransferoperationen anfällig für Manipulation sind. Während DNSSEC also Datenursprungsauthentifizierung und Datenintegrität für RRsets bereitstellen kann, kann es dies nicht für Zonen tun, und andere Mechanismen (wie TSIG, SIG(0) oder IPsec) müssen verwendet werden, um Zonentransferoperationen zu schützen.

Bitte siehe [RFC4034] und [RFC4035] für zusätzliche Sicherheitsüberlegungen.