5. Scope of the DNSSEC Document Set and Last Hop Issues (Umfang des DNSSEC-Dokumentensatzes und Last-Hop-Probleme)

Die Spezifikation in diesem Dokumentensatz definiert das Verhalten für Zonensignierer und sicherheitsbewusste Nameserver und Resolver so, dass die validierenden Entitäten den Zustand der Daten eindeutig bestimmen können.

Ein validierender Resolver kann die folgenden 4 Zustände bestimmen:

Secure (Sicher): Der validierende Resolver hat einen Vertrauensanker, hat eine Vertrauenskette und ist in der Lage, alle Signaturen in der Antwort zu verifizieren.

Insecure (Unsicher): Der validierende Resolver hat einen Vertrauensanker, eine Vertrauenskette und an einem Delegationspunkt einen signierten Nachweis der Nichtexistenz eines DS-Datensatzes. Dies zeigt an, dass nachfolgende Zweige im Baum nachweislich unsicher sind. Ein validierender Resolver kann eine lokale Richtlinie haben, um Teile des Domänenraums als unsicher zu markieren.

Bogus (Gefälscht): Der validierende Resolver hat einen Vertrauensanker und eine sichere Delegation, die anzeigt, dass Unterdaten signiert sind, aber die Antwort kann aus irgendeinem Grund nicht validiert werden: fehlende Signaturen, abgelaufene Signaturen, Signaturen mit nicht unterstützten Algorithmen, fehlende Daten, die der relevante NSEC-RR sagt, sollten vorhanden sein, und so weiter.

Indeterminate (Unbestimmt): Es gibt keinen Vertrauensanker, der anzeigen würde, dass ein bestimmter Teil des Baums sicher ist. Dies ist der Standard-Betriebsmodus.

Diese Spezifikation definiert nur, wie sicherheitsbewusste Nameserver nicht validierenden Stub-Resolvern signalisieren können, dass Daten als gefälscht befunden wurden (unter Verwendung von RCODE=2, "Server Failure", Serverfehler, siehe [RFC4035]).

Es gibt einen Mechanismus für sicherheitsbewusste Nameserver, um sicherheitsbewussten Stub-Resolvern zu signalisieren, dass Daten als sicher befunden wurden (unter Verwendung des AD-Bits, siehe [RFC4035]).

Diese Spezifikation definiert kein Format für die Kommunikation, warum Antworten als gefälscht befunden oder als unsicher markiert wurden. Der aktuelle Signalisierungsmechanismus unterscheidet nicht zwischen unbestimmten und unsicheren Zuständen.

Eine Methode zur Signalisierung fortgeschrittener Fehlercodes und Richtlinien zwischen einem sicherheitsbewussten Stub-Resolver und sicherheitsbewussten rekursiven Nameservern ist ein Thema für zukünftige Arbeiten, ebenso wie die Schnittstelle zwischen einem sicherheitsbewussten Resolver und den Anwendungen, die ihn verwenden. Beachten Sie jedoch, dass das Fehlen der Spezifikation einer solchen Kommunikation die Bereitstellung signierter Zonen oder die Bereitstellung sicherheitsbewusster rekursiver Nameserver, die die Verbreitung gefälschter Daten an die Anwendungen verhindern, nicht ausschließt.