メインコンテンツまでスキップ

5. DNS64 Normative Specification (DNS64規範的仕様)

DNS64は, AレコードからAAAAレコードを合成する論理機能です。DNS64機能は, スタブリゾルバ, 再帰リゾルバ, または権威ネームサーバーに実装できます。これらのDNS機能内で動作し, ネットワーク上では[RFC1034]と[RFC1035]に準拠した"プレーン"なDNSリゾルバまたはネームサーバーとして表示されます。

実装は, 別々のIPv4アドレス範囲を別々のIPv6プレフィックスにマッピングして, AAAAレコード合成をサポートすべきです (SHOULD)。これにより, 特別な用途のIPv4アドレス[RFC5735]の処理が可能になります。

DNSメッセージにはいくつかのセクションが含まれています。DNS64によって変更されるDNSメッセージの部分は応答セクションであり, これは以下のセクション5.1で議論されます。結果として得られる合成応答は他のセクションと組み合わされ, それがDNSクエリへの応答として実際に返されるメッセージを作成します。その応答の組み立ては, 以下のセクション5.4で扱われます。

DNS64は, AAAAレコードRRsの合成に使用するIPv6プレフィックスのいずれかを含むアドレスに関するPTRクエリにも応答します。

5.1. Resolving AAAA Queries and the Answer Section (AAAAクエリの解決と応答セクション)​

DNS64がタイプAAAAおよびクラスINのRRsのクエリを受信すると, まずこのタイプとクラスの非合成RRsを取得しようとします。クエリを実行するか, 権威サーバーの場合は自身の結果を調べることによって行います。クエリは, 利用可能な場合, ローカルキャッシュから応答される場合があります。IN以外のクラスのDNS64操作は未定義であり, DNS64はDNS64機能が設定されていないかのように動作しなければなりません (MUST)。

5.1.1. The Answer when There is AAAA Data Available (AAAAデータが利用可能な場合の応答)​

クエリの結果, 応答セクションに1つ以上のAAAAレコードが含まれる場合, 結果は通常のDNSセマンティクスに従って要求元クライアントに返されます。ただし, セクション5.1.4で検討されているように, AAAAレコードのいずれかが特別な除外セットのプレフィックスと一致する場合を除きます。(除外されていない)AAAAデータが利用可能な場合, DNS64は応答に合成AAAAレコードRRsを含めるべきではありません (SHOULD NOT) (この推奨に従わないことの動機と影響の分析については付録Aを参照してください)。デフォルトで, DNS64実装は実際のAAAAレコードRRsが存在する場合, AAAAレコードRRsを合成してはなりません (MUST NOT)。

5.1.2. The Answer when There is an Error (エラーがある場合の応答)​

クエリの結果, 0 (エラー条件なし) 以外のRCODEの応答が得られた場合, 2つの可能性があります。RCODE=3 (Name Error) の結果は, 通常のDNS操作に従って処理されます (通常は, クライアントにエラーを返します)。この段階はまだ合成が発生する前なので, クライアントに返される応答は, DNS操作で通常発生する以外の特別な組み立てを必要としません。

他のRCODEは, RCODEが0であり (セクション5.1.6および5.1.7を参照), 応答セクションが空であるかのように扱われます。これは, AAAAクエリを受信したときにAAAAレコードが利用できない場合, 展開されたネームサーバーからのさまざまな応答が多数あるためです ([RFC4074]を参照)。これは, 実際上, DNSのいくつかの異なるクラスのエラーがすべて, そのオーナー名にAAAAレコードが利用できないかのように扱われることを意味します。

この文書の執筆時点では, 一部のサーバーは, そのオーナー名にAレコードが利用可能であっても, AAAAクエリに対してRCODE=3で応答します。これらのサーバーはRCODE 3の意味に明確に違反しており, IPv6展開が増加するにつれて使用が減少することが期待されます。

5.1.3. Dealing with Timeouts (タイムアウトの処理)​

クエリがタイムアウト前に応答を受信しない場合 (DNS64が再帰リゾルバモードであるかどうかに応じて, すべての権威サーバーからのタイムアウトの場合があります), RCODE=2 (Server failure) として扱われます。

5.1.4. Special Exclusion Set for AAAA Records (AAAAレコードの特別な除外セット)​

一部のIPv6アドレスは, IPv6のみのホストによって実際には使用できません。したがって, それらがAAAAレコードとしてIPv6のみのクエリエージェントに返される場合, 障害モードの数を減らすという目標は達成されません。例には, ::ffff:0:0/96ネットワーク内のアドレスを持つAAAAレコード, および (コンテキストに応じて) サイトのPref64::/nまたはWell-Known Prefixを持つAAAAレコードが含まれます (Well-Known Prefixの詳細については以下を参照してください)。DNS64実装は, それらを含むAAAAを空の応答であるかのように扱うIPv6プレフィックス範囲を指定するメカニズムを提供すべきです (SHOULD)。実装は, デフォルトでそのレンジに::ffff/96ネットワークを含めるべきです (SHOULD)。この機能を提供しないと, DNS64機能を照会するクライアントがデュアルスタックホストから到達可能なホストと通信できない可能性があります。

DNS64が初期AAAAクエリを実行するとき, 除外範囲内のアドレスのみを含むAAAAレコードを持つ応答を受信した場合, その応答を空の応答であるかのように扱い, それに応じて進めなければなりません (MUST)。除外範囲外のアドレスを含む少なくとも1つのAAAAレコードを持つ応答を受信した場合, デフォルトで, 除外範囲内のアドレスを含まないAAAAレコードのみを含む応答セクションを構築すべきです (SHOULD)。その応答セクションは, セクション5.4で詳述されているように応答の組み立てに使用されます。あるいは, 空の応答であるかのように応答を扱い, それに応じて進めてもよい (MAY)。応答の一部として問題のあるAAAAレコードを返してはなりません (MUST NOT)。

5.1.5. Dealing with CNAME and DNAME (CNAMEとDNAMEの処理)​

応答にCNAMEまたはDNAMEが含まれる場合, 最初の終端AまたはAAAAレコードに到達するまで, CNAMEまたはDNAMEチェーンがたどられます。これには, 元のAAAAクエリへの応答がAAAAレコードなしのCNAMEまたはDNAMEである場合, DNS64がAレコードを要求する必要がある場合があります。結果として得られるAAAAまたはAレコードは, 適切に他のAAAAまたはAケースのように扱われます。

応答セクションを組み立てるとき, CNAMEまたはDNAME RRsのチェーンは, (適切な場合) 合成AAAAと共に応答の一部として含まれます。

5.1.6. Data for the Answer when Performing Synthesis (合成を実行する際の応答のためのデータ)​

クエリの結果がエラーなしで応答セクションが空の場合, DNS64は問題の名前のAレコードを取得しようとします。別のクエリを実行するか, 権威サーバーの場合は自身の結果を調べることによって行います。この新しいAレコードRRクエリの結果が空の応答またはエラーになった場合, 空の結果またはエラーがクエリクライアントに返される応答の基礎として使用されます。代わりにクエリの結果が1つ以上のAレコードRRsになった場合, DNS64はセクション5.1.7で概説されている手順に従って, AレコードRRsに基づいてAAAAレコードRRsを合成します。DNS64は合成の基礎を形成するAレコードを削除し, 応答セクションに合成AAAAレコードを返します。

5.1.7. Performing the Synthesis (合成の実行)​

合成AAAAレコードは, 次のようにAレコードから作成されます:

  • NAMEフィールドは, AレコードのNAMEフィールドに設定されます。

  • TYPEフィールドは28 (AAAA)に設定されます。

  • CLASSフィールドは元のCLASSフィールド, 1に設定されます。本仕様では, 1以外のCLASSに対するDNS64は未定義です。

  • Time to Live (TTL)フィールドは, 元のAレコードRRのTTLとクエリされたドメインのSOAレコードRRのTTLの最小値に設定されます。(SOAレコードRRのTTLを取得するために, DNS64は新しいクエリを実行する必要はありませんが, AAAAクエリへのネガティブ応答のSOAレコードRRからTTLを記憶できます。SOAレコードRRがAAAAクエリへのネガティブ応答と共に配信されなかった場合, DNS64は元のAレコードRRのTTLまたは600秒のいずれか短い方を使用すべきです (SHOULD)。代わりにSOAレコードRRを明示的にクエリし, そのクエリの結果を使用することも可能ですが, これは追加の利益がほとんどないままクエリ負荷と解決時間を増加させます。) これはネガティブキャッシング[RFC2308]で使用されるアプローチと一致しています。

  • RDLENGTHフィールドは16に設定されます。

  • RDATAフィールドは, AレコードのRDATAフィールドのIPv4アドレスのIPv6表現に設定されます。DNS64は, 設定されたIPv4アドレス範囲に対して各AレコードRRをチェックし, AAAAレコードRRの合成に使用する対応するIPv6プレフィックスを選択しなければなりません (MUST)。変換を実行する際に使用されるアルゴリズムの議論については, セクション5.2を参照してください。

5.1.8. Querying in Parallel (並列でのクエリ)​

DNS64は, 遅延を最小限に抑えるために, AAAAレコードRRとAレコードRRのクエリを並列で実行してもよい (MAY)。

注: 並列でクエリを実行すると, AAAAレコードRR合成が必要ない場合に不要なAレコードRRクエリを実行することになります。可能なトレードオフは, それらを順次実行することですが, 間隔を非常に短くすることです。したがって, 高速な応答を取得した場合, 追加のクエリを実行することを回避できます。(この議論は, DNS64機能がRRをフェッチするために外部クエリを実行する必要がある場合にのみ関連します。必要なRR情報が権威サーバーの場合のようにローカルで利用可能な場合, 問題はもはや関連しません。)

5.2. Generation of the IPv6 Representations of IPv4 Addresses (IPv4アドレスのIPv6表現の生成)​

DNS64は, IPv4アドレスのIPv6表現の生成のための複数のアルゴリズムをサポートします。生成アルゴリズムに課される制約は次のとおりです:

  • IPv4アドレスからIPv6アドレスを作成する同じアルゴリズムが, DNS64によって, 元のAレコードRRに含まれるIPv4アドレスから合成AAAAレコードRRで返されるIPv6アドレスを作成するために, およびIPv6/IPv4トランスレータによって, 受信IPv4パケットのソースアドレスフィールドに含まれるIPv4アドレスから送信IPv6パケットのソースアドレスフィールドに含まれるIPv6アドレスを作成するために, 両方で使用されなければなりません (MUST)。

  • アルゴリズムは可逆でなければなりません (MUST)。つまり, IPv6表現から元のIPv4アドレスを導出できなければなりません。

  • アルゴリズムの入力は, IPv4アドレス, IPv6表現で使用されるIPv6プレフィックス (Pref64::/nと表記), およびオプションで, DNS64とNAT64で設定される安定したパラメータのセット (サフィックスとして使用される固定文字列など) に制限されなければなりません (MUST)。

    • 各プレフィックスPref64::/nについて, nは96以下でなければなりません (MUST)。1つ以上のPref64::/nが任意の手段 (手動設定, またはこの文書で指定されていない他の自動手段など) を通じてDNS64で設定されている場合, デフォルトアルゴリズムはこれらのプレフィックスを使用しなければならず (MUST) (Well-Known Prefixを使用してはなりません), プレフィックスが利用できない場合, アルゴリズムは[RFC6052]で定義されたWell-Known Prefix 64:ff9b::/96を使用して, IPv4ユニキャストアドレス範囲を表さなければなりません (MUST)。

DNS64は, [RFC6052]のセクション2で定義されたIPv4アドレスのIPv6表現を生成するアルゴリズムをサポートしなければなりません (MUST)。さらに, 前述のアルゴリズムは, DNS64で使用されるデフォルトアルゴリズムでなければなりません (MUST)。アルゴリズムの規範的な記述は[RFC6052]で提供されていますが, アルゴリズムのサンプル記述とさまざまなシナリオへの適用は, 説明の目的でセクション7で提供されています。

5.3. Handling Other Resource Records and the Additional Section (その他のリソースレコードと追加セクションの処理)​

5.3.1. PTR Resource Record (PTRリソースレコード)​

DNS64サーバーがIP6.ARPAドメイン内のレコードのPTRクエリを受信した場合, QNAMEからIP6.ARPAラベルを削除し, [RFC3596]のセクション2.5で概説されたエンコーディングスキームに従ってQNAMEのアドレス部分を逆にし, 結果として得られるアドレスを調べて, そのプレフィックスがローカルに設定されたPref64::/nまたはデフォルトのWell-Known Prefixのいずれかと一致するかどうかを確認しなければなりません (MUST)。DNS64サーバーがそのようなPTRクエリに応答するための2つの代替手段があります。DNS64サーバーはこれらのうちの1つを提供しなければならず (MUST), 異なるIP6.ARPAゾーンが異なる種類の応答を必要とする場合を除き, 両方を同時に提供すべきではありません (SHOULD NOT):

  1. 最初のオプションは, DNS64サーバーがそのプレフィックスに対して権威的に応答することです。アドレスプレフィックスがサイトで使用されている任意のPref64::/n, NSPまたはWell-Known Prefix (つまり, 64:ff9b::/96) と一致する場合, DNS64サーバーはローカルに適切なRDATAを使用してクエリに応答してもよい (MAY)。DNS64サーバーはすべての応答に対して同じRDATAを使用してもよい (MAY)。要件は, サイトで使用されている任意のPref64::/nと一致することであり, ローカルに設定されたPref64::/nだけではないことに注意してください。これは, エンドクライアントが異なる (サイト提供の) DNS64を通じて受信したアドレスと一致するPTRレコードを要求する可能性があり, この戦略が有効な場合, それらのクエリがグローバルDNSに送信されるべきではないためです。この戦略の利点は, プレフィックスが (DNS64) サイトによって運営されていること, およびクライアントが取得している応答がDNS64によって生成されていることを, クエリを行うクライアントに明確にすることです。欠点は, グローバルDNSにある可能性のある有用な逆ツリー情報が, DNS64を照会するクライアントには利用できないことです。

  2. 2番目のオプションは, DNS64ネームサーバーがIP6.ARPA名前空間を対応するIN-ADDR.ARPA名にマッピングするCNAMEを合成することです。この場合, DNS64ネームサーバーは, 対応するIN-ADDR.ARPAのPTRにRDATAがあること, およびその名前に既存のCNAMEがないことを確認すべきです (SHOULD)。これは, CNAMEチェーンを長くするCNAMEを合成すること, または実際には何も指していないCNAMEを合成することを避けるためです。応答の残りは通常のDNS処理になります。CNAMEは必要に応じてオンザフライで署名できます。このアプローチの利点は, 逆ツリー内の有用な情報がクエリを行うクライアントに利用可能であることです。欠点は, DNS64に追加の負荷がかかること (Pref64::/nと一致する各PTRクエリに対してCNAMEを合成する必要があるため), およびオンザフライでの署名が必要になる可能性があることです。

アドレスプレフィックスが任意のPref64::/nと一致しない場合, DNS64サーバーは他のクエリであるかのようにクエリを処理しなければなりません (MUST)。つまり, 再帰ネームサーバーは他の (非A/AAAA) クエリであるかのようにクエリを解決しようと試みなければならず (MUST), 権威サーバーは適切に権威的にまたはリファラルで応答しなければなりません (MUST)。

5.3.2. Handling the Additional Section (追加セクションの処理)​

DNS64合成は, 合成された応答の追加セクション内の任意のレコードに対して実行してはなりません (MUST NOT)。DNS64は追加セクションを変更せずに渡さなければなりません (MUST)。

注: 追加セクションに合成レコードを追加することは望ましいように見えるかもしれません。なぜなら, クライアントは時々追加セクションのデータを使用して再クエリを必要とせずに進めるからです。しかし一般に, 追加セクションにすべての関連レコードが含まれるという約束はありません。したがって, 追加セクションがそのニーズを満たすことができること (つまり, 追加のクエリなし) に依存する任意のクライアントは必然的に壊れています。AAAAレコードが必要なIPv6のみのクライアントは, したがって, 消費している応答の追加セクションでそのようなレコードを見つけられない場合, 必要なAAAAレコードのクエリを送信します。正しく機能するクライアントにとって, 追加セクションが空であっても効果は異なりません。追加セクション内のAレコードを削除して合成AAAAレコードに置き換える代替案は, NAT64の背後にあるホストが問題のNAT64を認識していないネームサーバーに直接クエリを実行させる可能性があります。この場合の結果はとにかく解決失敗になりますが, 解決操作の後半になります。追加セクション内の合成データの禁止は, DNS64の背後からキャッシュされたDNSデータによる解決失敗の可能性を減らしますが, 排除しません。セクション6を参照してください。

5.3.3. Other Resource Records (その他のリソースレコード)​

DNS64が再帰リゾルバモードの場合, [DEFAULT-LOCAL-ZONES]で概説されている考慮事項が関連する場合があります。

他のすべてのRRsは変更されずに返されなければなりません (MUST)。これには, AレコードRRsのクエリへの応答が含まれます。

5.4. Assembling a Synthesized Response to a AAAA Query (AAAAクエリに対する合成応答の組み立て)​

DNS64は, クエリを行うクライアントに返される応答を構築するために, さまざまなデータの断片を使用します。

合成の基礎として使用されるクエリは, エラー, 合成の基礎として使用できる応答, または空の (権威的な) 応答のいずれかになります。空の応答がある場合, DNS64は元の (イニシエータの) クエリに対してDNS64が受信した応答で元のクエリクライアントに応答します。それ以外の場合, 応答は次のように組み立てられます。

ヘッダフィールドは, DNS64が提供している役割に応じて, 再帰または権威サーバーの通常のルールに従って設定されます。質問セクションは元の (イニシエータの) クエリからコピーされます。応答セクションは, セクション5.1.7のルールに従って設定されます。権限および追加セクションは, DNS64が実行した最終クエリへの応答からコピーされ, 合成の基礎として使用されます。

DNS64からの最終応答は, 切り詰め[RFC1035]およびEDNS0処理[RFC2671]を含む, すべての標準DNSルールの対象となります。

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

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

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

  1. CDが設定されておらず, DOが設定されていない場合, vDNS64は検証を実行し, 必要に応じて合成を行うべきです (SHOULD)。検証と合成の実行方法に関するルールについては, 次の項目を参照してください。ただしこの場合, vDNS64は任意の応答にADビットを設定してはなりません (MUST NOT)。

  2. 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ビットを使用すべきです。

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

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