Zusammenfassung

  • RFC 3655 ersetzte eine weit gefasste Server-Policy-Aussage durch ein engeres Signal: Die relevanten RRsets der Antwort waren nach den überarbeiteten Regeln authentifiziert.
  • AD ist eine Statusmeldung des Resolvers, weder eine Signatur des DNS-Pakets noch ein Beweis für einen vertrauenswürdigen Resolver, Netzwerkpfad oder die richtige Vertrauensentscheidung des Nutzers.

Analyse

Die Ausgangsszene ist gewöhnlich: Eine Anwendung fragt über ihren lokalen Stub-Resolver einen Namen ab. Der Stub leitet die Anfrage an einen rekursiven Resolver weiter, der der Schlüssel-Kette folgen, Signaturen abrufen und Ergebnisse aus dem Cache wiederverwenden kann. In der Antwort kann ein Header-Bit der Anwendung etwas über diese vorgelagerte Arbeit mitteilen. Die entscheidende Frage ist nicht, wie viele Bits der Header enthält, sondern wer diese Aussage treffen darf und welche Belege sie zusammenfasst.

RFC 2535 gab dem Authenticated-Data-Bit (AD) eine breite Bedeutung: Der Server erklärte, die Daten in Answer und Authority seien gemäß seiner eigenen Policy authentifiziert. RFC 3655 hielt diese Aussage im November 2003 für praktisch wenig hilfreich. Ein konformer Server sollte Daten, die seine Sicherheitspolitik nicht erfüllen, ohnehin nicht zurückgeben. Das Bit beschrieb damit vor allem die allgemeine Haltung des Servers und nicht den Sicherheitsstatus genau dieser Antwort.

Die Neufassung machte die Weitergabe konkreter. Ein rekursiver Server durfte AD nur setzen, wenn die relevanten RRsets in Answer und Authority die Authentifizierungsbedingungen erfüllten. Dazu gehörten die Antwortdaten und die einschlägigen Datensätze, die eine negative Antwort stützten. Das bedeutete nicht, dass jedes DNS-Paket selbst signiert war. DNSSEC authentifiziert Resource-Record-Sets; AD fasst die lokale Bewertung des Resolvers für diese Antwort zusammen.

Deshalb dürfen DO, CD und AD nicht gleichgesetzt werden. DO fordert DNSSEC-Datensätze an; RFC 3655 verlangte, dass sie angefordert und relevante SIG-Datensätze zurückgegeben wurden, bevor AD gesetzt werden durfte. CD deaktiviert die Prüfung für diese Abfrage. Es löschte AD nicht automatisch: Der Server konnte Daten weiterhin markieren, wenn sie bereits kryptografisch geprüft waren oder seiner lokalen Policy entsprachen. Die Bits stehen für verschiedene Schritte: Belege anfordern, Prüfungen steuern und ein Ergebnis melden.

RFC 3655 machte den rekursiven Resolver damit zu einer Vertrauensinstanz. Anwendungen mussten nicht alle einen vollständigen Validator einbauen und konnten Validierungsarbeit aus dem Cache teilen. Ein Stub durfte AD jedoch nicht als selbstbeglaubigenden Beleg ansehen. Er musste dem rekursiven Resolver ausdrücklich vertrauen und die Kommunikation schützen — durch einen sicheren Kanal oder Nachrichtenauthentisierung wie TSIG oder SIG(0). Ohne das blieb ein unterwegs gesetztes AD-Bit eine Behauptung über Validierung, kein sicher zugestellter Validierungsbeleg.

Die Regel für autoritative Server zeigte eine weitere Grenze. Ein Primärserver für eine sichere Zone durfte so konfiguriert werden, AD zu setzen; diese Option musste jedoch ausdrücklich aktiviert und standardmäßig ausgeschaltet sein. Das Dokument stellte klar, dass autoritative Server ihre eigenen Zonendaten nicht zwingend validieren müssen. Signaturen beim Laden oder bei jeder Anfrage zu prüfen, konnte Betriebskosten verursachen. AD in einer direkten autoritativen Antwort war daher standardmäßig keine Zusage rekursiver Validierung.

Auch ein nicht gesetztes AD-Bit lässt sich leicht überdeuten. RFC 3655 verbot AD bei einer unsicheren Antwort. Ein gelöschtes Bit sagte allein aber nicht, ob die Daten unsicher waren, der Resolver sie ungeprüft ließ, angeforderte DNSSEC-Datensätze fehlten oder der Server bewusst keine Aussage traf. AD=1 hatte nur innerhalb einer Vertrauensbeziehung eine klare Bedeutung; AD=0 war keine vollständige Diagnose.

2005 überarbeiteten RFC 4033, RFC 4034 und RFC 4035 den DNSSEC-Rahmen und lösten RFC 3655 ab. Die Statusweitergabe per AD blieb erhalten, wurde aber in eine umfassendere Beschreibung von Validatoren, Stubs, autoritativen Servern und Authentifizierungspfaden eingeordnet. Historisch war RFC 3655 die Reparatur einer schmalen Schnittstelle: die Bewertung eines rekursiven Resolvers weiterzureichen, ohne das Header-Bit selbst als kryptografischen Beweis auszugeben.

Die Beweiskette besteht aus mehreren Ebenen. Eine RRSIG kann die Authentifizierung eines RRsets über eine Schlüsselkette und einen Vertrauensanker stützen. Ein validierender Resolver trifft eine lokale Statusentscheidung. AD kann sie melden. Ein sicherer Kanal zu einem vertrauten Resolver kann die Antwort an den gewählten Dienst binden. Keiner dieser Umstände beweist für sich, dass der Inhaber eines Namens ehrlich ist, die Information für eine Anwendung aktuell bleibt oder die Anwendung sicher gehandelt hat.

Quellen