5.5. DNSSEC Processing DNS64 in Validating Resolver Mode (DNSSEC処理: 検証リゾルバモードのDNS64)

DNS64を実行している再帰リゾルバが, [RFC4035]のセクション5で概説されている手順に従って応答を検証するローカルポリシーも持っている場合を考えます。この一般的なケースをvDNS64と呼びます。

vDNS64は, DOおよびCDビットの存在を使用して, クエリの発信者が必要とするものについていくつかの決定を行い, それに応じて反応できます:

CDが設定されておらず, DOが設定されていない場合, vDNS64は検証を実行し, 必要に応じて合成を行うべきです (SHOULD)。検証と合成の実行方法に関するルールについては, 次の項目を参照してください。ただしこの場合, vDNS64は任意の応答にADビットを設定してはなりません (MUST NOT)。
CDが設定されておらず, DOが設定されている場合, vDNS64は検証を実行すべきです (SHOULD)。vDNS64が検証を実行する場合は常に, インターネット上に正当なAAAAレコードがないことを確認するために, 同じ名前のAレコードをクエリする前に, AAAAクエリのネガティブ応答を検証しなければなりません (MUST)。このステップを遵守しないと, 攻撃者がDNSSECを回避するメカニズムとしてDNS64を使用できるようになります。ネガティブ応答が検証され, Aクエリへの応答が検証された場合, vDNS64は合成を実行してもよく (MAY), クライアントへの応答にADビットを設定すべきです (SHOULD)。これは許容されます。なぜなら[RFC4035]のセクション3.2.3は, セキュリティ認識型の再帰ネームサーバーのネームサーバー側が, 応答および権限セクション内のすべてのRRSetsが本物であると見なす場合にのみADビットを設定すると述べているためです。この場合, ネームサーバーはすべてのRRSetsが本物であると信じる理由があるため, ADビットを設定すべきです (SHOULD)。データが検証されない場合, vDNS64はRCODE=2 (Server failure)で応答しなければなりません (MUST)。

セキュリティ認識型のエンドポイントは, ADビットの存在をデータが有効であることの指標として取り, DNSおよびDNSSECデータをアプリケーションに渡す可能性があります。アプリケーションが合成されたデータを検証しようとすると, もちろん検証は失敗します。したがって, このアプローチは望ましくないと主張することもできますが, セキュリティ認識型のスタブリゾルバは, [RFC4035]のセクション4.9.3で確立された特定の基準なしに, リゾルバから受信し, 彼らに代わって検証されたデータに依存してはなりません。自分自身で検証を実行したいアプリケーションは, CDビットを使用すべきです。

CDビットが設定され, DOが設定されている場合, vDNS64は検証を実行してもよい (MAY) ですが, 合成を実行してはなりません (MUST NOT)。通常の再帰リゾルバと同様にクエリイニシエータにデータを返し, クライアントが検証と合成自体を実行することに依存しなければなりません (MUST)。

このアプローチの欠点は, 変換に無知だがセキュリティ認識型で検証するエンドポイントがDNS64機能を使用できないことです。この場合, エンドポイントはNAT64の望ましい利益を得られません。事実上, この戦略は, NAT64コンテキストで検証を実行したい任意のエンドポイントも変換認識にアップグレードされなければならないことを意味します。