3

I'm running Ubuntu 18.04 (upgraded from some earlier version) which uses Network Manager and systemd-resolved for name resolution. When I boot, my ethernet connection enp0s31f6 is brought up by Network Manager and given three nameserver addresses via DHCP, 10.1.13.10, 10.1.141.10, 10.1.13.36. Running nmcli shows the three nameservers under "DNS configuration". Running systemd-resolve --status shows them under a "Link 2 (enp0s31f6)" section. I can ping each one. No other connection is active.

testuser ☼ systemd-resolve --status
Global
          DNS Domain: (my org's domain)
          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 3 (wlp4s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (enp0s31f6)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.1.13.10
                      10.1.141.10
                      10.1.13.36
          DNS Domain: (my org's domain)

However, when I actually try to resolve a name, even the name of one of the nameservers, dig claims that "connection timed out: no servers could be reached".

testuser ☼ dig dcpdc001.(my org's domain)

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> dcpdc001.(my org's domain)
;; global options: +cmd
;; connection timed out; no servers could be reached

Note that this name should resolve to 10.1.13.10, the first nameserver.

I have configured resolvconf to use dynamic updates. /etc/resolv.conf points to /run/resolvconf/resolv.conf. This file contains only (non-comments):

nameserver 127.0.0.53
search (my orgs local search domain)

If I add nameserver 10.1.13.10 to this file manually, suddenly dig can resolve again, and anything else that needs to see local names can do so. Removing the nameserver breaks that again.

I don't know much about the servers. They're part of a Windows-based network, but I can use them if I edit resolv.conf manually so I don't think that's the issue, and it implies I don't need to be authenticated to the domain to use them. (I can authenticate to the domain via Ubuntu using Realmd/SSSD, but not if I can't resolve the domain controller...)

The journalctl entries for systemd-resolved show only a few messages about "Using degraded feature set ... for DNS server" but they only refer to the third nameserver, not the others. Nothing for the primary nameserver.

How can I get name resolution working without having to manually edit resolv.conf every time I boot?

I assume the contents of my resolv.conf mean that Network Manager or Systemd has some sort of local caching resolver running? If so, would bypassing it fix things?


I increased the logging level of systemd-resolved and journalctl -f -u systemd-resolved shows:

Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Got DNS stub UDP query packet for id 19836
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Looking up RR for dcpdc001.(org domain) IN A.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Switching to DNS server 10.1.13.10 for interface enp0s31f6.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Cache miss for dcpdc001.(org domain) IN A
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Transaction 12728 for <dcpdc001.(org domain) IN A> scope dns on enp0s31f6/*.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Using feature level UDP+EDNS0+DO+LARGE for transaction 12728.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Using DNS server 10.1.13.10 for transaction 12728.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Sending query packet with id 12728.
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Processing query...
Jul 20 10:33:23 heerij-ubuntu systemd-resolved[2352]: Timeout reached on transaction 12728.
9

Systemd comes with a "stub" resolver, systemd-resolved, which according to them is not actually meant to be used as a DNS server:

Well, resolved is not supposed to be a DNS server, it's supposed to be exactly good enough so that libc-like DNS clients can resolve their stuff, and we carry enough info for the AD bit to be set.

For whatever reason, Ubuntu is configured to use it as a DNS server and, in fact, the only one.

A comment on bug #1624320 points out that systemd-resolved has three modes of operation, and the second one is what fixed my problem. Namely:

$ sudo rm -f /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
  • 2
    This is actually good to know since I will be upgrading to 18.04 soon and I was worried about it resolving to 127.0.0.53 instead of my DNS server. Better control in my opinion. +1 – Terrance Jul 20 '18 at 3:24
  • 1
    @Terrance Glad we got to the bottom of it then! – detly Jul 20 '18 at 3:29
  • 1
    It's worth noting for Google searches that this resolve a DNS resolution problem I had on AWS, where my Ubuntu 18.04 image couldn't resolve Route53 entries. – Iain Hunter Jul 26 '18 at 12:26
  • 1
    Also fixed my Comcast imap mail server resolution problem. Thanks! – Organic Marble Nov 30 '18 at 0:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.