rfc9665v4.txt   rfc9665.txt 
Internet Engineering Task Force (IETF) T. Lemon Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 9665 S. Cheshire Request for Comments: 9665 S. Cheshire
Category: Standards Track Apple Inc. Category: Standards Track Apple Inc.
ISSN: 2070-1721 October 2024 ISSN: 2070-1721 June 2025
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
Abstract Abstract
The Service Registration Protocol (SRP) for DNS-based Service The Service Registration Protocol (SRP) for DNS-based Service
Discovery (DNS-SD) uses the standard DNS Update mechanism to enable Discovery (DNS-SD) uses the standard DNS Update mechanism to enable
DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD using only unicast packets. This makes it possible to deploy
DNS-SD without multicast, which greatly improves scalability and DNS-SD without multicast, which greatly improves scalability and
improves performance on networks where multicast service is not an improves performance on networks where multicast service is not an
skipping to change at line 36 skipping to change at line 36
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9665. https://www.rfc-editor.org/info/rfc9665.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 276 skipping to change at line 276
services. services.
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Strictly speaking, fully qualified domain names end with a period. Strictly speaking, fully qualified domain names end with a dot (".").
In DNS zone files and other similar contexts, if the final period is In DNS zone files and other similar contexts, if the final dot is
omitted, then a name may be treated incorrectly as relative to some omitted, then a name may be treated incorrectly as relative to some
other parent domain. This document follows the formal DNS other parent domain. This document follows the formal DNS
convention, ending fully qualified domain names with a period ("."). convention, ending fully qualified domain names with a dot. When
When this document mentions domain names such as "local." and this document mentions domain names such as "local." and
"default.service.arpa.", the final period is part of the domain name "default.service.arpa.", the final dot is part of the domain name; it
and does not indicate the end of a sentence as it would in normal is not a period indicating the end of the sentence.
prose.
3. Service Registration Protocol 3. Service Registration Protocol
Services that implement SRP use DNS Update [RFC2136] with SIG(0) Services that implement SRP use DNS Update [RFC2136] with SIG(0)
[RFC3007] to publish service information in the DNS. Two variants [RFC3007] to publish service information in the DNS. Two variants
exist: One for full-featured hosts and one for devices designed for exist: One for full-featured hosts and one for devices designed for
Constrained-Node Networks (CNNs) [RFC7228]. An SRP registrar is most Constrained-Node Networks (CNNs) [RFC7228]. An SRP registrar is most
likely an authoritative DNS server or is a source of data for one or likely an authoritative DNS server or is a source of data for one or
more authoritative DNS servers. There is no requirement that the more authoritative DNS servers. There is no requirement that the
authoritative DNS server that is receiving SRP Updates be the same authoritative DNS server that is receiving SRP Updates be the same
 End of changes. 4 change blocks. 
9 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.48.