4. リクエスタの動作

4. リクエスタの動作

このセクションでは、リクエスタ、つまりUPDATEリクエストを行うエージェントの動作について説明します。

4.1. リクエスタは、更新されるゾーンの既知の権威ネームサーバーにUPDATEリクエストを送信します。このサーバーは、ゾーンのプライマリまたはスレーブサーバーである可能性があります。サーバーがスレーブの場合、リクエストはプライマリに転送されます。リクエスタは、権威があり更新を実行できるサーバーを見つけるまで、複数のサーバーを試すことができます。

4.2. サーバーがNOTAUTHまたはNOTIMP応答コードで応答する場合、リクエスタは別のサーバーを試す必要があります。

4.3. 応答コードがSERVFAILの場合、リクエスタは、おそらくある程度の遅延の後、更新を再試行する必要があります。ただし、DNSサービス検出プロトコルで指定されたより具体的な再試行アルゴリズムがない場合、リクエスタは無期限に再試行すべきではありません。

4.4. 応答コードがYXRRSETまたはNXRRSETの場合、これは前提条件が満たされなかったことを意味します。リクエスタは、変更された前提条件で再試行するか、更新を中止することができます。

4.5. 応答コードがNOERRORの場合、更新はプライマリマスターによって受け入れられました。ただし、これはすべてのスレーブが更新を受信したことを保証するものではありません。

4.6. リクエスタは、SOAパラメータを設定または変更するために、更新にSOA RRを含めることができます。同じゾーンに対して複数のUPDATEメッセージが順番に送信される場合、およびSOA SERIALがリクエスタによって管理されている場合、リクエスタは、後続の更新を送信する前に、ゾーンの現在のSOA SERIAL(おそらく以前のUPDATEへの応答を調べることによって)をチェックする必要があります。これにより、リクエスタのUPDATEメッセージとスレーブゾーン転送の間の競合が回避されます。

4.7. UDPは、単一のデータグラムに収まるUPDATEリクエストに推奨されます。これは、サーバーの負荷が少なく、リクエスタの遅延が少ないためです。ただし、一部のファイアウォールとパケットフィルターがUDPポート53をブロックするため、UDPリクエストがタイムアウトした場合、リクエスタはTCPを使用してリクエストを再試行する準備ができている必要があります。正確な応答コードを必要とするリクエスタは、UDP応答が転送中に失われる可能性があるため、TCPを使用する必要があります。

4.8. 単一のUPDATEメッセージに複数の更新を含めることは可能ですが、更新が強く関連していない限り、そうすることは推奨されません。その理由は、メッセージ内のいずれかの更新が前提条件を満たさない場合、または処理中にエラーが発生した場合、UPDATEメッセージ全体が拒否されるためです。したがって、リクエスタは一般に、無関係な更新には別々のUPDATEメッセージを送信する必要があります。