I know that systemd-resolve --status
lists all my connections and their DNS servers and nmcli connection show <connection> | grep -i dns
will list the priority of the DNS connections. But is there a single command I can run that will list all DNS servers and their priority/order?
List DNS Server Order in systemd-resolve
dnssystemd-resolved
Related Solutions
I experienced similar problems, for example with adding an extra USB wifi dongle. First I disabled dnsmasq in networkmanager as described above and I stopped dnsmasq (service dnsmasq stop)
I noticed that when resolving broke during my VPN connecting, the routing table looks slightly different (output of route command). The name of the Gateway is DD-WRT in the case it does not work and simply 'gateway' when it does work. The output of this did not change:
nmcli device show wlp1s0 | grep IP4.DNS
It kept showing my router IP. A workaround to get it to work for a while is to restart systemd-resolvd:
sudo service systemd-resolved restart
Since dnsmasq is out of the equation, it is either systemd-resolvd that is the cause of the issue, or anything changing the routing table.
So this is the only difference I see:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 601 0 0
which works. And this when it does NOT work:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default DD-WRT 0.0.0.0 UG 601 0 0 wlp1s0
And the same name difference on the VPN line :
vpn-dns.name gateway 255.255.255.255 UGH 0 0 0 wlp1s0
Who knows what may influence the routing table? It would be great if we can identify this so a bug report can be filed. I am getting seriously sick and tired of pursuing all these bugs, but I would like to get them fixed so future users and us will be happy :).
[update] It seems stopping systemd-resolved may fix this and not negatively impact other stuff. You can try that and let it know if it does break stuff. I saw when running systemd-resolvd in debug when it broke:
Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *
To disable:
sudo systemctl disable systemd-resolved.service
I updated the Ubuntu report with suggestions. [/update] Add: Note: the bug report : https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 has a patch for 17.04 for some issues. Please check the bug report and if possible test the patch. Thank you!
[update]
Please check the above mentioned bug report, the issue seems to be resolved for 17.10 and with a simple command DNS leakage can be disabled too.
[/update]
using 18.10 I had a similar problem. I resolved my problem by modifying /etc/systemd/resolved.conf with the dns server and search domain information. this looks to be correct behavior, according to the man page,
The DNS servers contacted are determined from the global settings in /etc/systemd/resolved.conf, the per-link static settings in /etc/systemd/network/*.network files (in case systemd- networkd.service(8) is used), the per-link dynamic settings received over DHCP, and any DNS server information made available by other system services. See resolved.conf(5) and systemd.network(5) for details about systemd's own configuration files for DNS servers. To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink to /run/systemd/resolve/stub-resolv.conf or /run/systemd/resolve/resolv.conf (see below).
my config looks like this, adjust to fit your environment,
192.168.1.1 is your private dns
domain syntax is important, don't forget the trailing dot "."
/etc/systemd/resolved.conf [Resolve] DNS=192.168.1.1 #FallbackDNS= Domains=blah.mydomain.com. blahblah.mydomain.com. #LLMNR=no #MulticastDNS=no #DNSSEC=no #DNSOverTLS=no #Cache=yes #DNSStubListener=yes
then restart the service
sudo systemctl restart systemd-resolved.service
verify service is running. syntax errors might cause issues that you can see here.
sudo systemctl status systemd-resolved.service
try to lookup a local domain
nslookup blah.mydomain.com
if that did not work, then verify the query does not time out. manually specify the dns server
nslookup blah.mydomain.com 192.168.1.1
resolved has a built-in query function which is helpful
% resolvectl query fedoraproject.org
fedoraproject.org: 2605:bc80:3010:600:dead:beef:cafe:fed9 -- link: enp5s0
2620:52:3:1:dead:beef:cafe:fed7 -- link: enp5s0
2610:28:3090:3001:dead:beef:cafe:fed3 -- link: enp5s0
2604:1580:fe00:0:dead:beef:cafe:fed1 -- link: enp5s0
2605:bc80:3010:600:dead:beef:cafe:feda -- link: enp5s0
2620:52:3:1:dead:beef:cafe:fed6 -- link: enp5s0
209.132.190.2 -- link: enp5s0
8.43.85.67 -- link: enp5s0
38.145.60.21 -- link: enp5s0
67.219.144.68 -- link: enp5s0
140.211.169.196 -- link: enp5s0
140.211.169.206 -- link: enp5s0
152.19.134.142 -- link: enp5s0
38.145.60.20 -- link: enp5s0
152.19.134.198 -- link: enp5s0
8.43.85.73 -- link: enp5s0
-- Information acquired via protocol DNS in 99.8ms.
-- Data is authenticated: no
Best Answer
It is stupid, but you can't!
systemd-resolved
follows internal rules to choose the "correct" DNS. This might be different for each query. It uses things like if a server worked or failed in the past, interface order and even what domains allocated to each interface. It's difficult to manage with some VPN setups.The best you can do is check the
/run/systemd/resolve/resolv.conf
file. That is theresolv.conf
file generated bysystemd-resolved
.