idnits 2.17.1 draft-ietf-dnssd-srp-11.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 411: '.../private key pair. This key pair MUST...' RFC 2119 keyword, line 413: '..., 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 (22 October 2021) is 914 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 1219, 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: 25 April 2022 22 October 2021 7 Service Registration Protocol for DNS-Based Service Discovery 8 draft-ietf-dnssd-srp-11 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 25 April 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified 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. SRP Server Behavior . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20 90 5.2. SRP Server Authentication . . . . . . . . . . . . . . . . 20 91 5.3. Required Signature Algorithm . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . 25 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 RFC 6763 describes the details of what each of these types of updates 315 contains and is the definitive source for information about what to 316 publish; the reason for summarizing this here is to provide the 317 reader with enough information about what will be published that the 318 service registration process can be understood at a high level 319 without first learning the full details of DNS-SD. Also, the 320 "Service Instance Name" is an important aspect of first-come, first- 321 serve naming, which we describe later on in this document. 323 2.2.2. Where to publish it 325 Multicast DNS uses a single namespace, ".local", which is valid on 326 the local link. This convenience is not available for DNS-SD using 327 the DNS protocol: services must exist in some specific unicast 328 namespace. 330 As described above, full-featured devices are responsible for knowing 331 in what domain they should register their services. Devices made for 332 Constrained-Node Networks register in the (proposed) special use 333 domain name [RFC6761] "default.service.arpa", and let the SRP server 334 handle rewriting that to a different domain if necessary. 336 2.2.3. How to publish it 338 It is possible to issue a DNS Update that does several things at 339 once; this means that it's possible to do all the work of adding a 340 PTR resource record to the PTR RRset on the Service Name, and 341 creating or updating the Service Instance Name and Host Description, 342 in a single transaction. 344 An SRP update takes advantage of this: it is implemented as a single 345 DNS Update message that contains a service's Service Discovery 346 records, Service Description records, and Host Description records. 348 Updates done according to this specification are somewhat different 349 than regular DNS Updates as defined in RFC2136. The RFC2136 update 350 process can involve many update attempts: you might first attempt to 351 add a name if it doesn't exist; if that fails, then in a second 352 message you might update the name if it does exist but matches 353 certain preconditions. Because the registration protocol uses a 354 single transaction, some of this adaptability is lost. 356 In order to allow updates to happen in a single transaction, SRP 357 updates do not include update prerequisites. The requirements 358 specified in Section 2.3 are implicit in the processing of SRP 359 updates, and so there is no need for the service sending the SRP 360 update to put in any explicit prerequisites. 362 2.2.3.1. How DNS-SD Service Registration differs from standard RFC2136 363 DNS Update 365 DNS-SD Service Registration is based on standard RFC2136 DNS Update, 366 with some differences: 368 * It implements first-come first-served name allocation, protected 369 using SIG(0) [RFC2931]. 370 * It enforces policy about what updates are allowed. 371 * It optionally performs rewriting of "default.service.arpa" to some 372 other domain. 373 * It optionally performs automatic population of the address-to-name 374 reverse mapping domains. 375 * An SRP server is not required to implement general DNS Update 376 prerequisite processing. 378 * SRP clients are allowed to send updates to the generic domain 379 "default.service.arpa" 381 2.2.4. How to secure it 383 Traditional DNS update is secured using the TSIG protocol, which uses 384 a secret key shared between the DNS Update client (which issues the 385 update) and the server (which authenticates it). This model does not 386 work for automatic service registration. 388 The goal of securing the DNS-SD Registration Protocol is to provide 389 the best possible security given the constraint that service 390 registration has to be automatic. It is possible to layer more 391 operational security on top of what we describe here, but what we 392 describe here is an improvement over the security of mDNS. The goal 393 is not to provide the level of security of a network managed by a 394 skilled operator. 396 2.2.4.1. First-Come First-Served Naming 398 First-Come First-Serve naming provides a limited degree of security: 399 a service that registers its service using DNS-SD Registration 400 protocol is given ownership of a name for an extended period of time 401 based on the key used to authenticate the DNS Update. As long as the 402 registration service remembers the name and the key used to register 403 that name, no other service can add or update the information 404 associated with that. FCFS naming is used to protect both the 405 Service Description and the Host Description. 407 2.2.5. Service Behavior 409 2.2.5.1. Public/Private key pair generation and storage 411 The service generates a public/private key pair. This key pair MUST 412 be stored in stable storage; if there is no writable stable storage 413 on the SRP client, the SRP client MUST be pre-configured with a 414 public/private key pair in read-only storage that can be used. This 415 key pair MUST be unique to the device. This key pair MUST be unique 416 to the device. A device with rewritable storage should retain this 417 key indefinitely. When the device changes ownership, it may be 418 appropriate to erase the old key and install a new one. Therefore, 419 the SRP client on the device SHOULD provide a mechanism to overwrite 420 the key, for example as the result of a "factory reset." 422 When sending DNS updates, the service includes a KEY record 423 containing the public portion of the key in each Host Description 424 update and each Service Description update. Each KEY record MUST 425 contain the same public key. The update is signed using SIG(0), 426 using the private key that corresponds to the public key in the KEY 427 record. The lifetimes of the records in the update is set using the 428 EDNS(0) Update Lease option [I-D.sekar-dns-ul]. 430 The KEY record in Service Description updates MAY be omitted for 431 brevity; if it is omitted, the SRP server MUST behave as if the same 432 KEY record that is given for the Host Description is also given for 433 each Service Description for which no KEY record is provided. 434 Omitted KEY records are not used when computing the SIG(0) signature. 436 2.2.5.2. Name Conflict Handling 438 Both Host Description records and Service Description Records can 439 have names that result in name conflicts. Service Discovery records 440 cannot have name conflicts. If any Host Description or Service 441 Description record is found by the server to have a conflict with an 442 existing name, the server will respond to the SRP Update with a 443 YXDOMAIN rcode. In this case, the Service MUST either abandon the 444 service registration attempt, or else choose a new name. 446 There is no specific requirement for how this is done; typically, 447 however, the service will append a number to the preferred name. 448 This number could be sequentially increasing, or could be chosen 449 randomly. One existing implementation attempts several sequential 450 numbers before choosing randomly. So for instance, it might try 451 host.service.arpa, then host-1.service.arpa, then host- 452 2.service.arpa, then host-31773.service.arpa. 454 2.2.5.3. Record Lifetimes 456 The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records 457 [RFC6763] uses the LEASE field of the Update Lease option, and is 458 typically set to two hours. This means that if a device is 459 disconnected from the network, it does not appear in the user 460 interfaces of devices looking for services of that type for too long. 462 The lifetime of the KEY records is set using the KEY-LEASE field of 463 the Update Lease Option, and should be set to a much longer time, 464 typically 14 days. The result of this is that even though a device 465 may be temporarily unplugged, disappearing from the network for a few 466 days, it makes a claim on its name that lasts much longer. 468 This means that even if a device is unplugged from the network for a 469 few days, and its services are not available for that time, no other 470 device can come along and claim its name the moment it disappears 471 from the network. In the event that a device is unplugged from the 472 network and permanently discarded, then its name is eventually 473 cleaned up and made available for re-use. 475 2.2.5.4. Compression in SRV records 477 Although [RFC2782] requires that the target name in the SRV record 478 not be compressed, an SRP client SHOULD compress the target in the 479 SRV record. The motivation for _not_ compressing in RFC2782 is not 480 stated, but is assumed to be because a caching resolver that does not 481 understand the format of the SRV record might store it as binary data 482 and thus return an invalid pointer in response to a query. This does 483 not apply in the case of SRP: an SRP server needs to understand SRV 484 records in order to validate the SRP update. Compression of the 485 target potentially saves substantial space in the SRP update. 487 2.2.5.5. Removing published services 489 2.2.5.5.1. Removing all published services 491 To remove all the services registered to a particular host, the SRP 492 client retransmits its most recent update with an Update Lease option 493 that has a LEASE value of zero. If the registration is to be 494 permanently removed, KEY-LEASE should also be zero. Otherwise, it 495 should have the same value it had previously; this holds the name in 496 reserve for when the SRP client is once again able to provide the 497 service. 499 SRP clients are normally expected to remove all service instances 500 when removing a host. However, in some cases a SRP client may not 501 have retained sufficient state to know that some service instance is 502 pointing to a host that it is removing. This method of removing 503 services is intended for the case where the client is going offline 504 and does not want its services advertised. Therefore, it is 505 sufficient for the client to send the Host Description Instruction 506 (Section 2.3.1.3). 508 To support this, when removing services based on the lease time being 509 zero, an SRP server MUST remove all service instances pointing to a 510 host when a host is removed, even if the SRP client doesn't list them 511 explicitly. If the key lease time is nonzero, the SRP server MUST 512 NOT delete the KEY records for these SRP clients. 514 2.2.5.5.2. Removing some published services 516 In some use cases a client may need to remove some specific service, 517 without removing its other services. This can be accomplished in one 518 of two ways. To simply remove a specific service, the client sends a 519 valid SRP update where the Service Discovery instruction 520 (Section 2.3.1.1) contains a single Delete an RR from an RRset 521 ([RFC2136], Section 2.5.4) update that deletes the PTR record whose 522 target is the service instance name. The Service Description 523 instruction (Section 2.3.1.2) in this case contains a single Delete 524 all RRsets from a Name ([RFC2136], Section 2.5.3) update to the 525 service instance name. 527 The second alternative is used when some service is being replaced by 528 a different service with a different service instance name. In this 529 case, the old service is deleted as in the first alternative. The 530 new service is added, just as it would be in an update that wasn't 531 deleting the old service. Because both the removal of the old 532 service and the add of the new service consist of a valid Service 533 Discovery instruction and a valid Service Description instruction, 534 the update as a whole is a valid SRP update, and will result in the 535 old service being removed and the new one added, or, to put it 536 differently, in the old service being replaced by the new service. 538 It is perhaps worth noting that if a service is being updated without 539 the service instance name changing, that will look very much like the 540 second alternative above. The difference is that because the target 541 for the PTR record in the Service Discovery instruction is the same 542 for both the Delete An RR From An RRset update and the Add To An 543 RRSet update, these will be seen as a single Service Description 544 instruction, not as two instructions. The same would be true of the 545 Service Description instruction. 547 Whichever of these two alternatives is used, the host lease will be 548 updated with the lease time provided in the SRP update. In neither 549 of these cases is it permissible to delete the host. All services 550 must point to a host. If a host is to be deleted, this must be done 551 using the method described in Section 2.2.5.5.1, which deletes the 552 host and all services that have that host as their target. 554 2.3. SRP Server Behavior 556 2.3.1. Validation of Adds and Deletes 558 The SRP server first validates that the DNS Update is a syntactically 559 and semantically valid DNS Update according to the rules specified in 560 RFC2136. 562 SRP Updates consist of a set of _instructions_ that together add or 563 remove one or more services. Each instruction consists some 564 combination of delete updates and add updates. When an instruction 565 contains a delete and an add, the delete MUST precede the add. 567 The SRP server checks each instruction in the SRP update to see that 568 it is either a Service Discovery update, a Service Description 569 update, or a Host Description update. Order matters in DNS updates. 570 Specifically, deletes must precede adds for records that the deletes 571 would affect; otherwise the add will have no effect. This is the 572 only ordering constraint; aside from this constraint, updates may 573 appear in whatever order is convenient when constructing the update. 575 Because the SRP update is a DNS update, it MUST contain a single 576 question that indicates the zone to be updated. Every delete and 577 update in an SRP update MUST be within the zone that is specified for 578 the SRP Update. 580 2.3.1.1. Service Discovery Instruction 582 An instruction is a Service Discovery Instruction if it contains 584 * exactly one "Add to an RRSet" or exactly one "Delete an RR from an 585 RRSet" ([RFC2136], Section 2.5.1) RR update, 586 * which updates a PTR RR, 587 * the target of which is a Service Instance Name 588 * for which name a Service Description Instruction is present in the 589 SRP Update 590 * if the Service Discovery Instruction is an "Add to an RRSet" 591 instruction, the Service Description Instruction does not match if 592 it does not contain an "Add to an RRset" update for the SRV RR 593 describing that service. 594 * if the Service Discovery Instruction is a "Delete an RR from an 595 RRSet" update, the Service Description Instruction does not match 596 if it contains an "Add to an RRset" update. 597 * Service Discovery Instructions do not contain any other add or 598 delete updates. 600 2.3.1.2. Service Description Instruction 602 An instruction is a Service Description Instruction if, for the 603 appropriate Service Instance Name, it contains 605 * exactly one "Delete all RRsets from a name" update for the service 606 instance name ([RFC2136], Section 2.5.3), 607 * zero or one "Add to an RRset" SRV RR, 608 * zero or one "Add to an RRset" KEY RR that, if present, contains 609 the public key corresponding to the private key that was used to 610 sign the message (if present, the KEY MUST match the KEY RR given 611 in the Host Description), 612 * zero or more "Add to an RRset" TXT RRs, 613 * If there is one "Add to an RRset" SRV update, there MUST be at 614 least one "Add to an RRset" TXT update. 615 * the target of the SRV RR Add, if present points to a hostname for 616 which there is a Host Description Instruction in the SRP Update, 617 or 618 * if there is no "Add to an RRset" SRV RR, then either 619 - the name to which the "Delete all RRsets from a name" applies 620 does not exist, or 622 - there is an existing KEY RR on that name, which matches the key 623 with which the SRP Update was signed. 624 * Service Descriptions Instructions do not modify any other RRs. 626 An SRP server MUST correctly handle compressed names in the SRV 627 target. 629 2.3.1.3. Host Description Instruction 631 An instruction is a Host Description Instruction if, for the 632 appropriate hostname, it contains 634 * exactly one "Delete all RRsets from a name" RR, 635 * one or more "Add to an RRset" RRs of type A and/or AAAA, 636 * A and/or AAAA records must be of sufficient scope to be reachable 637 by all hosts that might query the DNS. If a link-scope address or 638 IPv4 autoconfiguration address is provided by the SRP client, the 639 SRP server MUST treat this as if no address records were received; 640 that is, the Host Description is not valid. 641 * exactly one "Add to an RRset" RR that adds a KEY RR that contains 642 the public key corresponding to the private key that was used to 643 sign the message, 644 * there is a Service Instance Name Instruction in the SRP update for 645 which the SRV RR that is added points to the hostname being 646 updated by this update. 647 * Host Description updates do not modify any other records. 649 2.3.2. Valid SRP Update Requirements 651 An SRP Update MUST include zero or more Service Discovery 652 instructions. For each Service Discovery instruction, there MUST be 653 at least one Service Description instruction. Note that in the case 654 of SRP subtypes (Section 7.1 of [RFC6763]), it's quite possible that 655 two Service Discovery instructions might reference the same Service 656 Description instruction. For each Service Description instruction 657 there MUST be at least one Service Discovery instruction with its 658 service instance name as the target of its PTR record. There MUST be 659 exactly one Host Description Instruction. Every Service Description 660 instruction must have that Host Description instruction as the target 661 of its SRV record. A DNS Update that does not meet these constraints 662 is not an SRP update. 664 A DNS Update that contains any additional adds or deletes that cannot 665 be identified as Service Discovery, Service Description or Host 666 Description instructions is not an SRP update. A DNS update that 667 contains any prerequisites is not an SRP update. Such messages 668 should either be processed as regular RFC2136 updates, including 669 access control checks and constraint checks, if supported, or else 670 rejected with RCODE=REFUSED. 672 In addition, in order for an update to be a valid SRP update, the 673 target of every Service Discovery Instruction MUST be a Service 674 Description Instruction that is present in the SRP Update. There 675 MUST NOT be any Service Description Instruction to which no Service 676 Discovery Instruction points. The target of the SRV record in every 677 Service Description instruction MUST be the single Host Description 678 Instruction. 680 If the definitions of each of these instructions are followed 681 carefully and the update requirements are validated correctly, many 682 DNS Updates that look very much like SRP updates nevertheless will 683 fail to validate. For example, a DNS update that contains an RRset 684 Add to a Service Name and an RRset Add to a Service Instance Name, 685 where the Service Name does not reference the Service Instance Name, 686 is not a valid SRP update message, but may be a valid RFC2136 update. 688 2.3.3. FCFS Name And Signature Validation 690 Assuming that a DNS Update message has been validated with these 691 conditions and is a valid SRP Update, the server checks that the name 692 in the Host Description Instruction exists. If so, then the server 693 checks to see if the KEY record on that name is the same as the KEY 694 record in the Host Description Instruction. The server performs the 695 same check for the KEY records in any Service Description 696 Instructions. For KEY records that were omitted from Service 697 Description Instructions, the KEY from the Host Description 698 Instruction is used. If any existing KEY record corresponding to a 699 KEY record in the SRP Update does not match the KEY same record in 700 the SRP Update (whether provided or taken from the Host Description 701 Instruction), then the server MUST reject the SRP Update with the 702 YXDOMAIN RCODE. 704 Otherwise, the server validates the SRP Update using SIG(0) on the 705 public key in the KEY record of the Host Description update. If the 706 validation fails, the server MUST reject the SRP Update with the 707 REFUSED RCODE. Otherwise, the SRP update is considered valid and 708 authentic, and is processed according to the method described in 709 RFC2136. 711 KEY record updates omitted from Service Description update are 712 processed as if they had been explicitly present: every Service 713 Description that is updated MUST, after the update, have a KEY RR, 714 and it must be the same KEY RR that is present in the Host 715 Description to which the Service Description refers. 717 2.3.4. Handling of Service Subtypes 719 SRP servers MUST treat the update instructions for a service type and 720 all its subtypes as atomic. That is, when a service and its subtypes 721 are being updated, whatever information appears in the SRP update is 722 the entirety of information about that service and its subtypes. If 723 any subtype appeared in a previous update but does not appear in the 724 current update, then the DNS server MUST remove that subtype. 726 Similarly, there is no mechanism for deleting subtypes. A delete of 727 a service deletes all of its subtypes. To delete an individual 728 subtype, an SRP update must be constructed that contains the service 729 type and all subtypes for that service. 731 2.3.5. SRP Update response 733 The status that is returned depends on the result of processing the 734 update, and can be either SUCCESS or SERVFAIL: all other possible 735 outcomes should already have been accounted for when applying the 736 constraints that qualify the update as an SRP Update. 738 2.3.6. Optional Behavior 740 The server MAY add a Reverse Mapping that corresponds to the Host 741 Description. This is not required because the Reverse Mapping serves 742 no protocol function, but it may be useful for debugging, e.g. in 743 annotating network packet traces or logs. In order for the server to 744 add a reverse mapping update, it must be authoritative for the zone 745 or have credentials to do the update. The SRP client MAY also do a 746 reverse mapping update if it has credentials to do so. 748 The server MAY apply additional criteria when accepting updates. In 749 some networks, it may be possible to do out-of-band registration of 750 keys, and only accept updates from pre-registered keys. In this 751 case, an update for a key that has not been registered should be 752 rejected with the REFUSED RCODE. 754 There are at least two benefits to doing this rather than simply 755 using normal SIG(0) DNS updates. First, the same registration 756 protocol can be used in both cases, so both use cases can be 757 addressed by the same service implementation. Second, the 758 registration protocol includes maintenance functionality not present 759 with normal DNS updates. 761 Note that the semantics of using SRP in this way are different than 762 for typical RFC2136 implementations: the KEY used to sign the SRP 763 update only allows the SRP client to update records that refer to its 764 Host Description. RFC2136 implementations do not normally provide a 765 way to enforce a constraint of this type. 767 The server may also have a dictionary of names or name patterns that 768 are not permitted. If such a list is used, updates for Service 769 Instance Names that match entries in the dictionary are rejected with 770 YXDOMAIN. 772 3. TTL Consistency 774 All RRs within an RRset are required to have the same TTL 775 (Clarifications to the DNS Specification [RFC2181], Section 5.2). In 776 order to avoid inconsistencies, SRP places restrictions on TTLs sent 777 by services and requires that SRP servers enforce consistency. 779 Services sending SRP updates MUST use consistent TTLs in all RRs 780 within the SRP update. 782 SRP update servers MUST check that the TTLs for all RRs within the 783 SRP update are the same. If they are not, the SRP update MUST be 784 rejected with a REFUSED RCODE. 786 Additionally, when adding RRs to an RRset, for example when 787 processing Service Discovery records, the server MUST use the same 788 TTL on all RRs in the RRset. How this consistency is enforced is up 789 to the implementation. 791 TTLs sent in SRP updates are advisory: they indicate the SRP client's 792 guess as to what a good TTL would be. SRP servers may override these 793 TTLs. SRP servers SHOULD ensure that TTLs are reasonable: neither 794 too long nor too short. The TTL should never be longer than the 795 lease time (Section 4.1). Shorter TTLs will result in more frequent 796 data refreshes; this increases latency on the DNS-SD client side, 797 increases load on any caching resolvers and on the authoritative 798 server, and also increases network load, which may be an issue for 799 constrained networks. Longer TTLs will increase the likelihood that 800 data in caches will be stale. TTL minimums and maximums SHOULD be 801 configurable by the operator of the SRP server. 803 4. Maintenance 805 4.1. Cleaning up stale data 807 Because the DNS-SD registration protocol is automatic, and not 808 managed by humans, some additional bookkeeping is required. When an 809 update is constructed by the SRP client, it MUST include an EDNS(0) 810 Update Lease Option [I-D.sekar-dns-ul]. The Update Lease Option 811 contains two lease times: the Lease Time and the Key Lease Time. 813 These leases are promises, similar to DHCP leases [RFC2131], from the 814 SRP client that it will send a new update for the service 815 registration before the lease time expires. The Lease time is chosen 816 to represent the time after the update during which the registered 817 records other than the KEY record should be assumed to be valid. The 818 Key Lease time represents the time after the update during which the 819 KEY record should be assumed to be valid. 821 The reasoning behind the different lease times is discussed in the 822 section on first-come, first-served naming (Section 2.2.4.1). SRP 823 servers may be configured with limits for these values. A default 824 limit of two hours for the Lease and 14 days for the SIG(0) KEY are 825 currently thought to be good choices. Constrained devices with 826 limited battery that wake infrequently are likely to negotiate longer 827 leases. SRP clients that are going to continue to use names on which 828 they hold leases should update well before the lease ends, in case 829 the registration service is unavailable or under heavy load. 831 The lease time applies specifically to the host. All service 832 instances, and all service entries for such service instances, depend 833 on the host. When the lease on a host expires, the host and all 834 services that reference it MUST be removed at the same time-it is 835 never valid for a service instance to remain when the host it 836 references has been removed. If the KEY record for the host is to 837 remain, the KEY record for any services that reference it MUST also 838 remain. However, the service PTR record MUST be removed, since it 839 has no key associated with it, and since it is never valid to have a 840 service PTR record for which there is no service instance on the 841 target of the PTR record. 843 SRP Servers SHOULD also track a lease time per service instance. The 844 reason for doing this is that a client may re-register a host with a 845 different set of services, and not remember that some different 846 service instance had previously been registered. In this case, when 847 that service instance lease expires, the SRP server SHOULD remove the 848 service instance (although the KEY record for the service instance 849 SHOULD be retained until the key lease on that service expires). 850 This is beneficial because if the SRP client continues to renew the 851 host, but never mentions the stale service again, the stale service 852 will continue to be advertised. 854 The SRP server MUST include an EDNS(0) Update Lease option in the 855 response if the lease time proposed by the service has been shortened 856 or lengthened. The service MUST check for the EDNS(0) Update Lease 857 option in the response and MUST use the lease times from that option 858 in place of the options that it sent to the server when deciding when 859 to update its registration. The times may be shorter or longer than 860 those specified in the SRP update; the SRP client must honor them in 861 either case. 863 SRP clients should assume that each lease ends N seconds after the 864 update was first transmitted, where N is the lease duration. Servers 865 should assume that each lease ends N seconds after the update that 866 was successfully processed was received. Because the server will 867 always receive the update after the SRP client sent it, this avoids 868 the possibility of misunderstandings. 870 SRP servers MUST reject updates that do not include an EDNS(0) Update 871 Lease option. Dual-use servers MAY accept updates that don't include 872 leases, but SHOULD differentiate between SRP updates and other 873 updates, and MUST reject updates that would otherwise be SRP updates 874 if they do not include leases. 876 Lease times have a completely different function than TTLs. On an 877 authoritative DNS server, the TTL on a resource record is a constant: 878 whenever that RR is served in a DNS response, the TTL value sent in 879 the answer is the same. The lease time is never sent as a TTL; its 880 sole purpose is to determine when the authoritative DNS server will 881 delete stale records. It is not an error to send a DNS response with 882 a TTL of 'n' when the remaining time on the lease is less than 'n'. 884 5. Security Considerations 885 5.1. Source Validation 887 SRP updates have no authorization semantics other than first-come, 888 first-served. This means that if an attacker from outside of the 889 administrative domain of the server knows the server's IP address, it 890 can in principle send updates to the server that will be processed 891 successfully. Servers should therefore be configured to reject 892 updates from source addresses outside of the administrative domain of 893 the server. 895 For updates sent to an anycast IP address of an SRP server, this 896 validation must be enforced by every router on the path from the 897 Constrained-Device Network to the unconstrained portion of the 898 network. For TCP updates, the initial SYN-SYN+ACK handshake prevents 899 updates being forged by an off-network attacker. In order to ensure 900 that this handshake happens, Service Discovery Protocol servers 901 relying on three-way-handshake validation MUST NOT accept TCP Fast 902 Open payloads. If the network infrastructure allows it, an SRP 903 server MAY accept TCP Fast Open payloads if all such packets are 904 validated along the path, and the network is able to reject this type 905 of spoofing at all ingress points. 907 Note that these rules only apply to the validation of SRP updates. A 908 server that accepts updates from SRP clients may also accept other 909 DNS updates, and those DNS updates may be validated using different 910 rules. However, in the case of a DNS service that accepts SRP 911 updates, the intersection of the SRP update rules and whatever other 912 update rules are present must be considered very carefully. 914 For example, a normal, authenticated DNS update to any RR that was 915 added using SRP, but that is authenticated using a different key, 916 could be used to override a promise made by the registration 917 protocol, by replacing all or part of the service registration 918 information with information provided by an SRP client. An 919 implementation that allows both kinds of updates should not allow DNS 920 Update clients that are using different authentication and 921 authorization credentialsto to update records added by SRP clients. 923 5.2. SRP Server Authentication 925 This specification does not provide a mechanism for validating 926 responses from DNS servers to SRP clients. In the case of 927 Constrained Network/Constrained Node clients, such validation isn't 928 practical because there's no way to establish trust. In principle, a 929 KEY RR could be used by a non-constrained SRP client to validate 930 responses from the server, but this is not required, nor do we 931 specify a mechanism for determining which key to use. 933 5.3. Required Signature Algorithm 935 For validation, SRP servers MUST implement the ECDSAP256SHA256 936 signature algorithm. SRP servers SHOULD implement the algorithms 937 specified in [RFC8624], Section 3.1, in the validation column of the 938 table, that are numbered 13 or higher and have a "MUST", 939 "RECOMMENDED", or "MAY" designation in the validation column of the 940 table. SRP clients MUST NOT assume that any algorithm numbered lower 941 than 13 is available for use in validating SIG(0) signatures. 943 6. Privacy Considerations 945 Because DNSSD SRP updates can be sent off-link, the privacy 946 implications of SRP are different than for multicast DNS responses. 947 Host implementations that are using TCP SHOULD also use TLS if 948 available. Server implementations MUST offer TLS support. The use 949 of TLS with DNS is described in [RFC7858] and [RFC8310]. 951 Hosts that implement TLS support SHOULD NOT fall back to TCP; since 952 servers are required to support TLS, it is entirely up to the host 953 implementation whether to use it. 955 Public keys can be used as identifiers to track hosts. SRP servers 956 MAY elect not to return KEY records for queries for SRP 957 registrations. 959 7. Delegation of 'service.arpa.' 961 In order to be fully functional, the owner of the 'arpa.' zone must 962 add a delegation of 'service.arpa.' in the '.arpa.' zone [RFC3172]. 963 This delegation should be set up as was done for 'home.arpa', as a 964 result of the specification in Section 7 of [RFC8375]. 966 8. IANA Considerations 968 8.1. Registration and Delegation of 'service.arpa' as a Special-Use 969 Domain Name 971 IANA is requested to record the domain name 'service.arpa.' in the 972 Special-Use Domain Names registry [SUDN]. IANA is requested, with 973 the approval of IAB, to implement the delegation requested in 974 Section 7. 976 IANA is further requested to add a new entry to the "Transport- 977 Independent Locally-Served Zones" subregistry of the the "Locally- 978 Served DNS Zones" registry [LSDZ]. The entry will be for the domain 979 'service.arpa.' with the description "DNS-SD Registration Protocol 980 Special-Use Domain", listing this document as the reference. 982 8.2. 'dnssd-srp' Service Name 984 IANA is also requested to add a new entry to the Service Names and 985 Port Numbers registry for dnssd-srp with a transport type of tcp. No 986 port number is to be assigned. The reference should be to this 987 document, and the Assignee and Contact information should reference 988 the authors of this document. The Description should be as follows: 990 Availability of DNS Service Discovery Service Registration Protocol 991 Service for a given domain is advertised using the 992 "_dnssd-srp._tcp.." SRV record gives the target host and 993 port where DNSSD Service Registration Service is provided for the 994 named domain. 996 8.3. 'dnssd-srp-tls' Service Name 998 IANA is also requested to add a new entry to the Service Names and 999 Port Numbers registry for dnssd-srp with a transport type of tcp. No 1000 port number is to be assigned. The reference should be to this 1001 document, and the Assignee and Contact information should reference 1002 the authors of this document. The Description should be as follows: 1004 Availability of DNS Service Discovery Service Registration Protocol 1005 Service for a given domain over TLS is advertised using the 1006 "_dnssd-srp-tls._tcp.." SRV record gives the target host and 1007 port where DNSSD Service Registration Service is provided for the 1008 named domain. 1010 8.4. Anycast Address 1012 IANA is requested to allocate an IPv6 Anycast address from the IPv6 1013 Special-Purpose Address Registry, similar to the Port Control 1014 Protocol anycast address, 2001:1::1. The value TBD should be 1015 replaced with the actual allocation in the table that follows. The 1016 values for the registry are: 1018 +----------------------+-----------------------------+ 1019 | Attribute | value | 1020 +----------------------+-----------------------------+ 1021 | Address Block | 2001:1::TBD/128 | 1022 +----------------------+-----------------------------+ 1023 | Name | DNS-SD Service Registration | 1024 | | Protocol Anycast Address | 1025 +----------------------+-----------------------------+ 1026 | RFC | [this document] | 1027 +----------------------+-----------------------------+ 1028 | Allocation Date | [date of allocation] | 1029 +----------------------+-----------------------------+ 1030 | Termination Date | N/A | 1031 +----------------------+-----------------------------+ 1032 | Source | True | 1033 +----------------------+-----------------------------+ 1034 | Destination | True | 1035 +----------------------+-----------------------------+ 1036 | Forwardable | True | 1037 +----------------------+-----------------------------+ 1038 | Global | True | 1039 +----------------------+-----------------------------+ 1040 | Reserved-by-protocol | False | 1041 +----------------------+-----------------------------+ 1043 Table 1 1045 9. Implementation Status 1047 [Note to the RFC Editor: please remove this section prior to 1048 publication.] 1050 This section records the status of known implementations of the 1051 protocol defined by this specification at the time of posting of this 1052 Internet-Draft, and is based on a proposal described in RFC 7942. 1053 The description of implementations in this section is intended to 1054 assist the IETF in its decision processes in progressing drafts to 1055 RFCs. Please note that the listing of any individual implementation 1056 here does not imply endorsement by the IETF. Furthermore, no effort 1057 has been spent to verify the information presented here that was 1058 supplied by IETF contributors. This is not intended as, and must not 1059 be construed to be, a catalog of available implementations or their 1060 features. Readers are advised to note that other implementations may 1061 exist. 1063 According to RFC 7942, "this will allow reviewers and working groups 1064 to assign due consideration to documents that have the benefit of 1065 running code, which may serve as evidence of valuable experimentation 1066 and feedback that have made the implemented protocols more mature. 1067 It is up to the individual working groups to use this information as 1068 they see fit". 1070 There are two known independent implementations of SRP clients: 1072 * SRP Client for OpenThread: 1073 https://github.com/openthread/openthread/pull/6038 1075 * mDNSResponder open source project: https://github.com/Abhayakara/ 1076 mdnsresponder 1078 There are two related implementations of an SRP server. One acts as 1079 a DNS Update proxy, taking an SRP update and applying it to the 1080 specified DNS zone using DNS update. The other acts as an 1081 Advertising Proxy [I-D.sctl-advertising-proxy]. Both are included in 1082 the mDNSResponder open source project mentioned above. 1084 10. Acknowledgments 1086 Thanks to Toke Høiland-Jørgensen, Jonathan Hui, Esko Dijk, Kangping 1087 Dong and Abtin Keshavarzian for their thorough technical reviews. 1088 Thanks to Kangping and Abtin as well for testing the document by 1089 doing an independent implementation. Thanks to Tamara Kemper for 1090 doing a nice developmental edit, Tim Wattenberg for doing a SRP 1091 client proof-of-concept implementation at the Montreal Hackathon at 1092 IETF 102, and Tom Pusateri for reviewing during the hackathon and 1093 afterwards. 1095 11. Normative References 1097 [I-D.sekar-dns-ul] 1098 Cheshire, S. and T. Lemon, "An EDNS0 option to negotiate 1099 Leases on DNS Updates", Work in Progress, Internet-Draft, 1100 draft-sekar-dns-ul-03, 27 July 2021, 1101 . 1104 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1105 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1106 . 1108 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1109 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1110 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1111 . 1113 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1114 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1115 2000, . 1117 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1118 Requirements for the Address and Routing Parameter Area 1119 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1120 September 2001, . 1122 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1123 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1124 . 1126 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1127 and P. Hoffman, "Specification for DNS over Transport 1128 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1129 2016, . 1131 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1132 "IPv6 Router Advertisement Options for DNS Configuration", 1133 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1134 . 1136 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 1137 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 1138 . 1140 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 1141 Requirements and Usage Guidance for DNSSEC", RFC 8624, 1142 DOI 10.17487/RFC8624, June 2019, 1143 . 1145 [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 1146 RFC 8765, DOI 10.17487/RFC8765, June 2020, 1147 . 1149 [SUDN] "Special-Use Domain Names Registry", July 2012, 1150 . 1153 [LSDZ] "Locally-Served DNS Zones Registry", July 2011, 1154 . 1157 12. Informative References 1159 [RFC1035] Mockapetris, P., "Domain names - implementation and 1160 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1161 November 1987, . 1163 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1164 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1165 . 1167 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1168 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1169 . 1171 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1172 specifying the location of services (DNS SRV)", RFC 2782, 1173 DOI 10.17487/RFC2782, February 2000, 1174 . 1176 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1177 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1178 . 1180 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 1181 to Replace the AppleTalk Name Binding Protocol (NBP)", 1182 RFC 6760, DOI 10.17487/RFC6760, February 2013, 1183 . 1185 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 1186 RFC 6761, DOI 10.17487/RFC6761, February 2013, 1187 . 1189 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1190 DOI 10.17487/RFC6762, February 2013, 1191 . 1193 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1194 Constrained-Node Networks", RFC 7228, 1195 DOI 10.17487/RFC7228, May 2014, 1196 . 1198 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1199 for DNS over TLS and DNS over DTLS", RFC 8310, 1200 DOI 10.17487/RFC8310, March 2018, 1201 . 1203 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1204 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1205 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1206 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1207 . 1209 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 1210 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 1211 2020, . 1213 [I-D.cheshire-dnssd-roadmap] 1214 Cheshire, S., "Service Discovery Road Map", Work in 1215 Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 1216 23 October 2018, . 1219 [I-D.cheshire-edns0-owner-option] 1220 Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work 1221 in Progress, Internet-Draft, draft-cheshire-edns0-owner- 1222 option-01, 3 July 2017, 1223 . 1226 [I-D.sctl-advertising-proxy] 1227 Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD 1228 Service Registration Protocol", Work in Progress, 1229 Internet-Draft, draft-sctl-advertising-proxy-02, 12 July 1230 2021, . 1233 [ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration 1234 Networking: The Definitive Guide", O'Reilly Media, Inc. , 1235 ISBN 0-596-10100-7, December 2005. 1237 Appendix A. Testing using standard RFC2136-compliant servers 1239 It may be useful to set up a DNS server for testing that does not 1240 implement SRP. This can be done by configuring the server to listen 1241 on the anycast address, or advertising it in the 1242 _dnssd-srp._tcp. SRV and _dnssd-srp-tls._tcp. record. It 1243 must be configured to be authoritative for "default.service.arpa", 1244 and to accept updates from hosts on local networks for names under 1245 "default.service.arpa" without authentication, since such servers 1246 will not have support for FCFS authentication (Section 2.2.4.1). 1248 A server configured in this way will be able to successfully accept 1249 and process SRP updates from services that send SRP updates. 1250 However, no prerequisites will be applied, and this means that the 1251 test server will accept internally inconsistent SRP updates, and will 1252 not stop two SRP updates, sent by different services, that claim the 1253 same name(s), from overwriting each other. 1255 Since SRP updates are signed with keys, validation of the SIG(0) 1256 algorithm used by the client can be done by manually installing the 1257 client public key on the DNS server that will be receiving the 1258 updates. The key can then be used to authenticate the client, and 1259 can be used as a requirement for the update. An example 1260 configuration for testing SRP using BIND 9 is given in Appendix C. 1262 Appendix B. How to allow services to update standard RFC2136-compliant 1263 servers 1265 Ordinarily SRP updates will fail when sent to an RFC 2136-compliant 1266 server that does not implement SRP because the zone being updated is 1267 "default.service.arpa", and no DNS server that is not an SRP server 1268 should normally be configured to be authoritative for 1269 "default.service.arpa". Therefore, a service that sends an SRP 1270 update can tell that the receiving server does not support SRP, but 1271 does support RFC2136, because the RCODE will either be NOTZONE, 1272 NOTAUTH or REFUSED, or because there is no response to the update 1273 request (when using the anycast address) 1275 In this case a service MAY attempt to register itself using regular 1276 RFC2136 DNS updates. To do so, it must discover the default 1277 registration zone and the DNS server designated to receive updates 1278 for that zone, as described earlier, using the _dns-update._udp SRV 1279 record. It can then make the update using the port and host pointed 1280 to by the SRV record, and should use appropriate prerequisites to 1281 avoid overwriting competing records. Such updates are out of scope 1282 for SRP, and a service that implements SRP MUST first attempt to use 1283 SRP to register itself, and should only attempt to use RFC2136 1284 backwards compatibility if that fails. Although the owner name for 1285 the SRV record specifies the UDP protocol for updates, it is also 1286 possible to use TCP, and TCP should be required to prevent spoofing. 1288 Appendix C. Sample BIND9 configuration for default.service.arpa. 1290 zone "default.service.arpa." { 1291 type master; 1292 file "/etc/bind/master/service.db"; 1293 allow-update { key demo.default.service.arpa.; }; 1294 }; 1296 Figure 1: Zone Configuration in named.conf 1298 $ORIGIN . 1299 $TTL 57600 ; 16 hours 1300 default.service.arpa IN SOA ns3.default.service.arpa. 1301 postmaster.default.service.arpa. ( 1302 2951053287 ; serial 1303 3600 ; refresh (1 hour) 1304 1800 ; retry (30 minutes) 1305 604800 ; expire (1 week) 1306 3600 ; minimum (1 hour) 1307 ) 1308 NS ns3.default.service.arpa. 1309 SRV 0 0 53 ns3.default.service.arpa. 1310 $ORIGIN default.service.arpa. 1311 $TTL 3600 ; 1 hour 1312 _ipps._tcp PTR demo._ipps._tcp 1313 $ORIGIN _ipps._tcp.default.service.arpa. 1314 demo TXT "0" 1315 SRV 0 0 9992 demo.default.service.arpa. 1316 $ORIGIN _udp.default.service.arpa. 1317 $TTL 3600 ; 1 hour 1318 _dns-update PTR ns3.default.service.arpa. 1319 $ORIGIN _tcp.default.service.arpa. 1320 _dnssd-srp PTR ns3.default.service.arpa. 1321 $ORIGIN default.service.arpa. 1322 $TTL 300 ; 5 minutes 1323 ns3 AAAA 2001:db8:0:1::1 1324 $TTL 3600 ; 1 hour 1325 demo AAAA 2001:db8:0:2::1 1326 KEY 513 3 13 ( 1327 qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU 1328 9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg== 1329 ); alg = ECDSAP256SHA256 ; key id = 15008 1330 AAAA ::1 1332 Figure 2: Example Zone file 1334 Authors' Addresses 1336 Ted Lemon 1337 Apple Inc. 1338 One Apple Park Way 1339 Cupertino, California 95014 1340 United States of America 1342 Email: mellon@fugue.com 1343 Stuart Cheshire 1344 Apple Inc. 1345 One Apple Park Way 1346 Cupertino, California 95014 1347 United States of America 1349 Phone: +1 408 974 3207 1350 Email: cheshire@apple.com