To be honest, I didn't expect a task like this will be so complicated. I imagined that this was implemented in the GUI in such a simple way that you could just specify different DNSs for different interfaces/subnets and it would magically start working. But it's not.
I already did VPN split tunnel with forum help in this thread Static route split tunnelling understanding
I also read this https://github.com/egc112/OpenWRT-egc-add-on/tree/main/stop-dns-leak
Now I'm not even asking how to do DNS split. I'm trying to figure out which way to go and why. Which method to use?
When I asked AI, it listed these options:
Unbound as recursive resolver with access-control / forward-zone per view
Description: Run unbound on the router as a full recursive resolver or with forwarding; use access-control and view-like configuration (unbound supports access-control but not X-Client-IP based views directly; can use interface-based or access-control + stub-zone forwarding).
Pros:
Very flexible and privacy-friendly (can be fully recursive, avoiding upstream leakage).
Good DNSSEC support and advanced features.
Cons:
Unbound lacks native “views” by client-net; per-client different upstreams is awkward (requires multiple instances or complex ACL+interface binding).
More memory/CPU use than dnsmasq.
Complexity increases if you need to forward some clients to specific upstream resolvers.
Split DNS with multiple resolver instances (dnsmasq/unbound/stubby) bound to different IPs
Description: Run two resolver instances (e.g., dnsmasq or unbound) bound to different local IPs (e.g., 192.168.2.1 -> resolver A, 10.0.7.1 -> resolver B). Configure DHCP to hand out the corresponding resolver IP per subnet/interface.
Pros:
Clear separation: clients use the resolver you provide for their network.
Can make one resolver use VPN-side DNS and the other use ISP DNS.
Prevents leaks if resolvers are bound to correct outbound interfaces.
Cons:
Requires careful binding of instances to interfaces and firewall rules to prevent cross-use.
More configuration overhead and potential port conflicts.
Need to ensure resolver outbound traffic goes via intended interface (policy routing + iptables).
Policy-based routing + firewall (iptables/ipset) redirect of UDP/TCP 53
Description: Keep a single resolver but use policy routing and firewall rules (mangle table + ip rule/ip route) to force DNS traffic from a given source net to a specific gateway, or use NAT to redirect port 53 to a chosen local resolver.
Pros:
Works with existing single-resolver setups.
Highly granular: route DNS queries by source IP or mark.
Cons:
Complex to get right (ip rule/ip route, fwmark, iptables MARK).
Risk of breaking system services or causing loops if misapplied.
Must handle both UDP and TCP and DoH/DoT ports; DoH over 443 is hard to intercept.
DHCP option 6 per-interface / per-subnet
Description: Configure OpenWrt's DHCP to hand out option 6 (DNS servers) per interface/subnet so clients use different DNS automatically.
Pros:
Simple and standard-compliant.
Works for well-behaved DHCP clients.
Cons:
Does not prevent clients from using hardcoded or encrypted DNS (DoH/DoT).
Leaks possible if clients choose alternative resolvers or if network-level policy allows bypassing.
Using nftables with per-network NAT and redirect of DNS to local resolvers
Description: Use nftables (if available) to redirect/masquerade DNS traffic by source net to chosen resolvers and ensure policy routing of resolver outbound traffic.
Pros:
Modern packet filtering option; powerful and efficient.
Cons:
Complexity comparable to iptables solution; same pitfalls.
Excluded by me as ineligible:
dnsmasq with conditional forwarding / domain-based servers
Description: Use dnsmasq (default) to set upstream DNS per domain or use server=/domain/IP to forward specific domains to specific DNS servers or use tag-based rules in /etc/config/dhcp to assign different DNS to DHCP clients by MAC, interface, or tag.
Pros:
Lightweight and built-in to OpenWrt.
Easy to configure for domain-level routing or per-interface DHCP options.
Low latency and simple to maintain.
Cons:
dnsmasq's per-interface configuration for different upstream resolvers is limited — it uses domain-based forwarding or DHCP-option-based client assignment, not per-source-IP recursion.
Does not natively separate DNS over different upstream network interfaces (e.g., forcing queries from 192.168.2.0 to the tunnel’s DNS) without extra iptables/socat tricks.
DNS-over-HTTPS/ TLS integration is limited unless using stubby/unbound or forwarding to a local DoT/DoH client.
Local DoT/DoH clients per network + forwarding (e.g., stubby, cloudflared, doh-client)
Description: Run local TLS/HTTPS DNS clients tied to interfaces (or separate instances) and forward queries from clients on specific network to the chosen local stub resolver which then uses the appropriate upstream over the desired interface.
Pros:
Encrypts upstream DNS (avoids leakage to ISP).
Can enforce upstream selection per-client-net by binding stub to interface/IP.
Cons:
Running multiple stubs increases complexity and resource usage.
Some clients don't support binding to a specific source IP easily.
Need policy routing to ensure stub-to-upstream traffic uses expected gateway.
VPN client DNS management (push/pull hooks + resolvconf/odhcpd adjustments)
Description: Use the VPN client's scripts to push DNS to clients in the tunnel or adjust resolvconf so that DNS for tunnel-subnet is set to VPN DNS while others remain.
Pros:
Integrates DNS changes with VPN lifecycle; automatically uses VPN provider DNS for tunnel clients.
Convenient for OpenVPN/OpenConnect/ WireGuard post-up scripts.
Cons:
Hard to maintain when split-tunneling; resolvconf changes are global unless carefully scoped.
Risk of race conditions and leaks during reconfiguration.
Not fine-grained per LAN subnet unless DHCP is controlled.
DNS-over-HTTPS interception + proxy differences (transparent DoH proxying)
Description: Intercept HTTP(S) DoH traffic and forward to different DoH upstreams with a proxy based on source network.
Pros:
Can control encrypted DNS traffic per source net.
Cons:
Very complex; intercepting HTTPS breaks TLS unless using TLS termination (not acceptable).
Not recommended; likely impossible without client cooperation.
My problem is I don't know networks well, this is is my first openwrt steps and I don't have any good networking friends who I can endlessly ask. Other than AI, but AI often bullshitting me. So, help me figure this out. I read these descriptions and can't understand what is the best clean reliable way.
-
I want no DNS leak for sure for privacy goals
-
I want manually set up different DNS for WAN subnets and for VPN subnets
-
Not sure (depends on how much it complicates things). I want something universal that will work with multiple VPNs (on one router)
-
I want something true, rather than using hacks and crutches
-
I like when clients see router IP as DNS resolver that's why I am not sure DHCP option 6 is a good option. But I don't know
What can you recommend? I'm looking for an extended answer, but any information would be helpful
