Name resolution, service discovery

From Helpful
(Redirected from NSS)
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Name resolution


Authoritative and non-authoritative; iteration and recursion

Duplication and minimizing load

Resource record; zones


Zone transfers

Domain name transfers


See also


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Originally, for account and host information came from (some interface into) /etc/{passwd, group, shadow, hosts}, which you could sort of do yourself.

Then NIS and DNS and such came about, and it became a more pressingly good idea to have a single interface unify lookup of accounts, passwords, and hostnames.

This is basically what the Name Service Switch (NSS) subsystem is. It's part of glibc and used to backs things like getaddrinfo() and gethostbyname().

NSS allows hooking things into hostname resolution, user/group, password. Since you can have multiple sources, it also lets you configure when each is used.

(note that hosts.allow and hosts.deny is not part of NSS, but tcpwrappers and applies only to it(verify))

An obvious question is "So what about PAM? it deals with similar stuff."

PAM is primarily the logic of how to use such sources of information (when and how to authenticate, what to allow, etc.) but not itself the thing that accesses them.

So in most ways, it's a generalizing layer on top of NSS, and other things.

So yes, there are things you could do in both NSS and PAM. (which you'd choose depends a bit on what your program is. Parts of the system would probably use PAM, while a lot of applications that just want to look up a username or such probably use NSS because it's easier to hook into than PAM.

In a wider sense, you can use getent to fetch the mant

There's some funny specific cases, particularly hostname lookup.

Some command line tools (e.g. dig, host, nslookup) only query the nameserver, not your local system (so great for people debugging DNS)
"I want hostname lookup the same way the OS does" basically means using
, which is actually backed by NSS, so whatever /etc/nsswitch.conf configures
That NSS configuration is at
and the relevant line is usually at least (the order can vary):
hosts:  	 files dns myhostname 

On workstations it may be something like:

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname


order is fallback style
files refers to files like /etc/hosts,
dns is basically whatever's configured in /etc/resolv.conf
some form of mDNS
(mdns4_minimal: 4 to avoid timeout-based delays when you don't use IPv6, and _minimal doesn't attempt to resolve things that don't end in .local (which is why the "if tried but not found, then give up resolving it completely" makes sense))
myhostname is /etc/hostname and /etc/hosts (mainly to ensure your own hostname always resolves).
may be added last in a "well in case everything fails at least we have a name"
there are a few more, like nis, nisplus, hesiod, windbind, wins, systemd

local DNS (mDNS, LLMNR)

Multicast DNS is the concept of having a functional subset of DNS communicating on your LAN via local multicast.

Basically exists in two forms:

  • Apple's mDNS (moderately common)
  • Microsoft's LLMNR [1] (less common)

The two are similar, and apparently the only reason they aren't the same thing is some popcorn-worthy drama - mDNS is essentially the standard, and MS continues to do their own thing.

mDNS notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

So how do you resolve .local?

OSX does this pretty natively
Linux does lookups typically through avahi, so requires that to be installed, and hooked into nss.
Windows by default chooses not to support mDNS (or, since ~Win10, only some of it), because LLMNR.
There's Bonjour for windows, though a newer version of it is only available packaged with iTunes and a few other things[2].
Also note some apps have their own mDNS built in.

On zeroconf and service discovery

Zeroconf refers broadly to whatever allows automated network configuration, and also to discovery of services available on the (sub)net.

A little more precisely:

assignment of addresses for devices,
resolution of hostnames,
location of network services.

The first wasn't really necessary due to the already-existing DHCP, so zeroconf may largely refer to the latter two, often:

  • Multicast DNS for name resolution, often either
    • mDNS (all platforms)
    • LLMNR (mostly for windows)
  • plus some means of service discovery, for example
    • Apple's DNS-SD (DNS based Service Discovery)
    • Microsoft's SSDP (Simple Service Discovery Protocol), part of UPnP [3]


  • Bonjour (probably the most common Zeroconf setup) (previously 'Rendezvous')
    • from Apple
    • is mDNS and DNS-SD
    • available for Mac, Linux, other POSIX, and Windows
  • Avahi [4] [5]
    • is mDNS and DNS-SD
    • available for Linux, BSD
    • is LLMNR on linux
  • systemd-resolved
seems to mostly be a local cache(verify)
  • Howl (old, not developed anymore [6])
  • UPnP allows network device setup [7]
(though its lack of authentication makes it a security problem in a few cases)
  • Windows CE 5.0 has an LLMNR-based implementation
  • Windows 10 seems to have an mDNS for printers
apparently for proper mDNS, you should disable that and install Bonjour(verify)


  • SLP (Service Location Protocol) [8]
seemlingly aimed at printers, also used for some other shared services(verify)
systems that already use LDAP will probably use that instead of SLP
  • WS-Discovery [9]
Device/service coordination
Device/service coordination
  • Other device configurers: