After connected to VPN, systemd-resolve still use ISP's DNS server( which was polluted because of regulation )

[joshuafc]

Submission type

• Request for enhancement (RFE)

systemd version the issue has been seen with

systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

Used distribution

Ubuntu 17.04 Linux version 4.10.0-21-generic (buildd@lgw01-12) (gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2) ) #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017

Because of the Internet regulation, ISP's DNS server can not resolve some domian correctly( for example www.google.com www.youtube.com ). Under normal conditions, we use vpn and set the vpn as default internet gateway when needed to access above website.
When I start to use Ubuntu 17.04, It is found that when connected to vpn, all internet package transfer through vpn except domain name resolve. Infact, VPN server had tell correct DNS server IP address through DHCP. But systemd-resolve still use ISP's polluted resolve.
At /etc/resolv.conf, I found that DNS resolve had be taken over by systemd-resolve. There can't find any easy way to tell systemd-resolve to use a specified DNS server, or disable any DNS server according " systemd-resolve --help ".
Willing to accept guidance to correct my use of systemd-resolve,
If you can, Please add some necessary feature to systemd-resolve to solve such problem,

In case of bug report: Expected behaviour you didn't see

…

In case of bug report: Unexpected behaviour you saw

…

In case of bug report: Steps to reproduce the problem

…

[poettering]

Hmm, not sure I follow. How exactly did you configure your DNS? What does "systemd-resolve --status" report about the DNS servers? Is /etc/resolv.conf a file or a symlink?

[joshuafc]

@poettering thanks for your reply.

here is the information

zhoub@ubuntu:\~$ ll /etc/resolv.conf 
rwxrwxrwx 1 root root 29 Jun  6 09:35 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
zhoub@ubuntu:~$ cat /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
zhoub@ubuntu:~$ systemd-resolve --status
Global
          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 6 (ppp0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: yes

Link 2 (ens33)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
         DNS Servers: 192.168.83.2
          DNS Domain: localdomain
zhoub@ubuntu:~$ ping www.google.com
PING www.google.com (93.46.8.89) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
106 packets transmitted, 0 received, 100% packet loss, time 107507ms

ping failed, 93.46.8.89 is incorrect , ISP's DNS server resolve it to 93.46.8.89 because of Internet regulation. VPN's DNS Server resolve it to 172.217.26.36, which can ping successfully.

[aigarius]

Can confirm the same effect with a OpenVPN connection.

Link 8 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 172.20.0.50
                      172.20.0.14

Link 3 (wlan0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.192.1
          DNS Domain: net

Running "systemd-resolve internal.name.local" fails to find it (it only tries the 192.* DNS server), running "systemd-resolve -i tun0 internal.name.local" resolves the name correctly (via 172.* DNS server), but no applications actually supply that interface, naturally.

Systemd version 232
Ubuntu 17.04

Currently I have to workaround this by overwriting the /etc/resolv.conf file each time I connect to the VPN, but even that now stops working as some apps use the systemd-resolv directly if it is available.

Alternative solution that worked for me is using a patched version of NetworkManager from https://bugs.launchpad.net/network-manager/+bug/1624317 that forces using the VPN DNS server by adding a "DNS Domain: ~." declaration to the tun0 section of systemd-resolve

[mikken]

You (joshuafc and aigarius) need to do 2 things:

1. Make sure that DNS servers obtained from OpenVPN are used by systemd-resolved. You can do it with this little script: https://github.com/jonathanio/update-systemd-resolved
2. While OpenVPN is connected, block (reject with iptables or nftables) all requests that systemd-resolved makes to local DNS server

[mikken]

aigarius, for you the domain .local should be configured as "routing" domain on this link (tun0).

[PureRumble]

@mikken, that script you're telling us to use is 400 lines long. What does it do? Any bugs? Is it safe or does it expose our systems to vulnerabilities? Will it break something else? Why do we need a 400 lines long script (and then to do even more stuff) to achieve something as essential as getting DNS lookups to go through the VPN connection?

Nearly every time someone connects to a VPN service the user's expected system behaviour is that the VPN service's DNS servers should be used and all traffic should go through the VPN connection; this is especially true for novice users. This should therefore be the default behaviour.

But not only is this not the default behavior, there also isn't some easy way to make systemd-resolved to work as desired (e.g. you have to use 400 lines long scripts, block packets to your ISP's DNS server at the IP-level, etc).

systemd-resolved is a "system service that provides network name resolution". It is beyond essential that a system that "provides network name resolution" should be able to with little effort to be made to route DNS requests through a VPN connection. Also, it's default behavior out-of-the-box should comply with the most common use cases (e.g. user connects to a VPN service ==> all data goes through VPN connection).

[flo-wer]

See #7182

[snabb]

My current workaround is to do the following tricks every time I start my workplace VPN:

1. Find out the link number (a.k.a. interface index) of the ISP interface: systemd-resolve --status or ip l.
2. Connect the VPN.
3. Remove DNS settings from the ISP interface (using the link number from step 1) by sending a D-Bus command to systemd-resolved. This is an example using link number 2: sudo busctl call org.freedesktop.resolve1 /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager SetLinkDNS 'ia(iay)' 2 0
4. Inspect with systemd-resolve --status to ensure that only the correct DNS servers are there.

Apparently there isn't any simple cli tool for managing systemd-resolved's settings. That busctl command isn't very user-friendly. :)

[poettering]

So, resolved is actually doing the right thing here, given the configuration it was given. @joshuafc, resolved only knows the DNS server 192.168.83.2 in your setup, but you want it to know 208.67.222.222 and 8.8.8.8, right? If so, this information needs to be made available to resolved, and the ppp scripts (given that you are using ppp/pptp) need to push it into resolved, which i think ubuntu updated the "resolvconf" package to do. But that's really outside of the scope of upstream resolved. @nox, can you help? is there some ppp/pptp hookup missing for resolved in ubuntu?

[poettering]

@snabb #7576 adds the requested "simple cli" functionality to systemd-resolve.