18.04 Desktop LTS DNS behavior (systemd-resolved)

Bug #1777579 reported by Uwe
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Expired
Undecided
Unassigned

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

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1777579/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Paul White (paulw2u)
affects: ubuntu → systemd (Ubuntu)
tags: added: bionic
Revision history for this message
Ken Sharp (kennybobs) wrote :

You need to learn to use ubuntu-bug

Changed in systemd (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]

Changed in systemd (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Uwe (madscientist42) wrote :

Hi, this bug is still valid.
Out of the box, 18.04.x does not take local DNS into account, leading to massive lookup problems.
A lot of discussion and mediocre quality solutions can be found in the wild.
Even workarounds with Network Manager config changes are not persistent.

My proposal:
Revert back to the 16.04 DNS lookup mechanism and test the 18.04 implementation further.

18.04 is barely usable with this DNS implementation...
Unfortunately fixing the issue is beyond my own knowledge of the currently used DNS-SEC implementation.

Revision history for this message
Uwe (madscientist42) wrote :
Revision history for this message
Uwe (madscientist42) wrote :

I wonder what's going wrong here since this bug is not ranked, not confirmed, just expired.

Anyone able to give advice, what is needed to bring focus on it?

Uwe (madscientist42)
summary: - 18.04 Dekstop LTS DNS behavior (systemd-resolved)
+ 18.04 Desktop LTS DNS behavior (systemd-resolved)
Revision history for this message
Ubfan (ubfan1) wrote :

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)).

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

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.