RFC 9664

An EDNS(0) Option to Negotiate Leases on DNS Updates

📅 published June 2025, from ietf

RFC 9664: An EDNS(0) Option to Negotiate Leases on DNS Updates 💖

  • Request for Comments: 9664
  • Authors: S. Cheshire and T. Lemon, both from Apple Inc. 🍎
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: June 2025
  • Obsoletes: none listed in the title block
  • Updates: none listed in the title block
  • Series: Internet Engineering Task Force (IETF) 🌸

Okay bestie, this one is a Standards Track doc, so it's the real deal, not a casual idea. Let's go 🫶

Abstract ✨

So this doc describes an EDNS(0) option that DNS Update Requesters and authoritative DNS servers can use. The option carries a lifetime, which is a lease duration, inside a DNS Update or a DNS Update Response. The payoff is that the server can garbage collect stale Resource Records that were added by DNS Updates, as long as nobody renews them. 🧹💅

Status of This Memo 🎀

This is an Internet Standards Track document. 🔥

It's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and a way to send feedback, go to https://www.rfc-editor.org/info/rfc9664. 🌈

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. 📜 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. Those components come with no warranty, as described in the Revised BSD License.

Table of Contents 🧚

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

1. Introduction 🍓

Dynamic Update in the Domain Name System (DNS Update) [RFC2136] lets you map a persistent hostname to an IP address that keeps changing. This is super useful for mobile hosts, whose IP addresses can change a lot as they move around. 📱

The problem is that mobile devices often leave behind Resource Records (RRs) that were added with DNS Update and never got deleted. Picture a mobile user who publishes address RRs with DNS Update. They walk their laptop out of range of the Wi-Fi access point, and now that address RR, full of outdated info, can just hang around on the authoritative DNS server forever. 😭 So an extension to DNS Update is required, one that tells the server to automatically delete RRs after a set time if nobody refreshes them. It's giving tidy house rules. 🧹✨

2. 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" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do here. Lowercase versions don't count. 🙈

2.1. Terminology 📚

  • DNS-SD: DNS-based Service Discovery [RFC6763]
  • EDNS(0): Extension Mechanisms for DNS [RFC6891]
  • Update Lease option: Update Lease EDNS(0) option
  • Lease: An agreement by an authoritative DNS server to keep publishing a record from the time of registration until the lease duration runs out, and then stop publishing it. ⏳
  • Lease Duration: The time between the start and the end of a lease.
  • Lease Update Request: A DNS Update Request that contains an Update Lease option.
  • Lease Update Response: A DNS Update Response that contains an Update Lease option.
  • RR: Resource Record
  • Registration Request: A Lease Update Request built to add new information that is not thought to already be on the authoritative DNS server. 🆕
  • 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.

3. Mechanisms ⚙️

The Update Lease option goes inside a standard DNS Update Request [RFC2136], and it lives in an EDNS(0) OPT pseudo-RR [RFC6891]. That's the whole trick. 🦋

4. Lease Update Request and Response Format 🎀

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, laid out like this:

+===============+===========+======================================+
| 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

So in a Lease Update Request, the LEASE field inside the OPT RDATA holds an unsigned 32-bit integer. That number is how many seconds the Requester wants the lease to last, written in network (big-endian) byte order. In a Lease Update Response, that same field holds the lease duration the authoritative DNS server actually granted. Heads up: the server's granted duration might be less than, greater than, or equal to what the Requester asked for. Plans change, babe. 🤷‍♀️💅

There are two variants of the Update Lease option: the 4-byte variant and the 8-byte variant. 👯

In the 4-byte variant, the LEASE in the Update Lease option applies to every RR in the Update section. Simple and clean. ✨

In the 8-byte variant, the Update Lease option carries two lease durations. The LEASE applies to all RRs in the Update section except for KEY RRs. The KEY-LEASE applies to the KEY RRs in the Update section. 🔑

Section 4.3 has more on how each variant gets used. 🧭

KEY RRs get their own special lease duration because they're used in the DNS-SD Service Registration Protocol [RFC9665] to reserve a name (or names) while the service isn't actually around. Makes sense, right? 🧚

So here's how it plays out when a KEY RR and some other RR show up together. The KEY lease duration applies to the KEY RR, and the regular lease duration applies to the other RR. If more than one non-KEY RR is added by the same Lease Update Request, the lease duration (not the KEY lease duration) applies to all of them. And RRs that get removed are permanently removed. Gone, no comeback. 💀

4.1. Types of Lease Update Requests 🌟

This document describes two kinds of Lease Update Requests: Registrations and Refreshes. A Registration Request is a Lease Update Request meant to add information that isn't already on the authoritative DNS server. A Refresh Request just renews the lease on a previous Registration without changing anything, so it's a pure glow-up for the lease and nothing else. 💖

Since Registrations and Refreshes are both Lease Update Requests, the term "Lease Update Request" covers behavior that's the same for both types of DNS Updates. 🫶

Sometimes you need to add new information without getting rid of the old stuff. For this document, those Lease Update Requests count as Registrations. Even so, in effect, they may also refresh whatever information hasn't changed since a previous registration. Multitasking queen behavior. 👑🌈

4.2. Requester Behavior ✨

Okay bestie, requesters are the ones asking the server to do stuff, so listen up 🫶. DNS Update Requesters MUST send an Update Lease option with any DNS Update that changes RRs that aren't meant to stick around forever. The Update Lease option SHOULD ask for a lease duration no shorter than 1800 seconds (30 minutes) 🕰️. Requesters MAY ask for something shorter if they expect the RRs to change more often than every 30 minutes. Requesters who expect the RRs to be pretty static SHOULD ask for longer leases 🌸.

If the DNS Response a Requester gets back has no Update Lease option, that's the server's way of saying it doesn't support the option 🙈. In that case, the Requester SHOULD keep sending Refresh Requests (see below) as if the server had sent back an identical Update Lease option in its Response.

If the DNS Response does include an Update Lease option, the Requester MUST use the durations from it when deciding when to send Refresh Requests. This is true whether the server gives back shorter durations or longer ones 💅.

When sending a Registration Request, the Requester MUST delay the first transmission by a random amount between 0 and 3000 milliseconds, with a granularity of no more than 10 milliseconds ⏳. This stops a bunch of devices of the same type at one site from syncing up after a power failure. This only applies to that first Registration Request on startup. Refresh Requests also have a random factor, so any syncing that happens later should randomize pretty quickly 🎀.

🧚 The 10 ms granularity is a scheduling rule so Requests spread out instead of all landing an exact number of seconds after startup. It's not supposed to require anything from the link layer the packet goes out on. The link layer might have its own timing rules, and this document doesn't claim to override them.
💖 The 3000 ms (3-second) random delay is a sweet spot: long enough to spread the load when lots of devices renew at once, but not so long that people notice devices taking forever to show up. Say there are 100 devices and the random numbers are evenly spread. That works out to one renewal every 30 ms. Real-world SRP servers on small, constrained devices take around 7 ms to process a registration, so that feels reasonable ✨.

4.3. Server Behavior 👑

Authoritative DNS servers that implement the Update Lease option MUST include an Update Lease option in response to any successful DNS Update (RCODE=0) that includes one. Servers MAY hand back lease durations that are different from what the Requester asked for. They might grant longer leases to cut down on Refresh traffic, or shorter ones to shrink how long stale data hangs around 🦋.

Both the 4-byte and 8-byte variants are valid on requesters and servers. Still, older pre-standard requesters and servers might only support the 4-byte variant 🕰️. So requesters and servers that support both variants (which this spec requires) must account for the possibility that the peer they're talking to is an older implementation that only does 4-byte.

A server that gets an 8-byte variant from a requester MUST respond with an 8-byte variant that gives the granted lease times 💜.

A server that gets 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 too. In this case, the key and the other RRs all expire at the same time 🔑.

A requester that gets a 4-byte variant back from a server, even though it sent an 8-byte variant, MUST treat that 4-byte variant as specifying both the lease duration and the KEY lease duration 🌈.

5. Refresh Requests 🔁

A Refresh Request is a DNS Update Request that gets sent to the server after an initial DNS Update has already gone through. Its whole job is to keep the update's RRs from being garbage collected 🧹✨.

5.1. Refresh Request Format 🎀

Refresh Requests and their responses are formatted like Update Lease Requests and Update Lease Responses (see Section 4). A Refresh Request is built on the assumption that the previous Registration or Refresh is still in effect. If the RRs from an earlier update got garbage collected for some reason (like a server reboot that wiped its state), the Refresh Request will just add those RRs back again 🔄.

The Refresh Request SHOULD NOT include any DNS Update prerequisites that would 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 from the previous Registration or Refresh are gone. In other words, the Refresh Request should also work as a Registration Request 🫠. Sometimes that isn't possible, though. In those cases, the server's response can tell the Requester how to proceed when a Refresh Request fails.

A Lease Update Request that changes the authoritative DNS server state from a previous Refresh or Registration is a Registration Request, not a Refresh Request. Don't mix those two up, bestie 🙅‍♀️.

In a Refresh Request, the Update Lease option holds the desired new lease duration. In the response, the Update Lease option holds the lease that was actually granted. The duration in LEASE applies to every RR in the Update section of the Refresh Request. The exception is when the 8-byte Update Lease variant is sent: then the duration in KEY-LEASE applies to any KEY RRs in the Update section 🔑.

5.2. Requester Behavior 💅

A Requester that wants its RRs from a previous Registration or Refresh to stay active MUST send a Refresh Request before the lease expires. If it doesn't, the server will remove those RRs 😭.

To keep Registrations from expiring, Requesters MUST refresh them 🫶. When a Lease Update Request succeeds, the Requester works out a time limit. That limit is 80% of the lease duration plus a random offset between 0% and 5% of the lease duration. The random offset is there so refreshes don't all sync up 🎲. Once that time limit has passed, the Requester MUST send a Refresh Request if the data from the initial Registration should keep being advertised ⏰.

For Refresh Requests, the server is expected to return an Update Lease option (if it supports the option), just like it does with the initial Registration Request. As with the Registration Request, the Requester MUST use the durations the server returns in the Lease Update Response when deciding when to send the next Refresh Request 📅.

When sending Refresh Requests, the Requester MUST include an Update Lease option, same as it did in the initial Registration Request. That option MAY either ask for the same durations as the initial Registration Request, or use the values the server returned in the previous Lease Update Response, or use other values if they make sense 🌷. As with responses to Registration Requests, the Requester MUST use the lease durations the server returns when deciding when to send the next Refresh Request 🦋.

If the Requester sends a Refresh Request and gets no response from the authoritative DNS server, the Requester should use a reasonable retry strategy to try to refresh the record registrations before they expire 🔁. Since 15% - 20% of the lease lifetime is still left at that point, the retransmissions don't need to be super aggressive 😌. For example, the Requester could retry nine more times, spaced evenly from the time of the first failed Refresh attempt until the records expire. Once the records have expired, the Refresh Request basically turns into a new Registration Request, and any further retransmissions after that follow what's described in Section 6 💜.

5.2.1. Coalescing Refresh Requests 🧶

If the Requester has done multiple Registrations with one server for different RRs, it MAY send a single Refresh Request that contains the RRs from all of those Registrations. This puts all of the Requester's RRs on the same expiration schedule, which cuts down on Refresh traffic 🌈.

When doing this, the Requester includes every RR it has successfully registered on the server, including the ones that aren't close to expiring yet. The catch is that at least one RR being updated in that Refresh Request has to have used up at least 75% of its original lease duration ⏳. If the Requester uses UDP, it MUST NOT coalesce Refresh Requests when doing so would cause the Request to get truncated. In that case, the Requester either sends several Requests or uses TCP to send the whole Refresh Request at once 📦.

Requesters SHOULD NOT send a Refresh Request when every RR in it would still have more than 50% of its lease duration left before expiry 🙅‍♀️. That said, sometimes the Requester really does need to send an early Refresh Request, and it MAY do so. For example, a power-constrained (sleepy) device might need to send a Refresh Request while its radio is already on, so it doesn't have to wake the radio up again later 😴⚡.

Another case where an early Refresh might be needed is when the lease duration registered with the server no longer fits, and the Requester wants to negotiate a different one. In that situation, if the server doesn't honor the requested lease duration in its response, the Requester MUST NOT retry that negotiation 🚫.

5.3. Server Behavior 👑

When the server gets a valid Refresh Request, it MUST send an acknowledgment. That acknowledgment is a Lease Update Response as described in Section 4, and it carries the new lease duration for the Registration being Refreshed 🎉. The server MUST NOT increment a zone's serial number because of a Refresh Request if that operation doesn't change the zone contents 🙌.

The server's state doesn't always match what the Requester expects, though. In that case, a Refresh Request can look like a Registration Request from the server's point of view 🤔. If the Refresh Request does change the zone contents, the server MUST update the zone serial number ✨.

6. Retransmission Strategy 🔁🌸

The DNS protocol, including DNS updates, can run over UDP or TCP. For communication over UDP, reliable transmission has to be guaranteed by retransmitting when a DNS UDP message isn't acknowledged within a reasonable amount of time 💪. Section 4.2.1 of the DNS specification [RFC1035] has some guidance on this, and so does Section 1 of the IETF's guide to common DNS implementation errors [RFC1536]. Section 3.1.3 of the UDP Usage Guidelines [RFC8085] is also really useful, especially for DNS 🫶.

  1. Garbage Collection ✨

Okay so, if an RR's lease duration runs out and nobody has refreshed it, 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 the server handed back to the Requester are what get used to figure out when a lease has expired ⏰.

For all RRs other than a KEY RR that shows up 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, that one wins instead of the LEASE duration 👑. If KEY-LEASE wasn't specified, then the LEASE duration is used for all RRs in the Lease Update Request 💖.

  1. Security Considerations 🔐

Okay, bestie, this part is SERIOUS 😭 but I'm gonna explain it nicely. Section 8 of the DNS Update spec [RFC2136] talks about problems that can pop up around DNS updates, and servers implementing this spec should follow those recommendations 🫶.

Several extra issues can show up when you rely on the Update Lease option 👀.

First, a lease duration that's way too long is basically the same as having no lease at all 💀. The RRs tied to that Registration will effectively never get cleaned up. So servers implementing Update Lease should have a default upper bound on the maximum acceptable value for both the LEASE and KEY-LEASE values the requester sends 🚧. The default limits are 24 hours and 7 days, respectively, and those are RECOMMENDED 💅. Servers MAY give the operator a way to change this upper limit 🔧.

The second issue is that a lease that's too short can make server load spike, because Requesters keep renewing it over and over 📈. And if a renewal is delayed, the registered RRs could get removed too early 😱. So 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 ⏱️. But honestly, in most cases, much longer lease durations (like an hour) SHOULD be used 🍓. Servers MAY give the operator a way to change this lower limit 🛠️.

There can be some cost to renewing leases 💸. A malicious (or buggy) requester could renew at a super high rate to overload the server more than query traffic ever would 😤. This risk is there for an authoritative server handling normal (no-lease) DNS Updates too 🙄. 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 over TCP [SYN] [RFC4953] 🛡️.

Some authentication strategy should be used when accepting DNS updates 🔑. Shared secret [RFC8945] or public key signing (for example, SIG(0) [RFC2931]) should be required 🗝️. Keys should have limited authority, because if one key gets compromised, it should NOT lead to compromise of the entire contents of one or more zones the server manages 😰. (Wait, let me be precise: the original says "should not result in compromise," so the key-scope rule is a SHOULD, and that's how I'm presenting it 💅.) 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 🧚.

  1. IANA Considerations 🌸

IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry [EDNS0Reg] for value 2 like this 📋:

Value:  2
Name:  Update Lease
Status:  Standard
Reference:  RFC 9664
  1. References 📚

10.1. Normative References 💜

10.2. Informative References 🦋

Acknowledgments 🫶

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 👑.

Authors' Addresses 💌

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

📦 where this page comes from