[SOLVED] dns server priority in systemd resolve

vincix · 08-11-2020, 07:05 AM

I'd like to understand how the priority of the dns servers works in the systemd resolve service.
For instance, when I connect to the VPN, I get the DNS servers associated with the tun0 interface (systemd-resolve --status):

Code:

Link 6 (tun0)
      Current Scopes: DNS          
DefaultRoute setting: yes          
       LLMNR setting: yes          
MulticastDNS setting: no           
  DNSOverTLS setting: no           
      DNSSEC setting: no           
    DNSSEC supported: no           
  Current DNS Server: 192.168.50.21
         DNS Servers: 192.168.50.21
                      192.168.50.22
          DNS Domain: company.local

And for my main wlan interface (facing the internet):

Code:

Link 2 (wlp0s20f3)
      Current Scopes: DNS                                 
DefaultRoute setting: yes                                 
       LLMNR setting: yes                                 
MulticastDNS setting: no                                  
  DNSOverTLS setting: no                                  
      DNSSEC setting: no                                  
    DNSSEC supported: no                                  
  Current DNS Server: 192.168.0.1                         
         DNS Servers: 192.168.0.1                         
                      2a02:8109:a0c0:46c:10:18ff:febf:48dc
          DNS Domain: ~.

In this scenario, 192.168.0.1 (from my own router) is being used.
This is what I get when I tell the vpn client to "use this connection only for resources on its network".

But when I uncheck this, so that all the traffic goes through the vpn, there's no DNS anymore for Link 2 (the internet facing interface):

Code:

Link 2 (wlp0s20f3)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no

The one from tun0 remains the same.
So how can I actually tell what dns server is currently (default) being used without turning to tcpdump, for instance?

scasey · 08-12-2020, 09:32 AM

dig will (should) report the IP address of the name server that handled the request.

Code:

dig -x 8.8.8.8
8.8.8.8.in-addr.arpa.   82019   IN      PTR     dns.google.
;; Query time: 11 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Aug 12 07:31:41 MST 2020
;; MSG SIZE  rcvd: 73

...emphasis added

vincix · 08-12-2020, 02:55 PM

I think that happens only when you're not using systemd resolve as the dns daemon. If you've tried that on Centos 7, then it doesn't matter. Try it on Ubuntu 18 or 20, for instance. It might be the same on Centos 8, haven't tested it there. It will always show you 127.0.0.53#53.

scasey · 08-12-2020, 03:19 PM

The posted code is from this desktop, and uses the router...which is configured in turn to use the ISPs DNS.
I get a similar response from the server, except it returns the data center's DNS.

Both are current CentOS 7.8 configurations. Neither is running a DNS daemon.

vincix · 08-12-2020, 04:11 PM

systemd-resolved seems to work in different ways depending on the distro, but:

Quote:

Using the systemd DNS stub file - the systemd DNS stub file /run/systemd/resolve/stub-resolv.conf contains the local stub 127.0.0.53 as the only DNS server and a list of search domains. This is the recommended mode of operation.

https://wiki.archlinux.org/index.php/Systemd-resolved

On Centos 7 /etc/resolv.conf is an actual file, whereas on Ubuntu 18/20 (server and desktop) it's just a symlink to /run/systemd/resolve/stub-resolv.conf. On Centos 8 as see it's the same as on Centos 7.

Regardless, as long as you don't have access to the command systemd-resolve, it really doesn't matter

vincix · 08-16-2020, 02:49 PM

SO anyone any ideas yet? I find the situation a little bit ridiculous, you basically don't know what your main DNS Server is on systemd-resolve, if you get several from different sources. So what are the criteria?

vincix · 11-12-2020, 05:29 PM

So I've finally found the answer: by default systemd-resolve will query the dns server one after another:

Code:

root@ubuntu1:~# resolvectl dns
Global:
Link 10 (tun0): 192.168.50.21 192.168.50.22
Link 3 (docker0):
Link 2 (wlp0s20f3): 192.168.0.1

But more importantly is to see what domains are associated to an interface:

Code:

root@ubuntu1:~# resolvectl domain 
Global:
Link 10 (tun0): company.local
Link 3 (docker0):
Link 2 (wlp0s20f3): ~.

So company.local and all subdomains are going to use the tun0 dns servers, wheras the rest (~) is going to use 192.168.0.1.