Anhang C. Authentication Examples (Authentifizierungsbeispiele)
Die Beispiele in diesem Abschnitt zeigen, wie die Antwortnachrichten in Anhang B authentifiziert werden.
C.1. Authenticating an Answer (Authentifizierung einer Antwort)
Die Abfrage in Anhang B.1 hat ein MX RRset für x.w.example.com zurückgegeben. Der entsprechende RRSIG zeigt an, dass das MX RRset von einem "example" DNSKEY mit Algorithmus 5 und Key-Tag 38519 signiert wurde. Der Resolver benötigt den entsprechenden DNSKEY RR, um diese Antwort zu authentifizieren. Die folgende Diskussion beschreibt, wie ein Resolver diesen DNSKEY RR erhalten könnte.
Der RRSIG zeigt an, dass die ursprüngliche TTL des MX RRset 3600 war, und zum Zweck der Authentifizierung wird die aktuelle TTL durch 3600 ersetzt. Der RRSIG-Labels-Feldwert von 3 zeigt an, dass die Antwort nicht das Ergebnis einer Wildcard-Erweiterung war. Das MX RRset x.w.example.com wird in kanonische Form gebracht, und unter der Annahme, dass die aktuelle Zeit zwischen den Daten des Signaturbeginns und -ablaufs liegt, wird die Signatur authentifiziert.
C.1.1. Authenticating the Example DNSKEY RR (Authentifizierung des Beispiel-DNSKEY RR)
Dieses Beispiel zeigt den logischen Authentifizierungsprozess, der von einem konfigurierten Root-DNSKEY (oder DS RR) ausgeht und den Baum hinuntergeht, um den gewünschten "example" DNSKEY RR zu authentifizieren. Beachten Sie, dass die logische Reihenfolge zur Klarheit dargestellt wird. Eine Implementierung kann wählen, die Authentifizierung zu konstruieren, wenn Verweise empfangen werden, oder die Authentifizierungskette erst zu konstruieren, nachdem alle RRsets erhalten wurden, oder in jeder anderen Kombination, die sie für angemessen hält. Das Beispiel hier demonstriert nur den logischen Prozess und schreibt keine Implementierungsregeln vor.
Wir nehmen an, dass der Resolver mit einem konfigurierten DNSKEY RR für die Root-Zone (oder einem konfigurierten DS RR für die Root-Zone) beginnt. Der Resolver prüft, ob dieser konfigurierte DNSKEY RR im Root-DNSKEY RRset vorhanden ist (oder ob der DS RR mit einem DNSKEY im Root-DNSKEY RRset übereinstimmt), ob dieser DNSKEY RR das Root-DNSKEY RRset signiert hat und ob die Signaturlebensdauer gültig ist. Wenn alle diese Bedingungen erfüllt sind, werden alle Schlüssel im DNSKEY RRset als authentifiziert betrachtet. Der Resolver verwendet dann einen (oder mehrere) der Root-DNSKEY RRs, um das "example" DS RRset zu authentifizieren. Beachten Sie, dass der Resolver möglicherweise die Root-Zone abfragen muss, um das Root-DNSKEY RRset oder das "example" DS RRset zu erhalten.
Sobald das DS RRset mit dem Root-DNSKEY authentifiziert wurde, prüft der Resolver das "example" DNSKEY RRset auf einen "example" DNSKEY RR, der mit einem der authentifizierten "example" DS RRs übereinstimmt. Wenn ein solcher übereinstimmender "example" DNSKEY gefunden wird, prüft der Resolver, ob dieser DNSKEY RR das "example" DNSKEY RRset signiert hat und ob die Signaturlebensdauer gültig ist. Wenn diese Bedingungen erfüllt sind, werden alle Schlüssel im "example" DNSKEY RRset als authentifiziert betrachtet.
Schließlich prüft der Resolver, dass ein DNSKEY RR im "example" DNSKEY RRset Algorithmus 5 verwendet und ein Key-Tag von 38519 hat. Dieser DNSKEY wird verwendet, um den in der Antwort enthaltenen RRSIG zu authentifizieren. Wenn mehrere "example" DNSKEY RRs mit diesem Algorithmus und Key-Tag übereinstimmen, wird jeder DNSKEY RR ausprobiert, und die Antwort wird authentifiziert, wenn einer der übereinstimmenden DNSKEY RRs die Signatur wie oben beschrieben validiert.
C.2. Name Error (Namensfehler)
Die Abfrage in Anhang B.2 hat NSEC RRs zurückgegeben, die beweisen, dass die angeforderten Daten nicht existieren und kein Wildcard anwendbar ist. Die negative Antwort wird durch Überprüfung beider NSEC RRs authentifiziert. Die NSEC RRs werden auf die gleiche Weise authentifiziert wie das oben diskutierte MX RRset.
C.3. No Data Error (Keine Daten Fehler)
Die Abfrage in Anhang B.3 hat einen NSEC RR zurückgegeben, der beweist, dass der angeforderte Name existiert, aber der angeforderte RR-Typ nicht existiert. Die negative Antwort wird durch Überprüfung des NSEC RR authentifiziert. Der NSEC RR wird auf die gleiche Weise authentifiziert wie das oben diskutierte MX RRset.
C.4. Referral to Signed Zone (Verweis auf signierte Zone)
Die Abfrage in Anhang B.4 hat einen Verweis auf die signierte "a.example."-Zone zurückgegeben. Der DS RR wird auf die gleiche Weise authentifiziert wie das oben diskutierte MX RRset. Dieser DS RR wird verwendet, um das "a.example" DNSKEY RRset zu authentifizieren.
Sobald das "a.example" DS RRset mit dem "example" DNSKEY authentifiziert wurde, prüft der Resolver das "a.example" DNSKEY RRset auf einen "a.example" DNSKEY RR, der mit dem DS RR übereinstimmt. Wenn ein solcher übereinstimmender "a.example" DNSKEY gefunden wird, prüft der Resolver, ob dieser DNSKEY RR das "a.example" DNSKEY RRset signiert hat und ob die Signaturlebensdauer gültig ist. Wenn diese Bedingungen erfüllt sind, werden alle Schlüssel im "a.example" DNSKEY RRset als authentifiziert betrachtet.
C.5. Referral to Unsigned Zone (Verweis auf unsignierte Zone)
Die Abfrage in Anhang B.5 hat einen Verweis auf die unsignierte "b.example."-Zone zurückgegeben. Der NSEC RR beweist, dass kein DS RR mit der "b.example."-Delegation verbunden ist. Der NSEC RR wird auf die gleiche Weise authentifiziert wie das oben diskutierte MX RRset.
Der Resolver stellt fest, dass "b.example." eine unsignierte Zone ist und dass Antworten von "b.example." unsicher sein werden.
C.6. Wildcard Expansion (Wildcard-Erweiterung)
Die Abfrage in Anhang B.6 führte zu einer Wildcard-Erweiterung. Die Untersuchung des RRSIG-Labels-Felds zeigt, dass die Antwort das Ergebnis einer Wildcard-Erweiterung war. Der Wildcard-Name "*.w.example." wird in kanonische Form gebracht und wie in Anhang C.1 authentifiziert. Der Resolver muss auch den NSEC RR überprüfen, um zu beweisen, dass keine nähere Übereinstimmung in der Zone existiert, die anstelle der Wildcard-Übereinstimmung verwendet worden wäre.
C.7. Wildcard No Data Error (Wildcard Keine Daten Fehler)
Die Abfrage in Anhang B.7 wurde mit einem Wildcard beantwortet, aber die Antwort ist eine "keine Daten"-Antwort. Der RRSIG-Labels-Feldwert von 2 im RRSIG zeigt an, dass der NSEC RR von einem Wildcard abgeleitet wurde und liefert den Wildcard-Namen. Der "*.w.example." Wildcard-NSEC RR wird wie in Anhang C.1 authentifiziert. Der Resolver muss auch den NSEC RR überprüfen, um zu beweisen, dass keine nähere Übereinstimmung in der Zone existiert, die anstelle der Wildcard-Übereinstimmung verwendet worden wäre.
C.8. DS Child Zone No Data Error (DS Kindzone Keine Daten Fehler)
Die Abfrage in Anhang B.8 wurde an die Kindzone gesendet und hat einen NSEC RR zurückgegeben, der zeigt, dass kein DS RR in der Kindzone existiert. Beachten Sie, dass der NSEC RR anzeigt, dass es einen SOA RR am Apex der Kindzone gibt, was es dem Resolver ermöglicht zu bestimmen, dass diese Antwort von der Kindzone im Gegensatz zur Elternzone stammt. Der NSEC RR wird auf die gleiche Weise authentifiziert wie das oben diskutierte MX RRset.