Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#56684 - [filesystem] 2017.10-2 resolves localhost over network

Attached to Project: Arch Linux
Opened by Moviuro (Moviuro) - Monday, 11 December 2017, 20:07 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 01 May 2019, 17:21 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No


filesystem-2017.10-2 wipes /etc/hosts and leaves it empty. Along with /etc/nsswitch.conf ordering `dns` before `myhostname`, using "localhost" as a network identifier makes the system query the DNS server for `localhost.` (over the network)

This behavior is undesirable:
* It leaks data (you queried localhost at that time)
* A malicious DNS server could reply
* It could leak more data (curl http://localhost/some/thing)
* This setup breaks some tools if the DNS server replies to `localhost.` queries with something else than `` (e.g. mpc(1) relies on the localhost name rather than to connect to mpd(1))
* It adds latency (wait for DNS response before falling back to `myhostname`)

Additional info:
* Filesystem 2017.10-2
* No edits made to /etc/hosts or /etc/nsswitch.conf

Steps to reproduce:

1 - restore nsswitch.conf and hosts(5) to defaults:

# cp /etc/nsswitch.conf /etc/nsswitch.conf.bk
# cp /etc/hosts /etc/hosts.bk
# tar axf /var/cache/pacman/pkg/filesystem-2017.10-2-x86_64.pkg.tar.xz etc/hosts -O > /etc/hosts
# tar axf /var/cache/pacman/pkg/filesystem-2017.10-2-x86_64.pkg.tar.xz etc/nsswitch.conf -O > /etc/nsswitch.conf

2 - run sniffing

# tcpdump -tttnei <your if> port domain

3 - try to use 'localhost'

% ping -c1 localhost

4 - tcpdump should catch some `A? localhost.` and `AAAA? localhost.`


There are 2 independant solutions to this issue:

1. change order in nsswitch.conf: `hosts: files mymachines resolve [!UNAVAIL=return] myhostname dns`
2. revert changes from 2017.03-2 to 2017.10-2 made to /etc/hosts (`# tar axf /var/cache/pacman/pkg/filesystem-2017.03-2-x86_64.pkg.tar.xz etc/hosts -O > /etc/hosts`)

Choosing one solution is enough to fix the problem.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Wednesday, 01 May 2019, 17:21 GMT
Reason for closing:  Fixed
Comment by loqs (loqs) - Monday, 11 December 2017, 20:13 GMT
Change was fix for  FS#54875 
Comment by Moviuro (Moviuro) - Monday, 11 December 2017, 20:18 GMT
@loqs, I'm not discussing host.conf anywhere in here.
Comment by loqs (loqs) - Monday, 11 December 2017, 22:07 GMT
Thank you for the correction I misread /etc/hosts as /etc/hosts.conf
Comment by userwithuid (userwithuid) - Tuesday, 12 December 2017, 12:38 GMT
As the OP indicated, this is a security issue and should get higher priority...

I believe Arch's order of this line is a result of the upstream man page at [1] :

It is recommended to place "myhostname" last in the nsswitch.conf' "hosts:" line to make sure that this mapping is only used as fallback, and that any DNS or /etc/hosts based mapping takes precedence.

This recommendation stems from a very old, pre-v1 commit of systemd, see [2]. In the meantime, we got systemd-resolved, which - if enabled - will internally resolve the same special names as myhostname would [3], explicitly stating:

Lookups for the special hostname "localhost" are never routed to the network. (A few other, special domains are handled the same way.)

Other dns servers, for example "unbound", do the same by default. To protect users that use neither, putting "myhostname" before "dns" is quite the easy fix.

Comment by Sébastien Luttringer (seblu) - Saturday, 16 December 2017, 13:11 GMT
I agree, localhost, 127.* and ::1 should not be resolved over the network and current default configuration is a problem.
However, users of systemd-resolved are not impacted by this.

Restore a default localhost into /etc/hosts is not a suitable solution; there is too many lines to add to the job correctly (e.g -> localhost), and nss-myhostname is doing the job fine. So changing the order in nsswitch looks like the best idea.

But, we have implemented bug report  FS#51709 , which asked to stick to the default nsswitch.conf. Did you open a bug at systemd to ask them to change their default suggested line in nsswitch.conf ?

Note: some resolver don't use nss (and directly read /etc/resolv.conf) which make also important to use a local stub resolver which doesn't resolve local host names and adresses on the network.

Comment by userwithuid (userwithuid) - Sunday, 17 December 2017, 06:05 GMT
OK, looks like this was brought up before upstream:

1. to make it work properly, nss-myhostname would have to be split up: the part for localhost. would then be ordered before "dns", but the part for the host's domain (hostname --fqdn) name would come after.
2. systemd-resolved has made nss-myhostname mostly obsolete, it might even be removed eventually.

So I guess the reordering is not a future proof or upstream supported approach.

Might just wanna restore those 2 lines in /etc/hosts for now to fix the default config, worry about the best future approach later.
Comment by Sébastien Luttringer (seblu) - Sunday, 31 December 2017, 18:31 GMT
I think it could be good to point the security concern to upstream.

Until they remove nss-myhostname, it prevents more dns leaks to reorder /etc/nsswitch.conf than just put these 2 addresses back in /etc/hosts. Let's try that one.
Comment by Andrey Vihrov (andreyv) - Sunday, 31 December 2017, 19:14 GMT
There is a typo in filesystem 2017.12-1 /etc/nsswitch.conf: "mymachine myhostnames" -> "mymachines myhostname".
Comment by Sébastien Luttringer (seblu) - Sunday, 31 December 2017, 19:30 GMT
Damn. 5 days with that typo in my nsswitch.conf and I didn't view the difference. Thanks.
Comment by Adrián Laviós (Zirkelite) - Thursday, 18 January 2018, 15:59 GMT
Since systemd-resolved already handles "special" cases like localhost and the current hostname please consider ordering hosts like so:

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

This way, you can be sure that systemd-resolved (which correctly handles localhost and hostname use cases without sending them over the network) is used even for local resolution when it is available, but nss-myhostname is still used before nss-dns if it is not.
Comment by Tarqi Kazan (Tarqi) - Monday, 12 March 2018, 01:18 GMT
Not setting myhostname to the end results (in my case) in a failed dns-domain-name resolution. hostname -d is (none), hostname -f is just the short name, while the dns-domain-name is handed out by dhcp which registers the host in dns. The client is *not* using systemd-networkd.
Comment by Daniel Wendler (BMRMorph) - Tuesday, 13 March 2018, 08:02 GMT
Yesterday i upgrade from 2017.10-2 -> 2018.1-2 and to use 'myhostname' bevor resolve and/or dns definitely breaks the fqdn of my systems.
As Tarqi mentioned the hostname -d is (none), hostname -f is just the short name this beaks for example my duplicity backup as the source name changed.
I would guess this is not the only pice of software what breaks if there is not an fqdn.