What's new

difference between WAN and LAN DNS settings options

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Chenks

Regular Contributor
hi

can anyone tell me what the difference between these 2 "DNS" settings are? in WAN and LAN

in the WAN section there is a DNS server section, but there is also a DNS server section in the LAN settings (in DHCP).

i have 2 pihole servers on my LAN, and have added both IP addresses into both sections, and everything seems to work as expected, but i'm unsure if that is actually the correct way to have it configured.
I set the DNS servers in the LAN/DHCP settings and i definitely do want them pushed out over DHCP to the clients - which it does, but that leaves me wondering what the WAN DNS settings option actually does then.

Screenshot 2022-08-10 133834.jpg

Screenshot 2022-08-10 133859.jpg
 
The WAN DNS servers are used by the router itself (e.g. for resolving NTP addresses at boot) and as the upstream servers for the router's DNS server (dnsmasq). Personally I always set them to some reliable public servers (e.g. my ISP's and 1.1.1.1) so that the router isn't reliant on the availability of a local DNS server.
 
ah ok, so i should set them to a public DNS server, i already use Cloudfare are the upstream source for pihole, so i would probably use Cloudfare in the WAN section.
what i don't want is any device being able to skip pihole and resolve DNS anywhere other than my local pihole servers.
 
what i don't want is any device being able to skip pihole and resolve DNS anywhere other than my local pihole servers.
By "any device" I assume you mean LAN clients and not necessarily the router itself. Ensuring all LAN clients to use the PiHole starts getting complicated because you then have to start using DNSFilter and block DoH requests. And that doesn't even begin to address client proxies or VPNs. Nothing is 100% guaranteed.
 
A potential problem w/ your current configuration is that because you're specifying local DNS servers via DHCP, your clients will lose local name resolution through DNSMasq, or any other features it offers (caching, ad blocking, etc.). That may or may NOT be an issue for some ppl. NOT unless your alternate DNS servers are offering functional replacements (although I don't see how they could resolve dynamically assigned hostnames provided by DNSMasq).

Another (and perhaps) better option might be to assign those same local DNS servers on the WAN. Now both the router itself and your DHCP clients will use them. And now the WLAN/LAN clients will be assigned DNSMasq (e.g., 192.168.50.1) as their local DNS proxy, which in turn will forward public DNS queries to your local DNS servers, while preserving the benefits of DNSMasq.

As @ColinTaylor pointed out, some might argue this makes DNS resolution for the WAN more fragile than relying on public DNS servers. But if you feel that way, then you could instead define public DNS servers on the WAN, but use a dnsmasq.conf.add file to add the following directives to DNSMasq, effectively overriding the WAN's DNS servers for the DHCP server.

Code:
no-resolv
server=192.168.50.2
server=192.168.50.8

Yeah, it's all really complicated. But a lot of the ins and outs of dealing w/ DNS on the router are described ad nauseum in the following link. You might find it helpful.

 
By "any device" I assume you mean LAN clients and not necessarily the router itself. Ensuring all LAN clients to use the PiHole starts getting complicated because you then have to start using DNSFilter and block DoH requests. And that doesn't even begin to address client proxies or VPNs. Nothing is 100% guaranteed.

yes i mean LAN clients.
i don't want any LAN client not going thru pihole.
 
A potential problem w/ your current configuration is that because you're specifying local DNS servers via DHCP, your clients will lose local name resolution through DNSMasq, or any other features it offers (caching, ad blocking, etc.). That may or may NOT be an issue for some ppl. NOT unless your alternate DNS servers are offering functional replacements (although I don't see how they could resolve dynamically assigned hostnames provided by DNSMasq).

Another (and perhaps) better option might be to assign those same local DNS servers on the WAN. Now both the router itself and your DHCP clients will use them. And now the WLAN/LAN clients will be assigned DNSMasq (e.g., 192.168.50.1) as their local DNS proxy, which in turn will forward public DNS queries to your local DNS servers, while preserving the benefits of DNSMasq.

so maybe the better option is to set DHCP DNS to 192.168.50.1 (router), and set WAN dns to 192.168.50.2/192.168.50.8 ?
i want to make sure that no LAN client bypasses pihole (the upstream DNS servers are set to cloudfare in pihole with DNSSEC enabled).
 
so maybe the better option is to set DHCP DNS to 192.168.50.1 (router), and set WAN dns to 192.168.50.2/192.168.50.8 ?
i want to make sure that no LAN client bypasses pihole (the upstream DNS servers are set to cloudfare in pihole with DNSSEC enabled).

That's up to you. As I said, forcing your clients through DNSMasq for DNS purposes has its advantages. But if you want to use public DNS servers on the WAN, your clients will stlll be routed through your other local DNS servers for all other purposes, just so long as you use the dnsmasq.conf.add file as I described above.

IOW, there is no right or wrong answer here. You just need to understand the consequences of your choices more fully, but that's NOT always obvious. Then decide what works best for YOU.

P.S. For example, I don't use it myself, but let's say you use Diversion for ad blocking. Since that assumes the use of DNSMasq, you lose access to it if you end up bypassing DNSMasq! Then again, if your other local DNS servers are offering this same feature, then perhaps you don't care.
 
Last edited:
i'm probably more confused now than when before i started.

for the mean time i've changed the WAN DNS to the cloudfare public DNS servers, but left the DHCP DNS to my local pihole servers.

I suppose the other option would be to not router the router for DHCP at all, and enable the DHCP server on the pihole. but that's a thought for another day.
 
I know it's complicated. It's unfortunate. But that's just the nature of DNS on the router. Ppl have all kinds of options when it comes to DNS configuration (WAN settings, DHCP settings, DNS filters, the VPNs have DNS options, third-party DNS servers, DoT/Stubby, etc.), and they all have consequences that are NOT always obvious.

That's why I recommended that link, to help eliminate some of the confusion. But admittedly, it can be a tough read in itself. For many, I'm sure they would prefer to NOT think about it and hope things work out as expected. But since you asked the question, I thought I'd take the opportunity to explain it more fully.
 
Last edited:
oh don't get me started on VPN.
i am currently testing routing certain traffic thru a VPN (NordVPN) using VPN director (think you saw a previous thread i had about something similar), and i'm sure i have DNS leak somewhere, but haven't had the change to investigate more and seek out some assistance.
 
A potential problem w/ your current configuration is that because you're specifying local DNS servers via DHCP, your clients will lose local name resolution through DNSMasq,

PiHole has two ways of solving this issue.
  • It can replace router DHCP server - that way is fully aware of any host in the network and its IP address. I don't recommend this, you are starting to distribute the network management between multiple devices. You'd need to manually keep the configuration in sync etc.
  • PiHole can perform conditional forwarding: it can ask the main router running DHCP to resolve names in the local domain. Below an example for a fritz.box local domain (DHCP running on a Fritz!Box router). Reverse resolution (from IP to FQN) works as well.
conditional-forwarding.png
 
Last edited:
oh don't get me started on VPN.
i am currently testing routing certain traffic thru a VPN (NordVPN) using VPN director (think you saw a previous thread i had about something similar), and i'm sure i have DNS leak somewhere, but haven't had the change to investigate more and seek out some assistance.

There is an issue in the implementation in VPN director, which is loosing DNS intercept rules on certain scenarios. It will cause DNS queries leaking.
 
Last edited:
A potential problem w/ your current configuration is that because you're specifying local DNS servers via DHCP, your clients will lose local name resolution through DNSMasq, or any other features it offers (caching, ad blocking, etc.). That may or may NOT be an issue for some ppl. NOT unless your alternate DNS servers are offering functional replacements (although I don't see how they could resolve dynamically assigned hostnames provided by DNSMasq).

Another (and perhaps) better option might be to assign those same local DNS servers on the WAN. Now both the router itself and your DHCP clients will use them. And now the WLAN/LAN clients will be assigned DNSMasq (e.g., 192.168.50.1) as their local DNS proxy, which in turn will forward public DNS queries to your local DNS servers, while preserving the benefits of DNSMasq.

As @ColinTaylor pointed out, some might argue this makes DNS resolution for the WAN more fragile than relying on public DNS servers. But if you feel that way, then you could instead define public DNS servers on the WAN, but use a dnsmasq.conf.add file to add the following directives to DNSMasq, effectively overriding the WAN's DNS servers for the DHCP server.

Code:
no-resolv
server=192.168.50.2
server=192.168.50.8

Yeah, it's all really complicated. But a lot of the ins and outs of dealing w/ DNS on the router are described ad nauseum in the following link. You might find it helpful.

Sorry to hijack this thread - happy to create a new one if preferred but I have the issue with local name resolution since I started using Adguard on my lan for DNS/ad-blocking

My setup is:

WAN - use my ISP for DNS
DHCP - use a dedicated device (raspberry pi) on my network running Adguard home + unbound
DNSfilter - global set to 'router' with Adguard device set to 'no filtering'

When I ping local devices, name resolution does not work as I expected (or hoped) and i'm looking for a simple solution for this. I think the options are:

1. set WAN DNS to use my local DNS/adguard server
2. add directive to DNSMasq via dnsmasq.conf.add that adds my DNS server to override WAN's DNS server

Is this more or less correct?

thanks!
 
.
Sorry to hijack this thread - happy to create a new one if preferred but I have the issue with local name resolution since I started using Adguard on my lan for DNS/ad-blocking

My setup is:

WAN - use my ISP for DNS
DHCP - use a dedicated device (raspberry pi) on my network running Adguard home + unbound
DNSfilter - global set to 'router' with Adguard device set to 'no filtering'

Why? Be consistent - if you want all your DNS request from LAN to go to PiHole, make the DNSFilter point to it as well.

When I ping local devices, name resolution does not work as I expected (or hoped) and i'm looking for a simple solution for this. I think the options are:

Yep. This is expected. PiHole doesn't know anything about your local devices and cannot resolve their names. You need to enable Conditional Forwarding. It is not extensively described in PiHole documentation, but have a look here: https://docs.pi-hole.net/routers/fr...pi-holes-web-interface-conditional-forwarding
  • Local network in CIDR notation should define your local network, typically 192.168.0.0/24
  • IP Address of your DHCP server - typically 192.168.0.1
  • Local domain - name of the domain specified in the LAN/DHCP Server page. I think the default is local.
That way, if PiHole receives a request to resolve FQN in local domain, exp. myDesktop.local, it will try to resolve it locally. It knows nothing about it, so it will go to your ASUS to ask for it, not the upstream server (AdGuard). This still enables you to define static IP address allocation through Asus UI and PiHole resolve them properly too.

What's more, the PiHole dashboard will be very nicely populated with hostnames - you'll easily know which host is querying etc.

1664220470203.png
 
Last edited:
Thank you @grogi

I have been testing pi-hole and adguard home. When i was using pi-hole i had it configured as you outlined above.

At the moment I am using adguard home instead of pi-hole and trying to get that working in the same way - i.e. conditional forwarding. Do you know how to achieve the same solution with adguard home?

My ideal setup (i think is).

1. use google/ISP as DNS in my wan settings
2. use dhcp on merlin router that uses my local dns resolver (adguard + unbound on same device)
3. use dnsfilter to let specific dhcp clients use wan DNS rather than adguard by using the 'no filtering' option

but with this setup I still need to allow local name resolution (conditional forwarding in adguard)
 
I have zero experience in Adguard Home resolver.

What will work reliably, without much configuration:
  • WAN DNS - point to local adguard+unbound resolver
  • LAN/DHCP DNS - router IP
  • DNS Filter - router IP / no filter for some hosts
Local name resolution will work, regular name resolution will work, blocking will work. You will loose tracking of which clients query the Adguard Home appliance though.


You can also look into https://github.com/AdguardTeam/Adguardhome/wiki/Configuration#upstreams-for-domains to configure Conditional Forwarding for local domains and https://github.com/AdguardTeam/Adguardhome/wiki/Configuration#upstreams-for-rdns for AdGuard Home to properly perform reverse DNS lookup for local IP Ranges.

Then you'd have the same setup as described above for PiHole, but with Adguard Home:
  • WAN DNS - local adguard resolver or ISP resolver.
  • LAN/DHCP DNS - local adguard
  • DNS Filter - filter to local adguard / no filter for some hosts
 
Last edited:
Thanks again @grogi.

I am getting very close to what I need using adguard home but taking a different approach so i thought i would post my setup as it seems to be working as I hoped.

WAN DNS = my ISP DNS
DHCP DNS = my local adguard / unbound device
DNSFilter = global set to 'router'
DNSFilter = local DNS device running Adguard + unbound set to 'no filtering'
DNSFilter = devices that I do not want to use adguard/unbound set to 'custom 1' using google DNS 8.8.8.8

in Adguard, i have the following setup in the DNS settings

Upstream DNSservers:
[//100.168.192.in-addr.arpa/lan/local/]192.168.100.1:53
127.0.0.1:5335

Private reverse DNS servers
192.168.100.1


What I think all of this does/enables is:
  • local host name resolution works correctly - I can now ping any device on my network using xxx, xxx.lan or xxx.local
  • DHCP clients use adguard/unbound for DNS but lan to lan use the router
  • Adguard device set to 'no filtering' in DNSFilter enables correct identification of clients in adguard logs/stats
  • Client devices set to a custom DNS in DNSFilter (e.g. 8.8.8.8) will avoid local Adguard/unbound server and go directly to custom defined DNS
 
Last edited:
You don't need the complete [//100.168.192.in-addr.arpa/lan/local/]192.168.100.1:53 entry. [/lan/local/]192.168.100.1 will be enough - your private reverse DNS are specified below. If I understand it correctly, any address in 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 will be reverse resolved by those servers automatically.
 
You don't need the complete [//100.168.192.in-addr.arpa/lan/local/]192.168.100.1:53 entry. [/lan/local/]192.168.100.1 will be enough - your private reverse DNS are specified below. If I understand it correctly, any address in 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 will be reverse resolved by those servers automatically.
Thanks for the tip to shorten the command/string. From testing on my system (adguard + unbound on a RPI) local host resolution did not work until i added //100.168.192.in-addr.arpa/lan/local/]192.168.100.1:53. I will try the shortened version and confirm.

My setup is all working correctly and so thanks for your help with this.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top