It can, in my experience. The underlying system process, stubby, doesn’t always seem to ‘grasp onto’ the fact it should be sending traffic through the VPN link once the link is then established. Firmware 4.3.x should also have support for Encrypted DNS via Cloudflare’s DOH. DOH uses port 443 as if it’s just another packet of any other web traffic vs DOT’s :853. Try giving that a shot… with & without WG Client active.
I don’t see Cloudflare DOH in the menu on 4.3.6 under Network > DNS. Is it called something else?
Do the following two settings also matter when trying to use Cloudflare’s encrypted DNS together with a Wireguard VPN in client mode:
DNS Rebinding Attack Protection
Override DNS Settings for All Clients
What about specifying Cloudflare’s DNS IPs in the Wireguard client config?
Also, how can I check which DNS server is effectively being used? If I check on a client device behind the router NAT using scutil --dns, it is just going to return the router IP no matter what. If I check on the router using cat /etc/resolv.confit is just going to return 127.0.0.1 no matter what.
I have both enabled & the VPN Dashboard’s Global Options set to force all traffic thru my WG Client. Your use case may be different of course.
That could work too but if you ever deicide to move device MACs outside of the WG tunnel those lookups aren’t going to work too well. IMO it’s a better practice to set DOT (stubby) or DOH (dnscrypt-proxy). You can check to see which one is active via htop (opkg update && opkg install htop).
My Slate AX is running 4.2.3-release5:
GL GUI → Network → DNS → DNS Server Settings
→ Mode: Encrypted DNS
→ Encryption Type: DNS Over HTTPS
→ Servers → + Select Servers → [search to taste]
LAN-side lookups are handled by dnsmasq on localhost which forward requests to the above DNS for outbound.