5.3. Handling Other Resource Records and the Additional Section

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:

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