Ah that actually makes sense. To not bypass the defined DNS, the original entry must be removed, and as long as it does not store the original file/entries internally, it has no chance to revert. However, then probably it works automatically after:
apt install resolvconf
Hi everyone, thank you for the help and guidance 
I am still trying to figure out where nameserver:192.168.1.1 is being inject in /etc/resolv.conf
I installed the package resolvconf and also dbus ( dbus was needed to run the command resolvectl status)
If I run command
head /etc/resolv.conf
It’s contents are:
# 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 "resolvectl status" to see details about the actual nameservers.
nameserver 192.168.1.1
nameserver 127.0.0.53
If I run the command
ls -l /etc/resolv.conf
I get back
/etc/resolv.conf -> ../run/resolvconf/resolv.conf
the symlink conf file contains nameserver 192.168.1.1 …
What seems to be working is :
ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
And then modify /etc/systemd/resolved.conf entries to
DNS=9.9.9.9
FallbackDNS=8.8.8.8
Domains=~.
dig does now return:
;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
MichaIng Do I add
post-up /etc/openvpn/update-resolv-conf
post-down /etc/openvpn/update-resolv-conf
to dietpi-vpn edit up script as is?
I guess 192.168.1.1 is assigned via DHCP, isn’t it?
Hi Joulinar! I think it came from /etc/network/interfaces.d/ now the DNS is commented out #dns-nameservers 192.168.1.1
I noticed the VPN didn’t connect on reboot it timedout. If the vpn is disconnected and the killswitch is on, shouldn’t there not be any connections from the PI to the Internet? But in my case my PI can communicate with the outside world when the VPN is disconnected which is not what I want 
systemctl status dietpi-vpn.service
● dietpi-vpn.service - VPN Client (DietPi)
Loaded: loaded (/etc/systemd/system/dietpi-vpn.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2022-02-14 23:58:46 EST; 34min ago
Process: 456 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config /etc/openvpn/client.ovpn (code=exited, status=0/SUCCESS)
Main PID: 456 (code=exited, status=0/SUCCESS)
Status: "Initialization Sequence Completed"
CPU: 272ms
Feb 10 01:09:57 Pi openvpn[618]: net.ipv6.conf.all.disable_ipv6 = 1
Feb 10 01:09:57 Pi openvpn[621]: net.ipv6.conf.default.disable_ipv6 = 1
Feb 10 01:09:58 Pi openvpn[456]: Initialization Sequence Completed
Feb 14 23:58:46 Pi openvpn[456]: [openvpn2.vpnunlimitedapp.com] Inactivity timeout (--ping-exit), exiting
Feb 14 23:58:46 Pi openvpn[456]: sitnl_send: rtnl: generic error (-3): No such process
Feb 14 23:58:46 Pi openvpn[456]: ERROR: Linux route delete command failed
Feb 14 23:58:46 Pi openvpn[456]: net_addr_ptp_v4_del: 10.200.0.55 dev tun0
Feb 14 23:58:46 Pi openvpn[456]: /var/lib/dietpi/dietpi-vpn/static_down.sh tun0 1500 1553 10.200.0.55 10.200.0.54 init
Feb 14 23:58:46 Pi openvpn[456]: SIGTERM[soft,ping-exit] received, process exiting
Feb 14 23:58:46 Pi systemd[1]: dietpi-vpn.service: Succeeded.
First of all, the /etc/resolv.conf symlink to …/run/resolvconf/resolv.conf was correct, as this is how resolvconf sets it up to function. If you manually change it to the systemd-resolved template (which is not used, no systemd-resolved running, which would conflict with resolvconf, and 127.0.0.53 being invalid), it basically becomes a static file and all attempts to use resolvconf will fail to achieve anything.
/etc/systemd/resolved.conf similarly is the wrong place to configure DNS.
The dns-nameservers entry in /etc/network/interfaces is what controls the /etc/resolv.conf entry when a static IP is configured. If DHCP is used, it shouldn’t have any effect. I suggest, if you use a static IP, to set dns-nameserver 9.9.9.9 in /etc/network/interfaces.
OpenVPN in the logs shows an inactivity timeout after being up since some days. Not sure whether this is something it does by default, or defined in your ovpn client config? Does it work again when running systemctl restart dietpi-vpn?