6

I recently upgraded from 16.04 to 17.10, and some domain names now fail to resolve in systemd-resolved, even though my home DNS server resolves the domain names just fine.

My workplace domain is *.cs.bham.ac.uk (Computer Science inside a uni), and those domains resolve fine when I'm at work. But when I go home, those domains stop resolving. The place where I am now has no relationship to anything .bham.ac.uk.

bgeron@tinker ~> systemd-resolve git.cs.bham.ac.uk
git.cs.bham.ac.uk: resolve call failed: No appropriate name servers or networks for name found
bgeron@tinker ~> host git.cs.bham.ac.uk
Host git.cs.bham.ac.uk not found: 2(SERVFAIL)
bgeron@tinker ~> host git.cs.bham.ac.uk 192.168.1.254
Using domain server:
Name: 192.168.1.254
Address: 192.168.1.254#53
Aliases: 

git.cs.bham.ac.uk has address 147.188.203.99
bgeron@tinker ~> systemd-resolve --status
Global
          DNS Domain: lan
                      adf.bham.ac.uk
                      bham.ac.uk
                      cs.bham.ac.uk
          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 4 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (wlp4s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.254
          DNS Domain: lan

Link 2 (enp0s31f6)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

I have no idea why those DNS domains are listed there. It looks like a stale cache of some sorts. Executing systemd-resolve --flush-caches as root does not seem to have any impact.

Contents of /etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search lan adf.bham.ac.uk bham.ac.uk cs.bham.ac.uk

When I remove the search line, then the lookups work again. But obviously this is not a permanent solution.

I believe I'm pretty much just using vanilla NetworkManager. I have a Bluetooth PAN device set up but not activated.

In the past, at uni there was a problem with local hostnames not resolving: I believe *.cs.bham.ac.uk would resolve (as determined by host(1)) but not *.bham.ac.uk. I cannot recall what systemd-resolve would say for those situations. To fix it, I nuked /etc/nsswitch.conf and put in the following contents which I found online somewhere:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          dns [!UNAVAIL=return] files
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Some log entries in my journal that may or may not be related:

  • wpa_supplicant: Could not read interface p2p-dev-wlp4s0 flags: No such device
  • My GPU driver is giving off some warnings.

More:

Nov 05 22:39:59 tinker systemd[1]: Starting Network Name Resolution...
-- Subject: Unit systemd-resolved.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit systemd-resolved.service has begun starting up.
Nov 05 22:39:59 tinker systemd-resolved[11818]: Positive Trust Anchors:
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 05 22:39:59 tinker systemd-resolved[11818]: Negative trust anchors: 10.in-addr.arpa 16.172.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 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Nov 05 22:39:59 tinker systemd-resolved[11818]: Using system hostname 'tinker'.
Nov 05 22:39:59 tinker systemd[1]: Started Network Name Resolution.
-- Subject: Unit systemd-resolved.service has finished start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit systemd-resolved.service has finished starting up.
-- 
-- The start-up result is done.
Nov 05 22:50:52 tinker systemd-resolved[11818]: Flushed all caches.

Any ideas would be very welcome!

edit Clarification: Trying to resolve any of those hostnames does not result in any network traffic, it immediately gives a negative result.

  • 1
    One issue I found was that git.cs.bham.ac.uk is NOT authoritative on cs.bham.ac.uk's SOA which is dns0.cs.bham.ac.uk. It could be that at your work its somehow is authoritative. I also tried it with the other NSs and none of them resolve authoritative. This might happen if its somehow resolved internally which would explain why it works at your work but not at home. – jdwolf Nov 12 '17 at 23:16
  • Thanks for looking into this! When I use dig, indeed the AUTHORITY flag doesn't seem set on the answer. (Same at work.) But the same seems true for www.google.com. Do you think that might be a problem? – Bram Geron Nov 13 '17 at 14:38
  • 1
    No. That is just telling you that the DNS server is none authoritative for the requests you were making. Try this: dig www.google.com A dns-admin.google.com Authority flag is set because thats the SOA server. At least one of the SOA servers should be authoritative. In your SOA none of them are authoritative. Some DNS forwarders will not work unless they can get an authoritative response. – jdwolf Nov 13 '17 at 16:26
  • 1
    weird I checked this before and dns0.cs.bham.ac.uk would not give me an authoritative result for git.cs.bham.ac.uk. sorry for leading astray – jdwolf Nov 14 '17 at 18:38
  • 1
    @bgeron I have the exact same issue (but in a different CS department -- Cardiff!). I think this is caused by: bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713457. I've just uninstalled resolvconf (suggested as a fix in that comment thread) and will report back here next time I switch networks... – Joseph Redfern Nov 29 '17 at 16:20
3

Per suggestion of Joseph Redfern, it seems that resolvconf doesn't play well with systemd-resolved. Removing the resolvconf package fixed the problem for me.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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