systemd-resolve breaks resolution of local network hostnames

Bug #1699660 reported by Forest on 2017-06-22
48
This bug affects 12 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
High
Unassigned

Bug Description

After upgrading to Ubuntu 17.04 (zesty), resolution of my local network's host names is completely broken. Apparently the upgrade replaced my existing resolver with systemd-resolve, which deliberately refuses to pass "single-label" domain names to my domain name server. That is the server where all my network's host names are kept, so I can no longer resolve any of them.

Apparently, this is yet another example of Poettering's upstream decisions causing denial of service to people who have been saddled with his malware.
https://github.com/systemd/systemd/issues/2514#issuecomment-179203186

Would someone sensible please put a stop to this forced breakage during upgrade, and advise on how to fix it now that the damage has been done?

Dimitri John Ledkov 🌈 (xnox) wrote :

you should be able to opt-into UseDomains by creating

/etc/systemd/network/usedomains.network

[DNS]
UseDomains=true

I believe. does above help you resolve things?

Can you tar up and attach the tarball of /run/systemd to investigate which links you have available, and what domains they have?

Forest (foresto) wrote :

According to the systemd documentation, UseDomains only affects systems that get their network setup from DHCP, which is not the case at my site. Furthermore, it is documented as a way to add a DNS search domain, which would not help resolve hosts that have no domains.

So far, the only way I have found to fix the breakage is to manually disable systemd-resolve and configure a resolver that actually works properly.

Dimitri John Ledkov 🌈 (xnox) wrote :

You can adjust /etc/systemd/resolve.conf to add Domains= that you want to use for single domain resolution for non-DHCP specified DNS server.

Forest (foresto) wrote :

No, that won't help either.

You don't seem to understand: Adding a domain search list will not help because the local machines do not have domains. They only have names, like "host1" or "beetle", even on the network's DNS servers.

Since systemd's resolver refuses to consult the name servers for names like these, it completely breaks name resolution on networks like this.

Dimitri John Ledkov 🌈 (xnox) wrote :

Ok, i see what you mean now. I will test this locally to verify.

Changed in systemd (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Marc MAURICE (mmaurice) wrote :

Same here. After upgrading somes pcs in my company from 16.04 to 17.10 : lots of local services are not working anymore.

Dimitri John Ledkov 🌈 (xnox) wrote :

There is a regression with dns handling between xenial and zesty. There are updates/improvements made in artful that will be published soon. It may not solve your issue, but maybe/hopefully it will improve things a lot.

systemd (234-1ubuntu2) artful; urgency=medium

  * Set UseDomains to true, by default, on Ubuntu.
    On Ubuntu, fallback DNS servers are disabled, therefore we do not leak queries
    to a preset 3rd party by default. In resolved, dnssec is also disabled by
    default, as too much of the internet is broken and using Ubuntu users to debug
    the internet is not very productive - most of the time the end-user cannot fix
    or know how to notify the site owners about the dnssec mistakes. Inherintally
    the DHCP acquired DNS servers are therefore trusted, and are free to spoof
    records. Not trusting DNS search domains, in such scenario, provides limited
    security or privacy benefits. From user point of view, this also appears to be
    a regression from previous Ubuntu releases which do trust DHCP acquired search
    domains by default.
    Therefore we are enabling UseDomains by default on Ubuntu.
    Users may override this setting in the .network files by specifying
    [DHCP|IPv6AcceptRA] UseDomains=no|route options.
  * resolved: create private stub resolve file for integration with resolvconf.
    The stub-resolve.conf file points at resolved stub resolver, but also lists the
    available search domains. This is required to correctly resolve domains without
    using resolve nss module.
  * Enable systemd-resolved by default
  * Create /etc/resolv.conf at postinst, pointing at the stub resolver.
    The stub resolver file is dynamically managed by systemd-resolved. It points at
    the stub resolver as the nameserver, however it also dynamically updates the
    search stanza, thus non-nss dns tools work correctly with unqualified names and
    correctly use the DHCP acquired search domains.
  * libnss-resolve: do not disable and stop systemd-resolved
    resolved is always used by default on ubuntu via stub resolver, therefore it
    should continue to operate without libnss-resolve module installed.

 -- Dimitri John Ledkov <email address hidden> Fri, 21 Jul 2017 17:07:17 +0100

Dawid Wróbel (dawidw) wrote :

This is still a problem in 18.04. Like the OP, I have localhosts on my LAN, but have no local domain configured. I had to disable systemd-resolved on each of my LXC containers. What's worse, resolvconf creates an empty /etc/resolv.conf file. So I had to create resolv.conf by hand and point to DNS. Again, on each of my containers.

This is a major regression. If the systemd-resolved is to be kept, at least have some decency to explicitly note in 18.04 LTS release notes that local hostname resolution requires local domain to be configured for name resolution to work.

Evgeni (ev-mp) wrote :

One more affected usecase - wired LAN connection is not working properly for VMWare Virtual Machine.
I use laptop with Win10 and run Ubuntu 18.04 as guest OS with VMWare.
Everything worked fine with Ubuntu 16 and 14, but with the current version the DNS resolution is now broken and I cannot run even "sudo apt update"

Can someone publish instructions how to work around this issue ?

Evgeni Raikhel <email address hidden>

P.S
Interestingly enough, FireFox is able to reach internet, probably by circumventing the built-in DNS resolution mechanism.

Pedro Côrte-Real (pedrocr) wrote :

Just got bitten by this bug on 18.04 upgrade. This is the default config on LEDE/OpenWRT that gets broken by this upstream decision. Ubuntu should definitely ship a fix of some sort.

Pedro Côrte-Real (pedrocr) wrote :

After testing further I get somewhat random results. Sometimes it fails and sometimes after running "sudo service systemd-resolved restart" I can resolve domains. Very weird.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers