Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
DNS Service Discovery (DNS-SD) is a convention that lets software find named instances of a service by querying DNS. It uses existing DNS queries and record types—not a new DNS record type—and can operate with multicast DNS on a local network or with conventional unicast DNS in configured domains.
What DNS Service Discovery does
A client asks for a particular type of service in a domain. DNS-SD lets it receive a list of matching service instances, then look up the connection details for an instance it wants to use. The IETF defines the mechanism in RFC 6763, published in February 2013 by Stuart Cheshire and Marc Krochmal.
In the RFC’s words, the mechanism allows clients to discover “a list of named instances of that desired service, using standard DNS queries.” DNS-SD specifies how to name and use existing DNS records for this purpose; it does not define the service’s own application protocol.
How PTR, SRV, TXT, and address records work together
Discovery typically follows a sequence of DNS lookups. Each record answers a different question:
#1 Best Overall
- Used Book in Good Condition
| Record | What it tells the client |
|---|---|
| PTR | Which service instances are listed for the requested service type in the domain? |
| SRV | What host and port should the client use for a selected instance? |
| TXT | What additional structured key/value information is advertised for the instance? |
| A or AAAA | What IPv4 or IPv6 address does the SRV target hostname resolve to? |
- The client queries a service type in a domain with a PTR query. The response can list zero or more named instances.
- For an instance the client selects, it looks up the SRV record to find the target host and port.
- The client may read the instance’s TXT record for additional advertised information. TXT data can help describe an instance, but it is not a substitute for negotiating with the service using its own protocol.
- The client resolves the target hostname through A or AAAA records, then attempts to contact the service using its application protocol.
Put simply: PTR finds listed instances, SRV provides a host and port, TXT carries extra instance information, and address records resolve a hostname to an IP address. DNS-SD locates service instances; it does not prove that a service is reachable or available.
DNS-SD and mDNS are related, but not the same
DNS-SD defines the service-record naming and query convention. Multicast DNS (mDNS) is one way to use DNS-SD: it supports zero-configuration discovery on a local network link. DNS-SD can also use conventional unicast DNS when services are registered in configured DNS domains. The unicast approach will usually involve configuration, such as selecting registration domains and arranging authorization for DNS updates, as RFC 6763 explains.
Therefore, DNS-SD is not inherently multicast or limited to a local network. The deployment determines whether discovery uses mDNS on a link or unicast DNS in a configured domain.
Bonjour is broader than DNS-SD
Bonjour is Apple’s name for a suite of technologies that includes link-local addressing, mDNS, and DNS-SD; it is not another name for DNS-SD alone. Apple’s archived Bonjour documentation describes service registration using related PTR, SRV, and TXT records.
Apple also provides a DNS-SD API for advertising and discovering services. For Apple-platform apps that access the local network, the current developer documentation calls for an NSLocalNetworkUsageDescription entry. That is Apple-specific implementation guidance, not a requirement of the DNS-SD protocol itself.
What DNS-SD does not guarantee
- It does not define the service protocol. A client still needs to communicate with the discovered service using a compatible application protocol.
- It does not guarantee connectivity. A returned instance may be unavailable, unreachable from the client, or unable to complete the application-level exchange.
- TXT data is not a complete service contract. It provides additional advertised information, not a replacement for protocol negotiation.
- It is not automatically private. Advertised instance names, hostnames, and metadata may reveal information to potential queriers. The precise exposure depends on what is advertised and where DNS-SD is visible. RFC 8882 addresses DNS-SD privacy and security requirements.
When DNS-SD is useful
DNS-SD is useful when clients need to locate service instances without being given each instance’s host and port in advance. It can support local-link discovery with mDNS or discovery through services registered in a configured DNS domain. Which arrangement fits depends on the required network scope, whether multicast or unicast DNS is appropriate, the configuration and DNS-update arrangements needed, and what information the deployment should expose.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
