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

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情報が権威サーバーの場合のようにローカルで利用可能な場合, 問題はもはや関連しません。)

に最終更新