]> Apple Inc

mellon@fugue.com

Silicon Labs

somebody@example.com

INT DNSSD DNSSD mDNS DNS DNS Service Discovery provides several mechanisms whereby hosts can discover and advertise services on an IP network. Such discovery can be done using Multicast DNS (mDNS) or DNS, and advertising can be done with DNSSD Service Registration Protocol (SRP) or mDNS. This document describes a way to provide a unified DNSSD proxy service that allows hosts to advertise services using SRP and discover services using unicast DNS via a Discovery Proxy rather than using of mDNS, in scenarios where mDNS is currently the only option. About This Document Status information for this document may be found at . Discussion of this document takes place on the DNSSD Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction DNS Service Discovery (DNS-SD) is a general mechanism for advertising and discovering services on IP networks. mDNS is a commonly used transport for DNS-SD. However, it has several shortcomings: it relies entirely on multicast, which works somewhat poorly on WiFi networks. Devices publishing services have to always be available to answer mDNS queries, which can have significant battery impact. When doing service discovery, such devices may do WiFi beacon skipping to save power, and in so doing, miss a large percentage of multicast traffic, making mDNS unreliable. To address this, this document describes a way of combining several existing technologies to reduce reliance on multicast. This can be done in, for example, a CE router , or a SNAC Router . It can actually be done in any device that is expected to be continuously operational on a network link and has sufficient resources to provide the service. There are four logical parts to the service: - The DNS zone in which DNSSD information will be stored - The SRP service, which is used to add and update services in the DNS zone - The Advertising Proxy service, which advertises the contents of the zone using mDNS on the infrastructure link - The Discovery Proxy , which enables discovery of local services that are advertised using mDNS using the unicast DNS protocol. In addition, the service must be advertised so that devices that would like to make use of it can discover it.

Previous work This specification relies on existing technology and makes reference to that technology assuming that the reader is already familiar with it. Readers should familiarize themselves with at least the following documents.

• The DNS specification which discusses DNS zones
• The SRP specificaiton which explains how to register services in the DNS without a pre-shared key
• The Advertising Proxy specification which explains how to advertise the contents of a DNS zone using mDNS
• The Discovery Proxy specification which describes how to discover mDNS services on a link using DNS queries
• The DNS Push Specification which describes how to efficiently do long-lived DNS queries
• The DNS-SD specification which describes how to discover services using the DNS and mDNS protocols

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Modes of deployment This service can be deployed either as a centralized service provided by infrastructure, or as an ad-hoc service that takes advantage of infrastructure but is not part of infrastructure. An example of the first would be a Customer Edge router (CE Router) . CE routers are typically autonomously operating devices--although they can be configured by the end user, this is not typical. However, since they are the basis for the network infrastructure of a home network, we think of DNSSD service provided by a CE router as network infrastructure. An example of a device that provides full DNSSD service on an ad-hoc basis would be a SNAC router. SNAC routers connect infrastructure networks to stub networks on an ad-hoc basis and provide all four of the services required for DNSSD service to the SNAC network, but only provide Advertising Proxy service to the infrastructure network. This means that devices on infrastructure can discover devices on the stub network, but not to register with SRP service nor use the SNAC advertising proxy. A SNAC router that implements the behavior described in this document no longer has this limitation.

Content of Service Advertisement The goal of advertising the service is to provide sufficient information that, having resolved the service advertisement, a user of the service has all the information needed to use the service. This includes at least:

• Name of the domain to use for service discovery
• Name of the domain to use for service registration
• Name of the host providing the DNSSD service
• Ports to use for the UDP DNS protocol when communicating with the service

Service Advertisement on Infrastructure Service advertisement on infrastructure is provided using the 'dnssd.service.arpa.' domain. This is a locally-served domain . The local DNS resolver on infrastructure MUST answer authoratively for queries in the dnssd.service.arpa zone. Because this is an infrastructure-provided service, infrastructure advertises only one service instance, with the service instance name "infrastructure." Therefore, an infrastructure-provided DNSSD service advertises the infrastructure service instance in dnssd.service.arpa as follows: The infrastructure DNSSD service MUST support . Therefore, this query can be done as a single multi-qtype query. Typical DNS servers will, when answering an SRV query, include additional data containing address pp 4-5. In such situations, if the DNSSD service is provided by infrastructure, all of the information required to discover it will be returned in response to a single query.

Ad-Hoc Service Advertisement What we mean by "ad hoc" is something that is not integrated into infrastructure. Ad hoc servers do not have control of the local DNS resolver, and therefore cannot be discovered using DNS, and must instead be discovered using mDNS. Because there is no coordination, it is possible (and in some cases likely) that there will be more than one such server, so the service instance name should be handled normally section 4.1.1. Therefore, when advertising with mDNS, the service instance will be advertised as follows:

Content of SRV record mDNS APIs typically do not provide a way of setting the priority and weight of the SRV record, and the infrastructure service always has the highest priority. Therefore, these fields SHOULD be set to zero, and MUST be ignored. The reason they MUST be ignored is that since they SHOULD be zero, and most devices will not be able to set them to any other value, treating them as described in presents an opportunity for an attack by advertising a service with a weight of 65535. The port field should be set to the UDP port on which SRP service is provided. The target is the hostname of the host providing the service.

Content of the TXT record TXT records are made up of a series of name=value pairs. The following names are defined: srp-tcp='port': the port number to use for SRP registrations using the DNS Protocol over TCP. If not present, this service is assumed to be available on the port provided in the SRV record. dns-udp='port': the port number to use for DNSSD queries using the DNS protocol over UDP. If not present, this service is assumed to be available on the port provided in the SRV record. dns-tcp='port': the port number to use for DNSSD queries using the DNS protocol over TCP. If not present, this service is assumed to be available on the port provided in the SRV record. srp-tls='port': the port number to use for SRP registrations using TLS. If not present, port 853 is assumed. dns-tls='port': the port number to use for DNSSD queries using the DNS protocol over TLS. If not present, port 853 is assumed. reg-dn='domain': the domain name to use in SRP registrations. If not present, default.service.arpa is assumed. domains='domain-list': a comma-separated list of domains in which service discovery is available. If not present, dnssd.service.arpa and local are assumed to be the only domains. 'domain'='ip-subnet-list': a link-specific domain that can be used to query services on that specific IP link. The link is identified by a comma-separated list of IPv4 and/or IPv6 prefixes that are present on that link. See . priority='priority': a priority for this service. See

Interface-specific domains A DNSSD service may support link-specific discovery proxy service. In such cases, each IP link must have its own unique domain, which is specific to the individual DNSSD service. Each such domain must have an name=value entry in the TXT record. This entry has as its name a domain name. Its value is a comma-separated list of IP prefixes that are on-link for the IP link identified by the domain. IP subnets are in the form 'IP address'/'prefix-length'. IP addresses are represented according to the IP address family. IPv4 addresses are in the dotted-decimal format as defined in in the section titled GRAMMATICAL HOST TABLE SPECIFICATION, in subsection A under 'address'. IPv6 addresses are represented as described in . As a special (common) case, if the service only provides discovery proxy for a single link, and that is the link on which the DNSSD service is advertised, discovery of services on that link can use the "local" domain. In this case, no domains will be listed in the TXT record; if "local" discovery is to be supported alongside other domains, then the "local" domain must be included in the TXT record. If a service DNSSD service is advertised on more than one link, the local domain is specific to the link for which the destination address for the query is on-link. If the destination address is not on-link for any link, queries in .local are not valid and MUST be responded to with the REFUSED response code.

Service Priority Infrastructure service is always the highest priority, and there can be only one such service. When infrastructure service is discovered, this is done using infrastructure. Consequently there is no need to try to discover an ad hoc service, and no need to choose amongst services. The infrastructure service therefore MUST NOT include a priority. Ad-hoc servers SHOULD include a priority. If a priority is not included, the priority of the Ad-Hoc service is assumed to be 65535. Services should choose a priority based on their capabilities. The following priorities are defined: 0: Server is not constrained and is connected to a high-speed wired network link (that is, not WiFi, probably Ethernet or a fiber optic network). 100: Server is not constrained and is connected to a WiFi link 200: Server is constrained, but otherwise well able to provide service. 65535: Server can provide service if needed, but should not be preferred.

Discovering the DNSSD service A host that wishes to use the DNSSD service must first discover it. Discovery follows a series of steps:

1. Attempt to discover an infrastructure-provided DNSSD service
2. Failing that, browse for a list of Ad-Hoc services.
3. If one or more Ad-Hoc services are returned by the browse, choose one using the priority specified in the TXT record.
4. If no server is discovered, or if no discovered server appears to work, fall back to mDNS-based DNSSD service

Advertising using RAs DNSSD servers that send RAs MUST include a DNSSD-Service RA option in RAs that they send when the DNSSD service is active. DNSSD clients can distinguish infrastructure DNSSD service from ad-hoc service because infrastructure routers have nonzero lifetimes. It can be the case that there is more than one infrastructure router. In some cases these routers will be part of a managed infrastructure, in which case DNSSD service provided by these routers MUST be a common service.

Dual-homed infrastructure DNSSD service In a dual-homed network, there is more than one default router and potentially more than one DNSSD service. In the case of managed networks, the network operator MUST ensure that there is a single DNSSD service, even if it is advertised by more than one default router.

Unmanaged networks In an unmanaged network, there is no way for the operator to decide which default router will provide the DNSSD service when more than one default router is able to do so. So we have the following options:

1. One router defers to the other
2. The routers share a common DNS zone either using SRP replication or DNS zone transfers with secondary failover
3. SRP clients are required to register with both services

Practically speaking option 3 is the only easy option, although it places a greater burden on the client. With option 1, the SRP client may take some time to notice that an SRP service has gone away and then reregister, and this is not ideal. Option 2 requires mechanisms that are not yet described in a standard. Consequently, when more than one infrastructure DNSSD service is present, consumers of the DNSSD service that will register their service using SRP MUST register with all infrastructure DNSSD servers.

Security Considerations TODO Security

IANA Considerations ALlocate 'service-name', "_dnssd-server" is preferred

References Normative References This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204. Apple Inc. Google LLC This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations. Apple Inc. Apple Inc. An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNS-SD Service Registration Protocol (SRP), using multicast DNS. This allows legacy clients to discover services registered with SRP using multicast DNS. This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet Systems Consortium, Inc. This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0). This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Informative References Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice.

Acknowledgments TODO acknowledge.