On Tue, 8 Nov 2016 18:01:32 +0100 Damjan Georgievski via arch-general <arch-general@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