DNS-Based Service Discovery
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (27)
A DNS-SD Service Name must encode both the semantics (what the service does) and the protocol (how it is implemented), not just the underlying transport mechanism. For example, iTunes music sharing uses '_daap._tcp' rather than '_http._tcp', even though it is built on HTTP, because a generic HTTP client cannot meaningfully interact with it.
Service Instance Name components are ordered '<Instance>.<Service>.<Domain>' rather than '<Domain>.<Service>.<Instance>' for three reasons: semantic clarity (instance is the most specific part), network efficiency (DNS name compression compresses the common suffix shared by all instances), and operational flexibility (the subdomain can be delegated independently of instance names).
Service Names are limited to 15 characters because of DNS domain name length constraints: the full Service Instance Name must fit within 255 bytes, and conserving bytes in the service label leaves space for descriptive service subdomains and long parent domain names. Allowing more characters would not add expressiveness but would reduce usable parent domain length.
The 'txtvers' key is recommended as the first key/value pair in TXT records to enable backwards compatibility. Authors should increment this version only when an incompatible change is unavoidable; otherwise, new capabilities are added by defining new keys that older clients silently ignore.
DNS-SD is compatible with both Multicast DNS (RFC 6762) and conventional Unicast DNS infrastructure. When used with mDNS, zero-configuration operation is possible; when used with unicast DNS, DNS Update keys are typically required for service registration. The '_tcp' and '_udp' subdomain labels may be delegated to separate DNS server hardware from the main organizational DNS.
Address-derived Domain Enumeration queries SHOULD NOT be performed for IPv4 link-local addresses (RFC 3927) or IPv6 link-local addresses (RFC 4862).
DNS-SD implementations MUST NOT emit empty (zero-string) TXT records. Clients MUST treat a single-zero-byte TXT record, an empty TXT record, and the absence of any TXT record as equivalent.
Every DNS-SD service MUST have a TXT record with the same name as its SRV record, even if the TXT record contains only a single zero byte. This gives the service explicit control over the TTL of its TXT record.
If an implementation receives a TXT record containing the same key more than once, it MUST silently ignore all occurrences after the first. Implementations MUST also silently ignore unknown keys in a service TXT record.
If client software concatenates the three components of a Service Instance Name into a single string, dots within the <Instance> portion MUST be escaped with a backslash ('.' → '\.') and backslashes must also be escaped ('\' → '\\') to preserve DNS label boundaries.
The <Instance> portion of a Service Instance Name MUST NOT contain ASCII control characters (byte values 0x00–0x1F and 0x7F); otherwise it may contain any Net-Unicode characters including spaces, dots, and non-Roman text. It is stored as a single DNS label of canonical precomposed UTF-8 (NFC).
The target host name and port number of a service MUST NOT be duplicated as key/value attributes in the TXT record; they are given exclusively by the SRV record.
TXT record keys MUST consist of printable US-ASCII characters (0x20–0x7E) excluding '=' (0x3D). Keys are case-insensitive. Strings beginning with '=' (missing key) MUST be silently ignored. Keys SHOULD be no more than nine characters long.
TXT records larger than 1300 bytes are NOT RECOMMENDED; the intended typical size is 200 bytes or less. Records over 400 bytes risk not fitting in a single 512-byte DNS message, and records over 1300 bytes risk not fitting in a single Ethernet frame.
When including a PTR record in a DNS-SD response, the server SHOULD also include the corresponding SRV record(s), TXT record(s), and all A/AAAA address records named in the SRV rdata as additional records. Clients MUST be capable of functioning correctly even if these additional records are absent.
When more than one SRV record is returned for a service instance, clients MUST correctly interpret the priority and weight fields per RFC 2782: lower-priority-number servers are preferred, and equal-priority servers are selected randomly in proportion to weight. In the common single-SRV case, both fields SHOULD be set to zero.
When used with Multicast DNS, the target host field of a placeholder flagship SRV record MUST NOT be the empty root label, because Multicast DNS conflict detection requires a real target host name to detect conflicts between different devices.
A Service Instance Name has the form '<Instance>.<Service>.<Domain>', where <Instance> is a user-friendly Net-Unicode label, <Service> is a pair of DNS labels (e.g., '_ipp._tcp'), and <Domain> is the DNS subdomain in which the service is registered. Clients discover instances by querying for PTR records at '<Service>.<Domain>'.
Domain Enumeration uses five reserved PTR query names under a given domain: 'b._dns-sd._udp', 'db._dns-sd._udp', 'r._dns-sd._udp', 'dr._dns-sd._udp', and 'lb._dns-sd._udp'. These yield recommended browsing domains, default browsing domain, registration domains, default registration domain, and automatic browsing domain(s), respectively.
Flagship naming resolves naming conflicts across a family of protocols serving the same logical function. If a device does not implement the flagship protocol, it creates a placeholder SRV record (priority=0, weight=0, port=0) under that name to stake a claim and detect conflicts with other devices in the fleet. No PTR record is created for the placeholder.
Selective Instance Enumeration (subtypes) allows browsing for a narrower set of services using a PTR query for '<subtype>._sub.<service>.<domain>'. A service advertising with a subtype includes two PTR records: one for the base service type and one for the subtype; both point to the same SRV+TXT pair.
Service Instance Enumeration is performed by querying for DNS PTR records with the name '<Service>.<Domain>'. Each PTR record in the response contains a Service Instance Name pointing to an SRV+TXT record pair describing a specific service instance.
Service Instance Resolution uses DNS SRV and TXT records named by the Service Instance Name. The SRV record gives the target host name and port; the TXT record provides additional key/value metadata about the service.
Service Type Enumeration uses a special PTR query for '_services._dns-sd._udp.<Domain>' to enumerate all advertised service types in a domain. Each PTR response record contains a two-label '<service>.<domain>' name usable for subsequent Service Instance Enumeration queries.
IANA manages the namespace of unique Service Names per RFC 6335. When a protocol uses subtypes, these should be documented in the protocol specification or in the 'notes' field of the IANA registration. When a flagship protocol relationship exists, the flagship name should also be recorded in the 'notes' field of each related service registration.
DNS-SD introduces no security requirements beyond those of the underlying DNS system. For query authenticity, DNSSEC (RFC 4033) should be used. For DNS updates, secure dynamic updates (RFC 2136, RFC 3007) should generally be used to control which clients may register or modify DNS-SD records.
A DNS TXT record for DNS-SD consists of one or more constituent strings packed contiguously in memory. Each string is a single length byte (0–255) followed by 0–255 bytes of data in 'key=value' form. There is no overall length count or null terminator in the record data itself.