An EDNS0 option to negotiate Leases on DNS Updates
Apple Inc.One Apple Park WayCupertinoCalifornia95014USA+1 408 974 3207cheshire@apple.comApple IncP.O. Box 958BrattleboroVermontUnited States of America05302mellon@fugue.com
Internet
Internet Engineering Task ForceDNS UpdateRFCRequest for CommentsI-DInternet-DraftThis document proposes a new EDNS0 option that can be used by DNS Update clients and
DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale
resource records that have been added by DNS UpdatesIntroductionDynamic 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 DocumentThe 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
.MechanismsThe 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 MessagesResource 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 MessagesIf 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 FormatRefresh 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 BehaviorUpon 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 CollectionIf 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 ConsiderationsThe EDNS(0) OPTION CODE 2 has already been assigned for this DNS
extension. No additional IANA services are required by this document.AcknowledgmentsThanks 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.