7. Stub Resolver Considerations (Stub-Resolver-Überlegungen)

Obwohl das Protokoll dies nicht strikt erfordert, stammen die meisten DNS-Abfragen von Stub-Resolvern. Stub-Resolver sind per Definition minimale DNS-Resolver, die den rekursiven Abfragemodus verwenden, um den größten Teil der Arbeit der DNS-Auflösung auf einen rekursiven Nameserver auszulagern. Angesichts der weit verbreiteten Verwendung von Stub-Resolvern muss die DNSSEC-Architektur Stub-Resolver berücksichtigen, aber die in einem Stub-Resolver erforderlichen Sicherheitsfunktionen unterscheiden sich in einigen Aspekten von denen, die in einem sicherheitsbewussten iterativen Resolver erforderlich sind.

Selbst ein sicherheitsahnungsloser Stub-Resolver kann von DNSSEC profitieren, wenn die von ihm verwendeten rekursiven Nameserver sicherheitsbewusst sind, aber damit der Stub-Resolver sich tatsächlich auf DNSSEC-Dienste verlassen kann, muss der Stub-Resolver sowohl den betreffenden rekursiven Nameservern als auch den Kommunikationskanälen zwischen sich und diesen Nameservern vertrauen. Das erste dieser Probleme ist eine Frage der lokalen Richtlinie: Im Wesentlichen hat ein sicherheitsahnungsloser Stub-Resolver keine andere Wahl, als sich der Gnade der von ihm verwendeten rekursiven Nameserver auszuliefern, da er selbst keine DNSSEC-Gültigkeitsprüfungen durchführt. Das zweite Problem erfordert eine Art Kanalsicherheitsmechanismus, die ordnungsgemäße Verwendung von DNS-Transaktionsauthentifizierungsmechanismen wie SIG(0) ([RFC2931]) oder TSIG ([RFC2845]) würde ausreichen, ebenso wie die angemessene Verwendung von IPsec. Bestimmte Implementierungen können andere verfügbare Optionen haben, wie z.B. betriebssystemspezifische Interprozess-Kommunikationsmechanismen. Vertraulichkeit ist für diesen Kanal nicht erforderlich, aber Datenintegrität und Nachrichtenauthentifizierung sind erforderlich.

Ein sicherheitsbewusster Stub-Resolver, der sowohl seinen rekursiven Nameservern als auch seinem Kommunikationskanal zu ihnen vertraut, kann wählen, die Einstellung des Authenticated Data (AD)-Bits im Nachrichtenkopf der von ihm empfangenen Antwortnachrichten zu überprüfen. Der Stub-Resolver kann dieses Flag-Bit als Hinweis verwenden, um herauszufinden, ob der rekursive Nameserver in der Lage war, Signaturen für alle Daten in den Answer- und Authority-Abschnitten der Antwort zu validieren.

Es gibt einen weiteren Schritt, den ein sicherheitsbewusster Stub-Resolver unternehmen kann, wenn er aus irgendeinem Grund keine nützliche Vertrauensbeziehung zu den von ihm verwendeten rekursiven Nameservern aufbauen kann: Er kann seine eigene Signaturvalidierung durchführen, indem er das Checking Disabled (CD)-Bit in seinen Abfragenachrichten setzt. Ein validierender Stub-Resolver ist somit in der Lage, die DNSSEC-Signaturen als Vertrauensbeziehungen zwischen den Zonenadministratoren und dem Stub-Resolver selbst zu behandeln.