Zero-configuration networking: Difference between revisions

Revision as of 13:32, 14 February 2024

Latest revision as of 04:31, 11 August 2025

(8 intermediate revisions by 7 users not shown)

Line 10:

Computer networks use numeric [[network address]]es to identify communications endpoints in a network of participating devices. This is similar to the [[Plain old telephone service|telephone network]] which assigns a string of digits to identify each telephone. In modern [[networking protocol]]s, information to be transmitted is divided into a series of [[network packet]]s. Every packet contains the source and destination addresses for the transmission. [[Network router]]s examine these addresses to determine the best network path in [[Packet forwarding|forwarding the data packet]] at each step toward its destination.

Similarly to telephones being labeled with their telephone number, it was a common practice in early networks to attach an address label to networked devices. The dynamic nature of modern networks, especially residential networks in which devices are powered up only when needed, desire dynamic address assignment mechanisms that do not require user involvement for initialization and management. These systems automatically give themselves common names chosen either by the equipment manufacturer, such as a brand and model number, or chosen by users for identifying their equipment. The names and addresses are then automatically entered into a [[directory service]].

Early computer networking was built upon technologies of the telecommunications networks and thus protocols tended to fall into two groups: those intended to connect local devices into a [[local area network]] (LAN), and those intended primarily for long-distance communications. The latter [[wide area network]] (WAN) systems tended to have centralized setup, where a [[network administrator]] would manually assign addresses and names. LAN systems tended to provide more automation of these tasks so that new equipment could be added to a LAN with a minimum of operator and administrator intervention.

Line 40:

Use of either NetBIOS or LLMNR services on Windows is essentially automatic, since using standard DNS client APIs will result in the use of either NetBIOS or LLMNR depending on what name is being resolved (whether the name is a local name or not), the network configuration in effect (e.g. DNS suffixes in effect) and (in corporate networks) the policies in effect (whether LLMNR or NetBIOS are disabled), although developers may opt into bypassing these services for individual address lookups.

The mDNS and LLMNR protocols have minor differences in their approach to name resolution. mDNS allows a network device to choose a ___domain name in the [[.local|local]] DNS [[namespace]] and announce it using a special multicast IP address. This introduces special semantics for the [[top-level ___domain]] ''local'',<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html | title = Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard | access-date = 2006-02-10 | archive-url = https://web.archive.org/web/20081207202354/http://www.ietf.org/mail-archive/web/ietf/current/msg37126.html | archive-date = 2008-12-07 | url-status = dead }}</ref> which is considered a problem by some members of the IETF.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html | title = Re: Summary of the LLMNR Last Call | access-date = 2006-02-10 | archive-url = https://web.archive.org/web/20081207202402/http://www.ietf.org/mail-archive/web/ietf/current/msg37773.html | archive-date = 2008-12-07 | url-status = dead }}</ref> The current LLMNR draft allows a network device to choose any ___domain name, which is considered a security risk by some members of the IETF.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html | title = Summary of the LLMNR Last Call | access-date = 2005-11-11 | archive-url = https://web.archive.org/web/20081207202357/http://www.ietf.org/mail-archive/web/ietf/current/msg37740.html | archive-date = 2008-12-07 | url-status = dead }}</ref> mDNS is compatible with DNS-SD as described in the next section, while LLMNR is not.<ref>{{Citation | publisher = IETF | type = electronic mail message | url = http://www.mhonarc.org/archive/html/ietf/2005-08/msg00494.html | title = More details on the differences}}</ref>

==Service discovery==

Line 60:

====DNS-SD with multicast====

mDNS uses packets similar to [[Domain Name System#DNS message format|unicast DNS]] to resolve hostnames except they are sent over a multicast link. Each host listens on the mDNS port, 5353, transmitted to a well-known multicast address and resolves requests for the [[resource record|DNS record]] of its ''.local'' hostname (e.g. the [[List of DNS record types#A|A]], [[List of DNS record types#AAAA|AAAA]], [[CNAME record|CNAME]]) to its IP address. When an mDNS client needs to resolve a local hostname to an IP address, it sends a DNS request for that name to the well-known multicast address; the computer with the corresponding A/AAAA record replies with its IP address. The mDNS multicast address is {{IPaddr|224.0.0.251}} for IPv4 and {{IPaddr|ff02::fb}} for IPv6 link-local addressing.

DNS Service Discovery (aka [[DNS-SD)]] requests can also be sent using mDNS to yield zero-configuration DNS-SD.{{Ref RFC|6763}} This uses DNS [[PTR record|PTR]], SRV, [[TXT record|TXT]] records to advertise instances of service types, ___domain names for those instances, and optional configuration parameters for connecting to those instances. But SRV records can now resolve to ''.local'' ___domain names, which mDNS can resolve to local IP addresses.

====Support====

DNS-SD is used by Apple products, most network printers, many Linux distributions including [[Debian]] and [[Ubuntu (operating system)|Ubuntu]],<ref>{{cite web|title=Ubuntu 15.10 desktop manifest|url=http://releases.ubuntu.com/wily/ubuntu-15.10-desktop-amd64.manifest|publisher=Ubuntu|access-date=23 October 2015}}</ref> and a number of third-party products for various operating systems. For example, many [[OS X]] network applications written by Apple, including [[Safari (web browser)|Safari]], [[iChat]], and [[Messages (Apple)|Messages]], can use DNS-SD to locate nearby servers and peer-to-peer clients. Windows 10 includes support for DNS-SD for applications written using JavaScript.<ref name="WindowsDnssdNamespace">{{cite web|title=Windows.Networking.ServiceDiscovery.Dnssd namespace|url=https://msdn.microsoft.com/en-us/library/windows/desktop/bb870632(v=vs.85).aspx|website=Windows Dev Center|publisher=Microsoft|access-date=1 November 2015}}</ref> Individual applications may include their own support in older versions of the operating system, such that most instant messaging and [[VoIP]] clients on Windows support DNS-SD. Some [[Unix]], [[BSD]], and Linux distributions also include DNS-SD. For example, Ubuntu ships [[Avahi (software)|Avahi]], an mDNS/DNS-SD implementation, in its base distribution.

===UPnP===

Line 71:

====SSDP====

[[Simple Service Discovery Protocol]] (SSDP) is a UPnP protocol, used in [[Windows XP]] and later. SSDP uses HTTP notification announcements that give a service-type [[Uniform Resource Identifier|URI]] and a Unique Service Name (USN). Service types are regulated by the Universal Plug and Play Steering Committee. SSDP is supported by many printer, NAS and appliance manufacturers such as Brother. It is supported by certain brands of network equipment, and in many [[SOHO network|SOHO]] firewall appliances, where host computers behind it may pierce holes for applications. It is also used in [[home theater PC]] systems to facilitate media exchange between host computers and the media center.

====DLNA====

Line 80:

===AllJoyn===

[[AllJoyn]] is an open-source software stack for a myriad of devices, ranging from IoT devices to full-size computers, for discovery and control of devices on networks (Wifi, Ethernet) and other links (Bluetooth, ZigBee, etc.). It uses mDNS and [[HTTP]] over UDP and other protocols. The project has however not been active since 2016, and is not recommended to use for new projects.<ref>{{ Citation | title = Error compiling with modern gcc | url = https://github.com/alljoyn/core-alljoyn/issues/1 | access-date = 2025-01-31 }}</ref>

==Standardization==

Line 94:

==Security issues==

Because mDNS operates under a different trust model than unicast DNS—trusting the entire network rather than a designated DNS server, it is vulnerable to [[spoofing attack]]s by any system within the same [[broadcast ___domain]]. Like [[Simple Network Management Protocol|SNMP]] and many other network management protocols, it can also be used by attackers to quickly gain detailed knowledge of the network and its machines.<ref>{{Citation | url = http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/ | title = Name (MDNS) Poisoning Attacks Inside the LAN | publisher = GNU citizen | type = World Wide Web log | date = 23 January 2008}}</ref> Because of this, applications should still authenticate and encrypt traffic to remote hosts (e.g. via [[RSA (cryptosystem)|RSA]], [[Secure Shell|SSH]], etc.) after discovering and resolving them through DNS-SD/mDNS. LLMNR suffers from similar vulnerabilities.<ref>{{cite web |url=https://www.pentestpartners.com/security-blog/how-to-get-windows-to-give-you-credentials-through-llmnr/ |title=How to get Windows to give you credentials through LLMNR |first=David |last=Lodge |date=22 September 2015 |website=Pen Test Partners}}</ref>

==Major implementations==

Line 104:

===Avahi===

[[Avahi (software)|Avahi]] is a Zeroconf implementation for [[Linux]] and [[Berkeley Software Distribution|BSD]]s. It implements [[IPv4LL]], mDNS and DNS-SD. It is part of most Linux distributions, and is installed by default on some. If run in conjunction with nss-mdns, it also offers host name resolution.<ref>{{Citation | url = http://0pointer.de/lennart/projects/nss-mdns | title = nss-mdns 0.10 | last = Lennart | publisher = 0 pointer | place = [[Germany|DE]]}}</ref>

Avahi also implements binary compatibility libraries that emulate Bonjour and the historical mDNS implementation Howl, so software made to use those implementations can also utilize Avahi through the emulation interfaces.

Line 116:

===Link-local IPv4 addresses===

Where no DHCP server is available to assign a host an IP address, the host can select its own [[link-local address]]. Using a link-local address, hosts can communicate over this link but only locally; Access to other networks and the Internet is not possible. There are some link-local IPv4 address implementations available:

* Apple Mac OS and MS Windows have supported link-local addresses since [[Windows 98]] and [[Mac OS 8#Mac OS 8.5|Mac OS 8.5]] (both released in 1998).<ref name="rfc3927" /> Apple released its open-source implementation in the [[Darwin (operating system)|Darwin]] bootp package.

* [[Avahi (software)|Avahi]] contains an implementation of IPv4LL in the avahi-autoipd tool.

* Zero-Conf IP (zcip)<ref>{{Citation | url = httphttps://zeroconf.sourceforge.net/ | title = zcip | publisher = Source forge}}</ref>

* [[BusyBox]] can embed a simple IPv4LL implementation.

* Stablebox,<ref>{{Citation | url = http://code.google.com/p/stablebox/ | title = Code | contribution = Stable box}}</ref> a fork from Busybox, offers a slightly modified IPv4LL implementation named llad.

Line 143:

==External links==

* {{Citation | url = httphttps://jmdns.sourceforge.net/ | publisher = Source forge | title = JmDNS}}, a pure Java implementation of mDNS/DNS-SD.

* {{Citation | url = httphttps://sourceforge.net/projects/pyzeroconf/ | publisher = Source forge | title = pyZeroConf| date = 11 July 2015 }}, a pure [[Python (programming language)|Python]] implementation of mDNS/DNS-SD.

* {{Citation | url = http://mono-project.com/Mono.Zeroconf | title = Mono.Zeroconf | publisher = Mono project}}, a cross platform (Linux, MS Windows, Apple Mac), unified Mono/.NET library for Zeroconf, supporting both Bonjour and Avahi.

* {{Citation | url = httphttps://sourceforge.net/projects/wxservdisc/ | publisher = Source forge | title = WxServDisc| date = 13 June 2013 }}, a cross-platform wxWidgets-based service discovery module without external dependencies.

* {{Citation | url = http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt | title = Multicast DNS | last = Cheshire | first = Stuart | type = draft}}.

* {{Citation | url = http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt | publisher = DNS‐SDDNS-SD | title = DNS-Based Service Discovery Specification | last = Cheshire | first = Stuart | type = draft}}.

* {{Citation | url = http://video.google.com/videoplay?docid=-7398680103951126462&q=Google+techtalks | title = Zeroconf | type = tech talk | first = Stuart | last = Cheshire | format = video | access-date = 2006-03-08 | archive-url = https://web.archive.org/web/20080302221751/http://video.google.com/videoplay?docid=-7398680103951126462&q=Google+techtalks | archive-date = 2008-03-02 | url-status = dead }}.

* {{Citation | url = http://www.zeroconf.org/ | title = Zeroconf | first = Stuart | last = Cheshire}}, including Internet drafts.