Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist

実際のAAAAリソースレコードが存在する場合にAAAAレコードRRsを合成する動機は, 以下のシナリオをサポートすることです:

IPv4のみのサーバーアプリケーション (例: Webサーバーソフトウェア) がデュアルスタックホストで実行されています。同じホストでデュアルスタックサーバーアプリケーションも実行されている可能性があります。そのホストには完全にルーティング可能なIPv4およびIPv6アドレスがあり, したがって権威DNSサーバーにはAレコードとAAAAレコードがあります。
IPv6のみのクライアント (クライアントアプリケーションがIPv6のみであるか, クライアントスタックがIPv6のみであるか, IPv6アドレスのみを持っているかに関係なく) が上記のサーバーにアクセスしたいと考えています。
クライアントはDNS64リゾルバにDNSクエリを発行します。

DNS64が実際のAAAAがない場合にのみ合成AAAAを生成する場合, 通信は失敗します。実際のAAAAがあっても, 通信が成功する唯一の方法は変換されたアドレスを使用することです。したがって, このシナリオをサポートするために, DNS64サービスの管理者は, 実際のAAAAレコードRRsが存在する場合でもAAAAレコードRRsの合成を有効にしたい場合があります。

実際のAAAAレコードRRsが存在する場合に合成AAAAレコードRRsを含めることの意味は, DNS64がDNSサーバーモードで運用されている一部のケースで, ネイティブ接続よりも変換された接続が優先される可能性があることです。

RFC 3484 [RFC3484]ルールは, 優先する宛先アドレスを選択するために"最長一致プレフィックス"を使用します。したがって, DNS64リゾルバが合成AAAAレコードRRsと実際のAAAAレコードRRsの両方を返す場合, DNS64が開始ホストと同じドメインによって運用されており, グローバルユニキャストプレフィックス ([RFC6052]でNetwork-Specific Prefix (NSP)と呼ばれる) が使用されている場合, 合成AAAAレコードRRが優先される可能性が高いです。

これは, さらなる設定なしでは次のことを意味します:

"an IPv6 network to the IPv4 Internet"シナリオでは, NSPが使用されている場合, ホストは変換された接続を優先します。[RFC6052]で定義されたWell-Known Prefixが使用されている場合, おそらくネイティブ接続を優先します。
"IPv6 Internet to an IPv4 network"シナリオでは, NSPが使用されている場合 (このケースではWell-Known Prefixの使用はサポートされていません), DNS64リゾルバがDNS応答で最初に実際のAAAAを返す場合, 選択を実際のAAAAレコードRRに向けてバイアスをかけることが可能です。
"an IPv6 network to an IPv4 network"シナリオでは, ローカル宛先 (つまり, ローカルサイト内のターゲットホスト) の場合, NSPと宛先プレフィックスが同じである可能性が高いため, DNS応答内のRRの順序を使用してネイティブ接続を通じて選択にバイアスをかけることができます。Well-Known Prefixが使用されている場合, "最長一致プレフィックス"ルールはネイティブ接続を選択します。

問題は, RFC 3484 [RFC3484]ポリシーテーブルを適切に設定することで解決できます。