3. ホスト名解決クエリ処理 (Hostname Resolution Query Handling)

クライアントがIPv4とIPv6の両方の接続性を持ち、名前付きホストとの接続を確立しようとする場合、AAAAとA DNSクエリの両方を送信する必要があります。両方のクエリは可能な限り連続して行うべきです (SHOULD)。AAAAクエリを最初に実行し、その直後にAクエリを実行します。

実装は、接続確立を試みる前に両方のアドレスファミリーの応答が返されるのを待つべきではありません (SHOULD NOT)。一方のクエリが返されなかったり、返されるまでに著しく長い時間がかかったりする場合、2番目のアドレスファミリーを待つことで、最初のアドレスファミリーの接続確立が大幅に遅延する可能性があります。したがって、クライアントはDNS解決を非同期として扱うべきです (SHOULD)。プラットフォームが非同期DNS APIを提供していない場合、この動作は、異なるスレッドで2つの別々の同期クエリを実行することでシミュレートできることに注意してください。1つのアドレスファミリーにつき1つのスレッドです。

アルゴリズムは次のように進行します: 最初に肯定的なAAAA応答 (少なくとも1つの有効なAAAAレコードを含む応答) を受信した場合、最初のIPv6接続試行が即座に開始されます。再順序付けにより最初に肯定的なA応答を受信した場合、クライアントはIPv6に優先権を与えるために、AAAA応答を待つ短い時間待機すべきです (SHOULD) (AAAA応答がA応答の数ミリ秒後に続くことは一般的です)。この遅延は "Resolution Delay" (解決遅延) と呼ばれます。解決遅延の推奨値は50ミリ秒です。解決遅延期間内に肯定的なAAAA応答を受信した場合、クライアントは即座にIPv6接続試行を開始します。解決遅延期間内に否定的なAAAA応答 (エラーなし、データなし) を受信した場合、または解決遅延期間の終了までにAAAA応答が受信されなかった場合、クライアントは、これまでに返されたIPv4アドレスを使用してアドレスの並べ替え (セクション4を参照) と段階的接続試行 (セクション5を参照) に進むべきです (SHOULD)。AAAA応答がこれらの接続試行が進行中であるが、まだ接続が確立されていない間に到着した場合、新しく受信したIPv6アドレスは利用可能な候補アドレスのリストに組み込まれ (セクション6を参照)、接続試行のプロセスはIPv6アドレスを追加して続行され、1つの接続が確立されるまで続きます。

3.1. 複数のDNSサーバーアドレスの処理 (Handling Multiple DNS Server Addresses)

現在のネットワークに複数のDNSサーバーアドレスが設定されている場合、クライアントはIPv4またはIPv6を介してDNSクエリを送信するオプションを持つ場合があります。Happy Eyeballsアプローチに従って、クエリは最初にIPv6を介して送信されるべきです (SHOULD) (これは、AAAAまたはAクエリの送信を指すのではなく、DNSサーバー自体のアドレスとDNSメッセージの転送に使用されるIPバージョンを指すことに注意してください)。IPv6アドレスに送信されたDNSクエリが応答を受信しない場合、そのアドレスはペナルティが課されたものとしてマークされ、クエリは他のDNSサーバーアドレスに送信できます。

ネイティブIPv6デプロイメントがより普及し、IPv4アドレスが枯渇するにつれて、IPv6接続性がネットワーク内で優先的に扱われることが期待されます。DNSサーバーがIPv6を介してアクセス可能に設定されている場合、IPv6が優先アドレスファミリーであると仮定する必要があります。

クライアントシステムは、手動またはネットワークによって設定できるDNSサーバーの数に明示的な制限を設けるべきではありません (SHOULD NOT)。ハードウェアの制限によってそのような制限が必要な場合、クライアントは利用可能なリストから各アドレスファミリーから少なくとも1つのアドレスを使用すべきです (SHOULD)。