Editing Zero-configuration networking (section)

==Name service discovery==
Internet protocols use IP addresses for communications, but these are not easy for humans to use; IPv6 in particular uses very long strings of digits that are not easily entered manually. To address this issue, the internet has long used DNS, which allows human-readable names to be associated with IP addresses, and includes code for looking up these names from a hierarchical database system. Users type in domain names, such as ''example.org'', which the computer's DNS software looks up in the DNS databases to retrieve an IP address, and then hands off that address to the [[protocol stack]] for further communications.<ref name="DNS">Marshall Brain and Stephanie Crawford, [http://computer.howstuffworks.com/dns.htm "How Domain Name Servers Work"], howstuffworks</ref>

Looking up an address using DNS requires the IP address of the DNS server to be known. This has normally been accomplished by typing in the address of a known server into a field in one of the devices on the network. In early systems, this was normally required on every device, but this has been pushed up one layer in the hierarchy to the DHCP servers or [[broadband]] devices like [[cable modem]]s that receive this information from their [[internet service provider]]. This has reduced the user-side administration requirements and provides a key element of zero-configuration access.<ref name=DNS/>

DNS was intended to provide uniform names to groups of devices within the same administration realm, such as ''example.org'', provided by a name service. Assigning an address to a local device, e.g., ''thirdfloorprinter.example.org'', normally requires administrator access to the DNS server and is often accomplished manually. Additionally, traditional DNS servers are not expected to automatically correct for changes in configuration. For instance, if a printer is moved from one floor to another it might be assigned a new IP address by the local DHCP server.<ref name=DNS/>

To address the need for automatic configuration, Microsoft implemented [[NetBIOS Name Service]], part of which is the [[Computer Browser Service]] already in Microsoft Windows for Workgroups 3.11<ref name="ComputerBrowserService">{{cite web|title=Description of the Microsoft Computer Browser Service|url=https://support.microsoft.com/en-us/kb/188001|website=Microsoft Knowledge Base|publisher=Microsoft|access-date=1 November 2015}}</ref> as early as 1992. NetBIOS Name Service is zero-configuration on networks with a single subnet and may be used in conjunction with a [[Windows Internet Name Service|WINS]] server or a Microsoft DNS server that supports secure automatic registration of addresses. This system has small, but not zero, management overhead even on very large enterprise networks. The protocols NetBIOS can use are part of the [[Server Message Block]] (SMB) suite of open protocols<ref name=ComputerBrowserService /> which are also available on Linux and iOS, although Windows typically supports a wider range of so-called dialects which can be negotiated between Windows clients that support it. For example, Computer Browser Services running on server operating systems or later versions of Windows are elected as so-called ''master browser'' over those that are not running a server operating system or running older versions of Windows.<ref name=ComputerBrowserService />

In 2000, Bill Manning and [[Bill Woodcock]] described the ''Multicast Domain Name Service''<ref>{{Citation | url = https://datatracker.ietf.org/doc/html/draft-manning-dnsext-mdns-00.txt | title = Multicast Domain Name Service |last1 = Manning |first1=Bill |last2= Woodcock |first2= Bill | newspaper = Ietf Datatracker |publisher = [[IETF]] |date= August 2000}}</ref> which spawned the implementations by Apple and Microsoft. Both implementations are very similar. Apple's [[Multicast DNS]] (mDNS) is published as a standards track proposal {{IETF RFC|6762}}, while Microsoft's [[Link-local Multicast Name Resolution]] (LLMNR) is published as informational {{IETF RFC|4795}}. LLMNR is included in every Windows version from Windows Vista onwards<ref>{{Citation | publisher = Microsoft | type = webpage | url = https://technet.microsoft.com/library/bb878128 | title = Microsoft TechNet Library Link-Local Multicast Name Resolution | date = 5 May 2010 }}</ref> and acts as a side-by-side alternative for Microsoft's NetBIOS Name Service over IPv4 and as a replacement over IPv6, since NetBIOS is not available over IPv6. Apple's implementation is available as the [[Bonjour (software)|Bonjour service]] since 2002 in Mac OS X v10.2. The Bonjour implementation (mDNSResponder) is available under the [[Apache License|Apache 2 Open Source License]]<ref>{{Citation | publisher = Apple | type = webpage | url = https://developer.apple.com/softwarelicensing/agreements/bonjour.php | title = Bonjour Licensing and Trademarks }}</ref> and is included in [[Android Jelly Bean]] and later<ref>{{Citation | type = webpage | url = http://developer.android.com/about/versions/android-4.1.html | title = Android 4.1 APIs }}</ref> under the same license.

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>