Zero-configuration networking: Difference between revisions

Revision as of 16:58, 6 November 2022

Revision as of 15:52, 20 January 2023

Line 14:

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.

An early example of a zero-configuration LAN system is [[AppleTalk]], a protocol introduced by [[Apple Inc.]] for the early [[Mac (computer)|Macintosh]] computers in the 1980s. Macs, as well as other devices supporting the protocol, could be added to the network by simply plugging them in; all further configuration was automated. Network addresses were automatically selected by each device using a protocol known as AppleTalk Address Resolution Protocol (AARP), while each machine built its own local directory service using a protocol known as Name Binding Protocol (NBP). NBP included not only a name but the type of device and any additional user-provided information such as its physical ___location or availability. Users could look up any device on the network with the application [[Chooser (Mac OS)|Chooser]], which filtered names based on the device type.

On [[Internet Protocol]] (IP) networks, the [[Domain Name System]] database for a network was initially maintained manually by a network administrator. Efforts to automate maintenance of this database, led to the introduction of a number of new protocols providing automated services, such as the [[Dynamic Host Configuration Protocol]] (DHCP).

Line 52:

===DNS-based service discovery===

'''{{vanchor|DNS-SD}}''' allows clients to discover a named list of service instances and to resolve those services to hostnames using standard DNS queries. The specification is compatible with existing unicast DNS server and client software, but works equally well with mDNS in a zero-configuration environment. Each service instance is described using a DNS SRV<ref>{{IETF RFC|2782}}</ref> and DNS TXT<ref name="IETF RFC|1035">{{IETF RFC|1035}}</ref> record. A client discovers the list of available instances for a given service type by querying the DNS PTR<ref>{{ name="IETF RFC|1035}}<"/ref> record of that service type's name; the server returns zero or more names of the form &lt;Service&gt;.&lt;Domain&gt;, each corresponding to a SRV/TXT record pair. The [[SRV record]] resolves to the ___domain name providing the instance, while the TXT can contain service-specific configuration parameters. A client can then resolve the A/AAAA record for the ___domain name and connect to the service.

Service types are given on a first-come-first-serve basis. A service type registry was originally maintained by DNS-SD.org,<ref>{{Citation | url = http://www.dns-sd.org/ | title = DNS-SD}}</ref> but has since been merged into IANA's registry for DNS SRV records.<ref>{{Citation | url = http://www.dns-sd.org/ServiceTypes.html | publisher = DNS-SD | title = Service types}}</ref>

Line 87:

{{IETF RFC|3927}}, a standard for choosing addresses for networked items, was published in March 2005 by the IETF Zeroconf working group. The group included individuals from Apple, Sun, and Microsoft.<ref>{{Citation | publisher = IETF | url = http://www.ietf.org/html.charters/OLD/zeroconf-charter.html | title = Zero Configuration Networking (zeroconf) Charter | access-date = 2004-10-28 | archive-url = https://web.archive.org/web/20041101173627/http://www.ietf.org/html.charters/OLD/zeroconf-charter.html | archive-date = 2004-11-01 | url-status = dead }}</ref>

LLMNR was submitted for official adoption in the IETF DNSEXT working group, however, failed to gain consensus and thus was published as informational {{IETF RFC|4795}} in January 2007.<ref>{{Citation | url = http://www.ietf.org/html.charters/dnsext-charter.html | title = DNS Extensions (dnsext) Charter | publisher = IETF | access-date = 2005-03-02 | archive-url = https://web.archive.org/web/20050307044356/http://www.ietf.org/html.charters/dnsext-charter.html | archive-date = 2005-03-07 | url-status = dead }}</ref>

Following the failure of LLMNR to become an Internet standard and given that mDNS/DNS-SD is used much more widely than LLMNR, Apple was asked by the IETF to submit the mDNS/DNS-SD specs for publication as Informational RFC as well.{{citation needed|date=February 2016}}

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.