Zum Hauptinhalt springen

5. DNS64 Normative Specification (DNS64 Normative Spezifikation)

DNS64 ist eine logische Funktion, die AAAA-Einträge aus A-Einträgen synthetisiert. Die DNS64-Funktion kann in einem Stub-Resolver, in einem rekursiven Resolver oder in einem autoritativen Nameserver implementiert werden. Sie funktioniert innerhalb dieser DNS-Funktionen und erscheint im Netzwerk, als ob sie ein "einfacher" DNS-Resolver oder Nameserver wäre, der [RFC1034] und [RFC1035] entspricht.

Die Implementierung SOLLTE die Zuordnung separater IPv4-Adressbereiche zu separaten IPv6-Präfixen für die AAAA-Eintrags-Synthese unterstützen. Dies ermöglicht die Handhabung spezieller IPv4-Adressen [RFC5735].

DNS-Nachrichten enthalten mehrere Abschnitte. Der Teil einer DNS-Nachricht, der von DNS64 geändert wird, ist der Antwortabschnitt (Answer Section), der weiter unten in Abschnitt 5.1 besprochen wird. Die resultierende synthetische Antwort wird mit anderen Abschnitten zusammengestellt, und dies erstellt die Nachricht, die tatsächlich als Antwort auf die DNS-Abfrage zurückgegeben wird. Die Zusammenstellung dieser Antwort wird weiter unten in Abschnitt 5.4 behandelt.

DNS64 antwortet auch auf PTR-Abfragen, die Adressen betreffen, die eines der IPv6-Präfixe enthalten, die es für die Synthese von AAAA RRs verwendet.

5.1. Resolving AAAA Queries and the Answer Section (AAAA-Abfragen auflösen und der Antwortabschnitt)​

Wenn DNS64 eine Abfrage nach RRs vom Typ AAAA und Klasse IN empfängt, versucht es zunächst, nicht-synthetische RRs dieses Typs und dieser Klasse abzurufen, entweder durch Ausführen einer Abfrage oder, im Fall eines autoritativen Servers, durch Überprüfung seiner eigenen Ergebnisse. Die Abfrage kann aus einem lokalen Cache beantwortet werden, falls einer verfügbar ist. Der DNS64-Betrieb für andere Klassen als IN ist nicht definiert, und ein DNS64 MUSS sich so verhalten, als ob keine DNS64-Funktion konfiguriert wäre.

5.1.1. The Answer when There is AAAA Data Available (Die Antwort, wenn AAAA-Daten verfügbar sind)​

Wenn die Abfrage zu einem oder mehreren AAAA-Einträgen im Antwortabschnitt führt, wird das Ergebnis an den anfragenden Client gemäß normaler DNS-Semantik zurückgegeben, außer in dem Fall, in dem einer der AAAA-Einträge mit einem speziellen Ausschlusssatz von Präfixen übereinstimmt, wie in Abschnitt 5.1.4 betrachtet. Wenn (nicht ausgeschlossene) AAAA-Daten verfügbar sind, SOLLTE DNS64 KEINE synthetischen AAAA RRs in die Antwort aufnehmen (siehe Anhang A für eine Analyse der Motivationen und Implikationen der Nichteinhaltung dieser Empfehlung). Standardmäßig DÜRFEN DNS64-Implementierungen KEINE AAAA RRs synthetisieren, wenn echte AAAA RRs existieren.

5.1.2. The Answer when There is an Error (Die Antwort bei einem Fehler)​

Wenn die Abfrage zu einer Antwort mit einem anderen RCODE als 0 (No error condition) führt, gibt es zwei Möglichkeiten. Ein Ergebnis mit RCODE=3 (Name Error) wird gemäß normalem DNS-Betrieb behandelt (was normalerweise bedeutet, den Fehler an den Client zurückzugeben). Diese Phase liegt noch vor jeder Synthese, daher benötigt eine Antwort, die an den Client zurückgegeben werden soll, keine spezielle Zusammenstellung außer dem, was normalerweise im DNS-Betrieb geschehen würde.

Jeder andere RCODE wird so behandelt, als wäre der RCODE 0 (siehe Abschnitte 5.1.6 und 5.1.7) und der Antwortabschnitt leer. Dies liegt an der großen Anzahl verschiedener Antworten von bereitgestellten Nameservern, wenn sie AAAA-Abfragen erhalten, ohne dass ein AAAA-Eintrag verfügbar ist (siehe [RFC4074]). Beachten Sie, dass dies praktisch bedeutet, dass mehrere verschiedene Fehlerklassen im DNS alle so behandelt werden, als ob ein AAAA-Eintrag für diesen Owner Name nicht verfügbar wäre.

Es ist wichtig zu beachten, dass zum Zeitpunkt des Verfassens dieses Dokuments einige Server mit RCODE=3 auf eine AAAA-Abfrage antworten, selbst wenn ein A-Eintrag für diesen Owner Name verfügbar ist. Diese Server verstoßen eindeutig gegen die Bedeutung von RCODE 3, und es wird erwartet, dass ihre Nutzung mit zunehmender IPv6-Bereitstellung abnimmt.

5.1.3. Dealing with Timeouts (Umgang mit Timeouts)​

Wenn die Abfrage keine Antwort vor dem Timeout erhält (was das Timeout von jedem autoritativen Server sein könnte, je nachdem, ob sich DNS64 im Recursive-Resolver-Modus befindet), wird sie als RCODE=2 (Server failure) behandelt.

5.1.4. Special Exclusion Set for AAAA Records (Spezieller Ausschlusssatz für AAAA-Einträge)​

Einige IPv6-Adressen sind für reine IPv6-Hosts tatsächlich nicht nutzbar. Wenn sie als AAAA-Einträge an reine IPv6-Abfrage-Agenten zurückgegeben werden, wird das Ziel, die Anzahl der Fehlermodi zu verringern, nicht erreicht. Beispiele sind AAAA-Einträge mit Adressen im ::ffff:0:0/96-Netzwerk und möglicherweise (je nach Kontext) AAAA-Einträge mit dem Pref64::/n der Site oder dem Well-Known Prefix (siehe unten für mehr über das Well-Known Prefix). Eine DNS64-Implementierung SOLLTE einen Mechanismus bereitstellen, um IPv6-Präfixbereiche anzugeben, die so behandelt werden sollen, als ob die sie enthaltenden AAAA-Einträge eine leere Antwort wären. Eine Implementierung SOLLTE standardmäßig das ::ffff/96-Netzwerk in diesen Bereich einschließen. Das Fehlen dieser Funktion bedeutet, dass Clients, die die DNS64-Funktion abfragen, möglicherweise nicht mit Hosts kommunizieren können, die von einem Dual-Stack-Host aus erreichbar wären.

Wenn DNS64 seine anfängliche AAAA-Abfrage durchführt und eine Antwort mit nur AAAA-Einträgen erhält, die Adressen im/in den ausgeschlossenen Bereich(en) enthalten, MUSS es die Antwort so behandeln, als wäre sie eine leere Antwort, und entsprechend fortfahren. Wenn es eine Antwort mit mindestens einem AAAA-Eintrag erhält, der eine Adresse außerhalb aller ausgeschlossenen Bereiche enthält, SOLLTE es standardmäßig einen Antwortabschnitt für eine Antwort erstellen, der nur die AAAA-Einträge enthält, die keine der Adressen innerhalb der ausgeschlossenen Bereiche enthalten. Dieser Antwortabschnitt wird bei der Zusammenstellung einer Antwort wie in Abschnitt 5.4 beschrieben verwendet. Alternativ KANN es die Antwort so behandeln, als wäre sie eine leere Antwort, und entsprechend fortfahren. Es DARF die beanstandeten AAAA-Einträge NICHT als Teil einer Antwort zurückgeben.

5.1.5. Dealing with CNAME and DNAME (Umgang mit CNAME und DNAME)​

Wenn die Antwort einen CNAME oder einen DNAME enthält, wird der CNAME- oder DNAME-Kette gefolgt, bis der erste abschließende A- oder AAAA-Eintrag erreicht ist. Dies kann erfordern, dass DNS64 nach einem A-Eintrag fragt, falls die Antwort auf die ursprüngliche AAAA-Abfrage ein CNAME oder DNAME ohne einen nachfolgenden AAAA-Eintrag ist. Der resultierende AAAA- oder A-Eintrag wird wie jeder andere AAAA- oder A-Fall behandelt, wie jeweils angemessen.

Beim Zusammenstellen des Antwortabschnitts werden alle Ketten von CNAME- oder DNAME-RRs als Teil der Antwort zusammen mit dem synthetischen AAAA (falls angemessen) eingeschlossen.

5.1.6. Data for the Answer when Performing Synthesis (Daten für die Antwort bei der Synthese)​

Wenn die Abfrage zu keinem Fehler, aber einem leeren Antwortabschnitt in der Antwort führt, versucht DNS64, A-Einträge für den betreffenden Namen abzurufen, entweder durch Ausführen einer anderen Abfrage oder, im Fall eines autoritativen Servers, durch Überprüfung seiner eigenen Ergebnisse. Wenn diese neue A RR-Abfrage zu einer leeren Antwort oder einem Fehler führt, wird die leere Antwort oder der Fehler als Grundlage für die an den abfragenden Client zurückgegebene Antwort verwendet. Wenn die Abfrage stattdessen zu einem oder mehreren A RRs führt, synthetisiert DNS64 AAAA RRs basierend auf den A RRs gemäß dem in Abschnitt 5.1.7 beschriebenen Verfahren. DNS64 gibt die synthetisierten AAAA-Einträge im Antwortabschnitt zurück und entfernt die A-Einträge, die die Grundlage der Synthese bilden.

5.1.7. Performing the Synthesis (Durchführung der Synthese)​

Ein synthetischer AAAA-Eintrag wird aus einem A-Eintrag wie folgt erstellt:

  • Das NAME-Feld wird auf das NAME-Feld aus dem A-Eintrag gesetzt.

  • Das TYPE-Feld wird auf 28 (AAAA) gesetzt.

  • Das CLASS-Feld wird auf das ursprüngliche CLASS-Feld, 1, gesetzt. Unter dieser Spezifikation ist DNS64 für jede andere CLASS als 1 nicht definiert.

  • Das Time to Live (TTL)-Feld wird auf das Minimum des TTL des ursprünglichen A RR und des SOA RR für die abgefragte Domain gesetzt. (Beachten Sie, dass DNS64 keine neue Abfrage durchführen muss, um das TTL des SOA RR zu erhalten, sondern sich an das TTL aus dem SOA RR in der negativen Antwort auf die AAAA-Abfrage erinnern kann. Wenn der SOA RR nicht mit der negativen Antwort auf die AAAA-Abfrage geliefert wurde, SOLLTE DNS64 das TTL des ursprünglichen A RR oder 600 Sekunden verwenden, je nachdem, welches kürzer ist. Es ist stattdessen möglich, explizit nach dem SOA RR zu fragen und das Ergebnis dieser Abfrage zu verwenden, aber dies erhöht die Abfragelast und die Zeit zur Auflösung bei geringem zusätzlichen Nutzen.) Dies entspricht dem in Negative Caching [RFC2308] verwendeten Ansatz.

  • Das RDLENGTH-Feld wird auf 16 gesetzt.

  • Das RDATA-Feld wird auf die IPv6-Darstellung der IPv4-Adresse aus dem RDATA-Feld des A-Eintrags gesetzt. DNS64 MUSS jeden A RR gegen konfigurierte IPv4-Adressbereiche prüfen und das entsprechende IPv6-Präfix auswählen, das bei der Synthese des AAAA RR verwendet werden soll. Siehe Abschnitt 5.2 für eine Diskussion der bei der Transformation zu verwendenden Algorithmen.

5.1.8. Querying in Parallel (Parallele Abfragen)​

DNS64 KANN die Abfrage nach dem AAAA RR und nach dem A RR parallel durchführen, um die Verzögerung zu minimieren.

HINWEIS: Parallele Abfragen führen dazu, dass unnötige A RR-Abfragen in dem Fall durchgeführt werden, in dem keine AAAA RR-Synthese erforderlich ist. Ein möglicher Kompromiss wäre, sie sequenziell, aber mit einem sehr kurzen Intervall zwischen ihnen durchzuführen, so dass wir, wenn wir eine schnelle Antwort erhalten, die zusätzliche Abfrage vermeiden. (Beachten Sie, dass diese Diskussion nur relevant ist, wenn die DNS64-Funktion externe Abfragen durchführen muss, um die RR abzurufen. Wenn die benötigten RR-Informationen lokal verfügbar sind, wie im Fall eines autoritativen Servers, ist das Problem nicht mehr relevant.)

5.2. Generation of the IPv6 Representations of IPv4 Addresses (Generierung der IPv6-Darstellungen von IPv4-Adressen)​

DNS64 unterstützt mehrere Algorithmen für die Generierung der IPv6-Darstellung einer IPv4-Adresse. Die den Generierungsalgorithmen auferlegten Einschränkungen sind die folgenden:

  • Derselbe Algorithmus zur Erstellung einer IPv6-Adresse aus einer IPv4-Adresse MUSS sowohl von einem DNS64 verwendet werden, um die IPv6-Adresse zu erstellen, die im synthetischen AAAA RR aus der in einem ursprünglichen A RR enthaltenen IPv4-Adresse zurückgegeben werden soll, als auch von einem IPv6/IPv4-Translator, um die IPv6-Adresse zu erstellen, die im Quelladressfeld der ausgehenden IPv6-Pakete aus der im Quelladressfeld des eingehenden IPv4-Pakets enthaltenen IPv4-Adresse eingeschlossen werden soll.

  • Der Algorithmus MUSS reversibel sein; d.h., es MUSS möglich sein, die ursprüngliche IPv4-Adresse aus der IPv6-Darstellung abzuleiten.

  • Die Eingabe für den Algorithmus MUSS auf die IPv4-Adresse beschränkt sein; das IPv6-Präfix (bezeichnet als Pref64::/n), das in den IPv6-Darstellungen verwendet wird; und optional einen Satz stabiler Parameter, die im DNS64 und im NAT64 konfiguriert sind (wie eine feste Zeichenfolge, die als Suffix verwendet werden soll).

    • Für jedes Präfix Pref64::/n MUSS n kleiner oder gleich 96 sein. Wenn ein oder mehrere Pref64::/n im DNS64 durch beliebige Mittel konfiguriert sind (wie manuelle Konfiguration oder andere in diesem Dokument nicht spezifizierte automatische Mittel), MUSS der Standardalgorithmus diese Präfixe verwenden (und nicht das Well-Known Prefix verwenden). Wenn kein Präfix verfügbar ist, MUSS der Algorithmus das Well-Known Prefix 64:ff9b::/96, das in [RFC6052] definiert ist, verwenden, um den IPv4-Unicast-Adressbereich darzustellen.

Ein DNS64 MUSS den in Abschnitt 2 von [RFC6052] definierten Algorithmus zur Generierung von IPv6-Darstellungen von IPv4-Adressen unterstützen. Darüber hinaus MUSS der vorgenannte Algorithmus der Standardalgorithmus sein, der vom DNS64 verwendet wird. Während die normative Beschreibung des Algorithmus in [RFC6052] bereitgestellt wird, werden eine beispielhafte Beschreibung des Algorithmus und seine Anwendung auf verschiedene Szenarien in Abschnitt 7 zu Illustrationszwecken bereitgestellt.

5.3. Handling Other Resource Records and the Additional Section (Umgang mit anderen Resource Records und dem Additional Section)​

5.3.1. PTR Resource Record (PTR Resource Record)​

Wenn ein DNS64-Server eine PTR-Abfrage für einen Eintrag in der IP6.ARPA-Domain empfängt, MUSS er die IP6.ARPA-Labels vom QNAME entfernen, den Adressteil des QNAME gemäß dem in Abschnitt 2.5 von [RFC3596] beschriebenen Kodierungsschema umkehren und die resultierende Adresse überprüfen, um festzustellen, ob ihr Präfix mit einem der lokal konfigurierten Pref64::/n oder dem Standard-Well-Known Prefix übereinstimmt. Es gibt zwei Alternativen für einen DNS64-Server, um auf solche PTR-Abfragen zu antworten. Ein DNS64-Server MUSS eine davon bereitstellen und SOLLTE NICHT beide gleichzeitig bereitstellen, es sei denn, verschiedene IP6.ARPA-Zonen erfordern Antworten unterschiedlicher Art:

  1. Die erste Option besteht darin, dass der DNS64-Server autoritativ für seine Präfixe antwortet. Wenn das Adresspräfix mit einem am Standort verwendeten Pref64::/n übereinstimmt, entweder einem NSP oder dem Well-Known Prefix (d.h. 64:ff9b::/96), KANN der DNS64-Server die Abfrage mit lokal geeigneten RDATA beantworten. Der DNS64-Server KANN dieselben RDATA für alle Antworten verwenden. Beachten Sie, dass die Anforderung darin besteht, mit jedem am Standort verwendeten Pref64::/n übereinzustimmen, und nicht nur mit dem lokal konfigurierten Pref64::/n. Dies liegt daran, dass Endclients nach einem PTR-Eintrag fragen könnten, der einer über einen anderen (vom Standort bereitgestellten) DNS64 empfangenen Adresse entspricht, und wenn diese Strategie in Kraft ist, sollten diese Abfragen niemals an das globale DNS gesendet werden. Der Vorteil dieser Strategie besteht darin, dass sie dem abfragenden Client deutlich macht, dass das Präfix von der (DNS64-)Site betrieben wird und dass die Antworten, die der Client erhält, von DNS64 generiert werden. Der Nachteil besteht darin, dass alle nützlichen Reverse-Tree-Informationen, die im globalen DNS vorhanden sein könnten, für die Clients, die den DNS64 abfragen, nicht verfügbar sind.

  2. Die zweite Option besteht darin, dass der DNS64-Nameserver einen CNAME synthetisiert, der den IP6.ARPA-Namespace auf den entsprechenden IN-ADDR.ARPA-Namen abbildet. In diesem Fall SOLLTE der DNS64-Nameserver sicherstellen, dass RDATA am PTR des entsprechenden IN-ADDR.ARPA-Namens vorhanden ist und dass an diesem Namen kein vorhandener CNAME existiert. Dies dient dazu zu vermeiden, dass ein CNAME synthetisiert wird, der eine CNAME-Kette länger macht oder der tatsächlich auf nichts zeigt. Der Rest der Antwort wäre die normale DNS-Verarbeitung. Der CNAME kann bei Bedarf spontan signiert werden. Der Vorteil dieses Ansatzes besteht darin, dass alle nützlichen Informationen im Reverse-Tree für den abfragenden Client verfügbar sind. Die Nachteile bestehen darin, dass dies zusätzliche Last auf den DNS64 hinzufügt (da CNAMEs für jede PTR-Abfrage synthetisiert werden müssen, die mit dem Pref64::/n übereinstimmt), und dass dies möglicherweise spontanes Signieren erfordert.

Wenn das Adresspräfix mit keinem Pref64::/n übereinstimmt, MUSS der DNS64-Server die Abfrage so verarbeiten, als wäre sie eine andere Abfrage; d.h., ein rekursiver Nameserver MUSS versuchen, die Abfrage aufzulösen, als wäre sie eine andere (Nicht-A/AAAA-)Abfrage, und ein autoritativer Server MUSS autoritativ oder mit einer Referral antworten, je nachdem, was angemessen ist.

5.3.2. Handling the Additional Section (Umgang mit dem Additional Section)​

DNS64-Synthese DARF NICHT auf Einträgen im Additional Section synthetisierter Antworten durchgeführt werden. DNS64 MUSS den Additional Section unverändert weitergeben.

HINWEIS: Es mag erscheinen, dass das Hinzufügen synthetischer Einträge zum Additional Section wünschenswert ist, da Clients manchmal die Daten im Additional Section verwenden, um fortzufahren, ohne erneut abfragen zu müssen. Es gibt jedoch im Allgemeinen keine Garantie, dass der Additional Section alle relevanten Einträge enthält, sodass jeder Client, der darauf angewiesen ist, dass der Additional Section seine Bedürfnisse befriedigen kann (d.h. ohne zusätzliche Abfragen), zwangsläufig fehlerhaft ist. Ein reiner IPv6-Client, der einen AAAA-Eintrag benötigt, sendet daher eine Abfrage nach dem erforderlichen AAAA-Eintrag, wenn er einen solchen Eintrag im Additional Section einer von ihm verwendeten Antwort nicht finden kann. Für einen korrekt funktionierenden Client wäre der Effekt nicht anders, wenn der Additional Section leer wäre. Die Alternative, die A-Einträge im Additional Section zu entfernen und sie durch synthetische AAAA-Einträge zu ersetzen, kann dazu führen, dass ein Host hinter einem NAT64 direkt einen Nameserver abfragt, der nicht über das betreffende NAT64 Bescheid weiß. Das Ergebnis wird in diesem Fall sowieso ein Auflösungsfehler sein, aber später im Auflösungsvorgang. Das Verbot synthetischer Daten im Additional Section reduziert, aber eliminiert nicht die Möglichkeit von Auflösungsfehlern aufgrund von gecachten DNS-Daten von hinter dem DNS64. Siehe Abschnitt 6.

5.3.3. Other Resource Records (Andere Resource Records)​

Wenn sich DNS64 im Recursive-Resolver-Modus befindet, können die in [DEFAULT-LOCAL-ZONES] beschriebenen Überlegungen relevant sein.

Alle anderen RRs MÜSSEN unverändert zurückgegeben werden. Dies schließt Antworten auf Abfragen nach A RRs ein.

5.4. Assembling a Synthesized Response to a AAAA Query (Zusammenstellen einer synthetisierten Antwort auf eine AAAA-Abfrage)​

Ein DNS64 verwendet verschiedene Datenstücke, um die Antwort zu erstellen, die an den abfragenden Client zurückgegeben wird.

Die Abfrage, die als Grundlage für die Synthese verwendet wird, führt entweder zu einem Fehler, einer Antwort, die als Grundlage für die Synthese verwendet werden kann, oder einer leeren (autoritativen) Antwort. Wenn es eine leere Antwort gibt, antwortet DNS64 dem ursprünglichen abfragenden Client mit der Antwort, die DNS64 auf die ursprüngliche (Initiator-)Abfrage erhalten hat. Andernfalls wird die Antwort wie folgt zusammengestellt.

Die Header-Felder werden gemäß den üblichen Regeln für rekursive oder autoritative Server gesetzt, abhängig von der Rolle, die DNS64 übernimmt. Der Question-Abschnitt wird aus der ursprünglichen (Initiator-)Abfrage kopiert. Der Answer-Abschnitt wird gemäß den Regeln in Abschnitt 5.1.7 befüllt. Die Authority- und Additional-Abschnitte werden aus der Antwort auf die letzte Abfrage kopiert, die DNS64 durchgeführt hat, und als Grundlage für die Synthese verwendet.

Die endgültige Antwort von DNS64 unterliegt allen Standard-DNS-Regeln, einschließlich Truncation [RFC1035] und EDNS0-Behandlung [RFC2671].

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.

  1. 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.