2

On modern local area networks, devices use a few different techniques to resolve names. Specifically, just to name a few, things like DNS, Avahi, zeroconf, mDNS, Bonjour, NetBIOS, WINS, or even manual hosts files. Some of these are, I believe, different terms for basically the same thing. Some use decentralized technologies, others rely on DHCP to distribute central addresses.

How do current common operating systems go through these different, possibly conflicting, name resolution techniques? What order do they use? Do different OSes have different behaviors?

When one asks for the IP of foobar, when is the local search domain appended to the name -- after initial name resolution fails, before it asks something on the network, or some other time? Can (and/or do) DNS resolvers add search domains when trying to find an entry in their tables?

Why did the behavior of my clients change when I specified a local search domain (as opposed to blank) in my router?

Some of these methods support and/or use the .local tld/search domain. Is this only an Avahi thing?

How does adding a . on the end of a domain change things? Does this simply prevent searching "local domain"? When I lookup google.com, why don't I need the trailing .?

Why doesn't my DNS resolver search for google.com.local or google.com.MyLocalSearchDomain?

Can you have nested search domains?

Are NetBIOS and WINS the same thing? What about avahi, bonjour, and others?

Follow up question: how do each of these services work? I understand that DNS uses a more conventional style of (essentially) one central server that each client is configured to use. However, the decentralized methods must use some other techniques to auto-discover names. How do those work?

Improve this question
1
  • 2
    These are good questions to ask, but unfortunately, it's too many questions for one Question post, so it doesn't fit the model of this site very well. If W. Richard Stevens were still around, he could write a whole book named "Modern Name Resolution Illustrated". Try asking one core question at a time. – Spiff Sep 20 '18 at 2:05
5

In short, it's a very messy mix of different sets of name resolution protocols used by different OSes, products, apps, services, and APIs.

IETF ZeroConf defines the mDNS (multicast DNS) protocol and also the DNS-SD (DNS service discovery) protocol. Bonjour (née Rendezvous, a.k.a. mDNSResponder) and Avahi are two implementations of ZeroConf. I hear there's also an implementation from the OpenWrt community that simply calls itself "mDNS". Since Apple created this, Apple products focus on this, although Macs can also use NetBIOS Name Service and WINS for name resolution, especially when using macOS's SMB client to connect to SMB file servers (Windows Server, Linux SaMBa servers).

Microsoft proprietary name service protocols start with NetBIOS Name Service which was based on LAN-local (non-routable) broadcasts. I say "Microsoft proprietary", but technically it originated with IBM as part of the Server Message Block (SMB) protocols. As SMB file service became a de facto industry standard, many OSes had to adopt NetBIOS Name Service in their SMB clients and servers at the very least. Later, Microsoft created WINS to provide a server-based unicast solution for this same kind of Microsoft-proprietary name resolution. When Apple created mDNS under the name "Rendezvous" (later renamed Bonjour) and took it to the IETF to eventually become IETF ZeroConf, Microsoft bewilderingly decided to do their own slightly different, incompatible mDNS-like think that they called "Link-Local Multicast Name Resolution" (LLMNR). In the Microsoft world, requests for ".local" hosts usually goes to LLMNR, as if to spite ZeroConf's standardized use of ".local". Microsoft also uses UPnP for discovering some things on LANs, like routers (Wi-Fi APs and NAT gateways).

Linux, including Google Android, seem to be gravitating toward ZeroConf for LAN-based serverless name resolution now. Google ported Apple's POSIX-compliant open source "mDNSResponder" daemon to Linux for use in Android; it's what implements Android's "Network Service Discovery" (NSD) APIs.

Like macOS, Linux uses NetBIOS Name Service and WINS for the sake of connecting to SMB servers.

It's a huge mess, and which protocol(s) get used for a particular thing depends on which OS you're on, which APIs your software calls, and many other things.

Improve this answer
2
  • I have a faint suspicion that Win10 will eventually add mDNS name resolution, since they already support service discovery through it. Meanwhile, Linux systemd-resolved implements both mDNS and LLMNR (although nowhere near as good the former as Avahi, so far). – user1686 Sep 20 '18 at 14:32
  • Well that's odd – whether I try to reach foo or foo.local, my Windows 10.1803.17134 actually makes both LLMNR and mDNS queries at the same time (and NBNS but let's ignore that). This has to be built-in because I don't have and never had Bonjour/mDNSResponder installed on this system... – user1686 Sep 23 '18 at 11:36
1

Another piece of the puzzle is the /etc/nsswitch.conf file.  This is the “name service switch”, which is present on many Unix-based systems; it tells the system how to translate names into numeric values and back.  It contains about a dozen lines that look like

(database):   (source) …
Described in detail here.

An example line would be

hosts:        files dns
which means that, whenever any program* wants to translate a host / domain name into an IP address (or vice versa), it should

  1. Look in /etc/hosts, and, if it doesn’t find a result there,
  2. consult DNS.

So systems can be individually configured as to how to resolve hostnames (including the search order).
________
* This is true for most application programs, like ping, ssh, ftp, etc.  Utility programs like dig and nslookup are hard-coded to use DNS and nothing else.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.