resolved: correctly handle address families with /etc/hosts lookups

[Steve Langasek]

I have an ipv4 entry for a key host on my network listed in /etc/hosts, for network recovery purposes. This host also has ipv6 connectivity; the ipv6 address is resolvable via DNS, but I do not have it in /etc/hosts. Resolution of hostname should be independent for each address family.

Two days ago (I don't know what changed to trigger this), I stopped being able to resolve the ipv6 address for this host. I traced this down to systemd-resolved, returning a lookup failure for the nss request, because the ipv6 address is not listed in /etc/hosts.

Removing resolve from /etc/nsswitch.conf restores the correct behavior.

Removing the ipv4 entry for the host restores the correct behavior.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: systemd 231-9ubuntu1
ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1
Uname: Linux 4.8.0-27-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Nov 23 08:13:33 2016
InstallationDate: Installed on 2010-09-24 (2252 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MachineType: LENOVO 2306CTO
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago)
dmi.bios.date: 10/25/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: G2ET97WW (2.57 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2306CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2306CTO
dmi.product.version: ThinkPad X230
dmi.sys.vendor: LENOVO

[Martin Pitt (pitti)]

Confirmed. I wrote a test case for test/networkd-test.py which reproduces this. This should be committed together with the fix.

[Martin Pitt (pitti)]

I cannot confirm that glibc's "dns" works like that -- it behaves the same as resolved:

$ grep heise.de /etc/hosts
1.2.3.4 heise.de

$ grep hosts /etc/nsswitch.conf
hosts: files dns

$ getent ahosts heise.de | grep STREAM
1.2.3.4 STREAM heise.de

If I drop the heise.de entry from /etc/hosts, I get an IPv6 address again as expected:

$ getent ahosts heise.de | grep STREAM
2a02:2e0:3fe:1001:302:: STREAM heise.de
193.99.144.80 STREAM

This is all after "sudo systemctl stop systemd-resolved", so it's not interfering at all. Can you try the above on your system, to make sure it behaves the same?

[Steve Langasek (vorlon)]

I can confirm this behavior of 'getent ahosts'. 'getent ahostsv6' also shows ::ffff:207.[...] instead of the ipv6 address in this case. Nevertheless, the behavior is definitely different for e.g. 'ping6' or postfix address resolution depending on whether systemd-resolved is running.

[Martin Pitt (pitti)]

First PR sent upstream: https://github.com/systemd/systemd/pull/4808

[Martin Pitt (pitti)]

See the summary from https://github.com/systemd/systemd/pull/4808: I can't convince Lennart about falling back to DNS for IPv6 if hosts has an IPv4 entry -- if hosts has some answer, it should be considered authoritative, and we should not mix different sources for the same query. Often /etc/hosts gets used to blacklist ad/spam domains, and this behaviour would break that.

However, the more serious case is that if you have some *.example.com in /etc/hosts and then query the MX, SOA, or other non-address record for example.com then that query also fails. That's the part that I'll fix and Lennart agrees with.

[Martin Pitt (pitti)]

The fix landed in master: https://github.com/systemd/systemd/commit/4050e04b

[Dimitri John Ledkov (xnox)]

Fixed in artful.