28

Since upgrading to 17.04 I can no longer resolve addresses in my local network (silvesternet.local). I get the following response:

$ systemd-resolve edgerouter
edgerouter: resolve call failed: No appropriate name servers or networks for name found

In the journal there are only reports of timeouts for transaction related to this lookup.

I used Wireshark to sniff the network traffic, and it seems that it does not even try to lookup the name. There is no dns traffic whatsoever. Looking up another external domain works just fine.

Many issues around the same topic mention changing nsswitch.conf, but that does not seem to solve anything. My current settings are:

hosts:          files mdns4_minimal dns [NOTFOUND=return] resolve [!UNAVAIL=return] mdns4
3
  • 1
    Have you run sudo apt update && sudo apt full-upgrade? Bugs in the release image got fixed...
    – Zanna
    May 22, 2017 at 15:06
  • 1
    if you're using systemd-networkd to configure interfaces, you may need to add UseDomains=true in the [DHCP] section of your .network files: wiki.archlinux.org/index.php/systemd-networkd#.5BDHCP.5D
    – quixotic
    May 22, 2017 at 17:38
  • Indeed, close with the domain. It was actually a bug in edgerouter firmware that did not set the domain in the dhcp response. May 24, 2017 at 18:01

5 Answers 5

22

I believe this is by design.

Ubuntu 17.04 has switched to systemd-resolved for name resolution and it uses only LLMNR (multicast name lookup) for single-label names resolution. See this link for details: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html

For the reasoning behind this decision check out poettering's reply in this bug report: https://github.com/systemd/systemd/issues/2514

UPD: This issue can be worked around by using a domain for local network. If network interface is configured (either manually or by DHCP) to use a search domain then systemd-resolved will add this domain to single-label names and then look them up via unicast DNS.

Obviously the local DNS server should be reconfigured to recognise these domain. In case of dnsmasq that reads local host-to-IP pairs from /etc/hosts it can be accomplished by adding following instructions to dnsmasq.conf:

domain=mydomain.net
local=/mydomain.net/
expand-hosts

UPD2: Or you could just revert to dnsmasq as described here https://askubuntu.com/a/911432/692094

4
  • And one more bug page with some explanations: github.com/systemd/systemd/issues/4821
    – ish-west
    May 23, 2017 at 15:46
  • The domain-name was the issue here. It was actually also caused by a bug in the edgerouter firmware. The domain-name option from the configuration was not properly stored in dhcp configuration. So clients did not get a domain to search. May 24, 2017 at 18:00
  • UPD solved this years-long systemd-resolved headache for me. It is a true solution for me that lets newly created boxes on my LAN work out of the gate, with no systemd-resolved tomfoolery. Thank you very very very much.
    – moodboom
    Apr 14, 2021 at 15:31
  • home.arpa is the recommended fake domain name in en.wikipedia.org/wiki/.arpa#Residential_networking. And in my case I fixed my problem simply by adding domain name to the LAN settings of my home router; it was empty; after explicitly reconnecting my 20.04 can now resolve local network names normally. Jan 3, 2022 at 7:12
16

I got the same problem on Ubuntu 18.04, which also use systemd-resolved for DNS. Its default configuration does not resolve single-label hostnames or .local domain hostnames by DNS, but by LLMNR or mDNS respectively.

To make local single-label hostnames or .local domain hostnames resolved by DNS, I enabled the 3rd of the "Four modes of handling /etc/resolv.conf" described in the man page for systemd-resolved.service:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

A similar answer was given here. And again, for the reasoning behind the default, see poettering's reply in this bug report.

3

What worked for me after upgrating to 18.04 was to configure the file /etc/systemd/resolved.conf changing the Domains parameter to the domain (local or as in my case mydomain.local). I also changed the DNS parameter, but it seemed that it is not relevant, but I mention it just in case that is not true. For more information go to https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html.

Additionally I changed the avahi configuration (/etc/avahi/avahi-daemon.conf) to change the domain parameter inside the server section from local (the default) to something else as some people pointed out in this forum.

With the mentioned changes I can reach the machines using dotless names, for example, pinging to mycomputer the machine is contacted successfully. However, if I ping to mycomputer.mydomain.local it does not work, the FQDN is not resolved as expected.

Hoping this helps for some cases or lead to a more general solution.

1
  • I think this is the correct solution - systemd-resolve will then tack on the domain name to DNS requests before forwarding them to your local DNS server. Domainless requests averted, and problem solved. I don't know why using your FQDN doesn't work, it works for me (using a gateway with dnsmasq and domain and expand-host set) Apr 23, 2020 at 9:51
1

I faced with this problem because of misconfigured nsswitch.conf. Since 12.04 following string worked as expected. Hostnames without domain resolves succesfully.

But new 17.04 version (as well as version 16.10) of ubuntu with old template for configuring nss system doesn't work like before.

Misconfigured version of hosts, from old ubuntu versions: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

Success working version of hosts, for example from 17.04: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

1

If someone is using systemd version 242 or older (Ubuntu 17.04 came with systemd 232), systemd-networkd for network configuration and DHCP to obtain local domains (UseDomains=true in the [DHCP] section of .network files) then one reason for not resolving local (not necessarily .local) domains could be the bug systemd-networkd DHCP search domains option which made it so that resolving worked only if DHCP server had pushed domain names forcefully i.e. even if the client does not ask for it in the parameter request list.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .