idnits 2.17.1 draft-ietf-dnssd-srp-03.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 163: '...rvices using SRP MUST use the domain n...' RFC 2119 keyword, line 166: '...e than one domain name, it MUST NOT be...' RFC 2119 keyword, line 242: '...ce Instance Name MUST be referenced by...' RFC 2119 keyword, line 350: '.../private key pair. This key pair MUST...' RFC 2119 keyword, line 352: '...ient, the client MUST be pre-configure...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1345 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8375' is defined on line 846, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Informational S. Cheshire 5 Expires: January 14, 2021 Apple Inc. 6 July 13, 2020 8 Service Registration Protocol for DNS-Based Service Discovery 9 draft-ietf-dnssd-srp-03 11 Abstract 13 The Service Registration Protocol for DNS-Based Service Discovery 14 uses the standard DNS Update mechanism to enable DNS-Based Service 15 Discovery using only unicast packets. This makes it possible to 16 deploy DNS Service Discovery without multicast, which greatly 17 improves scalability and improves performance on networks where 18 multicast service is not an optimal choice, particularly 802.11 19 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration 20 uses public keys and SIG(0) to allow services to defend their 21 registrations against attack. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 14, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Service Registration Protocol . . . . . . . . . . . . . . . . 4 59 2.1. What to publish . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Where to publish it . . . . . . . . . . . . . . . . . . . 6 61 2.3. How to publish it . . . . . . . . . . . . . . . . . . . . 6 62 2.3.1. How DNS-SD Service Registration differs from standard 63 RFC2136 DNS Update . . . . . . . . . . . . . . . . . 7 64 2.4. How to secure it . . . . . . . . . . . . . . . . . . . . 7 65 2.4.1. First-Come First-Served Naming . . . . . . . . . . . 8 66 2.4.2. Removing published services . . . . . . . . . . . . . 9 67 2.4.3. SRP Server Behavior . . . . . . . . . . . . . . . . . 9 68 2.5. TTL Consistency . . . . . . . . . . . . . . . . . . . . . 12 69 2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 13 70 2.6.1. Cleaning up stale data . . . . . . . . . . . . . . . 13 71 2.6.2. Sleep Proxy . . . . . . . . . . . . . . . . . . . . . 14 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 3.1. Source Validation . . . . . . . . . . . . . . . . . . . . 15 74 3.2. SIG(0) signature validation . . . . . . . . . . . . . . . 16 75 3.3. Required Signature Algorithm . . . . . . . . . . . . . . 16 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 77 5. Delegation of 'service.arpa.' . . . . . . . . . . . . . . . . 16 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6.1. Registration and Delegation of 'service.arpa' as a 80 Special-Use Domain Name . . . . . . . . . . . . . . . . . 17 81 6.2. 'dnssd-srp' Service Name . . . . . . . . . . . . . . . . 17 82 6.3. 'dnssd-srp-tls' Service Name . . . . . . . . . . . . . . 17 83 6.4. Anycast Address . . . . . . . . . . . . . . . . . . . . . 17 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 8.2. Informative References . . . . . . . . . . . . . . . . . 19 88 Appendix A. Testing using standard RFC2136-compliant servers . . 20 89 Appendix B. How to allow services to update standard 90 RFC2136-compliant servers . . . . . . . . . . . . . 21 91 Appendix C. Sample BIND9 configuration for default.service.arpa. 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 DNS-Based Service Discovery [RFC6763] is a component of Zero 97 Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. 99 This document describes an enhancement to DNS-Based Service Discovery 100 [RFC6763] that allows services to automatically register their 101 services using the DNS protocol rather than using Multicast DNS 102 [RFC6762] (mDNS). There is already a large installed base of DNS-SD 103 clients that can discover services using the DNS protocol. This 104 extension makes it much easier to take advantage of this existing 105 functionality. 107 This document is intended for three audiences: implementors of 108 software that provides services that should be advertised using 109 DNS-SD, implementors of DNS servers that will be used in contexts 110 where DNS-SD registration is needed, and administrators of networks 111 where DNS-SD service is required. The document is intended to 112 provide sufficient information to allow interoperable implementation 113 of the registration protocol. 115 DNS-Based Service Discovery (DNS-SD) allows services to advertise the 116 fact that they provide service, and to provide the information 117 required to access that service. Clients can then discover the set 118 of services of a particular type that are available. They can then 119 select a service from among those that are available and obtain the 120 information required to use it. 122 The Service Registration Protocol for DNS-SD (SRP), described in this 123 document, provides a reasonably secure mechanism for publishing this 124 information. Once published, these services can be readily 125 discovered by clients using standard DNS lookups. 127 The DNS-SD specification [RFC6763], Section 10 ("Populating the DNS 128 with Information"), briefly discusses ways that services can publish 129 their information in the DNS namespace. In the case of mDNS, it 130 allows services to publish their information on the local link, using 131 names in the ".local" namespace, which makes their services directly 132 discoverable by peers attached to that same local link. 134 RFC6763 also allows clients to discover services using the DNS 135 protocol [RFC1035]. This can be done by having a system 136 administrator manually configure service information in the DNS, but 137 manually populating DNS authoritative server databases is costly and 138 potentially error-prone, and requires a knowledgable network 139 administrator. Consequently, although all DNS-SD client 140 implementations of which we are aware support DNS-SD using DNS 141 queries, in practice it is used much less frequently than mDNS. 143 The Discovery Proxy [I-D.ietf-dnssd-hybrid] provides one way to 144 automatically populate the DNS namespace, but is only appropriate on 145 networks where services are easily advertised using mDNS. This 146 document describes a solution more suitable for networks where 147 multicast is inefficient, or where sleepy devices are common, by 148 supporting both offering of services, and discovery of services, 149 using unicast. 151 2. Service Registration Protocol 153 Services that implement SRP use DNS Update [RFC2136] [RFC3007] to 154 publish service information in the DNS. Two variants exist, one for 155 full-featured hosts, and one for devices designed for "Constrained- 156 Node Networks" [RFC7228]. 158 Full-featured hosts are either configured manually with a 159 registration domain, or use the "dr._dns-sd._udp." query 160 ([RFC6763] Section 11) to learn the default registration domain from 161 the network. RFC6763 says to discover the registration domain using 162 either ".local" or a network-supplied domain name for . 163 Services using SRP MUST use the domain name received through the 164 DHCPv4 Domain Name option ([RFC2132] section 3.17), if available, or 165 the Neighbor Discovery DNS Search List option [RFC8106]. If the DNS 166 Search List option contains more than one domain name, it MUST NOT be 167 used. If neither option is available, the Service Registration 168 protocol is not available on the local network. 170 Manual configuration of the registraton domain can be done either by 171 querying the list of available registration zones ("r._dns-sd._udp") 172 and allowing the user to select one from the UI, or by any other 173 means appropriate to the particular use case being addressed. Full- 174 featured devices construct the names of the SRV, TXT, and PTR records 175 describing their service(s) as subdomains of the chosen service 176 registration domain. For these names they then discover the zone 177 apex of the closest enclosing DNS zone using SOA queries 178 [I-D.ietf-dnssd-push]. Having discovered the enclosing DNS zone, 179 they query for the "_dnssd-srp._tcp" SRV record to discover the 180 server to which they should send DNS updates. Hosts that support SRP 181 updates using TLS use the "_dnssd-srp-tls._tcp" SRV record 182 instead. 184 For devices designed for Constrained-Node Networks [RFC7228] some 185 simplifications are available. Instead of being configured with (or 186 discovering) the service registration domain, the (proposed) special- 187 use domain name (see [RFC6761]) "default.service.arpa" is used. The 188 details of how SRP server(s) are discovered will be specific to the 189 constrained network, and therefore we do not suggest a specific 190 mechanism here. 192 SRP clients on constrained networks are expected to receive from the 193 network a list of SRP servers with which to register. It is the 194 responsibility of a Constrained-Node Network supporting SRP to 195 provide one or more SRP server addresses. It is the responsibility 196 of the SRP server supporting a Constrained-Node Network to handle the 197 updates appropriately. In some network environments, updates may be 198 accepted directly into a local "default.service.arpa" zone, which has 199 only local visibility. In other network environments, updates for 200 names ending in "default.service.arpa" may be rewritten internally to 201 names with broader visibility. 203 The reason for these different assumptions is that low-power devices 204 that typically use Constrained-Node Networks may have very limited 205 battery power. The series of DNS lookups required to discover an SRP 206 server and then communicate with it will increase the power required 207 to advertise a service; for low-power devices, the additional 208 flexibility this provides does not justify the additional use of 209 power. It is also fairly typical of such networks that some network 210 service information is obtained as part of the process of joining the 211 network, and so this can be relied upon to provide nodes with the 212 information they need. 214 Networks that are not constrained networks can more complicated 215 topologies at the Internet layer. Nodes connected to such networks 216 can be assumed to be able to do DNSSD service registration domain 217 discovery. Such networks are generally able to provide registration 218 domain discovery and routing. By requiring the use of TCP, the 219 possibility of off-network spoofing is eliminated. 221 We will discuss several parts to this process: how to know what to 222 publish, how to know where to publish it (under what name), how to 223 publish it, how to secure its publication, and how to maintain the 224 information once published. 226 2.1. What to publish 228 We refer to the DNS Update message sent by services using SRP as an 229 SRP update. Three types of updates appear in an SRP update: Service 230 Discovery records, Service Description records, and Host Description 231 records. 233 o Service Discovery records are one or more PTR RRs, mapping from 234 the generic service type (or subtype) to the specific Service 235 Instance Name. 237 o Service Description records are exactly one SRV RR, exactly one 238 KEY RR, and one or more TXT RRs, all with the same name, the 239 Service Instance Name ([RFC6763] section 4.1). In principle 240 Service Description records can include other record types, with 241 the same Service Instance Name, though in practice they rarely do. 242 The Service Instance Name MUST be referenced by one or more 243 Service Discovery PTR records, unless it is a placeholder service 244 registration for an intentionally non-discoverable service name. 246 o The Host Description records for a service are a KEY RR, used to 247 claim exclusive ownership of the service registration, and one or 248 more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of 249 the host where the service resides. 251 RFC 6763 describes the details of what each of these types of updates 252 contains and is the definitive source for information about what to 253 publish; the reason for summarizing this here is to provide the 254 reader with enough information about what will be published that the 255 service registration process can be understood at a high level 256 without first learning the full details of DNS-SD. Also, the 257 "Service Instance Name" is an important aspect of first-come, first- 258 serve naming, which we describe later on in this document. 260 2.2. Where to publish it 262 Multicast DNS uses a single namespace, ".local", which is valid on 263 the local link. This convenience is not available for DNS-SD using 264 the DNS protocol: services must exist in some specific unicast 265 namespace. 267 As described above, full-featured devices are responsible for knowing 268 in what domain they should register their services. Devices made for 269 Constrained-Node Networks register in the (proposed) special use 270 domain name [RFC6761] "default.service.arpa", and let the SRP server 271 handle rewriting that to a different domain if necessary. 273 2.3. How to publish it 275 It is possible to issue a DNS Update that does several things at 276 once; this means that it's possible to do all the work of adding a 277 PTR resource record to the PTR RRset on the Service Name, and 278 creating or updating the Service Instance Name and Host Description, 279 in a single transaction. 281 An SRP update takes advantage of this: it is implemented as a single 282 DNS Update message that contains a service's Service Discovery 283 records, Service Description records, and Host Description records. 285 Updates done according to this specification are somewhat different 286 than regular DNS Updates as defined in RFC2136. The RFC2136 update 287 process can involve many update attempts: you might first attempt to 288 add a name if it doesn't exist; if that fails, then in a second 289 message you might update the name if it does exist but matches 290 certain preconditions. Because the registration protocol uses a 291 single transaction, some of this adaptability is lost. 293 In order to allow updates to happen in a single transaction, SRP 294 updates do not include update prerequisites. The requirements 295 specified in Section 2.4.3 are implicit in the processing of SRP 296 updates, and so there is no need for the service sending the SRP 297 update to put in any explicit prerequisites. 299 2.3.1. How DNS-SD Service Registration differs from standard RFC2136 300 DNS Update 302 DNS-SD Service Registration is based on standard RFC2136 DNS Update, 303 with some differences: 305 o It implements first-come first-served name allocation, protected 306 using SIG(0) [RFC2931]. 308 o It enforces policy about what updates are allowed. 310 o It optionally performs rewriting of "default.service.arpa" to some 311 other domain. 313 o It optionally performs automatic population of the address-to-name 314 reverse mapping domains. 316 o An SRP server is not required to implement general DNS Update 317 prerequsite processing. 319 o Clients are allowed to send updates to the generic domain 320 "default.service.arpa" 322 2.4. How to secure it 324 Traditional DNS update is secured using the TSIG protocol, which uses 325 a secret key shared between the client (which issues the update) and 326 the server (which authenticates it). This model does not work for 327 automatic service registration. 329 The goal of securing the DNS-SD Registration Protocol is to provide 330 the best possible security given the constraint that service 331 registration has to be automatic. It is possible to layer more 332 operational security on top of what we describe here, but what we 333 describe here is an improvement over the security of mDNS. The goal 334 is not to provide the level of security of a network managed by a 335 skilled operator. 337 2.4.1. First-Come First-Served Naming 339 First-Come First-Serve naming provides a limited degree of security: 340 a service that registers its service using DNS-SD Registration 341 protocol is given ownership of a name for an extended period of time 342 based on the key used to authenticate the DNS Update. As long as the 343 registration service remembers the name and the key used to register 344 that name, no other service can add or update the information 345 associated with that. FCFS naming is used to protect both the 346 Service Description and the Host Description. 348 2.4.1.1. Service Behavior 350 The service generates a public/private key pair. This key pair MUST 351 be stored in stable storage; if there is no writable stable storage 352 on the client, the client MUST be pre-configured with a public/ 353 private key pair in read-only storage that can be used. This key 354 pair MUST be unique to the device. 356 When sending DNS updates, the service includes a KEY record 357 containing the public portion of the key in each Host Description 358 update and each Service Description update. Each KEY record MUST 359 contain the same public key. The update is signed using SIG(0), 360 using the private key that corresponds to the public key in the KEY 361 record. The lifetimes of the records in the update is set using the 362 EDNS(0) Update Lease option [I-D.sekar-dns-ul]. 364 The KEY record in Service Description updates MAY be omitted for 365 brevity; if it is omitted, the SRP server MUST behave as if the same 366 KEY record that is given for the Host Description is also given for 367 each Service Description for which no KEY record is provided. 368 Omitted KEY records are not used when computing the SIG(0) signature. 370 The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records 371 [RFC6763] uses the LEASE field of the Update Lease option, and is 372 typically set to two hours. This means that if a device is 373 disconnected from the network, it does not appear in the user 374 interfaces of devices looking for services of that type for too long. 376 The lifetime of the KEY records is set using the KEY-LEASE field of 377 the Update Lease Option, and should be set to a much longer time, 378 typically 14 days. The result of this is that even though a device 379 may be temporarily unplugged, disappearing from the network for a few 380 days, it makes a claim on its name that lasts much longer. 382 This means that even if a device is unplugged from the network for a 383 few days, and its services are not available for that time, no other 384 device can come along and claim its name the moment it disappears 385 from the network. In the event that a device is unplugged from the 386 network and permanently discarded, then its name is eventually 387 cleaned up and made available for re-use. 389 2.4.2. Removing published services 391 To remove a service registration, the client retransmits its most 392 recent update with an Update Lease option that has a LEASE value of 393 zero. If the registration is to be permanently removed, KEY-LEASE 394 should also be zero. Otherwise, it should have the same value it had 395 previously; this holds the name in reserve for when the client is 396 once again able to provide the service. 398 SRP clients are normally expected to remove all service instances 399 when removing a host. However, in some cases a client may not have 400 retained sufficient state to know that some service instance is 401 pointing to a host that it is removing. Nevertheless, removing the 402 host can be assumed to mean that all service instances pointing to it 403 are no longer valid. Therefore, SRP servers MAY remove all service 404 instances pointing to a host when a host is removed, even if the 405 client doesn't remove them explicitly. 407 2.4.3. SRP Server Behavior 409 2.4.3.1. Validation of Adds 411 The SRP server first validates that the DNS Update is a syntactically 412 and semantically valid DNS Update according to the rules specified in 413 RFC2136. 415 SRP Updates consist of a set of Instructions that together add one or 416 more services. Each instruction consists either of a single add, or 417 a delete followed by an add. When an instruction contains a delete 418 and an add, the delete MUST precede the add. 420 The SRP server checks each Instruction in the SRP update to see that 421 it is either a Service Discovery update, a Service Description 422 update, or a Host Description update. Order matters in DNS updates. 423 Specifically, deletes must precede adds for records that the deletes 424 would affect; otherwise the add will have no effect. This is the 425 only ordering constraint; aside from this constraint, updates may 426 appear in whatever order is convenient when constructing the update. 428 Because the SRP update is a DNS update, it MUST contain a single 429 question that indicates the zone to be updated. Every delete and 430 update in an SRP update MUST be within the zone that is specified for 431 the SRP Update. 433 An Instruction is a Service Discovery Instruction if it contains 435 o exactly one "Add to an RRSet" ([RFC2136] Section 2.5.1) RR, 436 o which is a PTR RR, 437 o which points to a Service Instance Name 438 o for which a Service Description Instruction is present in the SRP 439 Update. 440 o Service Discovery Instructions do not contain any deletes, and do 441 not contain any other adds. 443 An Instruction is a Service Description Instruction if, for the 444 appropriate Service Instance Name, it contains 446 o exactly one "Delete all RRsets from a name" update for the service 447 instance name [RFC2136] Section 2.5.3, 448 o exactly one "Add to an RRset" SRV RR, 449 o zero or one "Add to an RRset" KEY RR that contains the public key 450 corresponding to the private key that was used to sign the message 451 (if present, the KEY MUST match the KEY RR given in the Host 452 Description), 453 o one or more "Add to an RRset" TXT RRs, 454 o and the target of the SRV RR Add points to a hostname for which 455 there is a Host Description Instruction in the SRP Update. 456 o Service Descriptions Instructions do not modify any other RRs. 458 An Instruction is a Host Description Instruction if, for the 459 appropriate hostname, it contains 461 o exactly one "Delete all RRsets from a name" RR, 462 o one or more "Add to an RRset" RRs of type A and/or AAAA, 463 o exactly one "Add to an RRset" RR that adds a KEY RR that contains 464 the public key corresponding to the private key that was used to 465 sign the message, 466 o there is a Service Instance Name Instruction in the SRP update for 467 which the SRV RR that is added points to the hostname being 468 updated by this update. 469 o Host Description updates do not modify any other records. 471 An SRP Update MUST include at least one Service Discovery 472 Instruction, at least one Service Description Instruction, and 473 exactly one Host Description Instruction. A DNS Update that does not 474 is not an SRP update. A DNS Update that contains any other adds, any 475 other deletes, or any prerequisites, is not an SRP update. Such 476 messages should either be processed as regular RFC2136 updates, 477 including access control checks and constraint checks, if supported, 478 or else rejected with RCODE=REFUSED. 480 Note that if the definitions of each of these update types are 481 followed carefully, this means that many things that look very much 482 like SRP updates nevertheless are not. For example, a DNS update 483 that contains an RRset Add to a Service Name and an RRset Add to a 484 Service Instance Name, where the Service Name does not reference the 485 Service Instance Name, is not a valid SRP update message, but may be 486 a valid RFC2136 update. 488 Assuming that a DNS Update message has been validated with these 489 conditions and is a valid SRP Update, the server checks that the name 490 in the Host Description Instruction exists. If so, then the server 491 checks to see if the KEY record on that name is the same as the KEY 492 record in the Host Description Instruction. The server performs the 493 same check for the KEY records in any Service Description 494 Instrructions. For KEY records that were omitted from Service 495 Description Instructions, the KEY from the Host Description 496 Instruction is used. If any existing KEY record corresponding to a 497 KEY record in the SRP Update does not match the KEY same record in 498 the SRP Update (whether provided or taken from the Host Description 499 Instruction), then the server MUST reject the SRP Update with the 500 YXDOMAIN RCODE. 502 Otherwise, the server validates the SRP Update using SIG(0) on the 503 public key in the KEY record of the Host Description update. If the 504 validation fails, the server MUST reject the SRP Update with the 505 REFUSED RCODE. Otherwise, the SRP update is considered valid and 506 authentic, and is processed according to the method described in 507 RFC2136. 509 KEY record updates omitted from Service Description update are 510 processed as if they had been explicitly present: every Service 511 Description that is updated MUST, after the update, have a KEY RR, 512 and it must be the same KEY RR that is present in the Host 513 Description to which the Service Description refers. 515 The status that is returned depends on the result of processing the 516 update, and can be either SUCCESS or SERVFAIL: all other possible 517 outcomes should already have been accounted for when applying the 518 constraints that qualify the update as an SRP Update. 520 The server MAY add a Reverse Mapping that corresponds to the Host 521 Description. This is not required because the Reverse Mapping serves 522 no protocol function, but it may be useful for debugging, e.g. in 523 annotating network packet traces or logs. In order for the server to 524 add a reverse mapping update, it must be authoritative for the zone 525 or have credentials to do the update. The client MAY also do a 526 reverse mapping update if it has credentials to do so. 528 The server MAY apply additional criteria when accepting updates. In 529 some networks, it may be possible to do out-of-band registration of 530 keys, and only accept updates from pre-registered keys. In this 531 case, an update for a key that has not been registered should be 532 rejected with the REFUSED RCODE. 534 There are at least two benefits to doing this rather than simply 535 using normal SIG(0) DNS updates. First, the same registration 536 protocol can be used in both cases, so both use cases can be 537 addressed by the same service implementation. Second, the 538 registration protocol includes maintenance functionality not present 539 with normal DNS updates. 541 Note that the semantics of using SRP in this way are different than 542 for typical RFC2136 implementations: the KEY used to sign the SRP 543 update only allows the client to update records that refer to its 544 Host Description. RFC2136 implementations do not normally provide a 545 way to enforce a constraint of this type. 547 The server may also have a dictionary of names or name patterns that 548 are not permitted. If such a list is used, updates for Service 549 Instance Names that match entries in the dictionary are rejected with 550 YXDOMAIN. 552 2.5. TTL Consistency 554 All RRs within an RRset are required to have the same TTL 555 (Clarifications to the DNS Specification [RFC2181], Section 5.2). In 556 order to avoid inconsistencies, SRP places restrictions on TTLs sent 557 by services and requires that SRP Servers enforce consistency. 559 Services sending SRP updates MUST use consistent TTLs in all RRs 560 within the SRP update. 562 SRP update servers MUST check that the TTLs for all RRs within the 563 SRP update are the same. If they are not, the SRP update MUST be 564 rejected with a REFUSED RCODE. 566 Additionally, when adding RRs to an RRset, for example when 567 processing Service Discovery records, the server MUST use the same 568 TTL on all RRs in the RRset. How this consistency is enforced is up 569 to the implementation. 571 TTLs sent in SRP updates are advisory: they indicate the client's 572 guess as to what a good TTL would be. SRP servers may override these 573 TTLs. SRP servers SHOULD ensure that TTLs are reasonable: neither 574 too long nor too short. The TTL should never be longer than the 575 lease time Section 2.6.1. Shorter TTLs will result in more frequent 576 data refreshes; this increases latency on the client side, and 577 increases load on any caching resolvers and on the authoritative 578 server. Longer TTLs will increase the likelihood that data in caches 579 will be stale. TTL minimums and maximums SHOULD be configurable by 580 the operator of the SRP server. 582 2.6. Maintenance 584 2.6.1. Cleaning up stale data 586 Because the DNS-SD registration protocol is automatic, and not 587 managed by humans, some additional bookkeeping is required. When an 588 update is constructed by the client, it MUST include include an 589 EDNS(0) Update Lease Option [I-D.sekar-dns-ul]. The Update Lease 590 Option contains two lease times: the Lease Time and the Key Lease 591 Time. 593 These leases are promises, similar to DHCP leases [RFC2131], from the 594 client that it will send a new update for the service registration 595 before the lease time expires. The Lease time is chosen to represent 596 the time after the update during which the registered records other 597 than the KEY record should be assumed to be valid. The Key Lease 598 time represents the time after the update during which the KEY record 599 should be assumed to be valid. 601 The reasoning behind the different lease times is discussed in the 602 section on first-come, first-served naming Section 2.4.1. SRP 603 servers may be configured with limits for these values. A default 604 limit of two hours for the Lease and 14 days for the SIG(0) KEY are 605 currently thought to be good choices. Clients that are going to 606 continue to use names on which they hold leases should update well 607 before the lease ends, in case the registration service is 608 unavailable or under heavy load. 610 The SRP server MUST include an EDNS(0) Update Lease option in the 611 response if the lease time proposed by the service has been shortened 612 or lengthened. The service MUST check for the EDNS(0) Update Lease 613 option in the response and MUST use the lease times from that option 614 in place of the options that it sent to the server when deciding when 615 to update its registration. The times may be shorter or longer than 616 those specified in the SRP update; the client must honor them in 617 either case. 619 Clients should assume that each lease ends N seconds after the update 620 was first transmitted, where N is the lease duration. Servers should 621 assume that each lease ends N seconds after the update that was 622 successfully processed was received. Because the server will always 623 receive the update after the client sent it, this avoids the 624 possibility of misunderstandings. 626 SRP servers MUST reject updates that do not include an EDNS(0) Update 627 Lease option. Dual-use servers MAY accept updates that don't include 628 leases, but SHOULD differentiate between SRP updates and other 629 updates, and MUST reject updates that would otherwise be SRP updates 630 updates if they do not include leases. 632 Lease times have a completely different function than TTLs. On an 633 authoritative DNS server, the TTL on a resource record is a constant: 634 whenever that RR is served in a DNS response, the TTL value sent in 635 the answer is the same. The lease time is never sent as a TTL; its 636 sole purpose is to determine when the authoritative DNS server will 637 delete stale records. It is not an error to send a DNS response with 638 a TTL of 'n' when the remaining time on the lease is less than 'n'. 640 2.6.2. Sleep Proxy 642 Another use of SRP is for devices that sleep to reduce power 643 consumption. 645 In this case, in addition to the DNS Update Lease option 646 [I-D.sekar-dns-ul] described above, the device includes an EDNS(0) 647 OWNER Option [I-D.cheshire-edns0-owner-option]. 649 The EDNS(0) Update Lease option constitutes a promise by the device 650 that it will wake up before this time elapses, to renew its 651 registration and thereby demonstrate that it is still attached to the 652 network. If it fails to renew the registration by this time, that 653 indicates that it is no longer attached to the network, and its 654 registration (except for the KEY in the Host Description) should be 655 deleted. 657 The EDNS(0) OWNER Option indicates that the device will be asleep, 658 and will not be receptive to normal network traffic. When a DNS 659 server receives a DNS Update with an EDNS(0) OWNER Option, that 660 signifies that the SRP server should set up a proxy for any IPv4 or 661 IPv6 address records in the DNS Update message. This proxy should 662 send ARP or ND messages claiming ownership of the IPv4 and/or IPv6 663 addresses in the records in question. In addition, proxy should 664 answer future ARP or ND requests for those IPv4 and/or IPv6 665 addresses, claiming ownership of them. When the DNS server receives 666 a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6 667 addresses for which it proxying, it should then wake up the sleeping 668 device using the information in the EDNS(0) OWNER Option. At present 669 version 0 of the OWNER Option specifies the "Wake-on-LAN Magic 670 Packet" that needs to be sent; future versions could be extended to 671 specify other wakeup mechanisms. 673 Note that although the authoritative DNS server that implements the 674 SRP function need not be on the same link as the sleeping host, the 675 Sleep Proxy must be on the same link. 677 It is not required that sleepy nodes on a Constrained-Node Network 678 support sleep proxy. Such devices may have different mechanisms for 679 dealing with sleep and wakeup. An SRP registration for such a device 680 will be useful regardless of the mechanism whereby messages are 681 delivered to the sleepy end device. For example, the message might 682 be held in a buffer for an extended period of time by an intermediate 683 device on a mesh network, and then delivered to the device when it 684 wakes up. The exact details of such behaviors are out of scope for 685 this document. 687 3. Security Considerations 689 3.1. Source Validation 691 SRP updates have no authorization semantics other than first-come, 692 first-served. This means that if an attacker from outside of the 693 administrative domain of the server knows the server's IP address, it 694 can in principle send updates to the server that will be processed 695 successfully. Servers should therefore be configured to reject 696 updates from source addresses outside of the administrative domain of 697 the server. 699 For Anycast updates, this validation must be enforced by every router 700 that connects the Constrained-Device Network to the unconstrained 701 portion of the network. For TCP updates, the initial SYN-SYN+ACK 702 handshake prevents updates being forged by an off-network attacker. 703 In order to ensure that this handshake happens, Service Discovery 704 Protocol servers MUST NOT accept TCP Fast Open payloads. 706 Note that these rules only apply to the validation of SRP updates. A 707 server that accepts updates from DNS-SD registration protocol clients 708 may also accept other DNS updates, and those DNS updates may be 709 validated using different rules. However, in the case of a DNS 710 service that accepts SRP updates, the intersection of the SRP update 711 rules and whatever other update rules are present must be considered 712 very carefully. 714 For example, a normal, authenticated RFC2136 update to any RR that 715 was added using SRP, but that is authenticated using a different key, 716 could be used to override a promise made by the registration 717 protocol, by replacing all or part of the service registration 718 information with information provided by a different client. An 719 implementation that allows both kinds of updates should not allow 720 updates to records added by SRP updates using different 721 authentication and authorization credentials. 723 3.2. SIG(0) signature validation 725 This specification does not provide a mechanism for validating 726 responses from DNS servers to SRP clients. In the case of 727 Constrained Network/Constrained Node clients, such validation isn't 728 practical because there's no way to establish trust. In principle, a 729 KEY RR could be used by a non-constrained SRP client to validate 730 responses from the server, but this is not required, nor do we 731 specify a mechanism for determining which key to use. 733 3.3. Required Signature Algorithm 735 For validation, SRP Servers MUST implement the ECDSAP256SHA256 736 signature algorithm. SRP servers SHOULD implement the algorithms 737 specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, in the 738 validation column of the table, starting with algorithm number 13. 739 SRP clients MUST NOT assume that any algorithm numbered lower than 13 740 is available for use in validating SIG(0) signatures. 742 4. Privacy Considerations 744 Because DNSSD SRP updates can be sent off-link, the privacy 745 implications of SRP are different than for multicast DNS responses. 746 Host implementations that are using TCP SHOULD also use TLS if 747 available. Server implementations MUST offer TLS support. The use 748 of TLS with DNS is described in [RFC7858] and [RFC8310]. 750 Hosts that implement TLS support SHOULD NOT fall back to TCP; since 751 servers are required to support TLS, it is entirely up to the host 752 implementation whether to use it. 754 5. Delegation of 'service.arpa.' 756 In order to be fully functional, there must be a delegation of 757 'service.arpa.' in the '.arpa.' zone [RFC3172]. This delegation 758 should be set up as was done for 'home.arpa', as a result of the 759 specification in [RFC8375]Section 7. 761 6. IANA Considerations 762 6.1. Registration and Delegation of 'service.arpa' as a Special-Use 763 Domain Name 765 IANA is requested to record the domain name 'service.arpa.' in the 766 Special-Use Domain Names registry [SUDN]. IANA is requested, with 767 the approval of IAB, to implement the delegation requested in 768 Section 5. 770 IANA is further requested to add a new entry to the "Transport- 771 Independent Locally-Served Zones" subregistry of the the "Locally- 772 Served DNS Zones" registry[LSDZ]. The entry will be for the domain 773 'service.arpa.' with the description "DNS-SD Registration Protocol 774 Special-Use Domain", listing this document as the reference. 776 6.2. 'dnssd-srp' Service Name 778 IANA is also requested to add a new entry to the Service Names and 779 Port Numbers registry for dnssd-srp with a transport type of tcp. No 780 port number is to be assigned. The reference should be to this 781 document, and the Assignee and Contact information should reference 782 the authors of this document. The Description should be as follows: 784 Availability of DNS Service Discovery Service Registration Protocol 785 Service for a given domain is advertised using the 786 "_dnssd-srp._tcp.." SRV record gives the target host and 787 port where DNSSD Service Registration Service is provided for the 788 named domain. 790 6.3. 'dnssd-srp-tls' Service Name 792 IANA is also requested to add a new entry to the Service Names and 793 Port Numbers registry for dnssd-srp with a transport type of tcp. No 794 port number is to be assigned. The reference should be to this 795 document, and the Assignee and Contact information should reference 796 the authors of this document. The Description should be as follows: 798 Availability of DNS Service Discovery Service Registration Protocol 799 Service for a given domain over TLS is advertised using the 800 "_dnssd-srp-tls._tcp.." SRV record gives the target host and 801 port where DNSSD Service Registration Service is provided for the 802 named domain. 804 6.4. Anycast Address 806 IANA is requested to allocate an IPv6 Anycast address from the IPv6 807 Special-Purpose Address Registry, similar to the Port Control 808 Protocol anycast address, 2001:1::1. This address is referred to 809 within the document as TBD1, and the document should be updated to 810 reflect the address that was allocated. 812 7. Acknowledgments 814 Thanks to Toke Hoeiland-Joergensen for a thorough technical review, 815 to Tamara Kemper for doing a nice developmental edit, Tim Wattenberg 816 for doing a service implementation at the Montreal Hackathon at IETF 817 102, Tom Pusateri for reviewing during the hackathon and afterwards, 818 and [...] more reviewers to come, hopefully. 820 8. References 822 8.1. Normative References 824 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 825 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 826 . 828 [I-D.sekar-dns-ul] 829 Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", 830 draft-sekar-dns-ul-02 (work in progress), August 2018. 832 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 833 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 834 . 836 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 837 Requirements for the Address and Routing Parameter Area 838 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 839 September 2001, . 841 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 842 "IPv6 Router Advertisement Options for DNS Configuration", 843 RFC 8106, DOI 10.17487/RFC8106, March 2017, 844 . 846 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 847 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 848 . 850 [I-D.ietf-dnsop-algorithm-update] 851 Wouters, P. and O. Sury, "Algorithm Implementation 852 Requirements and Usage Guidance for DNSSEC", draft-ietf- 853 dnsop-algorithm-update-10 (work in progress), April 2019. 855 [SUDN] "Special-Use Domain Names Registry", July 2012, 856 . 859 [LSDZ] "Locally-Served DNS Zones Registry", July 2011, 860 . 863 8.2. Informative References 865 [RFC1035] Mockapetris, P., "Domain names - implementation and 866 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 867 November 1987, . 869 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 870 RFC 2131, DOI 10.17487/RFC2131, March 1997, 871 . 873 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 874 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 875 RFC 2136, DOI 10.17487/RFC2136, April 1997, 876 . 878 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 879 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 880 . 882 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 883 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 884 2000, . 886 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 887 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 888 . 890 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 891 to Replace the AppleTalk Name Binding Protocol (NBP)", 892 RFC 6760, DOI 10.17487/RFC6760, February 2013, 893 . 895 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 896 RFC 6761, DOI 10.17487/RFC6761, February 2013, 897 . 899 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 900 DOI 10.17487/RFC6762, February 2013, 901 . 903 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 904 Constrained-Node Networks", RFC 7228, 905 DOI 10.17487/RFC7228, May 2014, 906 . 908 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 909 and P. Hoffman, "Specification for DNS over Transport 910 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 911 2016, . 913 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 914 for DNS over TLS and DNS over DTLS", RFC 8310, 915 DOI 10.17487/RFC8310, March 2018, 916 . 918 [I-D.ietf-dnssd-hybrid] 919 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 920 Service Discovery", draft-ietf-dnssd-hybrid-10 (work in 921 progress), March 2019. 923 [I-D.ietf-dnssd-push] 924 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 925 draft-ietf-dnssd-push-25 (work in progress), October 2019. 927 [I-D.cheshire-dnssd-roadmap] 928 Cheshire, S., "Service Discovery Road Map", draft- 929 cheshire-dnssd-roadmap-03 (work in progress), October 930 2018. 932 [I-D.cheshire-edns0-owner-option] 933 Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 934 cheshire-edns0-owner-option-01 (work in progress), July 935 2017. 937 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 938 Networking: The Definitive Guide", O'Reilly Media, Inc. , 939 ISBN 0-596-10100-7, December 2005. 941 Appendix A. Testing using standard RFC2136-compliant servers 943 It may be useful to set up a DNS server for testing that does not 944 implement SRP. This can be done by configuring the server to listen 945 on the anycast address, or advertising it in the 946 _dnssd-srp._tcp. SRV and _dnssd-srp-tls._tcp. record. It 947 must be configured to be authoritative for "default.service.arpa", 948 and to accept updates from hosts on local networks for names under 949 "default.service.arpa" without authentication, since such servers 950 will not have support for FCFS authentication Section 2.4.1. 952 A server configured in this way will be able to successfully accept 953 and process SRP updates from services that send SRP updates. 954 However, no prerequisites will be applied, and this means that the 955 test server will accept internally inconsistent SRP updates, and will 956 not stop two SRP updates, sent by different services, that claim the 957 same name(s), from overwriting each other. 959 Since SRP updates are signed with keys, validation of the SIG(0) 960 algorithm used by the client can be done by manually installing the 961 client public key on the DNS server that will be receiving the 962 updates. The key can then be used to authenticate the client, and 963 can be used as a requirement for the update. An example 964 configuration for testing SRP using BIND 9 is given in Appendix C. 966 Appendix B. How to allow services to update standard RFC2136-compliant 967 servers 969 Ordinarily SRP updates will fail when sent to an RFC 2136-compliant 970 server that does not implement SRP because the zone being updated is 971 "default.service.arpa", and no DNS server that is not an SRP server 972 should normally be configured to be authoritative for 973 "default.service.arpa". Therefore, a service that sends an SRP 974 update can tell that the receiving server does not support SRP, but 975 does support RFC2136, because the RCODE will either be NOTZONE, 976 NOTAUTH or REFUSED, or because there is no response to the update 977 request (when using the anycast address) 979 In this case a service MAY attempt to register itself using regular 980 RFC2136 DNS updates. To do so, it must discover the default 981 registration zone and the DNS server designated to receive updates 982 for that zone, as described earlier, using the _dns-update._udp SRV 983 record. It can then make the update using the port and host pointed 984 to by the SRV record, and should use appropriate prerequisites to 985 avoid overwriting competing records. Such updates are out of scope 986 for SRP, and a service that implements SRP MUST first attempt to use 987 SRP to register itself, and should only attempt to use RFC2136 988 backwards compatibility if that fails. Although the owner name for 989 the SRV record specifies the UDP protocol for updates, it is also 990 possible to use TCP, and TCP should be required to prevent spoofing. 992 Appendix C. Sample BIND9 configuration for default.service.arpa. 994 zone "default.service.arpa." { 995 type master; 996 file "/etc/bind/master/service.db"; 997 allow-update { key demo.default.service.arpa.; }; 998 }; 1000 Zone Configuration in named.conf 1002 $ORIGIN . 1003 $TTL 57600 ; 16 hours 1004 default.service.arpa IN SOA ns3.default.service.arpa. 1005 postmaster.default.service.arpa. ( 1006 2951053287 ; serial 1007 3600 ; refresh (1 hour) 1008 1800 ; retry (30 minutes) 1009 604800 ; expire (1 week) 1010 3600 ; minimum (1 hour) 1011 ) 1012 NS ns3.default.service.arpa. 1013 SRV 0 0 53 ns3.default.service.arpa. 1014 $ORIGIN default.service.arpa. 1015 $TTL 3600 ; 1 hour 1016 _ipps._tcp PTR demo._ipps._tcp 1017 $ORIGIN _ipps._tcp.default.service.arpa. 1018 demo TXT "0" 1019 SRV 0 0 9992 demo.default.service.arpa. 1020 $ORIGIN _udp.default.service.arpa. 1021 $TTL 3600 ; 1 hour 1022 _dns-update PTR ns3.default.service.arpa. 1023 $ORIGIN _tcp.default.service.arpa. 1024 _dnssd-srp PTR ns3.default.service.arpa. 1025 $ORIGIN default.service.arpa. 1026 $TTL 300 ; 5 minutes 1027 ns3 AAAA 2001:db8:0:1::1 1028 $TTL 3600 ; 1 hour 1029 demo AAAA 2001:db8:0:2::1 1030 KEY 513 3 13 ( 1031 qweEmaaq0FAWok5//ftuQtZgiZoiFSUsm0srWREdywQU 1032 9dpvtOhrdKWUuPT3uEFF5TZU6B4q1z1I662GdaUwqg== 1033 ); alg = ECDSAP256SHA256 ; key id = 15008 1034 AAAA ::1 1036 Example Zone file 1038 Authors' Addresses 1040 Ted Lemon 1041 Nibbhaya Consulting 1042 P.O. Box 958 1043 Brattleboro, Vermont 05302 1044 United States of America 1046 Email: mellon@fugue.com 1048 Stuart Cheshire 1049 Apple Inc. 1050 One Apple Park Way 1051 Cupertino, California 95014 1052 USA 1054 Phone: +1 408 974 3207 1055 Email: cheshire@apple.com