idnits 2.17.1 draft-sctl-service-registration-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 184: '... Name MUST be referenced by one o...' RFC 2119 keyword, line 296: '...s case a service MAY attempt to regist...' RFC 2119 keyword, line 304: '...tration Protocol MUST first attempt to...' RFC 2119 keyword, line 335: '.../private key pair. This key pair MUST...' RFC 2119 keyword, line 337: '...ient, the client MUST be pre-configure...' (18 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 14, 2018) is 2084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC3152' is defined on line 654, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-01 -- Obsolete informational reference (is this intentional?): RFC 3152 (Obsoleted by RFC 3596) == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-14 == Outdated reference: A later version (-03) exists of draft-cheshire-dnssd-roadmap-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Lemon 5 Expires: January 15, 2019 Nibbhaya Consulting 6 July 14, 2018 8 Service Registration Protocol for DNS-Based Service Discovery 9 draft-sctl-service-registration-02 11 Abstract 13 The DNS-SD Service Registration Protocol uses the standard DNS Update 14 mechanism to enable DNS-Based Service Discovery using only unicast 15 packets. This eliminates the dependency on Multicast DNS as the 16 foundation layer, which greatly improves scalability and improves 17 performance on networks where multicast service is not an optimal 18 choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. 19 DNS-SD Service registration uses public keys and SIG(0) to allow 20 services to defend their 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 January 15, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 DNS-Based Service Discovery [RFC6763] is a component of Zero 57 Configuration Networking [RFC6760] [ZC] [I-D.cheshire-dnssd-roadmap]. 59 This document describes an enhancement to DNS-Based Service Discovery 60 [RFC6763] that allows services to automatically register their 61 services using the DNS protocol rather than using mDNS. There is 62 already a large installed base of DNS-SD clients that can do service 63 discovery using the DNS protocol. This extension makes it much 64 easier to take advantage of this existing functionality. 66 This document is intended for three audiences: implementors of 67 software that provides services that should be advertised using DNS- 68 SD, implementors of DNS servers that will be used in contexts where 69 DNS-SD registration is needed, and administrators of networks where 70 DNS-SD service is required. The document is intended to provide 71 sufficient information to allow interoperable implementation of the 72 registration protocol. 74 DNS-Based Service Discovery (DNS-SD) allows services to advertise the 75 fact that they provide service, and to provide the information 76 required to access that service. Clients can then discover the set 77 of services of a particular type that are available. They can then 78 select a service from among those that are available and obtain the 79 information required to use it. 81 The DNS-SD Service Registration protocol, described in this document, 82 provides a reasonably secure mechanism for publishing this 83 information. Once published, these services can be readily 84 discovered by clients using standard DNS lookups. 86 In the DNS-Based Service Discovery specification [RFC6763] Section 10 87 "Populating the DNS with Information" briefly discusses ways that 88 services can publish their information in the DNS namespace. In the 89 case of Multicast DNS [RFC6762], it allows services to publish their 90 information on the local link, using names in the ".local" namespace, 91 which makes their services directly discoverable by peers attached to 92 that same local link. 94 RFC6763 also allows clients to discover services using the DNS 95 protocol [RFC1035]. This can be done by having a system 96 administrator manually configure service information in the DNS, but 97 manually populating DNS authoritative server databases is costly and 98 potentially error-prone, and requires a knowledgable network 99 administrator. Consequently, although all DNS-SD client 100 implementations of which we are aware support DNS-SD using DNS 101 queries, in practice it is used much less frequently than mDNS. The 102 Discovery Proxy [I-D.ietf-dnssd-hybrid] provides one way to 103 automatically populate the DNS namespace, but is only appropriate on 104 networks where services are already advertised using mDNS. This 105 document describes a solution more suitable for networks where 106 multicast is inefficient, or undesirable for other reasons, by 107 supporting both offering of services, and discovery of services, 108 using unicast. 110 2. Service Registration Protocol 112 Services that implement the DNS-SD Service Registration Protocol use 113 DNS Update [RFC2136] [RFC3007] to publish service information in the 114 DNS. Two variants exist, one for full-featured devices, and one for 115 devices designed for "Constrained-Node Networks" [RFC7228]. 117 Full-featured devices are either configured manually, or use the 118 "dr._dns-sd._udp" query [RFC6763] to learn the default registration 119 domain from the network. Using the chosen service registration 120 domain, full-featured devices construct the names of the SRV, TXT, 121 and PTR records describing their service(s). For these names they 122 then discover the zone apex of the closest enclosing DNS zone using 123 SOA queries [I-D.ietf-dnssd-push]. Having discovered the enclosing 124 DNS zone, they query for the "_dns-update._udp" SRV record to 125 discover the server to which they should send DNS updates. 127 For devices designed for "Constrained-Node Networks" [RFC7228] some 128 simplifications are used. Instead of being configured with (or 129 discovering) the service registration domain, the (proposed) special 130 use domain name [RFC6761] "services.arpa" is used. Instead of 131 learning the server to which they should send DNS updates, a fixed 132 IPv6 anycast address is used (value TBD). It is the responsibility 133 of a "Constrained-Node Network" supporting DNS-SD Service 134 Registration Protocol to provide appropriate anycast routing to 135 deliver the DNS updates to the appropriate server. It is the 136 responsibility of the DNS-SD Service Registration server on a 137 "Constrained-Node Network" to handle the updates appropriately. In 138 some network environments, updates may be accepted directly into a 139 local "services.arpa" zone, which has only local visibility. In 140 other network environments, updates for names ending in 141 "services.arpa" may be rewritten internally to names with broader 142 visibility. 144 The reason for these different assumptions is that "Constrained-Node 145 Networks" generally require special egress support, and Anycast 146 packets captured at the "Constrained-Node Network" egress can be 147 assumed to have originated locally. Low-power devices that typically 148 use "Constrained-Node Networks" may have very limited battery power. 149 The additional DNS lookups required to discover a registration server 150 and then communicate with it will increase the power required to 151 advertise a service; for low-power devices, the additional 152 flexibility this provides does not justify the additional use of 153 power. 155 General networks have the potential to have more complicated 156 topologies at the Internet layer, which makes anycast routing more 157 difficult. Such networks may or may not have the infrastructure 158 required to route anycast to a server that can process it. However, 159 they can be assumed to be able to provide registration domain 160 discovery and routing. By requiring the use of TCP, the possibility 161 of off-network spoofing is eliminated. 163 We will discuss several parts to this process: how to know what to 164 publish, how to know where to publish it (under what name), how to 165 publish it, how to secure its publication, and how to maintain the 166 information once published. 168 2.1. What to publish 170 We refer to the message that services using the DNSSD Registration 171 Protocol send as a Registration. Three types of updates appear in a 172 Registration: Service Discovery records, Service Description records, 173 and Host Description records. 175 o Service Discovery records are one or more PTR RRs, mapping from 176 the generic service type (or subtype) to the specific Service 177 Instance Name. 179 o Service Description records are exactly one SRV RR, and one or 180 more TXT RRs, both with the same name, the Service Instance Name 181 ([RFC6763] section 4.1). In principle Service Description records 182 can include other record types, with the same Service Instance 183 Name, though in practice they rarely do. The Service Instance 184 Name MUST be referenced by one or more Service Discovery PTR 185 records, unless it is a placeholder service registration for an 186 intentionally non-discoverable service name. 188 o The Host Description records for a service are a KEY RR, used to 189 claim exclusive ownership of the service registration, and one or 190 more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of 191 the host where the service resides. 193 RFC 6763 describes the details of what each of these types of updates 194 contains and is the definitive source for information about what to 195 publish; the reason for mentioning it here is to provide the reader 196 with enough information about what will be published that the service 197 registration process can be understood at a high level without first 198 learning the full details of DNS-SD. Also, the "Service Instance 199 Name" is an important aspect of first-come, first-serve naming, which 200 we describe later on in this document. 202 2.2. Where to publish it 204 Multicast DNS uses a single namespace, ".local", which is valid on 205 the local link. This convenience is not available for DNS-SD using 206 the DNS protocol: services must exist in some specific unicast 207 namespace. 209 As described above, full-featured devices are responsible for knowing 210 in what domain they should register their services. Devices made for 211 "Constrained-Node Networks" register in the (proposed) special use 212 domain name [RFC6761] "services.arpa", and let the DNS-SD Service 213 Registration server handle rewriting that to a different domain if 214 necessary. 216 2.3. How to publish it 218 It is possible to issue a DNS Update that does several things at 219 once; this means that it's possible to do all the work of adding a 220 PTR resource record to the PTR RRset on the Service Name if it 221 already exists, or creating one if it doesn't, and creating or 222 updating the Service Instance Name and Host Description in a single 223 transaction. 225 A Registration is therefore implemented as a single DNS Update 226 message that contains a service's Service Discovery records, Service 227 Description records, and Host Description records. 229 Updates done according to this specification are somewhat different 230 than regular DNS Updates as defined in RFC2136. RFC2136 assumes that 231 updating is a fairly heavyweight process, so you might first attempt 232 to add a name if it doesn't exist, and then in a second message 233 update the name if it does exist but matches certain preconditions. 234 Because the registration protocol uses a single transaction, some of 235 this adaptability is lost. 237 In order to allow updates to happen in a single transaction, 238 Registrations do not include update constraints. The constraints 239 specified in Section 2.4.2 are implicit in the processing of 240 Registrations, and so there is no need for the service sending the 241 Registration to put in any explicit constraints. 243 2.3.1. How DNS-SD Service Registration differs from standard RFC2136 244 DNS Update 246 DNS-SD Service Registration is based on standard RFC2136 DNS Update, 247 with some differences: 249 o It implements first-come first-served name allocation, protected 250 using SIG(0). 252 o It enforces policy about what updates are allowed. 254 o It optionally performs rewriting of "services.arpa" to some other 255 domain. 257 o It optionally performs automatic population of the address-to-name 258 reverse mapping domains. 260 o A DNS-SD Service Registration server is not required to implement 261 general DNS Update prerequsite processing. 263 o Simplified clients are allowed to send updates to an anycast 264 address, for names ending in "services.arpa" 266 2.3.2. Testing using standard RFC2136-compliant servers 268 It may be useful to set up a DNS server for testing that does not 269 implement the Registration protocol. This can be done by configuring 270 the server to listen on the anycast address, or advertising it in the 271 _dns-update._udp SRV record. It must be configured to be 272 authoritative for "services.arpa", and to accept updates from hosts 273 on local networks for names under "services.arpa" without 274 authentication. 276 A server configured in this way will be able to successfully accept 277 and process Registrations from services that send Registrations. 278 However, no constraints will be applied, and this means that the test 279 server will accept internally inconsistent Registrations, and will 280 not stop two Registrations, sent by different services, that claim 281 the same name(s), from overwriting each other. 283 2.3.3. How to allow services to update standard RFC2136-compliant 284 servers 286 Ordinarily Registrations will fail when sent to any non-Registration 287 Protocol server because the zone being updated is "services.arpa", 288 and no DNS server that is not a Registration Protocol server should 289 normally be configured to be authoritative for "services.arpa". 290 Therefore, a service that sends a Registration can tell that the 291 receiving server does not support the Registration Protocol, but does 292 support RFC2136, because the RCODE will either be NOTZONE, NOTAUTH or 293 REFUSED, or because there is no response to the update request (when 294 using the anycast address) 296 In this case a service MAY attempt to register itself using regular 297 RFC2136 DNS updates. To do so, it must discover default registration 298 zone and the DNS server designated to receive updates for that zone, 299 as described earlier using the _dns-update._udp SRV record. It can 300 then make the update using the port and host pointed to by the SRV 301 record, and should use appropriate constraints to avoid overwriting 302 competing records. Such updates are out of scope for the DNSSD 303 Registration Protocol, and a service that implements the DNSSD 304 Registration Protocol MUST first attempt to use the Registration 305 Protocol to register itself, and should only attempt to use RFC2136 306 backwards compatibility if that fails. 308 2.4. How to secure it 310 Traditional DNS update is secured using the TSIG protocol, which uses 311 a secret key shared between the client (which issues the update) and 312 the server (which authenticates it). This model does not work for 313 automatic service registration. 315 The goal of securing the DNS-SD Registration Protocol is to provide 316 the best possible security given the constraint that service 317 registration has to be automatic. It is possible to layer more 318 operational security on top of what we describe here, but what we 319 describe here improves upon the security of mDNS. The goal is not to 320 provide the level of security of a network managed by a skilled 321 operator. 323 2.4.1. First-Come First-Served Naming 325 First-Come First-Serve naming provides a limited degree of security: 326 a service that registers its service using DNS-SD Registration 327 protocol is given ownership of a name for an extended period of time 328 based on the key used to authenticate the DNS Update. As long as the 329 registration service remembers the Service Instance Name and the key 330 used to register that Service Instance Name, no other service can add 331 or update the information associated with that Service Instance Name. 333 2.4.1.1. Service Behavior 335 The service generates a public/private key pair. This key pair MUST 336 be stored in stable storage; if there is no writable stable storage 337 on the client, the client MUST be pre-configured with a public/ 338 private key pair that can be used. 340 When sending DNS updates, the service includes a KEY record 341 containing the public portion of the key in each Host Description 342 update. The update is signed using SIG(0), using the private key 343 that corresponds to the public key in the KEY record. The lifetimes 344 of the records in the update is set using the EDNS(0) Update Lease 345 option. 347 The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT records 348 [RFC6763] is typically set to two hours. This means that if a device 349 is disconnected from the network, it does not appear in the user 350 interfaces of devices looking for services of that type for too long. 352 However, the lifetime of its KEY record should be set to a much 353 longer time, typically 14 days. The result of this is that even 354 though a device may be temporarily unplugged, disappearing from the 355 network for a few days, it makes a claim on its name that lasts much 356 longer. 358 This way, even if a device is unplugged from the network for a few 359 days, and its services are not available for that time, no other 360 rogue device can come along and immediately claim its name the moment 361 it disappears from the network. In the event that a device is 362 unplugged from the network and permanently discarded, then its name 363 is eventually cleaned up and made available for re-use. 365 2.4.2. Registration Server Behavior 367 The Registration server checks each update in the Registration to see 368 that it contains a Service Discovery update, a Service Description 369 update, and a Host Description update. 371 An update is a Service Discovery update if it contains 373 o exactly one RRset update, 374 o which is for a PTR RR, 375 o which points to a Service Instance Name 376 o for which an update is present in the Registration. 378 An update is a Service Description update if, for the appropriate 379 Service Instance Name, it contains 381 o exactly one "Delete all RRsets from a name" update, 382 o exactly one SRV RRset update, 383 o one or more TXT RRset updates, 384 o and the target of the SRV record update references a hostname for 385 which there is a Host Description update in the Registration. 387 An update is a Host Description update if, for the appropriate 388 hostname, it contains 390 o exactly one "Delete all RRsets from a name" update, 391 o A or AAAA RR update(s) 392 o a KEY RR update that adds a KEY RR that contains the public key 393 corresponding to the private key that was used to sign the 394 message, 395 o there is a Service Instance Name update in the Registration that 396 updates an SRV RR so that it points to the hostname being updated 397 by this update. 399 A Registration MUST include at least one Service Name update, at 400 least one Service Description update, and exactly one Host 401 Description update. An update message that does not is not a 402 Registration. An update message that contains any other updates, or 403 any update constraints, is not a Registration. Such messages should 404 either be processed as regular RFC2136 updates, including access 405 control checks and constraint checks, if supported, or else rejected 406 with RCODE=REFUSED. 408 Note that if the definitions of each of these update types are 409 followed carefully, this means that many things that look very much 410 like Registrations nevertheless are not. For example, a Registration 411 that contains an update to a Service Name and an update to a Service 412 Instance Name, where the Service Name does not reference the Service 413 Instance Name, is not a valid Registration message, but may be a 414 valid RFC2136 update. 416 Assuming that an update message has been validated with these 417 conditions and is a valid Registration, the server checks that the 418 name in the Host Description update exists. If so, then the server 419 checks to see if the KEY record on the name is the same as the KEY 420 record in the update. If it is not, then the server MUST reject the 421 Registration with the YXDOMAIN RCODE. 423 Otherwise, the server validates the update using SIG(0) on the public 424 key in the KEY record of the Host Description update. If the 425 validation fails, the server MUST reject the rejectration rejected 426 with the REFUSED RCODE. Otherwise, the update is considered valid 427 and authentic, and is processed according to the method described in 428 RFC2136. The status that is returned depends on the result of 429 processing the update. 431 The server MAY add a Reverse Mapping that corresponds to the Host 432 Description. This is not required because the Reverse Mapping serves 433 no protocol function, but it may be useful for debugging, e.g. in 434 annotating network packet traces or logs. 436 The server MAY apply additional criteria when accepting updates. In 437 some networks, it may be possible to do out-of-band registration of 438 keys, and only accept updates from pre-registered keys. In this 439 case, an update for a key that has not been registered should be 440 rejected with the REFUSED RCODE. 442 There are at least two benefits to doing this rather than simply 443 using normal SIG(0) DNS updates. First, the same registration 444 protocol can be used in both cases, so both use cases can be 445 addressed by the same service implementation. Second, the 446 registration protocol includes maintenance functionality not present 447 with normal DNS updates. 449 Note that the semantics of using the Registration Protocol in this 450 way are different than for typical RFC2136 implementations: the KEY 451 used to sign the update in the Registration Protocol only allows the 452 client to update records that refer to its Host Description. RFC2136 453 implementations do not normally provide a way to enforce a constraint 454 of this type. 456 The server may also have a dictionary of names or name patterns that 457 are not permitted. If such a list is used, updates for Service 458 Instance Names that match entries in the dictionary are rejected with 459 YXDOMAIN. 461 2.5. TTL Consistency 463 All RRs within an RRset are required to have the same TTL 464 (Clarifications to the DNS Specification [RFC2181], Section 5.2). In 465 order to avoid inconsistencies, the Registration Protocol places 466 restrictions on TTLs sent by services and requires that Registration 467 Protocol Servers enforce consistency. 469 Services sending Registrations MUST use consistent TTLs in all RRs 470 within the Registration. 472 Registration Protocol servers MUST check that the TTLs for all RRs 473 within the Registration are the same. If they are not, the 474 Registration MUST be rejected with a REFUSED RCODE. 476 Additionally, when adding RRs to an RRset, for example when 477 processing Service Discovery records, the server MUST use the same 478 TTL on all RRs in the RRset. How this consistency is enforced is up 479 to the implementation. 481 2.6. Maintenance 483 2.6.1. Cleaning up stale data 485 Because the DNS-SD registration protocol is automatic, and not 486 managed by humans, some additional bookkeeping is required. When an 487 update is constructed by the client, it MUST include include an 488 EDNS(0) Update Lease Option [I-D.sekar-dns-ul]. The Update Lease 489 Option contains two lease times: the Update Lease Time and the 490 Instance Lease Time. 492 These leases are promises, similar to DHCP leases [RFC2131], from the 493 client that it will send a new update for the service registration 494 before the lease time expires. The Update Lease time is chosen to 495 represent the time after the update during which the registered 496 records other than the KEY record should be assumed to be valid. The 497 Instance Lease time represents the time after the update during which 498 the KEY record should be assumed to be valid. 500 The reasoning behind the different lease times is discussed in the 501 section on first-come, first-served naming Section 2.4.1. DNS-SD 502 Registration Protocol servers may be configured with limits for these 503 values. A default limit of two hours for the Update Lease and 14 504 days for the SIG(0) KEY are currently thought to be good choices. 505 Clients that are going to continue to use names on which they hold 506 leases should update well before the lease ends, in case the 507 registration service is unavailable or under heavy load. 509 The Registration Protocol server MUST include an EDNS(0) Update Lease 510 option in the response if the lease time proposed by the service has 511 been shortened. The service MUST check for the EDNS(0) Update Lease 512 option in the response and MUST use the lease times from that option 513 in place of the options that it sent to the server when deciding when 514 to update its registration. 516 Clients should assume that each lease ends N seconds after the update 517 was first transmitted, where N is the lease duration. Servers should 518 assume that each lease ends N seconds after the update that was 519 successfully processed was received. Because the server will always 520 receive the update after the client sent it, this avoids the 521 possibility of misunderstandings. 523 DNS-SD Registration Protocol servers MUST reject updates that do not 524 include an EDNS(0) Update Lease option. Dual-use servers MAY accept 525 updates that don't include leases, but SHOULD differentiate between 526 DNS-SD registration protocol updates and other updates, and MUST 527 reject updates that are known to be DNS-SD Registration Protocol 528 updates if they do not include leases. 530 2.6.2. Sleep Proxy 532 Another use of Service Registration Protocol is for devices that 533 sleep to reduce power consumption. 535 In this case, in addition to the DNS Update Lease option 536 [I-D.sekar-dns-ul] described above, the device includes an EDNS(0) 537 OWNER Option [I-D.cheshire-edns0-owner-option]. 539 The EDNS(0) Update Lease option constitutes a promise by the device 540 that it will wake up before this time elapses, to renew its 541 registration and thereby demonstrate that it is still attached to the 542 network. If it fails to renew the registration by this time, that 543 indicates that it is no longer attached to the network, and its 544 registration (except for the KEY in the Host Description) should be 545 deleted. 547 The EDNS(0) OWNER Option indicates that the device will be asleep, 548 and will not be receptive to normal network traffic. When a DNS 549 server receives a DNS Update with an EDNS(0) OWNER Option, that 550 signifies that the Registration Protocol server should set up a proxy 551 for any IPv4 or IPv6 address records in the DNS Update message. This 552 proxy should send ARP or ND messages claiming ownership of the IPv4 553 and/or IPv6 addresses in the records in question. In addition, proxy 554 should answer future ARP or ND requests for those IPv4 and/or IPv6 555 addresses, claiming ownership of them. When the DNS server receives 556 a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6 557 addresses for which it proxying, it should then wake up the sleeping 558 device using the information in the EDNS(0) OWNER Option. At present 559 version 0 of the OWNER Option specifies the "Wake-on-LAN Magic 560 Packet" that needs to be sent; future versions could be extended to 561 specify other wakeup mechanisms. 563 Note that although the authoritative DNS server that implements the 564 DNSSD Service Registration Protocol function need not be on the same 565 link as the sleeping host, the Sleep Proxy must be on the same link. 567 3. Security Considerations 569 DNS-SD Service Registration Protocol updates have no authorization 570 semantics other than first-come, first-served. This means that if an 571 attacker from outside of the administrative domain of the server 572 knows the server's IP address, it can in principle send updates to 573 the server that will be processed successfully. Servers should 574 therefore be configured to reject updates from source addresses 575 outside of the administrative domain of the server. 577 For Anycast updates, this validation must be enforced by every router 578 that connects the CDN to the unconstrained portion of the network. 579 For TCP updates, the initial SYN-SYN+ACK handshake prevents updates 580 being forged from off-network. In order to ensure that this 581 handshake happens, Service Discovery Protocol servers MUST NOT accept 582 0-RTT TCP payloads. 584 Note that these rules only apply to the validation of DNS-SD 585 registration protocol updates. A server that accepts updates from 586 DNS-SD registration protocol clients may also accept other DNS 587 updates, and those DNS updates may be validated using different 588 rules. However, in the case of a DNS service that accepts automatic 589 updates, the intersection of the DNS-SD service registration update 590 rules and whatever other update rules are present must be considered 591 very carefully. 593 For example, a normal, authenticated RFC2136 update to any RR that 594 was added using the Registration protocol, but that is authenticated 595 using a different key, could be used to override a promise made by 596 the registration protocol, by replacing all or part of the service 597 registration information with information provided by a different 598 client. An implementation that allows both kinds of updates should 599 not allow updates to records added by Registrations using different 600 authentication and authorization credentials. 602 4. Privacy Considerations 604 5. Acknowledgments 606 Thanks to Toke Hoeiland-Joergensen for a thorough technical review, 607 to Tamara Kemper for doing a nice developmental edit, Tim Wattenberg 608 for doing a service implementation at the Montreal Hackathon at IETF 609 102, and [...] more reviewers to come, hopefully. 611 6. References 613 6.1. Normative References 615 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 616 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 617 . 619 [I-D.sekar-dns-ul] 620 Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 621 ul-01 (work in progress), August 2006. 623 6.2. Informative References 625 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 626 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 627 . 629 [RFC1035] Mockapetris, P., "Domain names - implementation and 630 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 631 November 1987, . 633 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 634 RFC 2131, DOI 10.17487/RFC2131, March 1997, 635 . 637 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 638 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 639 RFC 2136, DOI 10.17487/RFC2136, April 1997, 640 . 642 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 643 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 644 . 646 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 647 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 648 2000, . 650 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 651 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 652 . 654 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 655 DOI 10.17487/RFC3152, August 2001, 656 . 658 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 659 to Replace the AppleTalk Name Binding Protocol (NBP)", 660 RFC 6760, DOI 10.17487/RFC6760, February 2013, 661 . 663 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 664 RFC 6761, DOI 10.17487/RFC6761, February 2013, 665 . 667 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 668 DOI 10.17487/RFC6762, February 2013, 669 . 671 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 672 Constrained-Node Networks", RFC 7228, 673 DOI 10.17487/RFC7228, May 2014, 674 . 676 [I-D.ietf-dnssd-hybrid] 677 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 678 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 679 progress), March 2018. 681 [I-D.ietf-dnssd-push] 682 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 683 draft-ietf-dnssd-push-14 (work in progress), March 2018. 685 [I-D.cheshire-dnssd-roadmap] 686 Cheshire, S., "Service Discovery Road Map", draft- 687 cheshire-dnssd-roadmap-01 (work in progress), March 2018. 689 [I-D.cheshire-edns0-owner-option] 690 Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 691 cheshire-edns0-owner-option-01 (work in progress), July 692 2017. 694 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 695 Networking: The Definitive Guide", O'Reilly Media, Inc. , 696 ISBN 0-596-10100-7, December 2005. 698 Authors' Addresses 699 Stuart Cheshire 700 Apple Inc. 701 One Apple Park Way 702 Cupertino, California 95014 703 USA 705 Phone: +1 408 974 3207 706 Email: cheshire@apple.com 708 Ted Lemon 709 Nibbhaya Consulting 710 P.O. Box 958 711 Brattleboro, Vermont 05302 712 United States of America 714 Email: mellon@fugue.com