5. Authenticating DNS Responses (Authentifizierung von DNS-Antworten)
Um DNSSEC-RRs für die Authentifizierung zu verwenden, benötigt ein sicherheitsbewusster Resolver konfiguriertes Wissen über mindestens einen authentifizierten DNSKEY- oder DS-RR. Der Prozess zum Erlangen und Authentifizieren dieses anfänglichen Vertrauensankers wird über einen externen Mechanismus erreicht. Beispielsweise könnte ein Resolver einen offline authentifizierten Austausch verwenden, um den DNSKEY-RR einer Zone zu erhalten oder um einen DS-RR zu erhalten, der den DNSKEY-RR einer Zone identifiziert und authentifiziert. Der Rest dieses Abschnitts setzt voraus, dass der Resolver auf irgendeine Weise eine anfängliche Menge von Vertrauensankern erhalten hat.
Ein anfänglicher DNSKEY-RR kann verwendet werden, um das Apex-DNSKEY-RRset einer Zone zu authentifizieren. Um ein Apex-DNSKEY-RRset mit einem anfänglichen Schlüssel zu authentifizieren, muss (MUST) der Resolver:
- überprüfen, dass der anfängliche DNSKEY-RR im Apex-DNSKEY-RRset erscheint und dass der DNSKEY-RR das Zone Key Flag (DNSKEY RDATA Bit 7) gesetzt hat; und
- überprüfen, dass es einen RRSIG-RR gibt, der das Apex-DNSKEY-RRset abdeckt, und dass die Kombination des RRSIG-RR und des anfänglichen DNSKEY-RR das DNSKEY-RRset authentifiziert. Der Prozess zur Verwendung eines RRSIG-RR zur Authentifizierung eines RRsets wird in Abschnitt 5.3 beschrieben.
Sobald der Resolver das Apex-DNSKEY-RRset mit einem anfänglichen DNSKEY-RR authentifiziert hat, können Delegationen aus dieser Zone mit DS-RRs authentifiziert werden. Dies ermöglicht es einem Resolver, von einem anfänglichen Schlüssel zu starten und DS-RRsets zu verwenden, um rekursiv den DNS-Baum hinabzugehen und andere Apex-DNSKEY-RRsets zu erhalten. Wenn der Resolver mit einem Root-DNSKEY-RR konfiguriert wäre und wenn jede Delegation einen zugeordneten DS-RR hätte, könnte der Resolver jedes beliebige Apex-DNSKEY-RRset erhalten und validieren. Der Prozess zur Verwendung von DS-RRs zur Authentifizierung von Verweisen wird in Abschnitt 5.2 beschrieben.
Abschnitt 5.3 zeigt, wie der Resolver DNSKEY-RRs im Apex-DNSKEY-RRset und RRSIG-RRs aus der Zone verwenden kann, um alle anderen RRsets in der Zone zu authentifizieren, sobald der Resolver das Apex-DNSKEY-RRset einer Zone authentifiziert hat. Abschnitt 5.4 zeigt, wie der Resolver authentifizierte NSEC-RRsets aus der Zone verwenden kann, um zu beweisen, dass ein RRset in der Zone nicht vorhanden ist.
Wenn ein Resolver Unterstützung für DNSSEC anzeigt (durch Setzen des DO-Bits), sollte ein sicherheitsbewusster Nameserver versuchen, die notwendigen DNSKEY-, RRSIG-, NSEC- und DS-RRsets in einer Antwort bereitzustellen (siehe Abschnitt 3). Ein sicherheitsbewusster Resolver kann jedoch immer noch eine Antwort erhalten, die die entsprechenden DNSSEC-RRs nicht enthält, sei es aufgrund von Konfigurationsproblemen wie einem vorgelagerten sicherheitsvergessenen rekursiven Nameserver, der versehentlich mit DNSSEC-RRs interferiert, oder aufgrund eines absichtlichen Angriffs, bei dem ein Angreifer eine Antwort fälscht, DNSSEC-RRs aus einer Antwort entfernt oder eine Abfrage so modifiziert, dass DNSSEC-RRs nicht angefordert zu werden scheinen. Das Fehlen von DNSSEC-Daten in einer Antwort darf (MUST NOT) an sich nicht als Hinweis darauf genommen werden, dass keine Authentifizierungsinformationen existieren.
Ein Resolver sollte (SHOULD) Authentifizierungsinformationen von signierten Zonen erwarten. Ein Resolver sollte (SHOULD) glauben, dass eine Zone signiert ist, wenn der Resolver mit öffentlichen Schlüsselinformationen für die Zone konfiguriert wurde oder wenn die übergeordnete Zone der Zone signiert ist und die Delegation von der übergeordneten Zone ein DS-RRset enthält.
5.1. Special Considerations for Islands of Security (Besondere Überlegungen für Sicherheitsinseln)
Sicherheitsinseln (siehe [RFC4033]) sind signierte Zonen, für die es nicht möglich ist, eine Authentifizierungskette von der übergeordneten Zone zur Zone zu konstruieren. Die Validierung von Signaturen innerhalb einer Sicherheitsinsel erfordert, dass der Validator andere Mittel zum Erlangen eines anfänglichen authentifizierten Zonenschlüssels für die Insel hat. Wenn ein Validator einen solchen Schlüssel nicht erhalten kann, sollte (SHOULD) er zum Betrieb übergehen, als wären die Zonen in der Sicherheitsinsel unsigniert.
Alle normalen Prozesse zur Validierung von Antworten gelten für Sicherheitsinseln. Der einzige Unterschied zwischen normaler Validierung und Validierung innerhalb einer Sicherheitsinsel liegt darin, wie der Validator einen Vertrauensanker für die Authentifizierungskette erhält.
5.2. Authenticating Referrals (Authentifizierung von Verweisen)
Sobald das Apex-DNSKEY-RRset für eine signierte Elternzone authentifiziert wurde, können DS-RRsets verwendet werden, um die Delegation an eine signierte Kindzone zu authentifizieren. Ein DS-RR identifiziert einen DNSKEY-RR im Apex-DNSKEY-RRset der Kindzone und enthält einen kryptografischen Digest des DNSKEY-RR der Kindzone. Die Verwendung eines starken kryptografischen Digest-Algorithmus stellt sicher, dass es rechnerisch nicht machbar ist für einen Angreifer, einen DNSKEY-RR zu generieren, der dem Digest entspricht. Somit ermöglicht die Authentifizierung des Digests einem Resolver, den übereinstimmenden DNSKEY-RR zu authentifizieren. Der Resolver kann dann diesen Kind-DNSKEY-RR verwenden, um das gesamte Kind-Apex-DNSKEY-RRset zu authentifizieren.
Bei einem DS-RR für eine Delegation kann das Apex-DNSKEY-RRset der Kindzone authentifiziert werden, wenn alle folgenden Bedingungen erfüllt sind:
- Der DS-RR wurde mit einem DNSKEY-RR im Apex-DNSKEY-RRset der übergeordneten Zone authentifiziert (siehe Abschnitt 5.3).
- Der Algorithm und Key Tag im DS-RR stimmen mit dem Algorithm-Feld und dem Key Tag eines DNSKEY-RR im Apex-DNSKEY-RRset der Kindzone überein, und wenn der Besitzername und die RDATA des DNSKEY-RR mit dem im Digest Type-Feld des DS-RR spezifizierten Digest-Algorithmus gehasht werden, entspricht der resultierende Digest-Wert dem Digest-Feld des DS-RR.
- Der übereinstimmende DNSKEY-RR in der Kindzone hat das Zone Flag-Bit gesetzt, der entsprechende private Schlüssel hat das Apex-DNSKEY-RRset der Kindzone signiert, und der resultierende RRSIG-RR authentifiziert das Apex-DNSKEY-RRset der Kindzone.
Wenn die Verweisung von der Elternzone kein DS-RRset enthielt, sollte die Antwort ein signiertes NSEC-RRset enthalten haben, das beweist, dass kein DS-RRset für den delegierten Namen existiert (siehe Abschnitt 3.1.4). Ein sicherheitsbewusster Resolver muss (MUST) die Nameserver für die Elternzone nach dem DS-RRset abfragen, wenn die Verweisung weder ein DS-RRset noch ein NSEC-RRset enthält, das beweist, dass das DS-RRset nicht existiert (siehe Abschnitt 4).
Wenn der Validator ein NSEC-RRset authentifiziert, das beweist, dass kein DS-RRset für diese Zone vorhanden ist, dann gibt es keinen Authentifizierungspfad, der von der übergeordneten zur untergeordneten Zone führt. Wenn der Resolver einen anfänglichen DNSKEY- oder DS-RR hat, der zur Kindzone oder zu einer Delegation unterhalb der Kindzone gehört, kann (MAY) dieser anfängliche DNSKEY- oder DS-RR verwendet werden, um einen Authentifizierungspfad wiederherzustellen. Wenn kein solcher anfänglicher DNSKEY- oder DS-RR existiert, kann der Validator RRsets in oder unterhalb der Kindzone nicht authentifizieren.
Wenn der Validator keinen der in einem authentifizierten DS-RRset aufgelisteten Algorithmen unterstützt, hat der Resolver keinen unterstützten Authentifizierungspfad, der von der übergeordneten zur untergeordneten Zone führt. Der Resolver sollte diesen Fall so behandeln, wie er den Fall eines authentifizierten NSEC-RRsets behandeln würde, das beweist, dass kein DS-RRset existiert, wie oben beschrieben.
Beachten Sie, dass es bei einer signierten Delegation zwei NSEC-RRs gibt, die mit dem delegierten Namen verbunden sind. Ein NSEC-RR befindet sich in der Elternzone und kann verwendet werden, um zu beweisen, ob ein DS-RRset für den delegierten Namen existiert. Der zweite NSEC-RR befindet sich in der Kindzone und identifiziert, welche RRsets am Apex der Kindzone vorhanden sind. Der elterliche NSEC-RR und der kindliche NSEC-RR können immer unterschieden werden, da das SOA-Bit im kindlichen NSEC-RR gesetzt und im elterlichen NSEC-RR gelöscht wird. Ein sicherheitsbewusster Resolver muss (MUST) den elterlichen NSEC-RR verwenden, wenn er versucht zu beweisen, dass ein DS-RRset nicht existiert.
Wenn der Resolver keinen der in einem authentifizierten DS-RRset aufgelisteten Algorithmen unterstützt, kann der Resolver den Authentifizierungspfad zur Kindzone nicht verifizieren. In diesem Fall sollte (SHOULD) der Resolver die Kindzone so behandeln, als wäre sie unsigniert.
5.3. Authenticating an RRset with an RRSIG RR (Authentifizierung eines RRsets mit einem RRSIG-RR)
Ein Validator kann einen RRSIG-RR und den entsprechenden DNSKEY-RR verwenden, um zu versuchen, RRsets zu authentifizieren. Der Validator überprüft zunächst den RRSIG-RR, um zu verifizieren, dass er das RRset abdeckt, ein gültiges Zeitintervall hat und einen gültigen DNSKEY-RR identifiziert. Der Validator konstruiert dann die kanonische Form der signierten Daten, indem er die RRSIG-RDATA (ohne das Signature-Feld) mit der kanonischen Form des abgedeckten RRsets anhängt. Schließlich verwendet der Validator den öffentlichen Schlüssel und die Signatur, um die signierten Daten zu authentifizieren. Die Abschnitte 5.3.1, 5.3.2 und 5.3.3 beschreiben jeden Schritt im Detail.
5.3.1. Checking the RRSIG RR Validity (Überprüfung der RRSIG-RR-Gültigkeit)
Ein sicherheitsbewusster Resolver kann einen RRSIG-RR verwenden, um ein RRset zu authentifizieren, wenn alle folgenden Bedingungen erfüllt sind:
- Der RRSIG-RR und das RRset müssen (MUST) denselben Besitzernamen und dieselbe Klasse haben.
- Das Signer's Name-Feld des RRSIG-RR muss (MUST) der Name der Zone sein, die das RRset enthält.
- Das Type Covered-Feld des RRSIG-RR muss (MUST) dem Typ des RRsets entsprechen.
- Die Anzahl der Labels im RRset-Besitzernamen muss (MUST) größer oder gleich dem Wert im Labels-Feld des RRSIG-RR sein.
- Die Vorstellung des Validators von der aktuellen Zeit muss (MUST) kleiner oder gleich der im Expiration-Feld des RRSIG-RR aufgeführten Zeit sein.
- Die Vorstellung des Validators von der aktuellen Zeit muss (MUST) größer oder gleich der im Inception-Feld des RRSIG-RR aufgeführten Zeit sein.
- Die Felder Signer's Name, Algorithm und Key Tag des RRSIG-RR müssen (MUST) mit dem Besitzernamen, dem Algorithmus und dem Key Tag eines DNSKEY-RR im Apex-DNSKEY-RRset der Zone übereinstimmen.
- Der übereinstimmende DNSKEY-RR muss (MUST) im Apex-DNSKEY-RRset der Zone vorhanden sein und muss (MUST) das Zone Flag-Bit (DNSKEY RDATA Flag-Bit 7) gesetzt haben.
Es ist möglich, dass mehr als ein DNSKEY-RR den obigen Bedingungen entspricht. In diesem Fall kann der Validator nicht vorbestimmen, welchen DNSKEY-RR er zur Authentifizierung der Signatur verwenden soll, und er muss (MUST) jeden übereinstimmenden DNSKEY-RR ausprobieren, bis entweder die Signatur validiert ist oder der Validator keine übereinstimmenden öffentlichen Schlüssel mehr zum Ausprobieren hat.
Beachten Sie, dass dieser Authentifizierungsprozess nur dann sinnvoll ist, wenn der Validator den DNSKEY-RR authentifiziert, bevor er ihn zur Validierung von Signaturen verwendet. Der übereinstimmende DNSKEY-RR wird als authentisch betrachtet, wenn:
- das Apex-DNSKEY-RRset, das den DNSKEY-RR enthält, als authentisch betrachtet wird; oder
- das vom RRSIG-RR abgedeckte RRset das Apex-DNSKEY-RRset selbst ist und der DNSKEY-RR entweder einem authentifizierten DS-RR aus der übergeordneten Zone entspricht oder einem Vertrauensanker entspricht.
5.3.2. Reconstructing the Signed Data (Rekonstruktion der signierten Daten)
Sobald der RRSIG-RR die in Abschnitt 5.3.1 beschriebenen Gültigkeitsanforderungen erfüllt hat, muss der Validator die ursprünglichen signierten Daten rekonstruieren. Die ursprünglichen signierten Daten umfassen RRSIG-RDATA (ohne das Signature-Feld) und die kanonische Form des RRsets. Abgesehen davon, dass sie geordnet ist, kann die kanonische Form des RRsets auch vom empfangenen RRset aufgrund von DNS-Namenkomprimierung, dekrementierter TTLs oder Wildcard-Expansion abweichen. Der Validator sollte das Folgende verwenden, um die ursprünglichen signierten Daten zu rekonstruieren:
signed_data = RRSIG_RDATA | RR(1) | RR(2)... wobei
"|" die Konkatenation bezeichnet
RRSIG_RDATA ist das Drahtformat der RRSIG-RDATA-Felder
mit ausgeschlossenem Signature-Feld und dem Signer's Name
in kanonischer Form.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
name wird gemäß der unten stehenden Funktion berechnet
class ist die Klasse des RRsets
type ist der RRset-Typ und alle RRs in der Klasse
OrigTTL ist der Wert aus dem RRSIG Original TTL-Feld
Alle Namen im RDATA-Feld sind in kanonischer Form
Die Menge aller RR(i) wird in kanonischer Reihenfolge sortiert.
Um den Namen zu berechnen:
sei rrsig_labels = der Wert des RRSIG Labels-Feldes
sei fqdn = der vollqualifizierte Domänenname des RRsets in
kanonischer Form
sei fqdn_labels = Label-Anzahl des obigen fqdn.
wenn rrsig_labels = fqdn_labels,
name = fqdn
wenn rrsig_labels < fqdn_labels,
name = "*." | die rechtesten rrsig_label Labels des
fqdn
wenn rrsig_labels > fqdn_labels
hat der RRSIG-RR die notwendigen Validierungsprüfungen
nicht bestanden und darf nicht (MUST NOT) zur Authentifizierung dieses
RRsets verwendet werden.
Die kanonischen Formen für Namen und RRsets sind in [RFC4034] definiert.
NSEC-RRsets an einer Delegationsgrenze erfordern eine spezielle Verarbeitung. Es gibt zwei unterschiedliche NSEC-RRsets, die mit einem signierten delegierten Namen verbunden sind. Ein NSEC-RRset befindet sich in der Elternzone und spezifiziert, welche RRsets in der Elternzone vorhanden sind. Das zweite NSEC-RRset befindet sich in der Kindzone und identifiziert, welche RRsets am Apex der Kindzone vorhanden sind. Das elterliche NSEC-RRset und das kindliche NSEC-RRset können immer unterschieden werden, da nur ein kindlicher NSEC-RR anzeigt, dass ein SOA-RRset am Namen existiert. Bei der Rekonstruktion des ursprünglichen NSEC-RRsets für die Delegation aus der Elternzone dürfen (MUST NOT) die NSEC-RRs nicht mit NSEC-RRs aus der Kindzone kombiniert werden. Bei der Rekonstruktion des ursprünglichen NSEC-RRsets für den Apex der Kindzone dürfen (MUST NOT) die NSEC-RRs nicht mit NSEC-RRs aus der Elternzone kombiniert werden.
Beachten Sie, dass jedes der beiden NSEC-RRsets an einem Delegationspunkt einen entsprechenden RRSIG-RR mit einem Besitzernamen hat, der dem delegierten Namen entspricht, und jeder dieser RRSIG-RRs ist autoritative Daten, die mit derselben Zone verbunden sind, die das entsprechende NSEC-RRset enthält. Falls notwendig, kann ein Resolver diese RRSIG-RRs auseinanderhalten, indem er das Signer's Name-Feld überprüft.
5.3.3. Checking the Signature (Überprüfung der Signatur)
Sobald der Resolver den RRSIG-RR wie in Abschnitt 5.3.1 beschrieben validiert und die ursprünglichen signierten Daten wie in Abschnitt 5.3.2 beschrieben rekonstruiert hat, kann der Validator versuchen, die kryptografische Signatur zu verwenden, um die signierten Daten zu authentifizieren und somit (endlich!) das RRset zu authentifizieren.
Das Algorithm-Feld im RRSIG-RR identifiziert den kryptografischen Algorithmus, der zur Erzeugung der Signatur verwendet wurde. Die Signatur selbst ist im Signature-Feld der RRSIG-RDATA enthalten, und der öffentliche Schlüssel, der zur Verifizierung der Signatur verwendet wird, ist im Public Key-Feld des oder der übereinstimmenden DNSKEY-RR(s) (gefunden in Abschnitt 5.3.1) enthalten. [RFC4034] bietet eine Liste von Algorithmustypen und bietet Zeiger auf die Dokumente, die die Verwendung jedes Algorithmus definieren.
5.4. Authenticated Denial of Existence (Authentifizierte Existenzverweigerung)
Ein Resolver kann authentifizierte NSEC-RRs verwenden, um zu beweisen, dass ein RRset in einer signierten Zone nicht vorhanden ist. Sicherheitsbewusste Nameserver sollten automatisch alle notwendigen NSEC-RRs für signierte Zonen in ihren Antworten an sicherheitsbewusste Resolver einschließen.
Die Existenzverweigerung wird durch die folgenden Regeln bestimmt:
-
Wenn der angeforderte RR-Name mit dem Besitzernamen eines authentifizierten NSEC-RR übereinstimmt, listet das Typ-Bitmap-Feld des NSEC-RR alle RR-Typen auf, die an diesem Besitzernamen vorhanden sind, und ein Resolver kann beweisen, dass der angeforderte RR-Typ nicht existiert, indem er im Bitmap nach dem RR-Typ sucht. Wenn die Anzahl der Labels im Besitzernamen eines authentifizierten NSEC-RR dem Labels-Feld des abdeckenden RRSIG-RR entspricht, beweist die Existenz des NSEC-RR, dass Wildcard-Expansion nicht hätte verwendet werden können, um der Anforderung zu entsprechen.
-
Wenn der angeforderte RR-Name gemäß der in [RFC4034] definierten kanonischen DNS-Namensordnung nach dem Besitzernamen eines authentifizierten NSEC-RR und vor dem im Next Domain Name-Feld dieses NSEC-RR aufgeführten Namen erscheinen würde, existieren keine RRsets mit dem angeforderten Namen in der Zone. Es ist jedoch möglich, dass ein Wildcard verwendet werden könnte, um dem angeforderten RR-Besitzernamen und -Typ zu entsprechen, sodass der Beweis, dass das angeforderte RRset nicht existiert, auch erfordert zu beweisen, dass kein mögliches Wildcard-RRset existiert, das hätte verwendet werden können, um eine positive Antwort zu generieren.
Zusätzlich müssen (MUST) sicherheitsbewusste Resolver die NSEC-RRsets authentifizieren, die den Nicht-Existenzbeweis darstellen, wie in Abschnitt 5.3 beschrieben.
Um die Nicht-Existenz eines RRsets zu beweisen, muss der Resolver in der Lage sein zu verifizieren, dass sowohl das abgefragte RRset nicht existiert als auch dass kein relevantes Wildcard-RRset existiert. Der Beweis hierfür kann mehr als ein NSEC-RRset aus der Zone erfordern. Wenn der vollständige Satz notwendiger NSEC-RRsets in einer Antwort nicht vorhanden ist (möglicherweise aufgrund von Nachrichtenabschneidung), muss (MUST) ein sicherheitsbewusster Resolver die Abfrage erneut senden, um zu versuchen, die vollständige Sammlung von NSEC-RRs zu erhalten, die zur Verifizierung der Nicht-Existenz des angeforderten RRsets erforderlich sind. Wie bei allen DNS-Operationen muss (MUST) der Resolver jedoch die Arbeit begrenzen, die er in die Beantwortung einer bestimmten Abfrage steckt.
Da ein validierter NSEC-RR die Existenz sowohl von sich selbst als auch von seinem entsprechenden RRSIG-RR beweist, muss (MUST) ein Validator die Einstellungen der NSEC- und RRSIG-Bits in einem NSEC-RR ignorieren.
5.5. Resolver Behavior When Signatures Do Not Validate (Resolver-Verhalten, wenn Signaturen nicht validiert werden)
Wenn aus irgendeinem Grund keiner der RRSIGs validiert werden kann, sollte (SHOULD) die Antwort als BAD betrachtet werden. Wenn die Validierung durchgeführt wurde, um eine rekursive Abfrage zu bedienen, muss (MUST) der Nameserver RCODE 2 an den ursprünglichen Client zurückgeben. Er muss (MUST) jedoch die vollständige Antwort zurückgeben, wenn und nur wenn die ursprüngliche Abfrage das CD-Bit gesetzt hatte. Siehe auch Abschnitt 4.7 zum Cachen von Antworten, die nicht validiert werden.
5.6. Authentication Example (Authentifizierungsbeispiel)
Anhang C zeigt ein Beispiel für den Authentifizierungsprozess.