DNS queries does not work properly with v15_beta

[trash-80]

After upgrading to v15_beta, I could no longer keep access to subdomains. All regular domains functioned as expected.
e.g. my.domain.org works just fine, but my.other.domain.org does not.

I downgraded to v13_beta and no longer have this issue.

When using v15_beta, I could flush my cache and the subdomains would function once again, for about 30 seconds, then once again were inaccessible.

[dsommers]

Can you provide the output of resolvectl when connecting to v15_beta and v13_beta.

Also, is /etc/resolv.conf a symlink to /run/systemd/resolve/stub-resolv.conf on your system? And what is the output of grep host /etc/nsswitch.conf?

The main difference between v13_beta and v15_beta is that openvpn3-linux integrates directly with systemd-resolved instead of manipulating /etc/resolv.conf. If /etc/resolv.conf is a symlink, systemd-resolved should pick up that change. But applications depending the glibc resolver might not query systemd-resolved if the nsswitch.conf file does not enable systemd-resolved.

[Ferke85]

I have a problem with DNS queries using v15_beta on Ubuntu 20.04.
I can connect to the server without any issue, but the server IP address changes every day and the reconnection doesn't work to the new IP.

2021-08-08 22:28:14 Client DEBUG: Server poll timeout, trying next remote entry...
2021-08-08 22:28:14 Client INFO: Reconnecting
2021-08-08 22:28:14 >> Connection, Client reconnect
2021-08-08 22:28:14 Client DEBUG: Contacting 193.X.X.98:11941 via UDP
2021-08-08 22:28:14 Client VERB1: Waiting for server response
2021-08-08 22:28:14 Client DEBUG: Connecting to [szXXX.ddns.net]:11941 (193.X.X.98) via UDPv4
2021-08-08 22:28:24 Client DEBUG: Server poll timeout, trying next remote entry...
2021-08-08 22:28:24 Client INFO: Reconnecting
2021-08-08 22:28:24 >> Connection, Client reconnect
2021-08-08 22:28:24 Client DEBUG: Contacting 193.X.X.98:11941 via UDP
2021-08-08 22:28:24 Client VERB1: Waiting for server response
2021-08-08 22:28:24 Client DEBUG: Connecting to [szXXX.ddns.net]:11941 (193.X.X.98) via UDPv4

ping szXXX.ddns.net
PING szXXX.ddns.net (94.X.X.210) 56(84) bytes of data.

As you can see the "ping" gets a different IP address (94.X.X.210) than openvpn3 client (193.X.X.98) does. The openvpn3 doesn't update the IP of the domain name, that are trying to connect to the old IP address, but of cource it doesn't work.

/etc/resolv.conf is a symlink:

ll /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jul 31  2020 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

grep host /etc/nsswitch.conf
hosts:          files dns

[dsommers]

I have currently blocked @trash-80 for 30 days for closing an unresolved issue, in addition restored the initial OP message and issue subject as that is still relevant. This kind of behavior is unacceptable.

[tonial]

Hi,

I have the same issue : with the vpn on, not all dsn work properly.
I've made the tests with v16_Beta instead of v15 since there's a newer version

v13_Beta resolvectl

Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          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 (tun0)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

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

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

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

Link 2 (enp0s31f6)
      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.254
         DNS Servers: 192.168.0.254
                      fd0f:ee:b0::1
          DNS Domain: ~.  

v16_Beta

Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          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 (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: 10.100.224.97
         DNS Servers: 10.100.224.97
          DNS Domain: ~.           

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

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

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

Link 2 (enp0s31f6)
      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.254
         DNS Servers: 192.168.0.254
                      fd0f:ee:b0::1
          DNS Domain: ~. 

With v13, my /etc/resolv.conf is a file :

#
# Generated by OpenVPN 3 Linux (NetCfg::DNS::ResolvConfFile)
# Last updated: 2021-10-26 06:56:40 
#

# OpenVPN defined name servers
nameserver 10.100.224.97

# System defined name servers
nameserver 127.0.0.53

# Other system settings
options edns0 trust-ad

With v16 I recreated the simlink : sudo ln -nsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

And lastly the hosts line in /etc/nsswitch.conf

➜  ~ grep host /etc/nsswitch.conf
hosts:          files resolve dns mdns4_minimal [NOTFOUND=return] [!UNAVAIL=return]

I tested with and without resolve that I added after reading a stackoverflow thread on the subject, no changes.

I hope it will help.

[dsommers]

First ... understanding the problem better

Can you please describe:

• What is not working for you in regards to the DNS queries? What you did you expect to see?
• Have you tried to flush the resolved cache? (resolvectl flush-caches).
• Which distro and systemd version are you running?

Switching back to the pre v14_beta behaviour of DNS configuration

For distributions known to ship with systemd-resolved enabled by default, this is how you revert back to the previous behavior. These instructions here requires v16_beta or newer. This is considered a "hackish quickfix" and not a sustainable solution.

Run all the commands presented here as root. First start by re-configure to modify directly /etc/resolv.conf and explicitly disable the systemd-resolved integration:

# openvpn3-admin netcfg-service --config-set resolve-conf /etc/resolv.conf
# openvpn3-admin netcfg-service --config-set systemd-resolved false

Then ensure you have no VPN sessions running (check with openvpn3-admin sessionmgr-service --list-sessions) and do a simple killall -INT openvpn3-service-netcfg. Double check that there are no openvpn3-service-netcfg processes running before you start the VPN connection again.

[dsommers]

@Ferke85 I'm sorry to see you didn't get a reply on your challenge. This isn't necessarily related to this issue, but a different one we resolved in the OpenVPN 3 Core library, also included in v16_beta release. Please re-test v16_beta and open a new issue on your issue if you still experience this.