3. Services Provided by DNS Security (Von DNS-Sicherheit bereitgestellte Dienste)
Die Domain Name System (DNS) Sicherheitserweiterungen bieten Ursprungsauthentifizierung und Integritätssicherung für DNS-Daten, einschließlich Mechanismen für die authentifizierte Ablehnung der Existenz von DNS-Daten. Diese Mechanismen werden im Folgenden beschrieben.
Diese Mechanismen erfordern Änderungen am DNS-Protokoll. DNSSEC fügt vier neue Ressourcen-Datensatztypen hinzu: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) und Next Secure (NSEC). Es fügt auch zwei neue Nachrichtenkopf-Bits 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 auch EDNS0-Unterstützung ([RFC2671]). Schließlich erfordert DNSSEC Unterstützung für das DNSSEC OK (DO) EDNS-Header-Bit ([RFC3225]), damit ein sicherheitsbewusster Resolver in seinen Anfragen angeben kann, dass er DNSSEC-RRs in Antwortnachrichten empfangen möchte.
Diese Dienste schützen vor den meisten in [RFC3833] beschriebenen Bedrohungen für das Domain Name System. Siehe Abschnitt 12 für eine Diskussion der Einschränkungen dieser Erweiterungen.
3.1. Data Origin Authentication and Data Integrity (Datenursprungsauthentifizierung und Datenintegrität)
DNSSEC bietet Authentifizierung, indem es kryptografisch generierte digitale Signaturen mit DNS-RRsets verknüpft. Diese digitalen Signaturen werden in einem neuen Ressourcen-Datensatz, dem RRSIG-Datensatz, gespeichert. Typischerweise gibt es einen einzelnen privaten Schlüssel, der die Daten einer Zone signiert, aber mehrere Schlüssel sind möglich. Zum Beispiel kann es Schlüssel für mehrere verschiedene digitale Signaturalgorithmen geben. Wenn ein sicherheitsbewusster Resolver den öffentlichen Schlüssel einer Zone zuverlässig lernt, 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 Nameservern der Zone verbunden ist. (Öffentliche Schlüssel für DNS-Transaktionsauthentifizierungsmechanismen können auch in Zonen erscheinen, wie in [RFC2931] beschrieben, aber DNSSEC selbst befasst sich mit der Objektsicherheit von DNS-Daten, nicht mit der Kanalsicherheit von DNS-Transaktionen. Die mit der Transaktionssicherheit verbundenen Schlüssel können in verschiedenen RR-Typen gespeichert werden. Siehe [RFC3755] für Details.)
Ein sicherheitsbewusster Resolver kann den öffentlichen Schlüssel einer Zone entweder lernen, indem er einen Vertrauensanker im Resolver konfiguriert hat oder durch normale DNS-Auflösung. Um Letzteres zu ermöglichen, werden öffentliche Schlüssel in einem neuen Typ von Ressourcen-Datensatz gespeichert, dem DNSKEY-RR. Beachten Sie, dass die privaten Schlüssel, die zum Signieren von Zonendaten verwendet werden, sicher aufbewahrt werden müssen und wenn praktisch offline gespeichert werden sollten. Um einen öffentlichen Schlüssel zuverlässig über DNS-Auflösung zu entdecken, muss der Zielschlüssel selbst entweder von einem konfigurierten Authentifizierungsschlüssel oder einem anderen Schlüssel signiert sein, der zuvor authentifiziert wurde. Sicherheitsbewusste Resolver authentifizieren Zoneninformationen, indem sie eine Authentifizierungskette von einem neu gelernten öffentlichen Schlüssel zurück zu einem zuvor bekannten Authentifizierungs-öffentlichen Schlüssel bilden, der wiederum entweder in den Resolver konfiguriert wurde oder zuvor gelernt und verifiziert worden sein muss. Daher muss der Resolver mit mindestens einem Vertrauensanker konfiguriert sein.
Wenn der konfigurierte Vertrauensanker ein Zonensignaturschlüssel ist, authentifiziert er die zugehörige Zone, wenn der konfigurierte Schlüssel ein Schlüsselsignaturschlüssel ist, authentifiziert er einen Zonensignaturschlüssel. Wenn der konfigurierte Vertrauensanker der Hash eines Schlüssels und nicht der Schlüssel selbst ist, muss der Resolver möglicherweise den Schlüssel über eine DNS-Abfrage erhalten. Um sicherheitsbewussten Resolvern zu helfen, diese Authentifizierungskette herzustellen, versuchen sicherheitsbewusste Nameserver, die Signatur(en), die zur Authentifizierung der öffentlichen Schlüssel einer Zone benötigt werden, in der DNS-Antwortnachricht zusammen mit dem öffentlichen Schlüssel selbst zu senden, vorausgesetzt, dass in der Nachricht Platz verfügbar ist.
Der Delegation Signer (DS) RR-Typ vereinfacht einige der administrativen Aufgaben, die mit der Signierung von Delegationen über Organisationsgrenzen hinweg verbunden sind. Das DS-RRset befindet sich an einem Delegationspunkt in einer Elternzone und gibt die öffentlichen Schlüssel an, die den privaten Schlüsseln entsprechen, die zum Selbstsignieren des DNSKEY-RRset am Scheitelpunkt der delegierten Kindzone verwendet werden. Der Administrator der Kindzone verwendet wiederum die privaten Schlüssel, die einem oder mehreren der öffentlichen Schlüssel in diesem DNSKEY-RRset entsprechen, um die Daten der Kindzone zu signieren. Die typische Authentifizierungskette ist daher DNSKEY->[DS->DNSKEY]->RRset, wobei "" null oder mehr DS->DNSKEY-Unterketten bezeichnet. DNSSEC erlaubt komplexere Authentifizierungsketten, wie zusätzliche Schichten von DNSKEY-RRs, die andere DNSKEY-RRs innerhalb einer Zone signieren.
Ein sicherheitsbewusster Resolver konstruiert diese Authentifizierungskette normalerweise von der Wurzel der DNS-Hierarchie bis zu den Blattzonen basierend auf konfiguriertem Wissen über den öffentlichen Schlüssel für die Wurzel. Die lokale Richtlinie kann jedoch auch einem sicherheitsbewussten Resolver erlauben, einen oder mehrere konfigurierte öffentliche Schlüssel (oder Hashes von öffentlichen Schlüsseln) außer dem Wurzel-öffentlichen Schlüssel zu verwenden, kann kein konfiguriertes Wissen über den Wurzel-öffentlichen 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 verifizierbaren Signaturen signiert sind. DNSSEC bietet Mechanismen, mit denen ein sicherheitsbewusster Resolver bestimmen kann, ob die Signatur eines RRset im Sinne von DNSSEC "gültig" ist. In der endgültigen Analyse ist jedoch die Authentifizierung sowohl von DNS-Schlüsseln als auch von Daten eine Frage der lokalen Richtlinie, die die in diesem Dokumentensatz definierten Protokollerweiterungen erweitern oder sogar überschreiben kann. Siehe Abschnitt 5 für weitere Diskussionen.
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, vorhandene RRsets in einer Zone zu signieren. Das Problem, negative Antworten mit demselben Grad an Authentifizierung und Integrität bereitzustellen, erfordert die Verwendung eines weiteren neuen Ressourcen-Datensatztyps, des NSEC-Datensatzes. Der NSEC-Datensatz ermöglicht es einem sicherheitsbewussten Resolver, eine negative Antwort für entweder Namen- oder Typnichtexistenz mit denselben Mechanismen zu authentifizieren, die zur Authentifizierung anderer DNS-Antworten verwendet werden. Die Verwendung von NSEC-Datensätzen erfordert eine kanonische Darstellung und Sortierung für Domainnamen in Zonen. Ketten von NSEC-Datensätzen beschreiben explizit die Lücken oder "Leerräume" zwischen Domainnamen in einer Zone und listen die Typen von RRsets auf, die an vorhandenen Namen vorhanden sind. Jeder NSEC-Datensatz wird unter Verwendung der in Abschnitt 3.1 beschriebenen Mechanismen signiert und authentifiziert.