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
