[arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf

Patrick Burroughs (Celti) celti at celti.name
Tue Nov 8 17:43:48 UTC 2016


On Tue, 8 Nov 2016 18:01:32 +0100
Damjan Georgievski via arch-general <arch-general at archlinux.org> wrote:

> > $ getent -s resolve hosts $(hostname)  
> 
> this should fail since you don't have the resolved service running.

nss-resolve will chainload nss-dns when systemd-resolved is not running
(see `man 8 nss-resolve`).

> but, when using `hosts: files mymachines resolve [!UNAVAIL=return] dns
> myhostname` standard resolving should then go to the dns source, and
> then to the myhostname source.

The `resolve [!UNAVAIL=return]` entry in the new default nsswitch.conf
causes NSS to /only/ continue down the list if the nss-resolve module
is /not available/; i.e., in a standard Arch setup nss-resolve will
always be queried, and pass the query on to systemd-resolved if it is
running, or fall back to nss-dns if it is not.

Nothing after the conditional will be queried — that is, in this
configuration myhostname will /always/ be skipped unless nss-resolve
fails to load. See `man 5 nsswitch.conf` for details on how the
conditional works.

There is actually a sensible reason for this: if both `resolve` and
`dns` are in there without the conditional, querying a non-existent DNS
record will cause the query to go out twice: once for nss-resolve and
once for nss-dns, because a NOTFOUND result automatically falls back to
the next item in the chain (that is, from nss-resolve to nss-dns).

Sensible solution: change the hosts line as follows.

    hosts: files myhostname mymachines resolve [!UNAVAIL=return] dns

Or if you you use Zeroconf (Avahi)...

    hosts: files myhostname mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

~Celti
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20161108/17ff6409/attachment-0001.asc>


More information about the arch-general mailing list