idnits 2.17.1 draft-ietf-dnssd-srp-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 223: '...rvices using SRP MUST use the domain n...' RFC 2119 keyword, line 226: '...e than one domain name, it MUST NOT be...' RFC 2119 keyword, line 306: '...ce Instance Name MUST be referenced by...' RFC 2119 keyword, line 413: '.../private key pair. This key pair MUST...' RFC 2119 keyword, line 415: '..., the SRP client MUST be pre-configure...' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 April 2022) is 726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.cheshire-edns0-owner-option' is defined on line 1235, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSDZ' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Lemon 3 Internet-Draft S. Cheshire 4 Intended status: Standards Track Apple Inc. 5 Expires: 26 October 2022 24 April 2022 7 Service Registration Protocol for DNS-Based Service Discovery 8 draft-ietf-dnssd-srp-13 10 Abstract 12 The Service Registration Protocol for DNS-Based Service Discovery 13 uses the standard DNS Update mechanism to enable DNS-Based Service 14 Discovery using only unicast packets. This makes it possible to 15 deploy DNS Service Discovery without multicast, which greatly 16 improves scalability and improves performance on networks where 17 multicast service is not an optimal choice, particularly 802.11 18 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration 19 uses public keys and SIG(0) to allow services to defend their 20 registrations against attack. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 26 October 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Service Registration Protocol . . . . . . . . . . . . . . . . 5 57 2.1. Protocol Variants . . . . . . . . . . . . . . . . . . . . 5 58 2.1.1. Full-featured Hosts . . . . . . . . . . . . . . . . . 5 59 2.1.2. Constrained Hosts . . . . . . . . . . . . . . . . . . 6 60 2.1.3. Why two variants? . . . . . . . . . . . . . . . . . . 6 61 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 7 62 2.2.1. What to publish . . . . . . . . . . . . . . . . . . . 7 63 2.2.2. Where to publish it . . . . . . . . . . . . . . . . . 7 64 2.2.3. How to publish it . . . . . . . . . . . . . . . . . . 8 65 2.2.3.1. How DNS-SD Service Registration differs from 66 standard RFC2136 DNS Update . . . . . . . . . . . . 8 67 2.2.4. How to secure it . . . . . . . . . . . . . . . . . . 9 68 2.2.4.1. First-Come First-Served Naming . . . . . . . . . 9 69 2.2.5. Service Behavior . . . . . . . . . . . . . . . . . . 9 70 2.2.5.1. Public/Private key pair generation and storage . 9 71 2.2.5.2. Name Conflict Handling . . . . . . . . . . . . . 10 72 2.2.5.3. Record Lifetimes . . . . . . . . . . . . . . . . 10 73 2.2.5.4. Compression in SRV records . . . . . . . . . . . 11 74 2.2.5.5. Removing published services . . . . . . . . . . . 11 75 2.3. Validation and Processing of SRP Updates . . . . . . . . 12 76 2.3.1. Validation of Adds and Deletes . . . . . . . . . . . 12 77 2.3.1.1. Service Discovery Instruction . . . . . . . . . . 13 78 2.3.1.2. Service Description Instruction . . . . . . . . . 13 79 2.3.1.3. Host Description Instruction . . . . . . . . . . 14 80 2.3.2. Valid SRP Update Requirements . . . . . . . . . . . . 14 81 2.3.3. FCFS Name And Signature Validation . . . . . . . . . 15 82 2.3.4. Handling of Service Subtypes . . . . . . . . . . . . 16 83 2.3.5. SRP Update response . . . . . . . . . . . . . . . . . 16 84 2.3.6. Optional Behavior . . . . . . . . . . . . . . . . . . 16 85 3. TTL Consistency . . . . . . . . . . . . . . . . . . . . . . . 17 86 4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.1. Cleaning up stale data . . . . . . . . . . . . . . . . . 18 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 5.1. Source Validation . . . . . . . . . . . . . . . . . . . . 19 90 5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20 91 5.3. Required Signature Algorithm . . . . . . . . . . . . . . 20 92 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 93 7. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 21 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 8.1. Registration and Delegation of 'service.arpa' as a 96 Special-Use Domain Name . . . . . . . . . . . . . . . . . 21 98 8.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 21 99 8.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 22 100 8.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 22 101 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 102 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 103 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 104 12. Informative References . . . . . . . . . . . . . . . . . . . 26 105 Appendix A. Testing using standard RFC2136-compliant servers . . 27 106 Appendix B. How to allow services to update standard 107 RFC2136-compliant servers . . . . . . . . . . . . . . . . 28 108 Appendix C. Sample BIND9 configuration for 109 default.service.arpa. . . . . . . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 112 1. Introduction 114 DNS-Based Service Discovery [RFC6763] is a component of Zero 115 Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. 117 This document describes an enhancement to DNS-Based Service Discovery 118 [RFC6763] that allows services to register their services using the 119 DNS protocol rather than using Multicast DNS [RFC6762] (mDNS). There 120 is already a large installed base of DNS-SD clients that can discover 121 services using the DNS protocol. 123 This document is intended for three audiences: implementors of 124 software that provides services that should be advertised using 125 DNS-SD, implementors of DNS servers that will be used in contexts 126 where DNS-SD registration is needed, and administrators of networks 127 where DNS-SD service is required. The document is intended to 128 provide sufficient information to allow interoperable implementation 129 of the registration protocol. 131 DNS-Based Service Discovery (DNS-SD) allows services to advertise the 132 fact that they provide service, and to provide the information 133 required to access that service. DNS-SD clients can then discover 134 the set of services of a particular type that are available. They 135 can then select a service from among those that are available and 136 obtain the information required to use it. Although DNS-SD using the 137 DNS protocol (as opposed to mDNS) can be more efficient and 138 versatile, it is not common in practice, because of the difficulties 139 associated with updating authoritative DNS services with service 140 information. 142 Existing practice for updating DNS zones is to either manually enter 143 new data, or else use DNS Update [RFC2136]. Unfortunately DNS Update 144 requires either that the authoritative DNS server automatically trust 145 updates, or else that the DNS Update client have some kind of shared 146 secret or public key that is known to the DNS server and can be used 147 to authenticate the update. Furthermore, DNS Update can be a fairly 148 chatty process, requiring multiple round trips with different 149 conditional predicates to complete the update process. 151 The SRP protocol adds a set of default heuristics for processing DNS 152 updates that eliminates the need for DNS update conditional 153 predicates: instead, the SRP server has a set of default predicates 154 that are applied to the update, and the update either succeeds 155 entirely, or fails in a way that allows the registering service to 156 know what went wrong and construct a new update. 158 SRP also adds a feature called First-Come, First-Served Naming, which 159 allows the registering service to claim a name that is not yet in 160 use, and, using SIG(0) [RFC2931], to authenticate both the initial 161 claim and subsequent updates. This prevents name conflicts, since a 162 second SRP service attempting to claim the same name will not possess 163 the SIG(0) key used by the first service to claim it, and so its 164 claim will be rejected and the second service will have to choose a 165 new name. 167 Finally, SRP adds the concept of a 'lease,' similar to leases in 168 Dynamic Host Configuration Protocol [RFC8415]. The SRP registration 169 itself has a lease which may be on the order of an hour; if the 170 registering service does not renew the lease before it has elapsed, 171 the registration is removed. The claim on the name can have a longer 172 lease, so that another service cannot claim the name, even though the 173 registration has expired. 175 The Service Registration Protocol for DNS-SD (SRP), described in this 176 document, provides a reasonably secure mechanism for publishing this 177 information. Once published, these services can be readily 178 discovered by DNS-SD clients using standard DNS lookups. 180 The DNS-SD specification [RFC6763], Section 10 ("Populating the DNS 181 with Information"), briefly discusses ways that services can publish 182 their information in the DNS namespace. In the case of mDNS, it 183 allows services to publish their information on the local link, using 184 names in the ".local" namespace, which makes their services directly 185 discoverable by peers attached to that same local link. 187 RFC6763 also allows clients to discover services using the DNS 188 protocol [RFC1035]. This can be done by having a system 189 administrator manually configure service information in the DNS, but 190 manually populating DNS authoritative server databases is costly and 191 potentially error-prone, and requires a knowledgable network 192 administrator. Consequently, although all DNS-SD client 193 implementations of which we are aware support DNS-SD using DNS 194 queries, in practice it is used much less frequently than mDNS. 196 The Discovery Proxy [RFC8766] provides one way to automatically 197 populate the DNS namespace, but is only appropriate on networks where 198 services are easily advertised using mDNS. This document describes a 199 solution more suitable for networks where multicast is inefficient, 200 or where sleepy devices are common, by supporting both offering of 201 services, and discovery of services, using unicast. 203 2. Service Registration Protocol 205 Services that implement SRP use DNS Update [RFC2136] [RFC3007] to 206 publish service information in the DNS. Two variants exist, one for 207 full-featured hosts, and one for devices designed for "Constrained- 208 Node Networks" [RFC7228]. An SRP server is most likely an 209 authoritative DNS server, or else is updating an authoritative DNS 210 server. There is no requirement that the server that is receiving 211 SRP requests be the same server that is answering queries that return 212 records that have been registered. 214 2.1. Protocol Variants 216 2.1.1. Full-featured Hosts 218 Full-featured hosts are either configured manually with a 219 registration domain, or use the "dr._dns-sd._udp." query 220 ([RFC6763], Section 11) to learn the default registration domain from 221 the network. RFC6763 says to discover the registration domain using 222 either ".local" or a network-supplied domain name for . 223 Services using SRP MUST use the domain name received through the 224 DHCPv4 Domain Name option ([RFC2132], Section 3.17), if available, or 225 the Neighbor Discovery DNS Search List option [RFC8106]. If the DNS 226 Search List option contains more than one domain name, it MUST NOT be 227 used. If neither option is available, the Service Registration 228 protocol is not available on the local network. 230 Manual configuration of the registration domain can be done either by 231 querying the list of available registration zones ("r._dns-sd._udp") 232 and allowing the user to select one from the UI, or by any other 233 means appropriate to the particular use case being addressed. Full- 234 featured devices construct the names of the SRV, TXT, and PTR records 235 describing their service(s) as subdomains of the chosen service 236 registration domain. For these names they then discover the zone 237 apex of the closest enclosing DNS zone using SOA queries [RFC8765]. 238 Having discovered the enclosing DNS zone, they query for the 239 "_dnssd-srp._tcp." SRV record to discover the server to which 240 they should send DNS updates. Hosts that support SRP Updates using 241 TLS use the "_dnssd-srp-tls._tcp." SRV record instead. 243 2.1.2. Constrained Hosts 245 For devices designed for Constrained-Node Networks [RFC7228] some 246 simplifications are available. Instead of being configured with (or 247 discovering) the service registration domain, the (proposed) special- 248 use domain name (see [RFC6761]) "default.service.arpa" is used. The 249 details of how SRP server(s) are discovered will be specific to the 250 constrained network, and therefore we do not suggest a specific 251 mechanism here. 253 SRP clients on constrained networks are expected to receive from the 254 network a list of SRP servers with which to register. It is the 255 responsibility of a Constrained-Node Network supporting SRP to 256 provide one or more SRP server addresses. It is the responsibility 257 of the SRP server supporting a Constrained-Node Network to handle the 258 updates appropriately. In some network environments, updates may be 259 accepted directly into a local "default.service.arpa" zone, which has 260 only local visibility. In other network environments, updates for 261 names ending in "default.service.arpa" may be rewritten internally to 262 names with broader visibility. 264 2.1.3. Why two variants? 266 The reason for these different assumptions is that low-power devices 267 that typically use Constrained-Node Networks may have very limited 268 battery power. The series of DNS lookups required to discover an SRP 269 server and then communicate with it will increase the power required 270 to advertise a service; for low-power devices, the additional 271 flexibility this provides does not justify the additional use of 272 power. It is also fairly typical of such networks that some network 273 service information is obtained as part of the process of joining the 274 network, and so this can be relied upon to provide nodes with the 275 information they need. 277 Networks that are not constrained networks can have more complicated 278 topologies at the Internet layer. Nodes connected to such networks 279 can be assumed to be able to do DNSSD service registration domain 280 discovery. Such networks are generally able to provide registration 281 domain discovery and routing. By requiring the use of TCP, the 282 possibility of off-network spoofing is eliminated. 284 2.2. Protocol Details 286 We will discuss several parts to this process: how to know what to 287 publish, how to know where to publish it (under what name), how to 288 publish it, how to secure its publication, and how to maintain the 289 information once published. 291 2.2.1. What to publish 293 We refer to the DNS Update message sent by services using SRP as an 294 SRP Update. Three types of updates appear in an SRP update: Service 295 Discovery records, Service Description records, and Host Description 296 records. 298 * Service Discovery records are one or more PTR RRs, mapping from 299 the generic service type (or subtype) to the specific Service 300 Instance Name. 301 * Service Description records are exactly one SRV RR, exactly one 302 KEY RR, and one or more TXT RRs, all with the same name, the 303 Service Instance Name ([RFC6763], Section 4.1). In principle 304 Service Description records can include other record types, with 305 the same Service Instance Name, though in practice they rarely do. 306 The Service Instance Name MUST be referenced by one or more 307 Service Discovery PTR records, unless it is a placeholder service 308 registration for an intentionally non-discoverable service name. 309 * The Host Description records for a service are a KEY RR, used to 310 claim exclusive ownership of the service registration, and one or 311 more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of 312 the host where the service resides. 314 [RFC6763] describes the details of what each of these types of 315 updates contains, with the exception of the KEY RR, which is defined 316 in [RFC2539]. These RFCs should be considered the definitive source 317 for information about what to publish; the reason for summarizing 318 this here is to provide the reader with enough information about what 319 will be published that the service registration process can be 320 understood at a high level without first learning the full details of 321 DNS-SD. Also, the "Service Instance Name" is an important aspect of 322 first-come, first-serve naming, which we describe later on in this 323 document. 325 2.2.2. Where to publish it 327 Multicast DNS uses a single namespace, ".local", which is valid on 328 the local link. This convenience is not available for DNS-SD using 329 the DNS protocol: services must exist in some specific unicast 330 namespace. 332 As described above, full-featured devices are responsible for knowing 333 in what domain they should register their services. Devices made for 334 Constrained-Node Networks register in the (proposed) special use 335 domain name [RFC6761] "default.service.arpa", and let the SRP server 336 handle rewriting that to a different domain if necessary. 338 2.2.3. How to publish it 340 It is possible to issue a DNS Update that does several things at 341 once; this means that it's possible to do all the work of adding a 342 PTR resource record to the PTR RRset on the Service Name, and 343 creating or updating the Service Instance Name and Host Description, 344 in a single transaction. 346 An SRP Update takes advantage of this: it is implemented as a single 347 DNS Update message that contains a service's Service Discovery 348 records, Service Description records, and Host Description records. 350 Updates done according to this specification are somewhat different 351 than regular DNS Updates as defined in RFC2136. The RFC2136 update 352 process can involve many update attempts: you might first attempt to 353 add a name if it doesn't exist; if that fails, then in a second 354 message you might update the name if it does exist but matches 355 certain preconditions. Because the registration protocol uses a 356 single transaction, some of this adaptability is lost. 358 In order to allow updates to happen in a single transaction, SRP 359 Updates do not include update prerequisites. The requirements 360 specified in Section 2.3 are implicit in the processing of SRP 361 Updates, and so there is no need for the service sending the SRP 362 Update to put in any explicit prerequisites. 364 2.2.3.1. How DNS-SD Service Registration differs from standard RFC2136 365 DNS Update 367 DNS-SD Service Registration is based on standard RFC2136 DNS Update, 368 with some differences: 370 * It implements first-come first-served name allocation, protected 371 using SIG(0) [RFC2931]. 372 * It enforces policy about what updates are allowed. 373 * It optionally performs rewriting of "default.service.arpa" to some 374 other domain. 375 * It optionally performs automatic population of the address-to-name 376 reverse mapping domains. 377 * An SRP server is not required to implement general DNS Update 378 prerequisite processing. 380 * Constrained-Node SRP clients are allowed to send updates to the 381 generic domain "default.service.arpa" 383 2.2.4. How to secure it 385 Traditional DNS update is secured using the TSIG protocol, which uses 386 a secret key shared between the DNS Update client (which issues the 387 update) and the server (which authenticates it). This model does not 388 work for automatic service registration. 390 The goal of securing the DNS-SD Registration Protocol is to provide 391 the best possible security given the constraint that service 392 registration has to be automatic. It is possible to layer more 393 operational security on top of what we describe here, but what we 394 describe here is an improvement over the security of mDNS. The goal 395 is not to provide the level of security of a network managed by a 396 skilled operator. 398 2.2.4.1. First-Come First-Served Naming 400 First-Come First-Serve naming provides a limited degree of security: 401 a service that registers its service using DNS-SD Registration 402 protocol is given ownership of a name for an extended period of time 403 based on the key used to authenticate the DNS Update. As long as the 404 registration service remembers the name and the key used to register 405 that name, no other service can add or update the information 406 associated with that. FCFS naming is used to protect both the 407 Service Description and the Host Description. 409 2.2.5. Service Behavior 411 2.2.5.1. Public/Private key pair generation and storage 413 The service generates a public/private key pair. This key pair MUST 414 be stored in stable storage; if there is no writable stable storage 415 on the SRP client, the SRP client MUST be pre-configured with a 416 public/private key pair in read-only storage that can be used. This 417 key pair MUST be unique to the device. A device with rewritable 418 storage should retain this key indefinitely. When the device changes 419 ownership, it may be appropriate to erase the old key and install a 420 new one. Therefore, the SRP client on the device SHOULD provide a 421 mechanism to overwrite the key, for example as the result of a 422 "factory reset." 424 When sending DNS updates, the service includes a KEY record 425 containing the public portion of the key in each Host Description 426 Instruction and each Service Description Instruction. Each KEY 427 record MUST contain the same public key. The update is signed using 428 SIG(0), using the private key that corresponds to the public key in 429 the KEY record. The lifetimes of the records in the update is set 430 using the EDNS(0) Update Lease option [I-D.sekar-dns-ul]. 432 The KEY record in Service Description updates MAY be omitted for 433 brevity; if it is omitted, the SRP server MUST behave as if the same 434 KEY record that is given for the Host Description is also given for 435 each Service Description for which no KEY record is provided. 436 Omitted KEY records are not used when computing the SIG(0) signature. 438 2.2.5.2. Name Conflict Handling 440 Both Host Description records and Service Description Records can 441 have names that result in name conflicts. Service Discovery records 442 cannot have name conflicts. If any Host Description or Service 443 Description record is found by the server to have a conflict with an 444 existing name, the server will respond to the SRP Update with a 445 YXDOMAIN rcode. In this case, the Service MUST either abandon the 446 service registration attempt, or else choose a new name. 448 There is no specific requirement for how this is done; typically, 449 however, the service will append a number to the preferred name. 450 This number could be sequentially increasing, or could be chosen 451 randomly. One existing implementation attempts several sequential 452 numbers before choosing randomly. So for instance, it might try 453 host.service.arpa, then host-1.service.arpa, then host- 454 2.service.arpa, then host-31773.service.arpa. 456 2.2.5.3. Record Lifetimes 458 The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records 459 [RFC6763] uses the LEASE field of the Update Lease option, and is 460 typically set to two hours. This means that if a device is 461 disconnected from the network, it does not appear in the user 462 interfaces of devices looking for services of that type for too long. 464 The lifetime of the KEY records is set using the KEY-LEASE field of 465 the Update Lease Option, and should be set to a much longer time, 466 typically 14 days. The result of this is that even though a device 467 may be temporarily unplugged, disappearing from the network for a few 468 days, it makes a claim on its name that lasts much longer. 470 This means that even if a device is unplugged from the network for a 471 few days, and its services are not available for that time, no other 472 device can come along and claim its name the moment it disappears 473 from the network. In the event that a device is unplugged from the 474 network and permanently discarded, then its name is eventually 475 cleaned up and made available for re-use. 477 2.2.5.4. Compression in SRV records 479 Although [RFC2782] requires that the target name in the SRV record 480 not be compressed, an SRP client SHOULD compress the target in the 481 SRV record. The motivation for _not_ compressing in RFC2782 is not 482 stated, but is assumed to be because a caching resolver that does not 483 understand the format of the SRV record might store it as binary data 484 and thus return an invalid pointer in response to a query. This does 485 not apply in the case of SRP: an SRP server needs to understand SRV 486 records in order to validate the SRP Update. Compression of the 487 target potentially saves substantial space in the SRP Update. 489 2.2.5.5. Removing published services 491 2.2.5.5.1. Removing all published services 493 To remove all the services registered to a particular host, the SRP 494 client retransmits its most recent update with an Update Lease option 495 that has a LEASE value of zero. If the registration is to be 496 permanently removed, KEY-LEASE should also be zero. Otherwise, it 497 should have the same value it had previously; this holds the name in 498 reserve for when the SRP client is once again able to provide the 499 service. 501 SRP clients are normally expected to remove all service instances 502 when removing a host. However, in some cases a SRP client may not 503 have retained sufficient state to know that some service instance is 504 pointing to a host that it is removing. This method of removing 505 services is intended for the case where the client is going offline 506 and does not want its services advertised. Therefore, it is 507 sufficient for the client to send the Host Description Instruction 508 (Section 2.3.1.3). 510 To support this, when removing services based on the lease time being 511 zero, an SRP server MUST remove all service instances pointing to a 512 host when a host is removed, even if the SRP client doesn't list them 513 explicitly. If the key lease time is nonzero, the SRP server MUST 514 NOT delete the KEY records for these SRP clients. 516 2.2.5.5.2. Removing some published services 518 In some use cases a client may need to remove some specific service, 519 without removing its other services. This can be accomplished in one 520 of two ways. To simply remove a specific service, the client sends a 521 valid SRP Update where the Service Discovery Instruction 522 (Section 2.3.1.1) contains a single Delete an RR from an RRset 523 ([RFC2136], Section 2.5.4) update that deletes the PTR record whose 524 target is the service instance name. The Service Description 525 Instruction (Section 2.3.1.2) in this case contains a single Delete 526 all RRsets from a Name ([RFC2136], Section 2.5.3) update to the 527 service instance name. 529 The second alternative is used when some service is being replaced by 530 a different service with a different service instance name. In this 531 case, the old service is deleted as in the first alternative. The 532 new service is added, just as it would be in an update that wasn't 533 deleting the old service. Because both the removal of the old 534 service and the add of the new service consist of a valid Service 535 Discovery Instruction and a valid Service Description Instruction, 536 the update as a whole is a valid SRP Update, and will result in the 537 old service being removed and the new one added, or, to put it 538 differently, in the old service being replaced by the new service. 540 It is perhaps worth noting that if a service is being updated without 541 the service instance name changing, that will look very much like the 542 second alternative above. The difference is that because the target 543 for the PTR record in the Service Discovery Instruction is the same 544 for both the Delete An RR From An RRset update and the Add To An 545 RRSet update, these will be seen as a single Service Description 546 Instruction, not as two Instructions. The same would be true of the 547 Service Description Instruction. 549 Whichever of these two alternatives is used, the host lease will be 550 updated with the lease time provided in the SRP update. In neither 551 of these cases is it permissible to delete the host. All services 552 must point to a host. If a host is to be deleted, this must be done 553 using the method described in Section 2.2.5.5.1, which deletes the 554 host and all services that have that host as their target. 556 2.3. Validation and Processing of SRP Updates 558 2.3.1. Validation of Adds and Deletes 560 The SRP server first validates that the DNS Update is a syntactically 561 and semantically valid DNS Update according to the rules specified in 562 RFC2136. 564 SRP Updates consist of a set of _instructions_ that together add or 565 remove one or more services. Each instruction consists of some 566 combination of delete updates and add updates. When an instruction 567 contains a delete and an add, the delete MUST precede the add. 569 The SRP server checks each instruction in the SRP Update to see that 570 it is either a Service Discovery Instruction, a Service Description 571 Instruction, or a Host Description Instruction. Order matters in DNS 572 updates. Specifically, deletes must precede adds for records that 573 the deletes would affect; otherwise the add will have no effect. 574 This is the only ordering constraint; aside from this constraint, 575 updates may appear in whatever order is convenient when constructing 576 the update. 578 Because the SRP Update is a DNS update, it MUST contain a single 579 question that indicates the zone to be updated. Every delete and 580 update in an SRP Update MUST be within the zone that is specified for 581 the SRP Update. 583 2.3.1.1. Service Discovery Instruction 585 An instruction is a Service Discovery Instruction if it contains 587 * exactly one "Add to an RRSet" or exactly one "Delete an RR from an 588 RRSet" ([RFC2136], Section 2.5.1) RR update, 589 * which updates a PTR RR, 590 * the target of which is a Service Instance Name 591 * for which name a Service Description Instruction is present in the 592 SRP Update 593 * if the Service Discovery Instruction is an "Add to an RRSet" 594 instruction, the Service Description Instruction does not match if 595 it does not contain an "Add to an RRset" update for the SRV RR 596 describing that service. 597 * if the Service Discovery Instruction is a "Delete an RR from an 598 RRSet" update, the Service Description Instruction does not match 599 if it contains an "Add to an RRset" update. 600 * Service Discovery Instructions do not contain any other add or 601 delete updates. 603 2.3.1.2. Service Description Instruction 605 An instruction is a Service Description Instruction if, for the 606 appropriate Service Instance Name, it contains 608 * exactly one "Delete all RRsets from a name" update for the service 609 instance name ([RFC2136], Section 2.5.3), 610 * zero or one "Add to an RRset" SRV RR, 611 * zero or one "Add to an RRset" KEY RR that, if present, contains 612 the public key corresponding to the private key that was used to 613 sign the message (if present, the KEY MUST match the KEY RR given 614 in the Host Description), 615 * zero or more "Add to an RRset" TXT RRs, 616 * If there is one "Add to an RRset" SRV update, there MUST be at 617 least one "Add to an RRset" TXT update. 618 * the target of the SRV RR Add, if present points to a hostname for 619 which there is a Host Description Instruction in the SRP Update, 620 or 622 * if there is no "Add to an RRset" SRV RR, then either 623 - the name to which the "Delete all RRsets from a name" applies 624 does not exist, or 626 - there is an existing KEY RR on that name, which matches the key 627 with which the SRP Update was signed. 628 * Service Descriptions Instructions do not modify any other resource 629 records. 631 An SRP server MUST correctly handle compressed names in the SRV 632 target. 634 2.3.1.3. Host Description Instruction 636 An instruction is a Host Description Instruction if, for the 637 appropriate hostname, it contains 639 * exactly one "Delete all RRsets from a name" RR, 640 * one or more "Add to an RRset" RRs of type A and/or AAAA, 641 * A and/or AAAA records must be of sufficient scope to be reachable 642 by all hosts that might query the DNS. If a link-scope address or 643 IPv4 autoconfiguration address is provided by the SRP client, the 644 SRP server MUST treat this as if no address records were received; 645 that is, the Host Description is not valid. 646 * exactly one "Add to an RRset" RR that adds a KEY RR that contains 647 the public key corresponding to the private key that was used to 648 sign the message, 649 * there is a Service Instance Name Instruction in the SRP Update for 650 which the SRV RR that is added points to the hostname being 651 updated by this update. 652 * Host Description Instructions do not modify any other resource 653 records. 655 2.3.2. Valid SRP Update Requirements 657 An SRP Update MUST include zero or more Service Discovery 658 Instructions. For each Service Discovery Instruction, there MUST be 659 at least one Service Description Instruction. Note that in the case 660 of SRP subtypes (Section 7.1 of [RFC6763]), it's quite possible that 661 two Service Discovery Instructions might reference the same Service 662 Description Instruction. For each Service Description Instruction 663 there MUST be at least one Service Discovery Instruction with its 664 service instance name as the target of its PTR record. There MUST be 665 exactly one Host Description Instruction. Every Service Description 666 Instruction must have that Host Description Instruction as the target 667 of its SRV record. A DNS Update that does not meet these constraints 668 is not an SRP Update. 670 A DNS Update that contains any additional adds or deletes that cannot 671 be identified as Service Discovery, Service Description or Host 672 Description Instructions is not an SRP Update. A DNS update that 673 contains any prerequisites is not an SRP Update. Such messages 674 should either be processed as regular RFC2136 updates, including 675 access control checks and constraint checks, if supported, or else 676 rejected with RCODE=REFUSED. 678 In addition, in order for an update to be a valid SRP Update, the 679 target of every Service Discovery Instruction MUST be a Service 680 Description Instruction that is present in the SRP Update. There 681 MUST NOT be any Service Description Instruction to which no Service 682 Discovery Instruction points. The target of the SRV record in every 683 Service Description Instruction MUST be the single Host Description 684 Instruction. 686 If the definitions of each of these instructions are followed 687 carefully and the update requirements are validated correctly, many 688 DNS Updates that look very much like SRP Updates nevertheless will 689 fail to validate. For example, a DNS update that contains an Add to 690 an RRset instruction for a Service Name and an Add to an RRset 691 instruction for a Service Instance Name, where the PTR record added 692 to the Service Name does not reference the Service Instance Name, is 693 not a valid SRP Update message, but may be a valid RFC2136 update. 695 2.3.3. FCFS Name And Signature Validation 697 Assuming that a DNS Update message has been validated with these 698 conditions and is a valid SRP Update, the server checks that the name 699 in the Host Description Instruction exists. If so, then the server 700 checks to see if the KEY record on that name is the same as the KEY 701 record in the Host Description Instruction. The server performs the 702 same check for the KEY records in any Service Description 703 Instructions. For KEY records that were omitted from Service 704 Description Instructions, the KEY from the Host Description 705 Instruction is used. If any existing KEY record corresponding to a 706 KEY record in the SRP Update does not match the KEY record in the SRP 707 Update (whether provided or taken from the Host Description 708 Instruction), then the server MUST reject the SRP Update with the 709 YXDOMAIN RCODE. 711 Otherwise, the server validates the SRP Update using SIG(0) against 712 the public key in the KEY record of the Host Description Instruction. 713 If the validation fails, the server MUST reject the SRP Update with 714 the REFUSED RCODE. Otherwise, the SRP Update is considered valid and 715 authentic, and is processed according to the method described in 716 RFC2136. 718 KEY record updates omitted from Service Description Instruction are 719 processed as if they had been explicitly present: every Service 720 Description that is updated MUST, after the SRP Update has been 721 applied, have a KEY RR, and it must be the same KEY RR that is 722 present in the Host Description to which the Service Description 723 refers. 725 2.3.4. Handling of Service Subtypes 727 SRP servers MUST treat the update instructions for a service type and 728 all its subtypes as atomic. That is, when a service and its subtypes 729 are being updated, whatever information appears in the SRP Update is 730 the entirety of information about that service and its subtypes. If 731 any subtype appeared in a previous update but does not appear in the 732 current update, then the DNS server MUST remove that subtype. 734 Similarly, there is no mechanism for deleting subtypes. A delete of 735 a service deletes all of its subtypes. To delete an individual 736 subtype, an SRP Update must be constructed that contains the service 737 type and all subtypes for that service. 739 2.3.5. SRP Update response 741 The status that is returned depends on the result of processing the 742 update, and can be either SUCCESS or SERVFAIL: all other possible 743 outcomes should already have been accounted for when applying the 744 constraints that qualify the update as an SRP Update. 746 2.3.6. Optional Behavior 748 The server MAY add a Reverse Mapping that corresponds to the Host 749 Description. This is not required because the Reverse Mapping serves 750 no protocol function, but it may be useful for debugging, e.g. in 751 annotating network packet traces or logs. In order for the server to 752 add a reverse mapping update, it must be authoritative for the zone 753 or have credentials to do the update. The SRP client MAY also do a 754 reverse mapping update if it has credentials to do so. 756 The server MAY apply additional criteria when accepting updates. In 757 some networks, it may be possible to do out-of-band registration of 758 keys, and only accept updates from pre-registered keys. In this 759 case, an update for a key that has not been registered should be 760 rejected with the REFUSED RCODE. 762 There are at least two benefits to doing this rather than simply 763 using normal SIG(0) DNS updates. First, the same registration 764 protocol can be used in both cases, so both use cases can be 765 addressed by the same service implementation. Second, the 766 registration protocol includes maintenance functionality not present 767 with normal DNS updates. 769 Note that the semantics of using SRP in this way are different than 770 for typical RFC2136 implementations: the KEY used to sign the SRP 771 Update only allows the SRP client to update records that refer to its 772 Host Description. RFC2136 implementations do not normally provide a 773 way to enforce a constraint of this type. 775 The server may also have a dictionary of names or name patterns that 776 are not permitted. If such a list is used, updates for Service 777 Instance Names that match entries in the dictionary are rejected with 778 YXDOMAIN. 780 3. TTL Consistency 782 All RRs within an RRset are required to have the same TTL 783 (Clarifications to the DNS Specification [RFC2181], Section 5.2). In 784 order to avoid inconsistencies, SRP places restrictions on TTLs sent 785 by services and requires that SRP servers enforce consistency. 787 Services sending SRP Updates MUST use consistent TTLs in all RRs 788 within the SRP Update. 790 SRP servers MUST check that the TTLs for all RRs within the SRP 791 Update are the same. If they are not, the SRP update MUST be 792 rejected with a REFUSED RCODE. 794 Additionally, when adding RRs to an RRset, for example when 795 processing Service Discovery records, the server MUST use the same 796 TTL on all RRs in the RRset. How this consistency is enforced is up 797 to the implementation. 799 TTLs sent in SRP Updates are advisory: they indicate the SRP client's 800 guess as to what a good TTL would be. SRP servers may override these 801 TTLs. SRP servers SHOULD ensure that TTLs are reasonable: neither 802 too long nor too short. The TTL should never be longer than the 803 lease time (Section 4.1). Shorter TTLs will result in more frequent 804 data refreshes; this increases latency on the DNS-SD client side, 805 increases load on any caching resolvers and on the authoritative 806 server, and also increases network load, which may be an issue for 807 constrained networks. Longer TTLs will increase the likelihood that 808 data in caches will be stale. TTL minimums and maximums SHOULD be 809 configurable by the operator of the SRP server. 811 4. Maintenance 813 4.1. Cleaning up stale data 815 Because the DNS-SD registration protocol is automatic, and not 816 managed by humans, some additional bookkeeping is required. When an 817 update is constructed by the SRP client, it MUST include an EDNS(0) 818 Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Option 819 contains two lease times: the Lease Time and the Key Lease Time. 821 These leases are promises, similar to DHCP leases [RFC2131], from the 822 SRP client that it will send a new update for the service 823 registration before the lease time expires. The Lease time is chosen 824 to represent the time after the update during which the registered 825 records other than the KEY record should be assumed to be valid. The 826 Key Lease time represents the time after the update during which the 827 KEY record should be assumed to be valid. 829 The reasoning behind the different lease times is discussed in the 830 section on first-come, first-served naming (Section 2.2.4.1). SRP 831 servers may be configured with limits for these values. A default 832 limit of two hours for the Lease and 14 days for the SIG(0) KEY are 833 currently thought to be good choices. Constrained devices with 834 limited battery that wake infrequently are likely to request longer 835 leases; servers that support such devices may need to set higher 836 limits. SRP clients that are going to continue to use names on which 837 they hold leases should update well before the lease ends, in case 838 the registration service is unavailable or under heavy load. 840 The lease time applies specifically to the host. All service 841 instances, and all service entries for such service instances, depend 842 on the host. When the lease on a host expires, the host and all 843 services that reference it MUST be removed at the same time-it is 844 never valid for a service instance to remain when the host it 845 references has been removed. If the KEY record for the host is to 846 remain, the KEY record for any services that reference it MUST also 847 remain. However, the service PTR record MUST be removed, since it 848 has no key associated with it, and since it is never valid to have a 849 service PTR record for which there is no service instance on the 850 target of the PTR record. 852 SRP Servers SHOULD also track a lease time per service instance. The 853 reason for doing this is that a client may re-register a host with a 854 different set of services, and not remember that some different 855 service instance had previously been registered. In this case, when 856 that service instance lease expires, the SRP server SHOULD remove the 857 service instance (although the KEY record for the service instance 858 SHOULD be retained until the key lease on that service expires). 860 This is beneficial because if the SRP client continues to renew the 861 host, but never mentions the stale service again, the stale service 862 will continue to be advertised. 864 The SRP server MUST include an EDNS(0) Update Lease option in the 865 response if the lease time proposed by the service has been shortened 866 or lengthened. The service MUST check for the EDNS(0) Update Lease 867 option in the response and MUST use the lease times from that option 868 in place of the options that it sent to the server when deciding when 869 to update its registration. The times may be shorter or longer than 870 those specified in the SRP Update; the SRP client must honor them in 871 either case. 873 SRP clients should assume that each lease ends N seconds after the 874 update was first transmitted, where N is the lease duration. Servers 875 should assume that each lease ends N seconds after the update that 876 was successfully processed was received. Because the server will 877 always receive the update after the SRP client sent it, this avoids 878 the possibility of misunderstandings. 880 SRP servers MUST reject updates that do not include an EDNS(0) Update 881 Lease option. Dual-use servers MAY accept updates that don't include 882 leases, but SHOULD differentiate between SRP Updates and other 883 updates, and MUST reject updates that would otherwise be SRP Updates 884 if they do not include leases. 886 Lease times have a completely different function than TTLs. On an 887 authoritative DNS server, the TTL on a resource record is a constant: 888 whenever that RR is served in a DNS response, the TTL value sent in 889 the answer is the same. The lease time is never sent as a TTL; its 890 sole purpose is to determine when the authoritative DNS server will 891 delete stale records. It is not an error to send a DNS response with 892 a TTL of 'n' when the remaining time on the lease is less than 'n'. 894 5. Security Considerations 896 5.1. Source Validation 898 SRP Updates have no authorization semantics other than first-come, 899 first-served. This means that if an attacker from outside of the 900 administrative domain of the server knows the server's IP address, it 901 can in principle send updates to the server that will be processed 902 successfully. Servers should therefore be configured to reject 903 updates from source addresses outside of the administrative domain of 904 the server. 906 For updates sent to an anycast IP address of an SRP server, this 907 validation must be enforced by every router on the path from the 908 Constrained-Device Network to the unconstrained portion of the 909 network. For TCP updates, the initial SYN-SYN+ACK handshake prevents 910 updates being forged by an off-network attacker. In order to ensure 911 that this handshake happens, SRP servers relying on three-way- 912 handshake validation MUST NOT accept TCP Fast Open payloads. If the 913 network infrastructure allows it, an SRP server MAY accept TCP Fast 914 Open payloads if all such packets are validated along the path, and 915 the network is able to reject this type of spoofing at all ingress 916 points. 918 Note that these rules only apply to the validation of SRP Updates. A 919 server that accepts updates from SRP clients may also accept other 920 DNS updates, and those DNS updates may be validated using different 921 rules. However, in the case of a DNS service that accepts SRP 922 updates, the intersection of the SRP Update rules and whatever other 923 update rules are present must be considered very carefully. 925 For example, a normal, authenticated DNS update to any RR that was 926 added using SRP, but that is authenticated using a different key, 927 could be used to override a promise made by the SRP Server to an SRP 928 client, by replacing all or part of the service registration 929 information with information provided by an authenticated DNS update 930 client. An implementation that allows both kinds of updates should 931 not allow DNS Update clients that are using different authentication 932 and authorization credentials to to update records added by SRP 933 clients. 935 5.2. SRP Server Authentication 937 This specification does not provide a mechanism for validating 938 responses from DNS servers to SRP clients. In the case of 939 Constrained Network/Constrained Node clients, such validation isn't 940 practical because there's no way to establish trust. In principle, a 941 KEY RR could be used by a non-constrained SRP client to validate 942 responses from the server, but this is not required, nor do we 943 specify a mechanism for determining which key to use. 945 5.3. Required Signature Algorithm 947 For validation, SRP servers MUST implement the ECDSAP256SHA256 948 signature algorithm. SRP servers SHOULD implement the algorithms 949 specified in [RFC8624], Section 3.1, in the validation column of the 950 table, that are numbered 13 or higher and have a "MUST", 951 "RECOMMENDED", or "MAY" designation in the validation column of the 952 table. SRP clients MUST NOT assume that any algorithm numbered lower 953 than 13 is available for use in validating SIG(0) signatures. 955 6. Privacy Considerations 957 Because DNSSD SRP Updates can be sent off-link, the privacy 958 implications of SRP are different than for multicast DNS responses. 959 Host implementations that are using TCP SHOULD also use TLS if 960 available. Server implementations MUST offer TLS support. The use 961 of TLS with DNS is described in [RFC7858] and [RFC8310]. 963 Hosts that implement TLS support SHOULD NOT fall back to TCP; since 964 servers are required to support TLS, it is entirely up to the host 965 implementation whether to use it. 967 Public keys can be used as identifiers to track hosts. SRP servers 968 MAY elect not to return KEY records for queries for SRP 969 registrations. 971 7. Delegation of 'service.arpa.' 973 In order to be fully functional, the owner of the 'arpa.' zone must 974 add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172]. 975 This delegation should be set up as was done for 'home.arpa', as a 976 result of the specification in Section 7 of [RFC8375]. 978 8. IANA Considerations 980 8.1. Registration and Delegation of 'service.arpa' as a Special-Use 981 Domain Name 983 IANA is requested to record the domain name 'service.arpa.' in the 984 Special-Use Domain Names registry [SUDN]. IANA is requested, with 985 the approval of IAB, to implement the delegation requested in 986 Section 7. 988 IANA is further requested to add a new entry to the "Transport- 989 Independent Locally-Served Zones" subregistry of the the "Locally- 990 Served DNS Zones" registry [LSDZ]. The entry will be for the domain 991 'service.arpa.' with the description "DNS-SD Registration Protocol 992 Special-Use Domain", listing this document as the reference. 994 8.2. 'dnssd-srp' Service Name 996 IANA is also requested to add a new entry to the Service Names and 997 Port Numbers registry for dnssd-srp with a transport type of tcp. No 998 port number is to be assigned. The reference should be to this 999 document, and the Assignee and Contact information should reference 1000 the authors of this document. The Description should be as follows: 1002 Availability of DNS Service Discovery Service Registration Protocol 1003 Service for a given domain is advertised using the 1004 "_dnssd-srp._tcp." SRV record gives the target host and port 1005 where DNSSD Service Registration Service is provided for the named 1006 domain. 1008 8.3. 'dnssd-srp-tls' Service Name 1010 IANA is also requested to add a new entry to the Service Names and 1011 Port Numbers registry for dnssd-srp with a transport type of tcp. No 1012 port number is to be assigned. The reference should be to this 1013 document, and the Assignee and Contact information should reference 1014 the authors of this document. The Description should be as follows: 1016 Availability of DNS Service Discovery Service Registration Protocol 1017 Service for a given domain over TLS is advertised using the 1018 "_dnssd-srp-tls._tcp.." SRV record gives the target host and 1019 port where DNSSD Service Registration Service is provided for the 1020 named domain. 1022 8.4. Anycast Address 1024 IANA is requested to allocate an IPv6 Anycast address from the IPv6 1025 Special-Purpose Address Registry, similar to the Port Control 1026 Protocol anycast address, 2001:1::1. The value TBD should be 1027 replaced with the actual allocation in the table that follows. The 1028 values for the registry are: 1030 +----------------------+-----------------------------+ 1031 | Attribute | value | 1032 +----------------------+-----------------------------+ 1033 | Address Block | 2001:1::TBD/128 | 1034 +----------------------+-----------------------------+ 1035 | Name | DNS-SD Service Registration | 1036 | | Protocol Anycast Address | 1037 +----------------------+-----------------------------+ 1038 | RFC | [this document] | 1039 +----------------------+-----------------------------+ 1040 | Allocation Date | [date of allocation] | 1041 +----------------------+-----------------------------+ 1042 | Termination Date | N/A | 1043 +----------------------+-----------------------------+ 1044 | Source | True | 1045 +----------------------+-----------------------------+ 1046 | Destination | True | 1047 +----------------------+-----------------------------+ 1048 | Forwardable | True | 1049 +----------------------+-----------------------------+ 1050 | Global | True | 1051 +----------------------+-----------------------------+ 1052 | Reserved-by-protocol | False | 1053 +----------------------+-----------------------------+ 1055 Table 1 1057 9. Implementation Status 1059 [Note to the RFC Editor: please remove this section prior to 1060 publication.] 1062 This section records the status of known implementations of the 1063 protocol defined by this specification at the time of posting of this 1064 Internet-Draft, and is based on a proposal described in RFC 7942. 1065 The description of implementations in this section is intended to 1066 assist the IETF in its decision processes in progressing drafts to 1067 RFCs. Please note that the listing of any individual implementation 1068 here does not imply endorsement by the IETF. Furthermore, no effort 1069 has been spent to verify the information presented here that was 1070 supplied by IETF contributors. This is not intended as, and must not 1071 be construed to be, a catalog of available implementations or their 1072 features. Readers are advised to note that other implementations may 1073 exist. 1075 According to RFC 7942, "this will allow reviewers and working groups 1076 to assign due consideration to documents that have the benefit of 1077 running code, which may serve as evidence of valuable experimentation 1078 and feedback that have made the implemented protocols more mature. 1079 It is up to the individual working groups to use this information as 1080 they see fit". 1082 There are two known independent implementations of SRP clients: 1084 * SRP Client for OpenThread: 1085 https://github.com/openthread/openthread/pull/6038 1087 * mDNSResponder open source project: https://github.com/Abhayakara/ 1088 mdnsresponder 1090 There are two related implementations of an SRP server. One acts as 1091 a DNS Update proxy, taking an SRP Update and applying it to the 1092 specified DNS zone using DNS update. The other acts as an 1093 Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in 1094 the mDNSResponder open source project mentioned above. 1096 10. Acknowledgments 1098 Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping 1099 Dong and Abtin Keshavarzian for their thorough technical reviews. 1100 Thanks to Kangping and Abtin as well for testing the document by 1101 doing an independent implementation. Thanks to Tamara Kemper for 1102 doing a nice developmental edit, Tim Wattenberg for doing a SRP 1103 client proof-of-concept implementation at the Montreal Hackathon at 1104 IETF 102, and Tom Pusateri for reviewing during the hackathon and 1105 afterwards. 1107 11. Normative References 1109 [I-D.sekar-dns-ul] 1110 Cheshire, S. and T. Lemon, "An EDNS0 option to negotiate 1111 Leases on DNS Updates", Work in Progress, Internet-Draft, 1112 draft-sekar-dns-ul-03, 27 July 2021, 1113 . 1116 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1117 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1118 . 1120 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1121 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1122 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1123 . 1125 [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the 1126 Domain Name System (DNS)", RFC 2539, DOI 10.17487/RFC2539, 1127 March 1999, . 1129 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1130 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1131 2000, . 1133 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1134 Requirements for the Address and Routing Parameter Area 1135 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1136 September 2001, . 1138 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1139 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1140 . 1142 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1143 and P. Hoffman, "Specification for DNS over Transport 1144 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1145 2016, . 1147 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1148 "IPv6 Router Advertisement Options for DNS Configuration", 1149 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1150 . 1152 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1153 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1154 . 1156 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 1157 Requirements and Usage Guidance for DNSSEC", RFC 8624, 1158 DOI 10.17487/RFC8624, June 2019, 1159 . 1161 [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1162 RFC 8765, DOI 10.17487/RFC8765, June 2020, 1163 . 1165 [SUDN] "Special-Use Domain Names Registry", July 2012, 1166 . 1169 [LSDZ] "Locally-Served DNS Zones Registry", July 2011, 1170 . 1173 12. Informative References 1175 [RFC1035] Mockapetris, P., "Domain names - implementation and 1176 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1177 November 1987, . 1179 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1180 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1181 . 1183 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1184 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1185 . 1187 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1188 specifying the location of services (DNS SRV)", RFC 2782, 1189 DOI 10.17487/RFC2782, February 2000, 1190 . 1192 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1193 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1194 . 1196 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 1197 to Replace the AppleTalk Name Binding Protocol (NBP)", 1198 RFC 6760, DOI 10.17487/RFC6760, February 2013, 1199 . 1201 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 1202 RFC 6761, DOI 10.17487/RFC6761, February 2013, 1203 . 1205 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1206 DOI 10.17487/RFC6762, February 2013, 1207 . 1209 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1210 Constrained-Node Networks", RFC 7228, 1211 DOI 10.17487/RFC7228, May 2014, 1212 . 1214 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1215 for DNS over TLS and DNS over DTLS", RFC 8310, 1216 DOI 10.17487/RFC8310, March 2018, 1217 . 1219 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1220 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1221 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1222 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1223 . 1225 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 1226 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 1227 2020, . 1229 [I-D.cheshire-dnssd-roadmap] 1230 Cheshire, S., "Service Discovery Road Map", Work in 1231 Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 1232 23 October 2018, . 1235 [I-D.cheshire-edns0-owner-option] 1236 Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work 1237 in Progress, Internet-Draft, draft-cheshire-edns0-owner- 1238 option-01, 3 July 2017, 1239 . 1242 [I-D.sctl-advertising-proxy] 1243 Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD 1244 Service Registration Protocol", Work in Progress, 1245 Internet-Draft, draft-sctl-advertising-proxy-02, 12 July 1246 2021, . 1249 [ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration 1250 Networking: The Definitive Guide", O'Reilly Media, Inc. , 1251 ISBN 0-596-10100-7, December 2005. 1253 Appendix A. Testing using standard RFC2136-compliant servers 1255 It may be useful to set up a DNS server for testing that does not 1256 implement SRP. This can be done by configuring the server to listen 1257 on the anycast address, or advertising it in the 1258 _dnssd-srp._tcp. SRV and _dnssd-srp-tls._tcp. record. It 1259 must be configured to be authoritative for "default.service.arpa", 1260 and to accept updates from hosts on local networks for names under 1261 "default.service.arpa" without authentication, since such servers 1262 will not have support for FCFS authentication (Section 2.2.4.1). 1264 A server configured in this way will be able to successfully accept 1265 and process SRP Updates from services that send SRP updates. 1266 However, no prerequisites will be applied, and this means that the 1267 test server will accept internally inconsistent SRP Updates, and will 1268 not stop two SRP Updates, sent by different services, that claim the 1269 same name(s), from overwriting each other. 1271 Since SRP Updates are signed with keys, validation of the SIG(0) 1272 algorithm used by the client can be done by manually installing the 1273 client public key on the DNS server that will be receiving the 1274 updates. The key can then be used to authenticate the client, and 1275 can be used as a requirement for the update. An example 1276 configuration for testing SRP using BIND 9 is given in Appendix C. 1278 Appendix B. How to allow services to update standard RFC2136-compliant 1279 servers 1281 Ordinarily SRP Updates will fail when sent to an RFC 2136-compliant 1282 server that does not implement SRP because the zone being updated is 1283 "default.service.arpa", and no DNS server that is not an SRP server 1284 should normally be configured to be authoritative for 1285 "default.service.arpa". Therefore, a service that sends an SRP 1286 Update can tell that the receiving server does not support SRP, but 1287 does support RFC2136, because the RCODE will either be NOTZONE, 1288 NOTAUTH or REFUSED, or because there is no response to the update 1289 request (when using the anycast address) 1291 In this case a service MAY attempt to register itself using regular 1292 RFC2136 DNS updates. To do so, it must discover the default 1293 registration zone and the DNS server designated to receive updates 1294 for that zone, as described earlier, using the _dns-update._udp SRV 1295 record. It can then make the update using the port and host pointed 1296 to by the SRV record, and should use appropriate prerequisites to 1297 avoid overwriting competing records. Such updates are out of scope 1298 for SRP, and a service that implements SRP MUST first attempt to use 1299 SRP to register itself, and should only attempt to use RFC2136 1300 backwards compatibility if that fails. Although the owner name for 1301 the SRV record specifies the UDP protocol for updates, it is also 1302 possible to use TCP, and TCP should be required to prevent spoofing. 1304 Appendix C. Sample BIND9 configuration for default.service.arpa. 1306 zone "default.service.arpa." { 1307 type master; 1308 file "/etc/bind/master/service.db"; 1309 allow-update { key demo.default.service.arpa.; }; 1310 }; 1312 Figure 1: Zone Configuration in named.conf 1314 $ORIGIN . 1315 $TTL 57600 ; 16 hours 1316 default.service.arpa IN SOA ns3.default.service.arpa. 1317 postmaster.default.service.arpa. ( 1318 2951053287 ; serial 1319 3600 ; refresh (1 hour) 1320 1800 ; retry (30 minutes) 1321 604800 ; expire (1 week) 1322 3600 ; minimum (1 hour) 1323 ) 1324 NS ns3.default.service.arpa. 1325 SRV 0 0 53 ns3.default.service.arpa. 1326 $ORIGIN default.service.arpa. 1327 $TTL 3600 ; 1 hour 1328 _ipps._tcp PTR demo._ipps._tcp 1329 $ORIGIN _ipps._tcp.default.service.arpa. 1330 demo TXT "0" 1331 SRV 0 0 9992 demo.default.service.arpa. 1332 $ORIGIN _udp.default.service.arpa. 1333 $TTL 3600 ; 1 hour 1334 _dns-update PTR ns3.default.service.arpa. 1335 $ORIGIN _tcp.default.service.arpa. 1336 _dnssd-srp PTR ns3.default.service.arpa. 1337 $ORIGIN default.service.arpa. 1338 $TTL 300 ; 5 minutes 1339 ns3 AAAA 2001:db8:0:1::1 1340 $TTL 3600 ; 1 hour 1341 demo AAAA 2001:db8:0:2::1 1342 KEY 513 3 13 ( 1343 qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU 1344 9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg== 1345 ); alg = ECDSAP256SHA256 ; key id = 15008 1346 AAAA ::1 1348 Figure 2: Example Zone file 1350 Authors' Addresses 1352 Ted Lemon 1353 Apple Inc. 1354 One Apple Park Way 1355 Cupertino, California 95014 1356 United States of America 1357 Email: mellon@fugue.com 1358 Stuart Cheshire 1359 Apple Inc. 1360 One Apple Park Way 1361 Cupertino, California 95014 1362 United States of America 1363 Phone: +1 408 974 3207 1364 Email: cheshire@apple.com