5.5. DNSSEC Processing - DNS64 in Validating Resolver Mode

5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode (DNSSEC-Verarbeitung: DNS64 im Validating-Resolver-Modus)

Wir betrachten den Fall, in dem ein rekursiver Resolver, der DNS64 durchführt, auch eine lokale Policy hat, um die Antworten gemäß den in [RFC4035], Abschnitt 5, beschriebenen Verfahren zu validieren. Wir nennen diesen allgemeinen Fall vDNS64.

vDNS64 verwendet das Vorhandensein der DO- und CD-Bits, um einige Entscheidungen darüber zu treffen, was der Abfrageinitiator benötigt, und kann entsprechend reagieren:

1. Wenn CD nicht gesetzt ist und DO nicht gesetzt ist, SOLLTE vDNS64 eine Validierung durchführen und bei Bedarf eine Synthese durchführen. Siehe den nächsten Punkt für Regeln zur Durchführung von Validierung und Synthese. In diesem Fall DARF vDNS64 jedoch das AD-Bit in keiner Antwort setzen.

2. Wenn CD nicht gesetzt ist und DO gesetzt ist, SOLLTE vDNS64 eine Validierung durchführen. Wann immer vDNS64 eine Validierung durchführt, MUSS es die negative Antwort auf AAAA-Abfragen validieren, bevor es mit der Abfrage von A-Einträgen für denselben Namen fortfährt, um sicherzustellen, dass es keinen legitimen AAAA-Eintrag im Internet gibt. Die Nichtbeachtung dieses Schritts würde es einem Angreifer ermöglichen, DNS64 als Mechanismus zur Umgehung von DNSSEC zu verwenden. Wenn die negative Antwort validiert wird und die Antwort auf die A-Abfrage validiert wird, KANN vDNS64 eine Synthese durchführen und SOLLTE das AD-Bit in der Antwort an den Client setzen. Dies ist akzeptabel, da [RFC4035], Abschnitt 3.2.3, besagt, dass das AD-Bit von der Nameserver-Seite eines sicherheitsbewussten rekursiven Nameservers genau dann gesetzt wird, wenn er alle RRSets im Answer- und Authority-Abschnitt als authentisch betrachtet. In diesem Fall hat der Nameserver Grund zu glauben, dass die RRSets alle authentisch sind, also SOLLTE er das AD-Bit setzen. Wenn die Daten nicht validieren, MUSS vDNS64 mit RCODE=2 (Server failure) antworten.

   Ein sicherheitsbewusster Endpunkt könnte das Vorhandensein des AD-Bits als Hinweis darauf nehmen, dass die Daten gültig sind, und kann die DNS- (und DNSSEC-)Daten an eine Anwendung weitergeben. Wenn die Anwendung versucht, die synthetisierten Daten zu validieren, wird die Validierung natürlich fehlschlagen. Man könnte daher argumentieren, dass dieser Ansatz nicht wünschenswert ist, aber sicherheitsbewusste Stub-Resolver DÜRFEN NICHT auf Daten vertrauen, die von Resolvern empfangen und in ihrem Namen ohne bestimmte in [RFC4035], Abschnitt 4.9.3, festgelegte Kriterien validiert wurden. Eine Anwendung, die selbst eine Validierung durchführen möchte, sollte das CD-Bit verwenden.

3. Wenn das CD-Bit gesetzt ist und DO gesetzt ist, KANN vDNS64 eine Validierung durchführen, DARF jedoch KEINE Synthese durchführen. Es MUSS die Daten an den Abfrageinitiator zurückgeben, genau wie ein regulärer rekursiver Resolver, und darauf vertrauen, dass der Client die Validierung und die Synthese selbst durchführt.

   Der Nachteil dieses Ansatzes besteht darin, dass ein Endpunkt, der übersetzungsoblivious, aber sicherheitsbewusst und validierend ist, die DNS64-Funktionalität nicht nutzen kann. In diesem Fall wird der Endpunkt nicht den gewünschten Nutzen von NAT64 haben. Tatsächlich bedeutet diese Strategie, dass jeder Endpunkt, der in einem NAT64-Kontext eine Validierung durchführen möchte, auch aktualisiert werden muss, um übersetzungsbewusst zu sein.