Yes. Stuart Cheshire, who was the creator and is a primary maintainer of Rendezvous/Bonjour at Apple, who also co-chaired the IETF ZeroConf working group, and wrote the O’Reilly book on Zero Configuration Networking, has described Bonjour as a “three-legged stool” where the legs are:
- IPv4 (and IPv6) link-local addressing
- Multicast Name Resolution (mDNS)
- DNS Service Discovery (DNS-SD)
The IETF ZeroConf working group and Apple both consider link-local addressing, especially IPv4 link-local addressing (169.254.0.0/16
addresses) to be part of ZeroConf/Bonjour, even though link-local addressing shipped years before the other two “legs of the stool”.
Note that since Windows already supports automatic link-local addressing even without Apple’s Bonjour for Windows software installed, many Windows users do not think of IPv4 link-local addressing to be part of Bonjour/ZeroConf.
Yes. Macs and Windows machines, by default, do IPv4 link-local addressing if they are configured for DHCP but there is no DHCP server available. Linux and BSD machines with Avahi (or possibly other ZeroConf implementations) installed will also do this.
If a computer is running Bonjour, its hostname is published on the LAN via mDNS. If your machine’s name is “Alice”, it will be Alice.local
via mDNS. From another computer (let’s call it “Bob”) on the same LAN (specifically, on the same link-local multicast domain), you should be able to simply type ping Alice.local
, and Bob should do an mDNS lookup of Alice.local
to discover Alice's IP address(es), and ping (one of) the address(es) it gets back.
Note, though, that Bonjour differentiates between hostnames and service names. For example, if you have two separate USB printers, let’s say “HP” and “Canon”, connected to Alice, and Alice is acting as, say, an lpr
print server for both of them, they can each show up as their own service, which maps back to Alice.local
as the host.
Their service names would show up to the user as “HP” and “Canon” with no mention of Alice. Behind the scenes, they would be known as HP._printer._tcp.local
and Canon._printer._tcp.local
, and DNS-SD lookups on those service names would show that those services are available on Alice.local
on two different TCP ports.
So yes, applications must notify the Bonjour daemon (called mDNSResponder
in Apple’s implementation) that they have services they want to advertise. macOS has mechanisms to automatically handle service advertisement for legacy services that are not natively Bonjour-aware. For instance, macOS's sshd
is OpenSSH, which doesn't support Bonjour directly, but macOS takes care of advertising the ssh
service via Bonjour so that you can just ssh username@Alice.local
from other machines on the LAN.
On macOS, there's a "dns-sd" command-line tool that can register a service using this syntax:
dns-sd -R <Name> <Type> <Domain> <Port> [<TXT>...]
# (Register a service)
So for example:
dns-sd -R MyWebsite _http._tcp local 80
I would not be surprised if it is included in Bonjour for Windows, or the Bonjour SDK for Windows, or if you can compile it for Windows from Apple’s mDNSResponder open-source project. Googling for dns-sd.exe
, I see such a thing exists. I am not sure I would just download a binary for it. Instead I would try to get it from one of the packages mentioned above, or compile it myself from the mDNSResponder project sources.
You can also use the dns-sd
command-line tool to browse for services and look them up. Here is an example of looking up a local web service:
Browse for local web services with -B
:
$ dns-sd -B _http._tcp local
Browsing for _http._tcp.local
Timestamp A/R Flags if Domain Service Type Instance Name
16:30:59.870 Add 3 6 local. _http._tcp. My Cool Web App
16:30:59.871 Add 3 6 local. _http._tcp. Someone Else's Web Service
16:30:59.871 Add 3 6 local. _http._tcp. A Third One
^C
Look up the one I want, "My Cool Web App", with -L
:
$ dns-sd -L "My Cool Web App" _http._tcp local
Lookup My Cool Web App._http._tcp.local
16:31:52.678 My\032Cool\032Web\032App._http._tcp.local. can be reached at MyWebServer.local.:80 (interface 6)
^C
Query the IP addresses for MyWebServer.local, with -Q
:
$ dns-sd -Q MyWebServer.local
Timestamp A/R Flags if Name T C Rdata
16:32:40.786 Add 2 6 MyWebServer.local. 1 1 169.254.45.209
^C
Note in these examples that you must Ctrl-C
out of the dns-sd
tool. Otherwise it will stay open forever, continuously watching the network and reporting any changes in the results of the query you issued (such as web servers coming and going on the network, while you sit with a -B
browse query open). I have found that for this and other reasons, the dns-sd
tool is not well suited for being called from a script. You might want to look at what the ZeroConf libraries for your preferred language after all.
To answer one of your other questions, I am not aware of any ZeroConf implementation that allows you to perform queries and get results just by reading/writing files. Most apps that use Bonjour do so by calling the APIs, either directly (C/C++/Obj-C/Swift apps) or through a library specific to the language (interpreted/scripting languages).
Best Answer
The standard way to detect devices (and their attributes, such as management ip address) on an ethernet network is to use LLDP.
You can find a list of lldp daemons here
All hosts in an ethernet Vlan will see LLDP announcements, since they are sent to a multicast mac address; this also means LLDP announcements are scoped to a Vlan. If you need device registry and detection across Vlans, you'll need to build your own IP announcement protocol... UDP would be a good choice for the transport.
If you are only looking for an IP address, and do not care whether you can tell whether the device is one of your embedded systems, you could use mDNS; however, this is more risky since you have no guarantee against namespace collisions in a customer LAN.
RFC 3330 allocates 169.254.0.0/16 for communication on a single link if a DHCP server is not available. Upon reflection, this is probably the safest block of addresses to use; however, your company should encourage your customers to allocate addresses themselves with DHCP instead of some form of auto-configuration in the 169.254.0.0/16 subnet.
How you assign individual IP addresses within 169.254.0.0/16 is a question that we can't decide for you... a couple of possibilities are: