wdiff rfc9664.alt-original rfc9664.txt

Internet Engineering Task Force (IETF) S. Cheshire
Internet-Draft Apple Inc.
Intended status: Standards Track
Request for Comments: 9664 T. Lemon
Expires: 8 January 2024
Category: Standards Track Apple Inc
7 July 2023 Inc.
ISSN: 2070-1721 October 2024

An EDNS(0) option Option to negotiate Negotiate Leases on DNS Updates
draft-ietf-dnssd-update-lease-08

Abstract

This document describes an EDNS(0) option that can be used by between
DNS Update requestors Requesters and authoritative DNS servers to include a lease
lifetime (lease duration) in a DNS Update or response, DNS Update Response,
allowing a server to garbage collect stale
resource records Resource Records that have
been added by DNS Updates

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://dnssd-
wg.github.io/draft-ietf-dnssd-update-lease/draft-ietf-dnssd-update-
lease.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/.

Discussion of this document takes place on the DNSSD Working Group
mailing list (mailto:dnssd@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/dnssd/. Subscribe at
https://www.ietf.org/mailman/listinfo/dnssd/.

Source for this draft and an issue tracker can be found at
https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease. if they are not renewed.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 January 2024.
https://www.rfc-editor.org/info/rfc9664.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology Used in this This Document . . . . . . 3
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 Terminology
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Lease Update Message Request and Response Format . . . . . . . . . . . . . . . . . . . . 3
4.1. Types of DNS Lease Update Request messages . . . . . . . . . . 4 Requests
4.2. Requestor Requester Behavior . . . . . . . . . . . . . . . . . . . 5
4.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6
5. Refresh Messages . . . . . . . . . . . . . . . . . . . . . . 6 Requests
5.1. Refresh Message Request Format . . . . . . . . . . . . . . . . . 6
5.2. Requestor Requester Behavior . . . . . . . . . . . . . . . . . . . 7
5.2.1. Coalescing Refresh Messages . . . . . . . . . . . . . 8 Requests
5.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 8
6. Retransmission Strategy . . . . . . . . . . . . . . . . . . . 9
7. Garbage Collection . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References
10.1. Normative References . . . . . . . . . . . . . . . . . . . . 11
12.
10.2. Informative References . . . . . . . . . . . . . . . . . . . 11
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

1. Introduction

Dynamic DNS Update in the Domain Name System (DNS Update) [RFC2136]
allows for a mapping from a persistent hostname to a dynamic an IP address. address that
changes over time. This capability is particularly beneficial to
mobile hosts, whose IP address addresses may frequently change with location.
However, the mobile nature of such hosts often means that dynamically updated resource records Resource
Records (RRs) added using DNS Update are not properly deleted.
Consider, for For
instance, consider a mobile user who publishes address records RRs via dynamic update. DNS
Update. If this user moves their laptop out of range of the Wi-Fi
access point, the address record RR containing stale information may remain
on the authoritative DNS server indefinitely. An Thus, an extension to
Dynamic
DNS Update is thus required to tell the server to automatically delete resource records if they are not refreshed RRs
after a period of
time. time if they are not refreshed.

2. Conventions and Terminology Used in this 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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2.1. Abbreviations

DNS-SD Terminology

DNS-SD: DNS-based service discovery Service Discovery [RFC6763]

EDNS(0)

EDNS(0): Extension Mechanisms for DNS, version 0 DNS [RFC6891]

Update Lease option: Update Lease EDNS(0) option

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

Lease Duration: The time between the start and end of a lease

Lease Update Request: DNS Update Request containing an Update Lease
option

Lease Update Response: DNS Update Response containing an Update
Lease option

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

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 EDNS(0) Update Lease option is included in a standard DNS Update
message Request
[RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].

4. Lease Update Message Request and Response Format

Dynamic DNS

Lease Update Leases Requests and Responses are formatted as standard DNS Dynamic
Update messages [RFC2136]. This update Such messages MUST include the EDNS(0)
OPT RR, as described in RR [RFC6891]. This OPT RR MUST include an EDNS(0) Option as
shown below.

The Update Lease EDNS(0) option is formatted as follows:

Figure |
+---------------+-----------+--------------------------------------+

Table 1

Lease Update Requests contain, in the LEASE field of the OPT RDATA,
an unsigned 32-bit integer indicating the lease lifetime, duration in seconds,
desired by the requestor, 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 requestor. Requester.

There are two variants of the EDNS(0) UPDATE-LEASE option, the basic
(4-byte) Update Lease option: The 4-byte variant
and the extended (8-byte) 8-byte variant.

In the basic (4-byte) 4-byte variant, the LEASE indicated in the Update Lease option
applies to all resource records RRs in the Update section.

In the extended (8-byte) 8-byte variant, the Update Lease communicates two lease lifetimes.
durations. The LEASE indicated in the Update Lease option applies to
all resource records RRs in the Update section *except* _except_ for KEY records. RRs. The KEY-LEASE
indicated in the Update Lease option applies to KEY records RRs in the Update
section.

The reason

More information about how the two variants are used is given in
Section 4.3.

KEY record can be RRs are given a special lease time is that
this record is duration because these RRs are used
in the DNS-SD Service Registration Protocol
[I-D.ietf-dnssd-srp] [RFC9665] to reserve a
name (or names) when the service is not present.

In the case of a KEY record RR and some other record, RR, obviously the KEY
LEASE lease
duration applies to the key, KEY RR, and the LEASE lease duration applies to the
other record. RR. If more than one record RR that is not a KEY record RR is added by the
update,
Lease Update Request, the LEASE lease duration (not the KEY LEASE) lease duration)
is applied to all such records.
Records RRs. RRs that are removed are permanently
removed.

4.1. Types of DNS Lease Update Request messages Requests

This document describes two types of updates: Lease Update Requests:
Registrations and Refreshes. A Registration Request is a DNS 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. Both messages Registrations and Refreshes are DNS both Lease Update messages,
Requests, so the term "DNS "Lease Update message" Request" is to specify behavior
that is the same for both types of DNS Update message. Update.

In some cases cases, it may be necessary to add new information without
removing old information. For the purpose of this document, such
messages
Lease Update Requests are referred to as Registrations, although in effect effect, they may
also refresh whatever information is unchanged from a previous
registration.

4.2. Requestor Requester Behavior

DNS Update requestors Requesters MUST send an Update Lease option with any DNS
Update that is updates RRs that are not intended to be present
indefinitely. The Update Lease option SHOULD specify a time interval lease
duration that is no shorter than 1800 seconds (30 minutes). Requestors
Requesters MAY specify a shorter lease duration if they anticipate
that the records RRs being updated will change sooner more frequently than every 30
minutes. Requestors Requesters that expect the updated records RRs to be relatively
static SHOULD request appropriately longer leases. lease durations.

If the DNS response Response received by the requestor Requester does not include an
Update Lease option, this is an indication that the authoritative DNS
server does not support the Update Lease option. The requestor SHOULD in In this
case case, the
Requester SHOULD continue sending Refresh messages Requests (see below) as if
the server had returned an identical update lease Update Lease option in its response.
Response.

If the DNS response Response does include an Update Lease option, the
requestor
Requester MUST use the interval(s) durations returned in this option when
determining when to send Refresh messages. Requests. This is true both if the
interval(s)
durations returned by the server are shorter and if they are longer.

When sending a Registration, Registration Request, the requestor 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:
startup; since Refreshes Refresh Requests include a random factor as well, any
synchronization that occurs after such an event should quickly
randomize.

Note: the requirement for 10ms

| The 10 ms granularity is a scheduling requirement intended to
| result in an even spread of requests, Requests so that every request 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.

Note: the reason for the 3000ms (three second)

| The use of a 3000 ms (3-second) random interval delay as opposed to some
| other random interval 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 are, for example example, 100 devices, and the random number
| generator spread is even, we would have one renewal every 30ms. 30
| ms. In practice, on relatively constrained devices acting as SRP
| Service Registration Protocol (SRP) servers, we are seeing the
| processing time for an SRP registration taking on the order of
7ms,
| 7 ms, so this seems reasonable.

4.3. Server Behavior

Authoritative DNS Servers 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
different lease interval(s) than durations different from those specified by the requestor,
Requester, granting
relatively longer or shorter leases to reduce network traffic due to
Refreshes,
Refreshes or shorter leases to reduce the lifetime of stale data, respectively.

Note that data.

Although both the 4-byte and 8-byte variant variants are valid on both
clients
requesters and servers, but clients older (pre-standard) requesters and servers
may exist that do not support only the newer 8-byte 4-byte variant. Therefore, clients
requesters and servers that do support (as required by this variant specification)
support both variants must account for the possibility that the server peer
with which they are communicating does not. may be an older implementation that
supports only the 4-byte variant.

A client server that receives a 4-byte an 8-byte variant from a server when it sent requester MUST
respond with an 8-byte variant MUST treat the 4-byte variant as specifying both giving the granted lease time and the key lease time. times.

A server that supports the 8-byte receives a 4-byte variant from a requester MUST treat
the 4-byte variant as specifying both the lease
time duration and the key KEY
lease time. When a server receives a 4-byte
variant, it duration and MUST respond with a 4-byte variant. In this case case,
the key and the other records RRs expire at the same time.

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.

5. Refresh Messages Requests

A Refresh message Request is a DNS Update message Request that is sent to the server
after an initial DNS Update has been sent, sent in order to prevent the
update's records RRs from being garbage collected.

5.1. Refresh Message Request Format

Refresh messages Requests are formatted like Dynamic Update Leases Lease Requests and Update
Lease Responses (see Section 4 "Update Message Format"). 4). The Refresh
message Request is constructed
with the assumption that the result of the previous Registration or Refresh is
still in effect. The Refresh
message will, in In the case that the records RRs added in a previous update
were for some reason garbage collected, collected (e.g., because of a server
reboot that resulted in loss of state), the Refresh Request will
result in those records RRs being added again.

The Refresh message Request SHOULD NOT include any update DNS Update prerequisites
that
would will fail if the requestor's Requester's previous Registration or Refresh is
still in effect. It also SHOULD NOT include prerequisites that would
fail if the records RRs affected by the previous Registration or Refresh are
no longer present--that present; that is, the Refresh Request should also work as a
Registration.
Registration Request. There may be cases where this is not possible, possible;
in which case case, the response from the server can be used to determine
how to proceed when the Refresh Request fails.

An update message

A Lease Update Request that changes the authoritative DNS server
state resulting from a previous Refresh or Registration is a Registration,
Registration Request, not a Refresh. Refresh Request.

The Update Lease option in a Refresh message Request contains the desired new
lease duration for Requests, and the actual granted lease for
Responses. The lease duration provided in LEASE interval indicated in the Update Lease
option applies to all
resource records RRs in the Update section of the Refresh request,
Request, except that if a KEY-LEASE interval when the 8-byte Update Lease variant is included as well, that interval sent,
the duration specified in KEY-LEASE applies to any KEY records RRs included
in the Update section.

5.2. Requestor Requester Behavior

A requestor Requester that intends that for its records RRs from a previous update,
whether a Registration or a Refresh,
Refresh to remain active, active MUST send a Refresh message Request before the lease elapses, or else
expires; otherwise, the records RRs will be removed by the server.

In order to prevent records Registrations expiring, requestors Requesters MUST refresh
resource records before they expire. At the time of registration,
them. When a Lease Update Request succeeds, the client requester computes an interval a
time limit that is 80% of the lease time duration plus a random offset
between 0 0% and 5% of the lease time. duration. The random offset is to
prevent refreshes from being synchronized. When this interval time limit has
expired, the client requester MUST refresh the message send a Refresh Request if the data in the
initial Registration should continue to be advertised.

For Refresh messages, Requests, the server is expected to return an Update
Lease option, if supported, just as with the initial Registration. Registration
Request. As with the Registration, Registration Request, the requestor Requester MUST use
the interval(s)
specified durations returned by the server in the Lease Update Response
when determining when to send the next Refresh message. Request.

When sending Refresh messages, Requests, the requestor Requester MUST include an Update
Lease option, as it did for in the initial Registration. Registration Request. The
Update Lease option MAY either specify the same intervals durations as in the
initial
Registration, Registration Request or MAY use the values returned by the server
in the previous Lease Update Response, whether it was a response to a Registration
a Refresh. Response. As with responses to Registrations,
Registration Requests, the requestor Requester MUST use the intervals lease durations
returned by the server in the response when determining when to send
the next Refresh message. 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.

5.2.1. Coalescing Refresh Messages Requests

If the requestor Requester has performed multiple successful Registrations with a single server,
server for different RRs, the requestor Requester MAY include Refreshes for send a Refresh Request
containing RRs from all such Registrations to that server in a single message.
Refresh Request. This effectively places all records RRs for a requestor Requester on
the same expiration schedule, reducing network traffic due to
Refreshes.

In doing so, the requestor Requester includes in the Refresh message Request all
existing updates to RRs previously successfylly registered on the server,
including those not yet close to expiration, so long as at least one resource record
RR updated in the message Refresh Request has elapsed at least 75% of its
original lease. lease duration. If the requestor Requester uses UDP, the requestor Requester
MUST NOT coalesce Refresh messages Requests if doing so would cause truncation
of the message; Request; in this case, the requestor
should Requester either send sends multiple messages
Requests or should use uses TCP to send the
entire update complete Refresh Request at once.

Requestors

Requesters SHOULD NOT send a Refresh messages Request when all of the records RRs in
the Refresh Request would have more than 50% of their lease interval duration
remaining before expiry. However, there may be cases where the requestor
Requester needs to send an early Refresh, Refresh Request, and it MAY do so.
For example, a power-
constrained power-constrained (sleepy) device may need to send an update a
Refresh Request when the radio is powered so as to avoid having to
power it up later.

Another case where this may be needed is if when the lease interval duration
registered with the server is no longer appropriate and the Requestor Requester
wishes to negotiate a different lease interval. duration. However, in this
case, if the server does not honor the requested interval lease duration in
its response, the requestor Requester MUST NOT retry this negotiation.

5.3. Server Behavior

Upon receiving a valid Refresh Request, the server MUST send an
acknowledgment. This acknowledgment is identical to the a Lease Update Response format as
described in Section 4 "Update Message Format", and contains the new lease duration of the resource records
Registration being Refreshed. The server MUST NOT increment the
serial number of a zone as the result of a Refresh. Refresh Request if the
operation does not result in any change to the zone contents.

However, the server's state may not match what the client requester expects.
In this case, a Refresh Request may actually appear to be a Registration,
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.

6. Retransmission Strategy

The DNS protocol, including DNS updates, can operate over UDP or TCP.
When using UDP, reliable transmission must be guaranteed by
retransmitting if a DNS UDP message is not acknowledged in a
reasonable interval. 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.

7. Garbage Collection

If the Update Lease lease duration of a resource record an RR elapses without being refreshed, the
authoritative DNS server MUST NOT return the expired record that RR in answers to
queries. The server MAY delete the record that RR from its database. The lease interval(s)
durations returned by the server to the requestor Requester are used in
determining when the lease on a resource record an RR has expired.

For all resource records RRs other than a KEY record RR included in a DNS Lease Update request, Request,
the Update Lease lease duration is the LEASE value in the Update Lease option.
For KEY records, RRs, if the optional KEY-LEASE value was included, this interval
duration is used rather than the interval duration specified in the LEASE. If
the KEY-LEASE was not specified, the interval duration specified in the LEASE
is used. used for all RRs in the Lease Update Request.

8. Security Considerations

Section 8 of the DNS Update specification [RFC2136] describes
problems that can occur around DNS updates. Servers implementing
this specification should follow these recommendations.

Several additional issues can arise when relying on the Update Lease
option.

First, a too-long lease time duration is not much different than from no lease time:
duration: the records RRs associated with this lease time 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 client. Servers
MAY provide a way for the operator to change this upper limit. 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.

The second issue is that a too-short lease can result in increased
server load as requestors Requesters rapidly renew the lease. such Registrations. A delay
in renewing could result in the data registered RRs being removed
prematurely. Servers implementing Update Lease MUST have a default
minimum lease interval duration that avoids this issue. We RECOMMEND a A minimum of 30
seconds for both the LEASE and KEY-LEASE intervals. durations is RECOMMENDED.
However, in most cases, much longer lease times durations (for example, an
hour) are RECOMMENDED. SHOULD be used. Servers MAY provide a way for the operator to
change this lower limit.

There may be some cost associated with renewing leases. A malicious
(or buggy) client 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 regular an authoritative server handling normal (no-
lease) DNS update Updates as well. The server MUST enforce a
minimum interval between updates. After a Refresh or Registration
has been successfully processed and acknowledged, another Update Servers should follow established
industry best practices to guard against flooding attacks, both for
malicious flooding of
either type from the client during that interval MUST be silently
ignored by the server. DNS messages over UDP and for similar flooding
attacks using TCP [SYN] [RFC4953].

Some authentication strategy should be used when accepting DNS
updates. Shared secret [RFC8945] or public key signing (e.g. (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. An example of a key
management strategy can be found in [I-D.ietf-dnssd-srp], which Service Registration
Protocol [RFC9665] uses
"first come, first-served naming" DNS Update Leases with "First Come, First
Served Naming" rather than an explicit trust establishment process, process to
confer update permission to a set of
records. RRs.

9. IANA Considerations

The EDNS(0) OPTION CODE 2

IANA has already been assigned for this DNS
extension. This document appears in updated the DNS "DNS EDNS0 Option Codes (OPT)
registry [EDNS0Codes] with the name 'UL' and the status 'On-hold,'
and a document reference to an older version of this document. When
this document has been approved, the IANA is asked to update the (OPT)" registry
[EDNS0Reg] as follows:

OLD:
Value: regards value 2
Name: UL
Status: On-hold
Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt

NEW: as follows:

Value: 2
Name: Update Lease
Status: Standard
Reference: [this document] RFC 9664

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

11. References

10.1. Normative References

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

12.

10.2. Informative References

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

[I-D.ietf-dnssd-srp]

[RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", Work in Progress,
Internet-Draft, draft-ietf-dnssd-srp-20, 29 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
srp-20>.

[EDNS0Codes] RFC 9665,
DOI 10.17487/RFC9665, October 2024,
<https://www.rfc-editor.org/info/rfc9665>.

[EDNS0Reg] IANA, "DNS EDNS0 Option Codes (OPT)", April 2023,
<https://www.iana.org/assignments/dns-parameters/dns-
parameters.xml>.
<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>.

Acknowledgments

Authors' Addresses

Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino, California CA 95014
United States of America
Phone: +1 408 974 3207
Email: cheshire@apple.com

Ted Lemon
Apple Inc Inc.
P.O. Box 958
Brattleboro, Vermont VT 05302
United States of America
Email: mellon@fugue.com