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

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のクエリへの応答が含まれます。

に最終更新