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.
When I use
– Bram Geron Nov 13 '17 at 14:38dig, 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?git.cs.bham.ac.ukandwww.google.com. If you lookup the SOA record forcs.bham.ac.ukandgoogle.comyou get an authoritative result, same for SOA forgit.cs.bham.ac.ukandwww.google.com, but requesting A ongit.cs.bham.ac.ukandwww.google.comis not authoritative. (All of this was tested from a remote (non-uni) host.) – Bram Geron Nov 14 '17 at 17:57dpkg-reconfigure resolvconf-ing will also resolve the problem. – Joseph Redfern Dec 04 '17 at 10:57dpkg-reconfigure resolvconf. I will try removing the package. – Bram Geron Dec 05 '17 at 12:43