For a fresh install of Ubuntu 18.04 I found that libnss-resolve needed to be installed to fix various systemd-resolvd errors (with a setup like you describe, gateway does DHCP for a local net and DNS). Your case may be different because you seem to have a null domain. My ISP sets up a line like "search blah.blah.isp.net" which becomes the domain for nslookup of plain names (without an ending period). When the ending period is used on the plain machine name, then just the name is returned without the period or domain and the address. Another problem may be that upgrades from 16.04 may result in a different systemd-resolvd setup. The standard I assume is /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf, which contains nameserver 127.0.0.53, options edns0, and search blah.blah.isp.net. There is another file /run/systemd/resolve/resolv.conf which contains the gateway instead of 127.0.0.53. If you switch the /etc/resolv.conf link to this file, you cut systemd-resolvd out of the loop, fixing some problems but maybe causing others. The libnss-resolve package changes the hosts line in /etc/nsswitch.conf to: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname which fixes all problems I have noticed (including the dns failures when running with a reduced function set after an NXDOMAIN error (see syslog)).
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1777579 Title: 18.04 Desktop LTS DNS behavior (systemd-resolved) Status in systemd package in Ubuntu: Expired Bug description: Hi, I am using te latest Ubuntu Mate Desktop 18.04 LTS release and have issues getting local DNS to work. In my network I maintain a central router instance that povides DHCP and DNS successfully over many years. The DHCP assigns a valid address and correct DNS information to my above mentioned network client. However DNS resolution does not work for DNS records maintained in my router for my local network. See here: (local DNS server on .3.1) uho@Asus:~/Schreibtisch$ systemd-resolve --status Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 2 (wlp2s0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.3.1 uho@Asus:~/Schreibtisch$ uho@Asus:~/Schreibtisch$ nslookup filou Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find filou: SERVFAIL uho@Asus:~/Schreibtisch$ nslookup filou 192.168.3.1 Server: 192.168.3.1 Address: 192.168.3.1#53 Non-authoritative answer: Name: filou Address: 192.168.3.10 uho@Asus:~/Schreibtisch$ nslookup 192.168.3.10 10.3.168.192.in-addr.arpa name = filou. Authoritative answers can be found from: uho@Asus:~/Schreibtisch$ The example above shows that DNS forward lookup for "filou" does not work, only reverse lookup works. The same behavior with explicit DNS setting in network manager. Any idea what's wrong? To me this looks weirdly broken. BTW: Old school setting in /etc/resolv.conf works like a charm. BR Uwe To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1777579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
