AP always adds LAN gateway to DNS via resolv.conf

RickNY

Occasional Visitor
Hi all.. I have a Zen WiFi AX Mini system running firmware 3.0.0.4.386_43129-g60defb2 -- this is the latest firmware I can use without breaking my Sonos speakers.. The system is set up in AP mode.. One thing that is bugging me is that the firmware keeps insisting on adding the LAN gateway to /etc /resolv.conf (and /tmp /resolv.conf) in addition to the configured DNS servers (either entered statically or received via DHCP) . My DNS runs on a separate device than my main router. The AP does at times attempt to resolve DNS through the gateway router instead of the assigned DNS server. My DHCP server is set to assign the IP of my DNS server. Is there any way to prevent this behavior? I have a firewall rule to redirect such requests to the DNS server if they come in to the router's LAN interface, but I shouldn't have to rely on that.

Thanks
 

Tech Junky

Very Senior Member
Disable DHCP on the router / AP and force clients to use the one assigned from your server instead. Resolv for the local device is handy for FW upgrades but, it shouldn't be used for anything else.

If you SSH into it you could potentially disable it completely. This would also minimize your potential for DNS Leaks due to the devices doing lookups.
 

RickNY

Occasional Visitor
I'll be more specific... The router runs OPNSense.. It manages the entire DHCP pool, and will continue that role. That sits at 10.20.1.1. The DHCP server has mostly static DHCP mappings, as well as a pool for true dynamic clients... The DHCP server is configured to issue 10.20.1.2 as the assigned DNS server -- 10.20.1.2 is a Pi-Hole, which is configured to forward DNS requests to Unbound running on the OPNSense box at 10.20.1.1. The Unbound instance running on that box is configured to only allow incoming requests from the Pi-Hole.

On the OPNSense box at 10.20.1.1, I have a firewall rule configured that says "If any client other than 10.20.1.2 tries to connect to destination port 53, redirect the request to 10.20.1.2" -- this is configured to log any redirects.. Throughout the day, I see requests coming from the Asus AP's (which are at 10.20.1.200, 10.20.1.205, and 10.20.1.207) trying to run DNS queries directly through 10.20.1.1. If I did not have the redirect rule in place, they would fail since 10.20.1.1 is set to only accept DNS requests from 10.20.1.2... When I log in to the web interface of the Asus AP's, the LAN configuration for DNS is set statically to just "10.20.1.2" -- so why would it be trying to run DNS through "10.20.1.1" you ask? Well, when I SSH into the Asus AP and do cat /tmp /resolv.conf - it reports TWO lines -- nameserver 10.20.1.2 and 10.20.1.1 -- no matter what I try, it insists on adding that on its own to its own resolv.conf -- and will use it when performing its own DNS lookups.
 

ColinTaylor

Part of the Furniture
What do you get if you run this on the AP:
Code:
nvram show | grep "10.20.1.2"
 

RickNY

Occasional Visitor
It shows only the configured DNS:
Code:
lan_dns1_x=10.20.1.2

However -- the reality is that the device is alternating between using that configured DNS server and the gateway IP.. I dont log the :

Code:
lan        2022-04-01T12:29:20-04:00    10.20.1.200:58596    10.20.1.2:53    udp    Intercept any outgoing DNS queries and redirect them to PiHole (LAN)   
lan        2022-04-01T12:29:20-04:00    10.20.1.200:58596    10.20.1.1:53    udp    rdr rule

These 3 ASUS APs are the only devices on the network doing that.. I do get a few here and there that try to reach external DNS Google DNS servers at 8.8.8.8, which I expect - and also redirect back to the PiHole -- but these 3 APs are the only one's trying to run DNS through the gateway router.

Also -- attached is a pic of the PiHole showing the redirected request from the gateway when it happens.. The first two queries were 2 of them behaving properly and contacting 10.20.1.2... The 3rd was one of them trying to get the answer directly from the 10.20.1.1 machine.
 

Attachments

  • asus_dns.jpg
    asus_dns.jpg
    27 KB · Views: 63

ColinTaylor

Part of the Furniture
OK, what does this show (I'm asking because I don't have this device so I can't check it myself):
Code:
nvram show | grep "^lan_dns"
 

Tech Junky

Very Senior Member
Resolv uses the loopback or gateway by default. If you disable it then the issue goes away. I override this on my Linux box that also uses pihole through this method and the DHCP options for when it pulls an ip from the ISP. Dig into the Linux commands for it. It can be a real pita to deal with when trying to be more specific in your lookups.
 

RickNY

Occasional Visitor
Code:
[email protected]_XD4-6420:/tmp/home/root# nvram show | grep "^lan_dns"
size: 65854 bytes (65218 left)
lan_dns1_x=10.20.1.2
lan_dns2_x=
lan_dnsenable_x=0

lan_dnsenable_x appears to indicate whether the setting for DNS is static or received via DHCP
 

ColinTaylor

Part of the Furniture
Hmmm, it doesn't look promising.

I don't have access to the Zen WiFi AX source code but I assume it's the same as that which Merlin's firmware is based on. In there we can see that if the value of lan_gateway is anything other than a null string it will add that to the list of servers in the resolv file.


I guess you could try setting that to a null value but I'd assume it would break lots of things (and possibly make the device inaccessible).
Code:
nvram get lan_gateway
nvram set lan_gateway=""
 
Last edited:

RickNY

Occasional Visitor
Hmmm, it doesn't look promising.

I don't have access to the Zen WiFi AX source code but I assume it's the same as that which Merlin's firmware is based on. In there we can see that if the value of lan_gateway is anything other than a null string it will add that to the list of servers in the resolv file.


I guess you could try setting that to a null value but I'd assume it would break lots of things (and possibly making the device inaccessible).
Code:
nvram get lan_gateway
nvram set lan_gateway=""
Yeah, thats certainly what it looks like its doing in this as well.. I thought maybe it only did it if only one of the DNS fields were populated -- but, nope -- it will just add a 3rd nameserver line with the gateway IP. What an odd thing to do -- granted, in many setups, the router and DNS are one and the same -- but certainly not all.

Since these arent doing routing, my guess is doing what you propose would break 1) NTP time sync 2) the internet connectivity checks to dns.msftncsi.com and 3) firmware checks. Since I do have a way to deal with this at the router itself (the redirect to the Pi-hole), I'm not sure if its worth the effort.
 

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