リゾルバーは、DNS の拡張機能 (EDNS0) 標準を使用すると、UDP プロトコルを使用してより効率的にリソース情報を取得することができます。これらの標準が存在する前は、ネーム・サーバーからの UDP 応答は 512 バイトに制限されていました。DNS 応答メッセージに多くのリソース・レコードが表示される場合、リゾルバーにすべての応答データを戻すためには 512 バイトを超えるバイト数が必要になる可能性があります。IPv6 リソース・レコードは IPv4 リソース・レコードより大きくなります。このため、IPV6 リソース・レコードの場合、IPv4 より少ないレコード数で 512 バイト制限に達してしまいますが、IPv4 リソース・レコードだけでも制限に達する場合があります。応答メッセージを提供しているネーム・サーバーも EDNS0 をサポートしている場合、EDNS0 は、リゾルバーが UDP プロトコルを使用して 512 バイトを超える DNS メッセージを受信することを許可します。
EDNS0 標準用のサポートを構成する必要はありません。リゾルバーが、ネーム・サーバーの EDNS0 機能を判別できていない場合、リゾルバーはそのネーム・サーバーに EDNS0 を使用しません。また、ネーム・サーバーに送信する照会で、EDNS0 処理をサポートすることを示しません。リゾルバーは、ネーム・サーバーが EDNS0 処理をサポートしていることを動的に判別してから、ネーム・サーバーに送信される DNS 要求を変更して、EDNS0 を使用します。
リゾルバーは、初めてネーム・サーバーから切り捨てられた UDP 応答を受信したときに、ネーム・サーバーの EDNS0 機能の判別を動的に試みます。リゾルバーは、同じ照会をネーム・サーバーに送信し、EDNS0 処理をサポートしていることを示します (EDNS0 プローブと呼ばれます)。リゾルバーは、以下の想定される EDNS0 プローブの結果に基づいて、ネーム・サーバーが EDNS0 をサポートするかどうかを判別します。
リゾルバーは、タイムアウトが発生した原因を判別できないため、最小の 5 分のインターバルの間、そのネーム・サーバーに EDNS0 を使用しません。そのインターバルの終了時、必要に応じて、リゾルバーは、再度 EDNS0 プローブ照会を送信して、そのネーム・サーバーが EDNS0 をサポートしているかどうかを判別します。EDNS0 パフォーマンスの利点を最大限に得るには、大きな UDP パケットが到達するのに十分なだけの、リゾルバーのタイムアウト値を選択する必要があります。
リゾルバーは、EDNS0 プローブへの応答で、ネーム・サーバーが EDNS0 をサポートしていないことが明示的に示されていても、そのネーム・サーバーが EDNS0 をサポートしていないことを定期的に確認します。 定期的な EDNS0 プローブ処理によって、リゾルバーはそのネーム・サーバーの機能が変更されていても、その変更を動的にディスカバリーすることができます (ただし、この再ディスカバリーには若干の時間がかかる場合があります)。 MODIFY RESOLVER,REFRESH コマンドを使用すると、リゾルバーはネーム・サーバーの機能をより素早く再ディスカバーできます。MODIFY RESOLVER,REFRESH コマンドについて詳しくは、「z/OS Communications Server: IP システム管理者のコマンド」を参照してください。
ネーム・サーバーで EDNS0 がサポートされているかどうかを確認するには、+bufsize= オプションを指定した dig コマンドを使用して、dig に、要求で OPT RR レコードを送信させます。ネーム・サーバーで EDNS0 がサポートされている場合、ネーム・サーバーは独自の OPT RR レコードが指定された応答を戻します。
EDNS0 をサポートするようにネーム・サーバーをアップグレードした場合は、MODIFY RESOLVER,REFRESH コマンドを発行して、強制的に、リゾルバーにネーム・サーバーの機能を動的に判別させることができます。そして、リゾルバーは EDNS0 サポートを使用して、512 バイトを超える DNS メッセージを受信することができます。その際、リソースの使用量が少ない UDP プロトコルが使用されるため、DNS およびリゾルバーのパフォーマンスが改善されます。