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

Die Spezifikation dieses Dokumentensatzes definiert das Verhalten von Zonen-Signierern sowie sicherheitsbewussten Name Servern und Resolvern derart, dass validierende Entitäten den Status der Daten eindeutig bestimmen können.

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

Secure (Sicher) : Der validierende Resolver verfügt über eine Vertrauensanker, besitzt eine Kette des Vertrauens und ist in der Lage, alle Signaturen der Antwort zu überprüfen.

Insecure (Unsicher) : Der validierende Resolver verfügt über eine Vertrauensanker, eine Kette des Vertrauens und, an einem Delegationspunkt, einen signierten Beweis für die Nichtexistenz eines DS-Records. Dies zeigt an, dass nachgelagerte Zweige des Baums als unsicher erweisbar sind. Ein validierender Resolver kann eine lokale Richtlinie haben, um Teile des Domain-Namensraums als unsicher zu markieren.

Bogus (Gefälscht) : Der validierende Resolver verfügt über eine Vertrauensanker und eine sichere Delegation, die angibt, dass die untergeordneten Daten signiert sind, aber die Antwort aus irgendeinem Grund die Validierung nicht besteht: fehlende Signaturen, abgelaufene Signaturen, Signaturen mit nicht unterstützten Algorithmen, fehlende Daten, die der betreffende NSEC-RR als vorhanden ausweist, usw.

Indeterminate (Unbestimmt) : Es gibt keine Vertrauensanker, die angeben würde, dass ein bestimmter Teil des Baums sicher ist. Dies ist der Standardbetriebsmodus.

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

Es existiert ein Mechanismus, mit dem sicherheitsbewusste Name Server sicherheitsbewussten Stub-Resolvern signalisieren können, dass Daten als sicher befunden wurden (durch Verwendung des AD-Bits; siehe [RFC4035]).

Diese Spezifikation definiert kein Format, um mitzuteilen, warum Antworten als gefälscht befunden oder als unsicher markiert wurden. Der aktuelle Signalmechanismus unterscheidet nicht zwischen den Zuständen unbestimmt und unsicher.

Eine Methode zur Signalisierung erweiterter Fehlercodes und Richtlinien zwischen einem sicherheitsbewussten Stub-Resolver und sicherheitsbewussten rekursiven Name Servern ist Gegenstand zukünftiger Arbeiten, ebenso wie die Schnittstelle zwischen einem sicherheitsbewussten Resolver und den Anwendungen, die ihn nutzen. Beachten Sie jedoch, dass das Fehlen einer solchen Kommunikationsspezifikation die Bereitstellung signierter Zonen oder die Bereitstellung rekursiver sicherheitsbewusster Name Server, die die Verbreitung gefälschter Daten an Anwendungen unterbinden, nicht verbietet.