Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. Intended status: Informational T. Lemon Expires: January 3, 2018 Nominum, Inc. July 2, 2017 Service Registration Protocol for DNS-Based Service Discovery draft-sctl-service-registration-00 Abstract The DNS-SD Service Registration Protocol provides a way to perform DNS-Based Service Discovery using only unicast packets. This eliminates the dependency on Multicast DNS as the foundation layer, which has worked well in some environments, like the simplest of home networks, but not in others, like large enterprise networks (where multicast does not scale well to thousands of devices) and mesh networks (where multicast and broadcast are supported poorly, if at all). Broadly speaking, the DNS-SD Service Registration Protocol is DNS Update, with a few additions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Cheshire & Lemon Expires January 3, 2018 [Page 1] Internet-Draft Service Registration Protocol July 2017 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction DNS-Based Service Discovery [RFC6763] is a component of Zero Configuration Networking [RFC6760] [ZC] [Roadmap]. There are two facets of DNS-Based Service Discovery to consider: how relevant information makes its way into the DNS namespace (how a server offers its services to interested clients) and how clients access that information (how an interested client discovers and uses a service instance). This document is concerned with the first of those two facets: how relevant information makes its way into the DNS namespace. In the DNS-Based Service Discovery specification [RFC6763] Section 10 "Populating the DNS with Information" briefly discusses ways that relevant information can make its way into the DNS namespace. In the case of Multicast DNS [RFC6762], the relevant information trivially becomes visible in the ".local" namespace by virtue of devices answering for themselves. For unicast DNS names, ways that information makes its way into the DNS namespace include manual configuration of DNS zone files, possibly assisted using tools such as the "dns-sd -Z" command, automated tools such as a Discovery Proxy [DisProx], or explicit registration by the services themselves. It is the last option -- explicit registration by the services themselves -- that is the subject of this document. Cheshire & Lemon Expires January 3, 2018 [Page 2] Internet-Draft Service Registration Protocol July 2017 2. Service Registration Protocol The DNS-SD Service Registration Protocol is largely built on DNS Update [RFC2136] [RFC3007], with some additions. When a device advertises services using Multicast DNS, the parent domain is implicitly ".local". When a device advertises services in the traditional unicast DNS namespace, it needs to know the parent domain name for its services. This parent domain can be manually configured by a human operator, or learned from the network. In the DNS-SD specification [RFC6763] section 11, "Discovery of Browsing and Registration Domains (Domain Enumeration)", describes how a client device can learn a recommended default registration domain from the network. In the remainder of this document, Section 3 covers cleanup of stale data, and Section 4 covers advertising services on behalf of devices that are sleeping to reduce power consumption. The final question is security. Most dynamic DNS servers will not accept unauthenticated updates. In the case of manual configuration of registration domain by a human operator, the human operator can also configure an appropriate TSIG security key. In the case of automatic configuration via DNS-SD Domain Enumeration queries, it would be nice to also have zero-configuration security. While at first glance zero-configuration security may seem to be a self- contradiction, this document proposes a simple first-come first- served security mechanism, described below in Section 5. Cheshire & Lemon Expires January 3, 2018 [Page 3] Internet-Draft Service Registration Protocol July 2017 3. Cleanup of Stale Data The traditional DNS Update mechanisms [RFC2136] [RFC3007] implicitly assume they are being used by a human operator. If a human operator uses DNS Update (perhaps via the 'nsupdate' command) to create a record, then that record should stay created until the human operator decides to remove it. The same assumptions do not apply to machine-generated records. If a mobile device creates one or more records using DNS Update, and later unceremoniously departs the network, then those stale records should eventually be removed. The mechanism proposed here is modeled on DHCP. Just like a DHCP address lease, a record created using DNS Update has a lifetime. If the record is not refreshed before its lifetime expires, then the record is deleted. When a client performs a DNS Update, it includes a EDNS(0) Update Lease option [DNS-UL]. The DNS Update Lease option indicates the requested lifetime of the records created or updated in the associated DNS Update message. In the DNS Update reply, the server returns its own EDNS(0) Update Lease option indicating the granted lifetime, which may be shorter, the same, or longer than the client requested. If the records are not refreshed before the granted lifetime expires, then the records are deleted. DNS servers may be configured to refuse DNS Updates that do not include a DNS Update Lease option. Cheshire & Lemon Expires January 3, 2018 [Page 4] Internet-Draft Service Registration Protocol July 2017 4. Sleep Proxy Another use of Service Registration Protocol is for devices that sleep to reduce power consumption. In this case, in addition to the DNS Update Lease option [DNS-UL] described above, the device includes an EDNS(0) OWNER Option [Owner]. The DNS Update Lease option constitutes a promise by the device that it will wake up before this time elapses, to renew its records and thereby demonstrate that it is still attached to the network. If it fails to renew the records by this time, that indicates that it is no longer attached to the network, and its records should be deleted. The EDNS(0) OWNER Option indicates that the device will be asleep, and will not be receptive to normal network traffic. When a DNS server receives a DNS Update with an EDNS(0) OWNER Option, that signifies that the DNS server should act as a proxy for any IPv4 or IPv6 address records in the DNS Update message. This means that the DNS server should send ARP or ND messages claiming ownership of the IPv4 and/or IPv6 addresses in the records in question. In addition, the DNS server should answer future ARP or ND requests for those IPv4 and/or IPv6 addresses, claiming ownership of them. When the DNS server receives a TCP SYN or UDP packet addressed to one of the IPv4 or IPv6 addresses for which it proxying, it should then wake up the sleeping device using the information in the EDNS(0) OWNER Option. At present version 0 of the OWNER Option specifies the "Wake-on-LAN Magic Packet" that needs to be sent; future versions could be extended to specify other wakeup mechanisms. Cheshire & Lemon Expires January 3, 2018 [Page 5] Internet-Draft Service Registration Protocol July 2017 5. First-Come First-Served Naming In some environments, such as home networks with an appropriate border gateway, it may be preferable to have some limited security on the protected internal network rather than no security at all. Users have shown limited willingness to endure complicated configuration for their networked home devices. It is rare for home users to change even the factory-default name for their wireless printer, so it's questionable whether it's reasonable to expect them to configure passwords or security keys. This document presents a zero-configuration first-come first-served naming mechanism. Instead of requiring a preconfigured key installed by manual administration, a new device optimistically creates its DNS Service Discovery records, plus a DNS SIG(0) public key, using a DNS Update signed with its DNS SIG(0) private key. The DNS server validates the signature on the message using the SIG(0) key already stored on the name, if present, and otherwise with the key sent in the update, if the requested name is not yet present. The server may check that the two public keys are the same before validating, and refuse the update if they are not, to avoid the cost of verifying the signature. The lifetime of the DNS-SD PTR, SRV and TXT records [RFC6763] is typically set to two hours. That way, if a device is disconnected from the network, its stale data does not persist for too long, advertising a service that is not accessible. However, the lifetime of its DNS SIG(0) public key should be set to a much longer time, typically 14 days. The result of this is that even though a device may be temporarily unplugged, disappearing from the network for a few days, it makes a claim on its name that lasts much longer. This way, even if a device is unplugged from the network for a few days, and its services are not available for that time, no other rogue device can come along and immediately claim its name the moment it disappears from the network. It takes a much longer time before an abandoned name becomes available for re-use. When using this first-come first-served security mechanism, the server accepting or rejecting the updates utilizes knowledge of the DNS-Based Service Discovery semantics [RFC6763]. Specifically, for all records aside from PTR records, the update must be validly signed Cheshire & Lemon Expires January 3, 2018 [Page 6] Internet-Draft Service Registration Protocol July 2017 using the SIG(0) key with the same DNS resource record owner name (the name on the left in a traditional textual zone file). For additions or deletions of PTR records, the update must be validly signed using the SIG(0) key with the same DNS resource record owner name as the rdata in the PTR record (the name on the right in a traditional textual zone file). 6. Security Considerations To be completed. Cheshire & Lemon Expires January 3, 2018 [Page 7] Internet-Draft Service Registration Protocol July 2017 7. References 7.1. Normative References [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . 7.2. Informative References [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", draft-ietf-dnssd-hybrid-06 (work in progress), March 2017. [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- ul-01 (work in progress), August 2006. [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- cheshire-dnssd-roadmap-00 (work in progress), July 2017. [Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- cheshire-edns0-owner-option-01 (work in progress), July 2017. [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc. , ISBN 0-596-10100-7, December 2005. Cheshire & Lemon Expires January 3, 2018 [Page 8] Internet-Draft Service Registration Protocol July 2017 Authors' Addresses Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, California 94065 United States of America Phone: +1 650 381 6000 Email: ted.lemon@nominum.com Cheshire & Lemon Expires January 3, 2018 [Page 9]