3. Services Provided by DNS Security (Von der DNS-Sicherheit bereitgestellte Dienste)
Die Security Extensions des Domain Name System (DNS) bieten Dienste zur Datenursprungs-Authentifizierung und Integritätssicherung für DNS-Daten, einschließlich Mechanisme für den authentifizierten Beweis der Nichtexistenz von DNS-Daten. Diese Mechanisme werden im Folgenden beschrieben.
Diese Mechanisme erfordern Änderungen am DNS-Protokoll. DNSSEC fügt vier neue Resource-Record-Typen hinzu: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) und Next Secure (NSEC). Es fügt außerdem zwei neue Bits im Nachrichten-Header hinzu: Checking Disabled (CD) und Authenticated Data (AD). Um die größeren DNS-Nachrichtengrößen zu unterstützen, die sich aus dem Hinzufügen der DNSSEC-RRs ergeben, erfordert DNSSEC zudem die Unterstützung von EDNS0 ([RFC2671]). Schließlich erfordert DNSSEC die Unterstützung des EDNS-DNSSEC-OK-Header-Bits (DO) ([RFC3225]), damit ein sicherheitsbewusster Resolver in seinen Anfragen angeben kann, dass er die DNSSEC-RRs in den Antwortnachrichten erhalten möchte.
Diese Dienste schützen vor den meisten in [RFC3833] beschriebenen Bedrohungen des Domain Name System. Eine Diskussion der Grenzen dieser Erweiterungen finden Sie in Abschnitt 12.
3.1. Data Origin Authentication and Data Integrity (Datenursprungs-Authentifizierung und Datenintegrität)
DNSSEC stellt die Authentifizierung bereit, indem es kryptographisch erzeugte digitale Signaturen an DNS-RRsets bindet. Diese digitalen Signaturen werden in einem neuen Resource Record, dem RRSIG-Record, gespeichert. Es wird im Allgemeinen einen einzelnen privaten Schlüssel geben, der die Daten einer Zone signiert, jedoch sind mehrere Schlüssel möglich. Beispielsweise können für jeden von mehreren verschiedenen digitalen Signaturalgorithmen Schlüssel vorhanden sein. Wenn ein sicherheitsbewusster Resolver den öffentlichen Schlüssel einer Zone zuverlässig erlernt, kann er die signierten Daten dieser Zone authentifizieren. Ein wichtiges DNSSEC-Konzept ist, dass der Schlüssel, der die Daten einer Zone signiert, mit der Zone selbst und nicht mit den autoritativen Name Servern der Zone verknüpft ist. (Öffentliche Schlüssel für DNS-Transaktions-Authentifizierungsmechanismen können ebenfalls in Zonen erscheinen, wie in [RFC2931] beschrieben, aber DNSSEC befasst sich selbst mit der Objektsicherheit von DNS-Daten und nicht mit der Kanalssicherheit von DNS-Transaktionen. Schlüssel, die mit Transaktionssicherheit verbunden sind, können in anderen RR-Typen gespeichert werden. Nähere Einzelheiten finden Sie in [RFC3755].)
Ein sicherheitsbewusster Resolver kann den öffentlichen Schlüssel einer Zone entweder erlernen, indem eine Vertrauensanker in ihm konfiguriert ist, oder durch normale DNS-Auflösung. Um den letzteren Fall zu ermöglichen, werden die öffentlichen Schlüssel in einem neuen Resource-Record-Typ gespeichert, dem DNSKEY-RR. Beachten Sie, dass die privaten Schlüssel, die zur Signierung von Zonendaten verwendet werden, sicher aufbewahrt und nach Möglichkeit offline gespeichert werden müssen. Um einen öffentlichen Schlüssel über die DNS-Auflösung zuverlässig zu entdecken, muss der Zielschlüssel selbst von einem konfigurierten Authentifizierungsschlüssel oder von einem zuvor authentifizierten anderen Schlüssel signiert sein. Sicherheitsbewusste Resolver authentifizieren Zoneninformationen, indem sie eine Kette der Authentifizierung von einem neu erlernten öffentlichen Schlüssel zu einem zuvor bekannten öffentlichen Authentifizierungsschlüssel bilden, der wiederum im Resolver konfiguriert wurde oder zuvor erlernt und verifiziert worden sein muss. Daher muss der Resolver mit mindestens einer Vertrauensanker konfiguriert sein.
Wenn die konfigurierte Vertrauensanker ein Zonen-Signierschlüssel ist, authentifiziert sie die zugehörige Zone; wenn der konfigurierte Schlüssel ein Schlüssel-Signierschlüssel ist, authentifiziert sie einen Zonen-Signierschlüssel. Wenn die konfigurierte Vertrauensanker der Hash eines Schlüssels und nicht der Schlüssel selbst ist, muss der Resolver den Schlüssel möglicherweise über eine DNS-Abfrage abrufen. Um sicherheitsbewusste Resolver beim Aufbau dieser Kette der Authentifizierung zu unterstützen, versuchen sicherheitsbewusste Name Server, die zum Authentifizieren der öffentlichen Schlüssel einer Zone notwendigen Signaturen in der DNS-Antwortnachricht zusammen mit dem öffentlichen Schlüssel selbst zu senden, sofern in der Nachricht Platz vorhanden ist.
Der RR-Typ Delegation Signer (DS) vereinfacht einige der mit der Signierung von Delegationen über organisatorische Grenzen hinweg verbundenen administrativen Aufgaben. Der DS-RRset befindet sich an einem Delegationspunkt in einer übergeordneten Zone und gibt den oder die öffentlichen Schlüssel an, die den privaten Schlüsseln entsprechen, die zur Selbstsignierung des DNSKEY-RRset an der Spitze der delegierten untergeordneten Zone verwendet werden. Der Administrator der untergeordneten Zone wiederum verwendet die privaten Schlüssel, die einem oder mehreren der öffentlichen Schlüssel dieses DNSKEY-RRset entsprechen, um die Daten der untergeordneten Zone zu signieren. Die typische Kette der Authentifizierung ist also DNSKEY->[DS->DNSKEY]->RRset, wobei „“ null oder mehrere DS->DNSKEY-Teilketten bezeichnet. DNSSEC erlaubt komplexere Ketten der Authentifizierung, wie etwa zusätzliche Ebenen von DNSKEY-RRs, die andere DNSKEY-RRs innerhalb einer Zone signieren.
Ein sicherheitsbewusster Resolver bildet diese Kette der Authentifizierung normalerweise von der Wurzel der DNS-Hierarchie zu den Blattzonen, basierend auf dem konfigurierten Wissen um den öffentlichen Schlüssel der Wurzel. Die lokale Richtlinie kann jedoch auch einem sicherheitsbewussten Resolver erlauben, einen oder mehrere konfigurierte öffentliche Schlüssel (oder Hashes öffentlicher Schlüssel) außer dem Wurzel-Schlüssel zu verwenden, muss nicht das konfigurierte Wissen um den Wurzel-Schlüssel bereitstellen oder kann den Resolver daran hindern, bestimmte öffentliche Schlüssel aus beliebigen Gründen zu verwenden, selbst wenn diese öffentlichen Schlüssel ordnungsgemäß mit überprüfbaren Signaturen signiert sind. DNSSEC stellt Mechanisme bereit, mit denen ein sicherheitsbewusster Resolver bestimmen kann, ob die Signatur eines RRset im Sinne von DNSSEC „gültig“ ist. Letztlich unterliegt jedoch sowohl die Authentifizierung von Schlüsseln als auch von DNS-Daten der lokalen Richtlinie, die die in diesem Dokumentensatz definierten Protokollerweiterungen erweitern oder sogar ersetzen kann. Eine weitere Diskussion finden Sie in Abschnitt 5.
3.2. Authenticating Name and Type Non-Existence (Authentifizierung der Nichtexistenz von Namen und Typen)
Der in Abschnitt 3.1 beschriebene Sicherheitsmechanismus bietet nur eine Möglichkeit, die existierenden RRsets einer Zone zu signieren. Das Problem, negative Antworten mit demselben Grad an Authentifizierung und Integrität bereitzustellen, erfordert die Verwendung eines weiteren neuen Resource-Record-Typs, des NSEC-Records. Der NSEC-Record ermöglicht einem sicherheitsbewussten Resolver, eine negative Antwort für die Nichtexistenz eines Namens oder Typs mit denselben Mechanismen zu authentifizieren, die zur Authentifizierung anderer DNS-Antworten verwendet werden. Die Verwendung von NSEC-Records erfordert eine kanonische Darstellung und Sortierung von Domänennamen in Zonen. Die Ketten von NSEC-Records beschreiben explizit die Lücken oder „leeren Räume“ zwischen den Domänennamen einer Zone und zählen die an existierenden Namen vorhandenen RRset-Typen auf. Jeder NSEC-Record wird mit den in Abschnitt 3.1 beschriebenen Mechanismen signiert und authentifiziert.