An EDNS0 option to negotiate Leases on DNS Updates

Introduction Dynamic DNS Update allows for a mapping from a persistent hostname to a dynamic IP address. This capability is particularly beneficial to mobile hosts, whose IP address may frequently change with location. However, the mobile nature of such hosts often means that dynamically updated resource records are not properly deleted. Consider, for instance, a mobile user who publishes address records via dynamic update. If this user moves their laptop out of range of the Wi-Fi access point, the address record containing stale information may remain on the server indefinitely. An extension to Dynamic Update is thus required to tell the server to automatically delete resource records if they are not refreshed after a period of time. Note that overloading the resource record TTL is not appropriate for purposes of garbage collection. Data that is susceptible to frequent change or invalidation, thus requiring a garbage collection mechanism, needs a relatively short resource record TTL to avoid polluting intermediate DNS caches with stale data. Using this TTL, short enough to minimize stale cached data, as a garbage collection lease lifetime would result in an unacceptable amount of network traffic due to refreshes (see "Refresh Messages").

Conventions and Terminology Used in this Document 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 "Key words for use in RFCs to Indicate Requirement Levels", when, and only when, they appear in all capitals, as shown here .

Mechanisms The EDNS0 Update Lease option is included in a standard DNS Update message within an EDNS(0) OPT pseudo-RR with a new OPT and RDATA format proposed here. Encoding the Update Lease Lifetime in an OPT RR requires minimal modification to a name server's front-end, and will cause servers that do not implement this extension to automatically return a descriptive error (NOTIMPL).

Update Message Format Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic Update messages , with the addition of a single OPT RR in the Additional section. Note that if a TSIG resource record is to be added to authenticate the update , the TSIG RR should appear *after* the OPT RR, allowing the message digest in the TSIG to cover the OPT RR. The OPT RR is formatted as follows:

Update Requests contain, in the LEASE field of the OPT RDATA, an unsigned 32-bit integer indicating the lease lifetime, in seconds, desired by the client, represented in network (big-endian) byte order. In Update Responses, this field contains the actual lease granted by the server. The lease granted by the server may be less than, greater than, or equal to the value requested by the client. To reduce network and server load, a minimum lease of 30 minutes (1800 seconds) is RECOMMENDED. Leases are expected to be sufficiently long as to make timer discrepancies (due to transmission latency, etc.) between a client and server negligible. Clients that expect the updated records to be relatively static MAY request appropriately longer leases. Servers MAY grant relatively longer or shorter leases to reduce network traffic due to refreshes, or reduce stale data, respectively. There are two variants of the EDNS(0) UPDATE-LEASE option, the basic (4-byte) variant and the extended (8-byte) variant. In the basic (4-byte) variant, the LEASE indicated in the OPT RR applies to all resource records in the Update section. In the extended (8-byte) variant, the Update Lease communicates two lease lifetimes. The LEASE indicated in the OPT RR applies to all resource records in the Update section *except* for KEY records. The KEY-LEASE indicated in the OPT RR applies to KEY records in the Update section. This variant is used specifically for supporting the DNS-SD Service Registration Protocol .

Refresh Messages Resource records not to be deleted by the server MUST be refreshed by the client before the lease elapses. Clients SHOULD refresh resource records after 75% of the original lease has elapsed. If the client uses UDP and does not receive a response from the server, the client SHOULD re-try after 2 seconds. The client SHOULD continue to re-try, doubling the length of time between each re-try, or re-try using TCP.

Coalescing Refresh Messages If the client has sent multiple updates to a single server, the client MAY include refreshes for all valid updates to that server in a single message. This effectively places all records for a client on the same expiration schedule, reducing network traffic due to refreshes. In doing so, the client includes in the refresh message all existing updates to the server, including those not yet close to expiration, so long as at least one resource record in the message has elapsed at least 75% of its original lease. If the client uses UDP, the client MUST NOT coalesce refresh messages if doing so would cause truncation of the message; in this case, multiple messages or TCP should be used.

Refresh Message Format Refresh messages are formatted like Dynamic Update Leases Requests and Responses (see "Update Message Format"). The resource records to be refreshed are contained in the Update section. These same resource records are repeated in the Prerequisite section, as an "RRSet exists (value dependent)" prerequisite . An OPT RR is the last resource record in the Additional section (except for a TSIG record, which, if required, follows the OPT RR). The OPT RR contains the desired new lease on Requests, and the actual granted lease on Responses. The Update Lease indicated in the OPT RR applies to all resource records in the Update section.

Server Behavior Upon receiving a valid Refresh Request, the server MUST send an acknowledgment. This acknowledgment is identical to the Update Response format described in "Update Message Format", and contains the new lease of the resource records being refreshed. If no records in the Refresh Request have completed 50% of their leases, the server SHOULD NOT refresh the records; the response should contain the smallest remaining (unrefreshed) lease of all records in the refresh message. The server MUST NOT increment the SOA serial number of a zone as the result of a refresh.

Garbage Collection If the Update Lease of a resource record elapses without being refreshed, the server MUST NOT return the expired record in answers to queries. The server MAY delete the record from its database.

When DNS Update is enabled on an authoritative server, the Security Considerations of that specification should be considered. The addition of a record lifetime to facilitate automated garbage collection does not itself add any significant new security concerns.

IANA Considerations The EDNS(0) OPTION CODE 2 has already been assigned for this DNS extension. No additional IANA services are required by this document.

Acknowledgments Thanks to Marc Krochmal and Kiren Sekar to their work in 2006 on the precursor to this document. Thanks also to Roger Pantos and Chris Sharp for their contributions.