5.1. Resolving AAAA Queries and the Answer Section

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