3. Background to DNS64-DNSSEC Interaction (Hintergrund zur DNS64-DNSSEC-Interaktion)

3. Background to DNS64-DNSSEC Interaction (Hintergrund zur DNS64-DNSSEC-Interaktion)

DNSSEC ([RFC4033], [RFC4034], [RFC4035]) stellt eine besondere Herausforderung für DNS64 dar, da DNSSEC darauf ausgelegt ist, Änderungen an DNS-Antworten zu erkennen, und DNS64 Antworten von einem autoritativen Server ändern kann.

Ein rekursiver Resolver kann sicherheitsbewusst (security-aware) oder sicherheitsoblivious (security-oblivious) sein. Darüber hinaus kann ein sicherheitsbewusster rekursiver Resolver je nach Operator-Policy validierend oder nicht-validierend sein. In den folgenden Fällen führt der rekursive Resolver auch DNS64 aus und hat eine lokale Policy zur Validierung. Wir nennen diesen allgemeinen Fall vDNS64, aber in allen folgenden Fällen sollte angenommen werden, dass die DNS64-Funktionalität benötigt wird.

DNSSEC enthält einige Signalisierungsbits, die einige Indikatoren dafür bieten, was der Abfrageinitiator versteht.

Wenn eine Abfrage bei einem vDNS64-Gerät mit gesetztem "DNSSEC OK" (DO)-Bit ankommt, signalisiert der Abfrageinitiator, dass er DNSSEC versteht. Das DO-Bit zeigt nicht an, dass der Abfrageinitiator die Antwort validieren wird. Es bedeutet nur, dass der Abfrageinitiator Antworten verstehen kann, die DNSSEC-Daten enthalten. Umgekehrt ist es ein Beweis dafür, dass der abfragende Agent nicht über DNSSEC Bescheid weiß, wenn das DO-Bit nicht gesetzt ist.

Wenn eine Abfrage bei einem vDNS64-Gerät mit gesetztem "Checking Disabled" (CD)-Bit ankommt, ist dies ein Hinweis darauf, dass der abfragende Agent alle Validierungsdaten haben möchte, damit er die Überprüfung selbst durchführen kann. Durch lokale Policy könnte vDNS64 dennoch validieren, muss aber alle Daten trotzdem an den abfragenden Agenten zurückgeben.

Hier sind die möglichen Fälle:

1. Ein DNS64 (DNSSEC-aware oder DNSSEC-oblivious) empfängt eine Abfrage mit nicht gesetztem DO-Bit. In diesem Fall ist DNSSEC kein Problem, da der abfragende Agent keine DNSSEC-Antworten versteht. DNS64 kann die Validierung der Antwort durchführen, wenn es durch seine lokale Policy vorgegeben ist.

2. Ein security-oblivious DNS64 empfängt eine Abfrage mit gesetztem DO-Bit und gelöschtem oder gesetztem CD-Bit. Dies ist genau wie im Fall eines Nicht-DNS64-Falls: Der Server unterstützt es nicht, also hat der abfragende Agent Pech.

3. Ein sicherheitsbewusster und nicht-validierender DNS64 empfängt eine Abfrage mit gesetztem DO-Bit und gelöschtem CD-Bit. Ein solcher Resolver validiert keine Antworten, wahrscheinlich aufgrund lokaler Policy (siehe [RFC4035], Abschnitt 4.2). Aus diesem Grund entspricht dieser Fall dem vorherigen Fall, und es findet keine Validierung statt.

4. Ein sicherheitsbewusster und nicht-validierender DNS64 empfängt eine Abfrage mit gesetztem DO-Bit und gesetztem CD-Bit. In diesem Fall soll DNS64 alle Daten, die es erhält, an den Abfrageinitiator weitergeben (siehe Abschnitt 3.2.2 von [RFC4035]). Dieser Fall funktioniert nicht mit DNS64, es sei denn, der validierende Resolver ist bereit, DNS64 selbst durchzuführen. Wenn DNS64 den Eintrag ändert, erhält der Client die Daten zurück und versucht sie zu validieren, und die Daten werden aus Sicht des Clients ungültig sein.

5. Ein sicherheitsbewusster und validierender DNS64-Resolver empfängt eine Abfrage mit gelöschtem DO-Bit und gelöschtem CD-Bit. In diesem Fall validiert der Resolver die Daten. Wenn dies fehlschlägt, gibt er RCODE 2 (Server failure) zurück; andernfalls gibt er die Antwort zurück. Dies ist der ideale Fall für vDNS64. Der Resolver validiert die Daten und synthetisiert dann den neuen Eintrag und gibt diesen an den Client weiter. Der Client, der vermutlich nicht validiert (sonst hätte er DO und CD gesetzt), kann nicht erkennen, dass DNS64 beteiligt ist.

6. Ein sicherheitsbewusster und validierender DNS64-Resolver empfängt eine Abfrage mit gesetztem DO-Bit und gelöschtem CD-Bit. Dies funktioniert wie im vorherigen Fall, außer dass der Resolver auch das "Authentic Data" (AD)-Bit in der Antwort setzen sollte.

7. Ein sicherheitsbewusster und validierender DNS64-Resolver empfängt eine Abfrage mit gesetztem DO-Bit und gesetztem CD-Bit. Dies ist effektiv derselbe Fall wie der, in dem ein sicherheitsbewusster und nicht-validierender rekursiver Resolver eine ähnliche Abfrage empfängt, und dasselbe wird passieren: Der Downstream-Validator wird die Daten als ungültig markieren, wenn DNS64 eine Synthese durchgeführt hat. Der Knoten muss DNS64 selbst durchführen, sonst schlägt die Kommunikation fehl.