Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. 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) - Thursday, 05 May 2022, 12:21 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned   Reopened
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 17
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

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.
Comment by Alad Wenter (Alad) - Thursday, 14 October 2021, 21:56 GMT
  • Field changed: Percent Complete (100% → 0%)
The problem is not fixed because there is still software which reads /etc/hosts directly. As such, the installation guide still instructs users to add the old entries manually. See the discussion in:
Comment by nl6720 (nl6720) - Sunday, 31 October 2021, 09:28 GMT
The aforementioned wiki discussion was removed. Here's a permanent link:
Comment by Sébastien Luttringer (seblu) - Tuesday, 07 December 2021, 02:26 GMT
To quote my own words from 2017: « 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 addresses on the network. »

1) Which software are broken?
2) Why the localhost lines in /etc/hosts is better than a stub resolver (see SYNTHETIC RECORDS) as a guidance to users?
Comment by nl6720 (nl6720) - Tuesday, 07 December 2021, 15:01 GMT
1) I can't really name all software that reads /etc/hosts and /etc/resolv.conf directly. I only remember that browsers do it (but they hardcode localhost themselves) and GnuPG.
2) Not everyone wants to run a local DNS resolver. Since systemd-resolved.service is not enabled by default and no package ships its /etc/resolv.conf symlink, it makes sense to ship a /etc/hosts file with localhost entries so that things are sane by default.
Comment by Emil (xexaxo) - Thursday, 05 May 2022, 10:38 GMT
In case in matters, as mentioned above - currently systemd-resolved is not enabled by default.

Thus flatpak programs cannot resolve "localhost", leading to all sorts of fun user experiences
Comment by Jonas Witschel (diabonas) - Thursday, 05 May 2022, 10:54 GMT
Resolving localhost is not done by systemd-resolved, but by nss-myhostname ( which is enabled by default in the nsswitch.conf shipped by Arch. Therefore I would expect localhost resolution to work out of the box on a normal Arch system even without enabling systemd-resolved or adding it to /etc/hosts. This is also what the flatpak bug report you linked to reports. Therefore I see no reason to add localhost back to /etc/hosts for this particular use case.
Comment by nl6720 (nl6720) - Thursday, 05 May 2022, 11:18 GMT
nss-myhostname does not concern software that read /etc/hosts and /etc/resolv.conf directly.
Comment by Jonas Witschel (diabonas) - Thursday, 05 May 2022, 11:23 GMT
That is correct, but examples of such software where this would be a problem have not been provided yet in this thread yet. I am not saying there is no reason to have localhost in /etc/hosts, just that flatpak does not appear to be one of the cases where this would be beneficial (because the issue is already solved by using nss-myhostname, which is enabled by default in Arch).
Comment by Sébastien Luttringer (seblu) - Thursday, 05 May 2022, 16:16 GMT
We are not looking for all broken software but examples of supported packages which are reported to be problematic would be helpful.
Software, like browsers, which do not use the system resolver on purpose are not valid case studies.

People who do not want stub resolvers on their systems are free to add these lines if this is enough to correct their problem with software that does not respect the NSS APIs.

Our current documentation is misleading, the best practice is to have a stub resolver enabled and not to add some lines from the past in /etc/hosts. I don't think we have anything to correct here.
Comment by Emil (xexaxo) - Thursday, 05 May 2022, 18:07 GMT
Maybe I'm reading it wrong, but the statement comes as fairly dismissive - "Software, like browsers, which do not use the system resolver on purpose are not valid case studies."

Yes browsers are broken on various levels, yet they are still a major player within each distribution. If we are to ignore them, which package/project has enough weight to change our minds - flatpak? As outlined, flatpak also refuses to work (does not set "nss-myhostname" in it's nsswitch.conf) and one way to "fix" that is by adding the localhost entries to /etc/hosts.

Checking through "man 5 hosts" it explicitly lists the localhost entries in the EXAMPLES section. So we're sort of going against the official documentation - sure the entries are not mentioned as mandatory yet heavily implied as recommended.

Alternatively perhaps we can look at this from more pragmatic angle: Which takes more time and effort - analysing failures in various projects or reinstating the entries?

I deeply implore you to reconsider and opt for the more pragmatic solution.
Comment by Sébastien Luttringer (seblu) - Thursday, 05 May 2022, 23:07 GMT
I'm saying that browsers and others software like dig/drill do not use the system resolver by design! It's a FEATURE. It's nothing dismissive.
I didn't write or think that browsers are broken. Sorry wrong person.

I haven't read much about flatpak issues, but from previous comments there is no problem as nss-myhostname does its job.

The EXAMPLES section of the man pages should show examples, not required things. Also, in the man page you pointed to, the comment is "The following lines are desirable". Desirable is not mandatory. Anyway, the man pages are not official documentation.

Please stay technical with your answers, this is not the place to implore anyone. Use logic and good arguments to convince.