rfc9664v3.txt   rfc9664.txt 
skipping to change at line 199 skipping to change at line 199
removed. removed.
4.1. Types of Lease Update Requests 4.1. Types of Lease Update Requests
This document describes two types of Lease Update Requests: This document describes two types of Lease Update Requests:
Registrations and Refreshes. A Registration Request is a Lease Registrations and Refreshes. A Registration Request is a Lease
Update Request that is intended to add information not already Update Request that is intended to add information not already
present on the authoritative DNS server. A Refresh Request is present on the authoritative DNS server. A Refresh Request is
intended simply to renew the lease on a previous Registration without intended simply to renew the lease on a previous Registration without
changing anything. Registrations and Refreshes are both Lease Update changing anything. Registrations and Refreshes are both Lease Update
Requests, so the term "Lease Update Request" is to specify behavior Requests, so the term "Lease Update Request" is used to specify
that is the same for both types of DNS Update. behavior that is the same for both types of DNS Updates.
In some cases, it may be necessary to add new information without In some cases, it may be necessary to add new information without
removing old information. For the purpose of this document, such removing old information. For the purpose of this document, such
Lease Update Requests are Registrations, although in effect, they may Lease Update Requests are Registrations, although in effect, they may
also refresh whatever information is unchanged from a previous also refresh whatever information is unchanged from a previous
registration. registration.
4.2. Requester Behavior 4.2. Requester Behavior
DNS Update Requesters MUST send an Update Lease option with any DNS DNS Update Requesters MUST send an Update Lease option with any DNS
skipping to change at line 420 skipping to change at line 420
However, the server's state may not match what the requester expects. However, the server's state may not match what the requester expects.
In this case, a Refresh Request may actually appear to be a In this case, a Refresh Request may actually appear to be a
Registration Request, from the server's perspective. If the Refresh Registration Request, from the server's perspective. If the Refresh
Request changes the contents of the zone, the server MUST update the Request changes the contents of the zone, the server MUST update the
zone serial number. zone serial number.
6. Retransmission Strategy 6. Retransmission Strategy
The DNS protocol, including DNS updates, can operate over UDP or TCP. The DNS protocol, including DNS updates, can operate over UDP or TCP.
When using UDP, reliable transmission must be guaranteed by For communication using UDP, reliable transmission must be guaranteed
retransmitting if a DNS UDP message is not acknowledged in a by retransmitting when a DNS UDP message is not acknowledged in a
reasonable amount of time. Section 4.2.1 of the DNS specification reasonable amount of time. Section 4.2.1 of the DNS specification
[RFC1035] provides some guidance on this topic, as does Section 1 of [RFC1035] provides some guidance on this topic, as does Section 1 of
the IETF's guide to common DNS implementation errors [RFC1536]. the IETF's guide to common DNS implementation errors [RFC1536].
Section 3.1.3 of the UDP Usage Guidelines [RFC8085] also provides Section 3.1.3 of the UDP Usage Guidelines [RFC8085] also provides
useful guidance that is particularly relevant to DNS. useful guidance that is particularly relevant to DNS.
7. Garbage Collection 7. Garbage Collection
If the lease duration of an RR elapses without being refreshed, the If the lease duration of an RR elapses without being refreshed, the
authoritative DNS server MUST NOT return that RR in answers to authoritative DNS server MUST NOT return that RR in answers to
 End of changes. 2 change blocks. 
4 lines changed or deleted 4 lines changed or added

This html diff was produced by rfcdiff 1.48.