Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 9664 T. Lemon
Category: Standards Track Apple Inc.
ISSN: 2070-1721 June 2025
This document describes an EDNS(0) option that can be used between DNS Update Requesters and authoritative DNS servers to include a lifetime (lease duration) in a DNS Update or DNS Update Response, allowing a server to garbage collect stale Resource Records that have been added by DNS Updates if they are not renewed.
このドキュメントでは、DNSアップデートリクエスターと権威あるDNSサーバーの間で使用できるEDN（0）オプションについて説明して、DNSアップデートまたはDNS更新応答に寿命（リース期間）を含め、サーバーが更新されていない場合にDNSアップデートによって追加された古いリソースレコードを収集できるようにします。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9664.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9664で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology Used in This Document
2.1. Terminology
3. Mechanisms
4. Lease Update Request and Response Format
4.1. Types of Lease Update Requests
4.2. Requester Behavior
4.3. Server Behavior
5. Refresh Requests
5.1. Refresh Request Format
5.2. Requester Behavior
5.2.1. Coalescing Refresh Requests
5.3. Server Behavior
6. Retransmission Strategy
7. Garbage Collection
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
Dynamic Update in the Domain Name System (DNS Update) [RFC2136] allows for a mapping from a persistent hostname to an IP address that changes over time. This capability is particularly beneficial to mobile hosts, whose IP addresses may frequently change with location. However, the mobile nature of such hosts often means that Resource Records (RRs) added using DNS Update are not properly deleted. For instance, consider a mobile user who publishes address RRs via DNS Update. If this user moves their laptop out of range of the Wi-Fi access point, the address RR containing stale information may remain on the authoritative DNS server indefinitely. Thus, an extension to DNS Update is required to tell the server to automatically delete RRs after a period of time if they are not refreshed.
ドメイン名システム（DNSアップデート）[RFC2136]の動的更新により、永続的なホスト名から時間の経過とともに変化するIPアドレスへのマッピングが可能になります。この機能は、モバイルホストにとって特に有益であり、そのIPアドレスは場所とともに頻繁に変化する可能性があります。ただし、そのようなホストのモバイル性は、DNSアップデートを使用して追加されたリソースレコード（RR）が適切に削除されないことを意味します。たとえば、DNSアップデートを介してアドレスRRSを公開するモバイルユーザーを検討してください。このユーザーがWi-Fiアクセスポイントの範囲からラップトップを移動すると、古い情報を含むアドレスRRは、権威あるDNSサーバーに無期限に残ることができます。したがって、DNSアップデートへの拡張機能は、リフレッシュされていない場合にRRSを自動的に削除するようサーバーに指示するために必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
DNS-SD:
DNS-SD：
DNS-based Service Discovery [RFC6763]
DNSベースのサービスディスカバリー[RFC6763]
EDNS(0):
edns（0）：
Extension Mechanisms for DNS [RFC6891]
DNSの拡張メカニズム[RFC6891]
Update Lease option:
リースの更新オプション：
Update Lease EDNS(0) option
Lease EDNS（0）オプションを更新します
Lease:
リース：
An agreement by an authoritative DNS server to continue to publish a record from the time of registration until the lease duration has elapsed and then stop publishing it
登録期間からリース期間が経過するまでレコードを公開し続けるという権威あるDNSサーバーによる契約
Lease Duration:
リース期間：
The time between the start and end of a lease
リースの開始と終了の間の時間
Lease Update Request:
リース更新リクエスト：
DNS Update Request containing an Update Lease option
DNSアップデートリクエストを含むリクエストは、更新リースオプションです
Lease Update Response:
リース更新応答：
DNS Update Response containing an Update Lease option
DNSアップデートリースオプションを含む更新応答
RR:
RR:
Resource Record
リソースレコード
Registration Request:
登録リクエスト：
A Lease Update Request that is constructed with the purpose of adding new information that is not thought to already be present on the authoritative DNS server
権威あるDNSサーバーに既に存在するとは考えられていない新しい情報を追加する目的で構築されたリース更新リクエスト
Registration:
登録：
The result of a successful Registration Request
登録要求が成功した結果
Refresh Request:
リフレッシュリクエスト：
A Lease Update Request that extends the lease duration on an existing Registration
既存の登録時にリース期間を延長するリース更新リクエスト
Refresh:
リフレッシュ：
The result of a successful Refresh Request
リフレッシュリクエストが成功した結果
The Update Lease option is included in a standard DNS Update Request [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
更新リースオプションは、EDNS（0）OPT PSEUDO-RR [RFC6891]内の標準DNSアップデートリクエスト[RFC2136]に含まれています。
Lease Update Requests and Responses are formatted as standard DNS Update messages [RFC2136]. Such messages MUST include the EDNS(0) OPT RR [RFC6891]. This OPT RR MUST include an Update Lease EDNS(0) Option as shown below:
リース更新リクエストと応答は、標準のDNS更新メッセージ[RFC2136]としてフォーマットされます。このようなメッセージには、EDN（0）OPT RR [RFC6891]を含める必要があります。このOPT RRには、以下に示すように、更新リースEDNS（0）オプションを含める必要があります。
+===============+===========+======================================+
| Field Name | Field | Description |
| | Type | |
+===============+===========+======================================+
| OPTION-CODE | u_int16_t | UPDATE-LEASE (2) |
+---------------+-----------+--------------------------------------+
| OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE) |
+---------------+-----------+--------------------------------------+
| LEASE | u_int32_t | desired lease duration (Lease Update |
| | | Request) or granted lease duration |
| | | (Lease Update response), in seconds |
+---------------+-----------+--------------------------------------+
| KEY-LEASE | u_int32_t | optional desired (or granted) lease |
| | | duration for KEY RRs, in seconds |
+---------------+-----------+--------------------------------------+
Table 1
Lease Update Requests contain, in the LEASE field of the OPT RDATA, an unsigned 32-bit integer indicating the lease duration in seconds, desired by the Requester, represented in network (big-endian) byte order. In Lease Update Responses, this field contains the actual lease duration granted by the authoritative DNS server. The lease durations granted by the server may be less than, greater than, or equal to the value requested by the Requester.
リースアップデートリクエストには、OPT RDATAのリースフィールドに、ネットワーク（ビッグエンディアン）バイトの順序で表されるリクエスターが望む数秒でリース期間を示す署名されていない32ビット整数が含まれています。リース更新応答では、このフィールドには、権威あるDNSサーバーによって付与された実際のリース期間が含まれています。サーバーによって付与されたリース期間は、要求者が要求した値よりも大きい、より大きく、または等しい場合があります。
There are two variants of the Update Lease option: The 4-byte variant and the 8-byte variant.
更新リースオプションには、4バイトバリアントと8バイトバリアントの2つのバリエーションがあります。
In the 4-byte variant, the LEASE indicated in the Update Lease option applies to all RRs in the Update section.
4バイトバリアントでは、更新リースオプションに示されているリースは、更新セクションのすべてのRRに適用されます。
In the 8-byte variant, the Update Lease communicates two lease durations. The LEASE indicated in the Update Lease option applies to all RRs in the Update section _except_ for KEY RRs. The KEY-LEASE indicated in the Update Lease option applies to KEY RRs in the Update section.
8バイトのバリアントでは、アップデートリースは2つのリース期間を伝えます。更新リースオプションに示されているリースは、キーRRSの更新セクション_exicted_のすべてのRRに適用されます。更新リースオプションに示されているキーリースは、更新セクションのキーRRSに適用されます。
More information about how the two variants are used is given in Section 4.3.
2つのバリアントの使用方法に関する詳細については、セクション4.3に記載されています。
KEY RRs are given a special lease duration because these RRs are used in the DNS-SD Service Registration Protocol [RFC9665] to reserve a name (or names) when the service is not present.
これらのRRSは、サービスが存在しないときに名前（または名前）を予約するためにDNS-SDサービス登録プロトコル[RFC9665]で使用されているため、主要なRRSに特別なリース期間が与えられます。
In the case of a KEY RR and some other RR, obviously the KEY lease duration applies to the KEY RR, and the lease duration applies to the other RR. If more than one RR that is not a KEY RR is added by the Lease Update Request, the lease duration (not the KEY lease duration) is applied to all such RRs. RRs that are removed are permanently removed.
キーRRおよび他のRRの場合、明らかにキーリース期間がキーRRに適用され、リース期間は他のRRに適用されます。キーRRではない複数のRRがリースアップデートリクエストによって追加される場合、そのようなすべてのRRにリース期間（キーリース期間ではありません）が適用されます。削除されたRRは永久に削除されます。
This document describes two types of Lease Update Requests: Registrations and Refreshes. A Registration Request is a Lease Update Request that is intended to add information not already present on the authoritative DNS server. A Refresh Request is intended simply to renew the lease on a previous Registration without changing anything. Registrations and Refreshes are both Lease Update Requests, so the term "Lease Update Request" is used to specify behavior that is the same for both types of DNS Updates.
このドキュメントでは、2種類のリース更新リクエストについて説明します。登録とリフレッシュです。登録要求は、権威あるDNSサーバーにまだ存在していない情報を追加することを目的としたリース更新リクエストです。更新リクエストは、何も変更せずに以前の登録のリースを更新することを目的としています。登録とリフレッシュはどちらもリース更新要求であるため、「リース更新リクエスト」という用語は、両方のタイプのDNSアップデートで同じ動作を指定するために使用されます。
In some cases, it may be necessary to add new information without removing old information. For the purpose of this document, such Lease Update Requests are Registrations, although in effect, they may also refresh whatever information is unchanged from a previous registration.
場合によっては、古い情報を削除せずに新しい情報を追加する必要がある場合があります。このドキュメントの目的のために、このようなリース更新リクエストは登録ですが、実際には、以前の登録から変更されていない情報を更新することもあります。
DNS Update Requesters MUST send an Update Lease option with any DNS Update that updates RRs that are not intended to be present indefinitely. The Update Lease option SHOULD specify a lease duration that is no shorter than 1800 seconds (30 minutes). Requesters MAY specify a shorter lease duration if they anticipate that the RRs being updated will change more frequently than every 30 minutes. Requesters that expect the updated RRs to be relatively static SHOULD request appropriately longer lease durations.
DNSアップデートリクエスターは、無期限に存在することを意図していないRRを更新するDNSアップデートで更新リースオプションを送信する必要があります。更新リースオプションは、1800秒（30分）より短いリース期間を指定する必要があります。要求者は、更新されるRRSが30分ごとよりも頻繁に変化すると予想される場合、より短いリース期間を指定する場合があります。更新されたRRSが比較的静的であると予想されるリクエスト担当者は、適切に長いリース期間を要求する必要があります。
If the DNS Response received by the Requester does not include an Update Lease option, this is an indication that the authoritative DNS server does not support the Update Lease option. In this case, the Requester SHOULD continue sending Refresh Requests (see below) as if the server had returned an identical Update Lease option in its Response.
リクエスターが受信したDNS応答に更新リースオプションが含まれていない場合、これは権威あるDNSサーバーが更新リースオプションをサポートしていないことを示しています。この場合、要求者は、サーバーが応答で同一の更新リースオプションを返したかのように、更新要求（以下を参照）を継続する必要があります。
If the DNS Response does include an Update Lease option, the Requester MUST use the durations returned in this option when determining when to send Refresh Requests. This is true both if the durations returned by the server are shorter and if they are longer.
DNS応答に更新リースオプションが含まれている場合、リクエスタは更新リクエストを送信する時期を決定するときに、このオプションで返された期間を使用する必要があります。これは、サーバーによって返された期間が短い場合、およびそれらが長くなる場合の両方です。
When sending a Registration Request, the Requester MUST delay the initial transmission by a random amount of time across the range of 0-3000 milliseconds, with a granularity of no more than 10 milliseconds. This prevents synchronization of multiple devices of the same type at a site upon recovery from a power failure. This requirement applies only to the initial Registration Request on startup; since Refresh Requests include a random factor as well, any synchronization that occurs after such an event should quickly randomize.
登録要求を送信する場合、要求者は、10〜3000ミリ秒の範囲でランダムな時間だけで初期送信を遅らせる必要があり、粒度は10ミリ秒以下です。これにより、停電から回復する際に、サイトで同じタイプの複数のデバイスの同期を防ぎます。この要件は、起動時の最初の登録要求にのみ適用されます。更新リクエストにはランダムファクターも含まれるため、そのようなイベントの後に発生する同期は、すぐにランダム化する必要があります。
The 10 ms granularity is a scheduling requirement intended to result in an even spread of Requests so that every Request doesn't come an exact number of seconds after startup. This requirement should not be construed as requiring anything of the link layer on which the packet is transmitted: the link layer may well impose its own constraints on the timing at which a message is sent, and this document does not claim to override such constraints.
10ミリ秒の粒度は、スタートアップの均等な拡散をもたらすスケジューリング要件であるため、すべてのリクエストが起動後正確な秒数になりません。この要件は、パケットが送信されるリンクレイヤーのものを要求するものとして解釈されるべきではありません。リンクレイヤーは、メッセージが送信されるタイミングに独自の制約を課す可能性があり、このドキュメントはそのような制約をオーバーライドすることを主張していません。
The use of a 3000 ms (3-second) random delay as opposed to some other random delay is to allow for enough time to meaningfully spread the load when many devices renew at once, without delaying so long that the delay in discovery of devices becomes obvious to an end user. A 3-second random delay means that if there are, for example, 100 devices, and the random number generator spread is even, we would have one renewal every 30 ms. In practice, on relatively constrained devices acting as Service Registration Protocol (SRP) servers, we are seeing the processing time for an SRP registration taking on the order of 7 ms, so this seems reasonable.
他のいくつかのランダム遅延とは対照的に、3000ミリ秒（3秒）のランダム遅延を使用することは、多くのデバイスが一度に更新されたときに、デバイスの発見の遅延がエンドユーザーに明らかになるほど長い間遅延することなく、多くのデバイスが一度に更新されたときに有意義に負荷を広めるのに十分な時間を確保することです。3秒のランダム遅延は、たとえば100のデバイスがあり、乱数ジェネレーターの広がりがある場合、30ミリ秒ごとに1つの更新が行われることを意味します。実際には、サービス登録プロトコル（SRP）サーバーとして機能する比較的制約されたデバイスでは、SRP登録の処理時間が7ミリ秒を帯びていることがわかりますので、これは妥当と思われます。
Authoritative DNS servers implementing the Update Lease option MUST include an Update Lease option in response to any successful DNS Update (RCODE=0) that includes an Update Lease option. Servers MAY return lease durations different from those specified by the Requester, granting longer leases to reduce network traffic due to Refreshes or shorter leases to reduce the lifetime of stale data.
アップデートリースオプションを実装する権威あるDNSサーバーには、更新リースオプションを含む成功したDNSアップデート（rcode = 0）に応じて、更新リースオプションを含める必要があります。サーバーは、リクエスターによって指定されたものとは異なるリース期間を返すことができ、リフレッシュまたは短いリースによるネットワークトラフィックを削減するために長いリースを許可して、古いデータの寿命を減らすことができます。
Although both the 4-byte and 8-byte variants are valid on both requesters and servers, older (pre-standard) requesters and servers may exist that support only the 4-byte variant. Therefore, requesters and servers that (as required by this specification) support both variants must account for the possibility that the peer with which they are communicating may be an older implementation that supports only the 4-byte variant.
4バイトと8バイトの両方のバリアントは、リクエスターとサーバーの両方で有効ですが、4バイトのバリアントのみをサポートする古い（標準以前）リクエスタとサーバーが存在する場合があります。したがって、（この仕様で要求されるように）サポートする要求者とサーバーの両方のバリアントは、彼らが通信しているピアが4バイトのバリアントのみをサポートする古い実装である可能性を説明する必要があります。
A server that receives an 8-byte variant from a requester MUST respond with an 8-byte variant giving the granted lease times.
要求者から8バイトのバリアントを受信するサーバーは、付与されたリース時間を与える8バイトのバリアントで応答する必要があります。
A server that receives a 4-byte variant from a requester MUST treat the 4-byte variant as specifying both the lease duration and the KEY lease duration and MUST respond with a 4-byte variant. In this case, the key and the other RRs expire at the same time.
要求者から4バイトのバリアントを受信するサーバーは、4バイトのバリアントをリース期間とキーリース期間の両方を指定し、4バイトのバリアントで応答する必要があります。この場合、キーと他のRRは同時に期限切れになります。
A requester that receives a 4-byte variant from a server when it sent an 8-byte variant in its request MUST treat the 4-byte variant as specifying both the lease duration and the KEY lease duration.
リクエストに8バイトのバリアントを送信したときにサーバーから4バイトのバリアントを受信する要求者は、4バイトのバリアントをリース期間とキーリース期間の両方を指定するように扱う必要があります。
A Refresh Request is a DNS Update Request that is sent to the server after an initial DNS Update has been sent in order to prevent the update's RRs from being garbage collected.
更新リクエストは、更新のRRSがガベージが収集されないようにするために、最初のDNSアップデートが送信された後にサーバーに送信されるDNSアップデートリクエストです。
Refresh Requests and their corresponding responses are formatted like Update Lease Requests and Update Lease Responses (see Section 4). The Refresh Request is constructed with the assumption that the previous Registration or Refresh is still in effect. In the case that the RRs added in a previous update were for some reason garbage collected (e.g., because of a server reboot that resulted in loss of state), the Refresh Request will result in those RRs being added again.
リクエストとそれらの対応する応答は、更新リースリクエストと更新リース応答のようにフォーマットされます（セクション4を参照）。更新要求は、以前の登録または更新がまだ有効であるという仮定で構築されます。以前のアップデートでRRSが追加されたRRSが何らかの理由でガベージを収集した場合（たとえば、状態の損失をもたらすサーバーの再起動のため）、更新要求によりRRが再び追加されます。
The Refresh Request SHOULD NOT include any DNS Update prerequisites that will fail if the Requester's previous Registration or Refresh is still in effect. It also SHOULD NOT include prerequisites that would fail if the RRs affected by the previous Registration or Refresh are no longer present; that is, the Refresh Request should also work as a Registration Request. There may be cases where this is not possible; in which case, the response from the server can be used to determine how to proceed when the Refresh Request fails.
更新リクエストには、要求者の以前の登録または更新がまだ有効である場合に失敗するDNS更新前の前提条件を含めるべきではありません。また、前の登録または更新の影響を受けたRRSが存在しなくなった場合に失敗する前提条件を含めるべきではありません。つまり、更新リクエストも登録リクエストとして機能する必要があります。これが不可能な場合があります。その場合、サーバーからの応答を使用して、更新リクエストが失敗したときに進む方法を決定できます。
A Lease Update Request that changes the authoritative DNS server state resulting from a previous Refresh or Registration is a Registration Request, not a Refresh Request.
以前の更新または登録に起因する権威あるDNSサーバー状態を変更するリース更新リクエストは、更新リクエストではなく登録要求です。
In a Refresh Request, the Update Lease option contains the desired new lease duration, and in the corresponding response, the Update Lease option contains the actual granted lease. The lease duration provided in LEASE in the Update Lease option applies to all RRs in the Update section of the Refresh Request, except that when the 8-byte Update Lease variant is sent, the duration specified in KEY-LEASE applies to any KEY RRs included in the Update section.
更新リクエストでは、更新リースオプションには目的の新しいリース期間が含まれており、対応する応答では、更新リースオプションには実際の付与リースが含まれています。更新リースオプションのリースで提供されるリース期間は、8バイトアップデートリースバリアントが送信される場合、キーリースで指定された期間が更新セクションに含まれるキーRRに適用されることを除いて、更新リクエストのすべてのRRSに適用されます。
A Requester that intends for its RRs from a previous Registration or Refresh to remain active MUST send a Refresh Request before the lease expires; otherwise, the RRs will be removed by the server.
以前の登録からRRSを対象とするリクエスターまたはアクティブを維持するためにリフレッシュすることは、リースの有効期限が切れる前に更新リクエストを送信する必要があります。それ以外の場合、RRSはサーバーによって削除されます。
In order to prevent Registrations expiring, Requesters MUST refresh them. When a Lease Update Request succeeds, the requester computes a time limit that is 80% of the lease duration plus a random offset between 0% and 5% of the lease duration. The random offset is to prevent refreshes from being synchronized. When this time limit has expired, the requester MUST send a Refresh Request if the data in the initial Registration should continue to be advertised.
登録の期限切れを防ぐために、要求者はそれらを更新する必要があります。リースアップデートリクエストが成功すると、リクエスターはリース期間の80％である時間制限と、リース期間の0％〜5％のランダムオフセットを計算します。ランダムオフセットは、リフレッシュが同期されないようにすることです。この時間制限が期限切れになった場合、最初の登録のデータが引き続き宣伝される必要がある場合、要求者は更新要求を送信する必要があります。
For Refresh Requests, the server is expected to return an Update Lease option, if supported, just as with the initial Registration Request. As with the Registration Request, the Requester MUST use the durations returned by the server in the Lease Update Response when determining when to send the next Refresh Request.
更新リクエストの場合、サーバーは、最初の登録リクエストと同様に、サポートされている場合、更新リースオプションを返すことが期待されます。登録要求と同様に、リクエスターは、次の更新リクエストをいつ送信するかを決定する際に、リース更新応答でサーバーが返品した期間を使用する必要があります。
When sending Refresh Requests, the Requester MUST include an Update Lease option, as it did in the initial Registration Request. The Update Lease option MAY either specify the same durations as in the initial Registration Request or use the values returned by the server in the previous Lease Update Response or other desired values as appropriate. As with responses to Registration Requests, the Requester MUST use the lease durations returned by the server in the response when determining when to send the next Refresh Request.
更新リクエストを送信するとき、リクエスターは、最初の登録リクエストで行ったように、更新リースオプションを含める必要があります。更新リースオプションは、最初の登録要求と同じ期間を指定するか、以前のリース更新応答または必要に応じてその他の希望の値でサーバーによって返された値を使用する場合があります。登録リクエストへの回答と同様に、リクエスターは、次の更新リクエストをいつ送信するかを決定するときに、サーバーによって返されたリース期間を応答で使用する必要があります。
If the Requester sends a Refresh Request message and does not receive a response from the authoritative DNS server, then the Requester should implement a reasonable retry strategy to attempt to refresh the record registrations before they expire. Given that 15% - 20% of the lease lifetime still remains, these retransmissions do not need to be overly aggressive. For example, the Requester could retry nine more times, spaced uniformly at equal intervals from the time of the first failed Refresh attempt until the expiration time of the records. After the expiration time of the records, the Refresh Request effectively turns into a new Registration Request, and further retransmissions after this proceed as described in Section 6.
リクエスターが更新リクエストメッセージを送信し、権威あるDNSサーバーから応答を受け取らない場合、リクエスト担当者は、有効期限が切れる前にレコード登録を更新しようとする合理的な再試行戦略を実装する必要があります。リース寿命の15％から20％がまだ残っていることを考えると、これらの再送信は過度に攻撃的である必要はありません。たとえば、リクエスターは、最初の失敗した更新試行の時期からレコードの有効期限まで均一に間隔を置いて、さらに9回、さらに9回再試行することができます。レコードの有効期限の後、更新リクエストは効果的に新しい登録リクエストに変わり、この後にさらに再送信が行われ、セクション6で説明されています。
If the Requester has performed multiple Registrations with a single server for different RRs, the Requester MAY send a Refresh Request containing RRs from all such Registrations to that server in a single Refresh Request. This effectively places all RRs for a Requester on the same expiration schedule, reducing network traffic due to Refreshes.
リクエスターが異なるRRSの単一サーバーで複数の登録を実行した場合、リクエスターは、そのようなすべての登録からそのサーバーにRRを含むRRSを1つの更新リクエストで送信する場合があります。これにより、要求者のすべてのRRSが同じ有効期限スケジュールに効果的に配置され、更新によるネットワークトラフィックが削減されます。
In doing so, the Requester includes in the Refresh Request all existing RRs previously successfully registered on the server, including those not yet close to expiration, so long as at least one RR updated in the Refresh Request has elapsed at least 75% of its original lease duration. If the Requester uses UDP, the Requester MUST NOT coalesce Refresh Requests if doing so would cause truncation of the Request; in this case, the Requester either sends multiple Requests or uses TCP to send the complete Refresh Request at once.
そうすることで、リクエスターは、リフレッシュリクエストに更新された少なくとも1つのRRが元のリース期間の少なくとも75％を経過している限り、まだ有効期限に近いものを含め、サーバーに以前に正常に登録されていたすべての既存のRRSをリフレッシュリクエストに含める。要求者がUDPを使用している場合、要求者はリクエストの切り捨てを引き起こす場合、リクエストリクエストを合体してはなりません。この場合、リクエスターは複数のリクエストを送信するか、TCPを使用して完全な更新リクエストを一度に送信します。
Requesters SHOULD NOT send a Refresh Request when all of the RRs in the Refresh Request would have more than 50% of their lease duration remaining before expiry. However, there may be cases where the Requester needs to send an early Refresh Request, and it MAY do so. For example, a power-constrained (sleepy) device may need to send a Refresh Request when the radio is powered so as to avoid having to power it up later.
リクエスターは、リフレッシュリクエスト内のすべてのRRSが有効期限の前に残っているリース期間の50％以上を持つ場合、更新リクエストを送信しないでください。ただし、リクエスターが早期の更新リクエストを送信する必要がある場合がある場合があります。たとえば、ラジオの電源を供給しないように、電力が制約されている（眠そうな）デバイスは、電源を供給しているときに更新リクエストを送信する必要がある場合があります。
Another case where this may be needed is when the lease duration registered with the server is no longer appropriate and the Requester wishes to negotiate a different lease duration. However, in this case, if the server does not honor the requested lease duration in its response, the Requester MUST NOT retry this negotiation.
これが必要になる可能性のある別のケースは、サーバーに登録されたリース期間がもはや適切ではなく、リクエスターが異なるリース期間の交渉を希望する場合です。ただし、この場合、サーバーが応答の要求されたリース期間を尊重しない場合、リクエスタはこの交渉を再試行してはなりません。
Upon receiving a valid Refresh Request, the server MUST send an acknowledgment. This acknowledgment is a Lease Update Response as described in Section 4 and contains the new lease duration of the Registration being Refreshed. The server MUST NOT increment the serial number of a zone as the result of a Refresh Request if the operation does not result in any change to the zone contents.
有効な更新リクエストを受信すると、サーバーは確認を送信する必要があります。この承認は、セクション4で説明されているリース更新応答であり、登録の新しいリース期間が更新されています。操作がゾーンコンテンツに変更されない場合、サーバーは更新要求の結果としてゾーンのシリアル番号をインクリメントしてはなりません。
However, the server's state may not match what the requester expects. In this case, a Refresh Request may actually appear to be a Registration Request, from the server's perspective. If the Refresh Request changes the contents of the zone, the server MUST update the zone serial number.
ただし、サーバーの状態は、要求者が期待するものと一致しない場合があります。この場合、リフレッシュリクエストは、実際にサーバーの観点から登録要求のように見える場合があります。更新要求がゾーンの内容を変更した場合、サーバーはゾーンシリアル番号を更新する必要があります。
The DNS protocol, including DNS updates, can operate over UDP or TCP. For communication using UDP, reliable transmission must be guaranteed by retransmitting when a DNS UDP message is not acknowledged in a reasonable amount of time. Section 4.2.1 of the DNS specification [RFC1035] provides some guidance on this topic, as does Section 1 of the IETF's guide to common DNS implementation errors [RFC1536]. Section 3.1.3 of the UDP Usage Guidelines [RFC8085] also provides useful guidance that is particularly relevant to DNS.
DNSアップデートを含むDNSプロトコルは、UDPまたはTCPを介して動作できます。UDPを使用した通信の場合、DNS UDPメッセージが合理的な時間で認められていない場合に再送信することにより、信頼できる伝送を保証する必要があります。DNS仕様[RFC1035]のセクション4.2.1は、一般的なDNS実装エラー[RFC1536]に関するIETFのガイドのセクション1と同様に、このトピックに関するいくつかのガイダンスを提供します。UDP使用ガイドライン[RFC8085]のセクション3.1.3は、DNSに特に関連する有用なガイダンスも提供します。
If the lease duration of an RR elapses without being refreshed, the authoritative DNS server MUST NOT return that RR in answers to queries. The server MAY delete that RR from its database. The lease durations returned by the server to the Requester are used in determining when the lease on an RR has expired.
RRのリース期間が更新されずに経過する場合、権威あるDNSサーバーは、クエリへの回答でそのRRを返してはなりません。サーバーは、データベースからそのRRを削除する場合があります。サーバーによってリクエスターに返されるリース期間は、RRのリースがいつ失効したかを判断する際に使用されます。
For all RRs other than a KEY RR included in a Lease Update Request, the lease duration is the LEASE value in the Update Lease option. For KEY RRs, if the optional KEY-LEASE value was included, this duration is used rather than the duration specified in the LEASE. If the KEY-LEASE was not specified, the duration specified in the LEASE is used for all RRs in the Lease Update Request.
リースアップデートリクエストに含まれる主要なRR以外のすべてのRRの場合、リース期間はアップデートリースオプションのリース値です。キーRRSの場合、オプションのキーリース値が含まれている場合、この期間はリースで指定された期間ではなく使用されます。キーリースが指定されていない場合、リースで指定された期間は、リースアップデートリクエストのすべてのRRに使用されます。
Section 8 of the DNS Update specification [RFC2136] describes problems that can occur around DNS updates. Servers implementing this specification should follow these recommendations.
DNS更新仕様[RFC2136]のセクション8では、DNSの更新周辺で発生する可能性のある問題について説明します。この仕様を実装するサーバーは、これらの推奨事項に従う必要があります。
Several additional issues can arise when relying on the Update Lease option.
更新リースオプションに依存すると、いくつかの追加の問題が発生する可能性があります。
First, a too-long lease duration is not much different from no lease duration: the RRs associated with such a Registration will effectively never be cleaned up. Servers implementing Update Lease should have a default upper bound on the maximum acceptable value both for the LEASE and KEY-LEASE values sent by the requester. Default values for these limits of 24 hours and 7 days, respectively, are RECOMMENDED. Servers MAY provide a way for the operator to change this upper limit.
第一に、長すぎるリース期間は、リース期間なしとそれほど違いはありません。このような登録に関連するRRSは、事実上クリーンアップされません。更新リースを実装するサーバーには、リクエスターが送信したリース値とキーリース値の両方で、最大許容値にデフォルトの上限が必要です。これらの制限のデフォルト値は、それぞれ24時間と7日間を推奨します。サーバーは、オペレーターがこの上限を変更する方法を提供する場合があります。
The second issue is that a too-short lease can result in increased server load as Requesters rapidly renew such Registrations. A delay in renewing could result in the registered RRs being removed prematurely. Servers implementing Update Lease MUST have a default minimum lease duration that avoids this issue. A minimum of 30 seconds for both the LEASE and KEY-LEASE durations is RECOMMENDED. However, in most cases, much longer lease durations (for example, an hour) SHOULD be used. Servers MAY provide a way for the operator to change this lower limit.
2番目の問題は、要求者がそのような登録を迅速に更新するため、短すぎるリースがサーバーの負荷を増加させる可能性があることです。更新の遅延により、登録されたRRが時期尚早に削除される可能性があります。更新リースを実装するサーバーには、この問題を回避するデフォルトの最小リース期間が必要です。リース期間とキーリース期間の両方で最低30秒を推奨します。ただし、ほとんどの場合、はるかに長いリース期間（たとえば、1時間）を使用する必要があります。サーバーは、オペレーターがこの下限を変更する方法を提供する場合があります。
There may be some cost associated with renewing leases. A malicious (or buggy) requester could renew at a high rate in order to overload the server more than it would be overloaded by query traffic. This risk is present for an authoritative server handling normal (no-lease) DNS Updates as well. Servers should follow established industry best practices to guard against flooding attacks, both for malicious flooding of DNS messages over UDP and for similar flooding attacks using TCP [SYN] [RFC4953].
リースの更新に関連するいくらかのコストがあるかもしれません。悪意のある（またはバギー）リクエスカーは、クエリトラフィックによってオーバーロードされるよりもサーバーに過負荷をかけるために、高いレートで更新できます。このリスクは、通常の（リースなし）DNSの更新を処理する権威あるサーバーにも存在します。サーバーは、UDPを介したDNSメッセージの悪意のある洪水とTCP [syn] [RFC4953]を使用した同様の洪水攻撃の両方について、洪水攻撃を防ぐために確立された業界のベストプラクティスに従う必要があります。
Some authentication strategy should be used when accepting DNS updates. Shared secret [RFC8945] or public key signing (e.g., SIG(0) [RFC2931]) should be required. Keys should have limited authority: compromise of a key should not result in compromise of the entire contents of one or more zones managed by the server. Key management strategy is out of scope for this document. Service Registration Protocol [RFC9665] uses DNS Update Leases with "First Come, First Served Naming" rather than an explicit trust establishment process to confer update permission to a set of RRs.
DNSの更新を受け入れるときは、いくつかの認証戦略を使用する必要があります。共有秘密[RFC8945]または公開キーの署名（例：SIG（0）[RFC2931]）が必要です。キーには権限が限られている必要があります。キーの妥協は、サーバーが管理する1つ以上のゾーンの内容全体を妥協するものではありません。主要な管理戦略は、このドキュメントの範囲外です。サービス登録プロトコル[RFC9665]は、DNSアップデートリースを使用して、RRSのセットへの更新許可を付与するための明示的な信託確立プロセスではなく、「First Come、First Server Naming」を使用します。
IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry [EDNS0Reg] as regards value 2 as follows:
IANAは、「DNS EDNS0オプションコード（OPT）」レジストリ[EDNS0REG]を次のように更新しました。
Value:
値：
2
2
Name:
名前：
Update Lease
リースを更新します
Status:
状態：
Standard
標準
Reference:
参照：
RFC 9664
RFC 9664
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
<https://www.rfc-editor.org/info/rfc1536>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", RFC 9665,
DOI 10.17487/RFC9665, June 2025,
<https://www.rfc-editor.org/info/rfc9665>.
[EDNS0Reg] IANA, "DNS EDNS0 Option Codes (OPT)",
<https://www.iana.org/assignments/dns-parameters>.
[SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The
Internet Protocol Journal, Cisco Systems, Volume 9, Number
4, December 2006,
<https://www.cisco.com/web/about/ac123/ac147/
archived_issues/ipj_9-4/ipj_9-4.pdf>.
Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the precursor to this document. Thanks also to Roger Pantos and Chris Sharp for their contributions. Thanks to Chris Box, Esko Dijk, Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nathan Dyck, Steve Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their working group reviews of this document. Thanks to David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib for their directorate reviews and IANA reviews.
2006年のこの文書の前駆体での作業について、Marc KrochmalとKiren Sekarに感謝します。ロジャー・パントスとクリス・シャープの貢献にも感謝します。クリス・ボックス、エスコ・ディク、ジョナサン・フイ、ピーター・ヴァン・ディク、アブティン・ケシュヴァルツィアン、ネイサン・ダイク、スティーブ・ハンナ、ガブリエル・モンテネグロ、カンピン・ドン、およびティム・ウィシンスキーのこの文書のワーキンググループレビューをしてくれたことに感謝します。David Dong、Olafur Gudmundsson、Brian Trammel、およびShivan Sahibに感謝します。
Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Phone: +1 408 974 3207
Email: cheshire@apple.com
Ted Lemon
Apple Inc.
P.O. Box 958
Brattleboro, VT 05302
United States of America
Email: mellon@fugue.com