5. 転送の動作

5. 転送の動作

このセクションでは、転送サーバー、つまりUPDATEリクエストをプライマリマスターに転送するスレーブネームサーバーの動作について説明します。

5.1. スレーブサーバーが、それが権威を持つゾーンのUPDATEリクエストを受信した場合、そのゾーンのプライマリマスターにリクエストを転送する必要があります。プライマリマスターのアドレスは、ゾーンのSOA MNAMEフィールドまたはサーバー構成から取得する必要があります。

5.2. スレーブサーバーは、リクエストを転送する際に、元のリクエスタのアドレスとその他のリクエストパラメータを保持する必要があります。これにより、プライマリマスターはセキュリティポリシーを適用し、元のリクエスタに直接応答を送信できます。

5.3. スレーブサーバーがUDPを使用してリクエストを転送する場合、UDPリクエストがタイムアウトした場合、または応答でTC(切り捨て)ビットを受信した場合、TCPを使用して再試行する準備ができている必要があります。

5.4. スレーブサーバーがTCP経由でUPDATEリクエストを受信した場合、TCPを使用してプライマリマスターにリクエストを転送する必要があります。これにより、正確な応答コードを必要とするリクエスタ(そのためにTCPを使用した)がそれらを受信することが保証されます。

5.5. スレーブサーバーは、転送タイムアウトメカニズムを実装することができます。転送されたリクエストがこのタイムアウト期間内にプライマリマスターから応答を受信しない場合、スレーブは元のリクエスタにSERVFAIL応答を返し、接続を閉じる(TCPが使用された場合)ことができます。

5.6. スレーブサーバーがリクエストを転送できない場合(例えば、プライマリマスターに接続できないため)、リクエスタにSERVFAIL応答を返す必要があります。

5.7. スレーブサーバーが転送のチェーンを実装することは可能であり、更新がプライマリマスターに到達する前に複数のスレーブサーバーを介して転送されます。ただし、このような構成は、追加の障害点と遅延を導入するため、推奨されません。このような構成が使用される場合、チェーン内の各転送サーバーは、このセクションで説明されているルールに従う必要があります。

5.8. 転送サーバーは、DNSメッセージ転送に必要な場合を除き(例えば、構成に適した再帰要求ビットの設定)、UPDATEメッセージを変更すべきではありません。

5.9. 転送サーバーは、繰り返されるSOA MNAMEルックアップを回避するために、プライマリマスターのアドレスをキャッシュすることができます。ただし、プライマリマスターが再配置された可能性があるため、転送試行が失敗した場合、このキャッシュを更新する準備ができている必要があります。

5.10. 転送ループが検出された場合(例えば、スレーブサーバーが自身の転送されたリクエストを受信した場合)、サーバーは無限の転送ループを回避するためにSERVFAILを返す必要があります。