IEEE 2030.5 specifies DNS-based methods for service discovery, resource discovery, and hostname to IP address resolution. A service is defined as an application instance uniquely identified by {host, port, protocol}, where protocol in this case is IEEE 2030.5 plus its underlying transport bindings (e.g., HTTP(S)/TCP/IP). DNS-based Service Discovery (DNS-SD) (IETF RFC 6763) is a conventional use of existing DNS name syntax and message and record formats (PTR, SRV, TXT) to discover instances of a given service within a given domain. In IEEE 2030.5, DNS-SD (IETF RFC 6763) is used to describe the location of function sets and groups of resources by supplying the host, port, and protocol of the supporting servers along with additional details provided by those servers.
DNS-SD specifies that a DNS SRV and TXT record pair are used to describe a service instance. Both records have an identical Service Instance Name of the form “<Instance>.<Service>.<Domain>”. The SRV record contains the hostname and port of the service, while the TXT record may contain additional variables (such as a relative path) in text form. A service plus a path forms a URI and can be used to locate a resource. A client discovers instances of a given service or resource type by sending a query for a DNS PTR record with the name “<Service>.<Domain>”, which returns a set of zero or more Service Instance Names of DNS SRV/TXT record pairs for the requested service or resource type.
Multicast DNS (mDNS) IETF RFC 6762 provides the ability to perform DNS-like queries on the local link in the absence of any conventional unicast DNS server. In addition, mDNS reserves the top-level DNS
domain ".local." to name services that have link-local scope. mDNS employs link-local multicast addressing for requests and either multicast or unicast addressing for responses in support of service discovery. IPv6 address scoping is used to specify reachability and includes address types for global, site- local, and link-local addressing (IETF RFC 4291).
Extended Multicast DNS (xmDNS) (IETF Extended Multicast DNS Internet Draft) extends the scope of mDNS beyond the local link through the use of site-local multicast requests and responses. In addition, xmDNS reserves the top-level DNS domain ".site." to name services that have site-local scope. The site- local multicast address FF05::FB is designated for Extended Multicast DNS and SHALL be used as the destination address for all xmDNS multicast requests and multicast responses. The reachability of this address is administratively defined and MAY span multiple sub-networks. IEEE 2030.5 SHALL use global addresses or Unique Local Addresses (IETF RFC 4193) in the source address of xmDNS requests and responses. Extended Multicast DNS (xmDNS) (IETF Extended Multicast DNS Internet Draft) is normative for IEEE Std 2030.5.
Guidelines on the use of unicast responses SHALL be employed as described in the xmDNS draft unless noted otherwise. xmDNS requests from HAN devices that are mains powered SHALL use site-local multicast addressing to ensure that all sub-networks within the HAN are reachable and MAY request unicast responses. Battery-operated devices in the HAN SHOULD use site-local multicast addressing for xmDNS requests and SHOULD request unicast responses. HAN devices making xmDNS requests that generate responses specific to the requesting HAN device (e.g., requests such as those requesting EndDevice servers where the particular HAN device is registered) SHALL employ site-local multicast destination addresses and SHALL request unicast responses. When a server receives a request with the QU bit set, it SHALL return a unicast response.
If a device plans to communicate outside of the local network (i.e., over the Internet), it SHOULD support unicast DNS with DNS-SD. However, it should be noted that devices may not be routable to the global Internet or may not have access to a DNS name server. Further, not all devices will support name resolution via unicast DNS and thus unicast DNS should be used carefully. Devices SHOULD NOT use unicast DNS and DNS-SD unless they have been explicitly provided a target. If it is desired for a client to communicate to a server not present on the local network, there are multiple methods to inform the client of the server, including:
Using FunctionSetAssignments on the local network to direct the client to a server not on the local network.
Communicating a DNS name out of band (e.g., at manufacture, via a user interface) and then subsequently performing DNS-SD.
Communicating a DNS name or IP address out of band (e.g., at manufacture, via a user interface), along with the necessary elements (e.g., the URI of the DeviceCapabilities resource).