| Internet-Draft | SRP Remove All Services Option | October 2025 |
| Michel & Dijk | Expires 23 April 2026 | [Page] |
This document describes a new EDNS(0) option for an SRP Update to remove all previously registered services for a hostname before adding new services for that same hostname. This allows an SRP requester to replace all its previous service registrations with new ones using a single SRP Update.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-michel-srp-remove-all/.¶
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/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents 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 23 April 2026.¶
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) 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.¶
Some constrained devices may not afford storing the services, that they have currently registered to an SRP [SRP] registrar, in persistent memory. Instead, they only store their hostname and their SRP public/private key pair. Upon a reboot, they ensure no stale service registrations remain on the SRP registrar by first sending an SRP Update to remove all their previously registered services per Section 3.2.5.5.1 of [SRP]. Once that is done, they register their current services through another SRP Update. Since removing all services requires the lease time in the Update Lease option to be zero, and adding any service(s) requires the same option to have a nonzero lease value, SRP effectively prevents the removal of all previous services and registering new services for a same hostname in the same Update (Section 3.2.5.5.1 of [SRP]). Therefore, this has to be done using two separate, successive SRP Updates.¶
This document defines a new EDNS(0) [EDNS0] option called SRP Remove All Services allowing to include the previous services removal operation in the same SRP Update that registers the new services. The option also allows an SRP requester to send a single SRP Update that removes all its registered services, while keeping its hostname registered, which is not possible currently with [SRP]. This significantly reduces the amount of data transmitted over the network for doing these operations and reduces the risk of congestion caused by the operation of SRP in constrained networks.¶
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.¶
The SRP Remove All Services Option has a length of zero and therefore has no payload. Its presence in an SRP Update for a particular hostname (as defined in the Host Description Instruction) signals to the registrar to first remove all published services for that hostname before processing the Service Discovery Instructions and Service Description Instructions contained in the Update. It is almost equivalent to first sending an SRP Update as defined by Section 3.2.5.5.1 of [SRP] before sending this Update. The only difference is that when the SRP Remove All Services Option is used, the "Removing All Published Services" operation and the subsequent SRP Update are considered as a single atomic transaction that either entirely succeeds, or fails.¶
An SRP registrar receiving a valid SRP Update containing the SRP Remove All Services Option first removes all service registrations for the hostname in the Host Description Instruction. This includes all SRV/TXT records for all service instance names of which the SRV record has this hostname as a target. It also includes all PTR records that point to these service instance names. Then, it processes the remaining instructions of the SRP Update as defined by [SRP]. In response to an Update containing the SRP Remove All Services Option, the SRP registrar MUST include the option in its SRP Update response to indicate that it is supported. This is done regardless of whether any of the additional operations induced by the option, or the instructions contained in the SRP Update, succeed or fail.¶
If the "Delete All RRsets From A Name" operations induced by the SRP Remove All Services Option results in an error on the SRP registrar, it SHOULD immediately stop processing the SRP Update and MUST return the adequate response code as it would have done when processing a regular "Delete All RRsets From A Name".¶
If all the "Delete All RRsets From A Name" operations implied by the option succeed, but the subsequent SRP Update processing fails, then all the implied "Delete All RRsets From A Name" operations are undone and the adequate error response code for the SRP Update failure is returned as defined by [SRP].¶
The SRP Remove All Services Option relies on existing security mechanisms defined in [SRP]. The SRP requester MUST be properly authenticated for the hostname contained in the Host Description Instruction before the SRP registrar processes the "Delete All RRsets From A Name" operations induced by the option.¶
Since an SRP attacker can replay any SRP Update, it can also replay the "Delete All RRsets From A Name" operations induced by the option.¶
IANA is requested to allocate a new OPT RR option code from the DNS EDNS0 Option Codes (OPT) registry for the 'SRP Remove All Services' Option. The Name shall be 'SRP-RAS'. The value shall be allocated by IANA. The meaning shall be 'SRP Remove All Services'. Reference shall refer to this document, once published. IANA shall determine the registration date.¶
TODO acknowledge.¶