In a similar vein of the question at How to keep resolv.conf after reboot, I want to customise resolv.conf's nameserver entry to point to my local DNS elsewhere on my network so that DNS requests being made on the Omnia go through my own DNS. So in short, /etc/resolv.conf looks like so:
search home
nameserver 127.0.0.1
which directs DNS requests to the Omnia’s local DNS server. The search line can be controlled via the Local domain setting for dnsmasq in LuCI but what I need is for the nameserver line to be changed to nameserver 10.1.1.x where the IP is my local DNS server. None of the settings in LuCI seem to affect this latter line.
If I stop dnsmasq, the /etc/resolv.conf file is changed to reflect the custom DNS servers set on my wan and wan6 interfaces (which I’ve also set to my local DNS server), so this solves that issue, but breaks my network because dnsmasq is providing DHCP.
The workaround I’ve been using is to edit /etc/resolv.conf by hand whilst dnsmasq is running, but this doesn’t persist past restarts of dnsmasq which cause the file to be rewritten. I’ve already got the Omnia advertising my custom DNS to DHCP clients fine (eg set via LuCI —> LAN —> DHCP-Options) but now it’s a case of requests on the Omnia itself.
Thoughts? Is there some sort of additional dnsmasq setting that will make it operate as needed? Thanks.
For anyone else playing along at home, this is a list so you can add multiple DNS servers by re-running the command. To save and apply the setting, run:
uci commit dhcp
/etc/init.d/dnsmasq restart
Running uci commit without the qualifying section does also save the setting but gives an odd, seemingly unrelated “error” message, don’t know what it refers to:
uci: Parse error (invalid command) at line 1, byte 0
uci: Entry not found
I’m finding that my Omnia’s /etc/hosts file is seemingly being ignored and various requests for localhost are now being sent to my separate DNS server, seemingly since today’s upgrade to 3.11.1. This is around 1000 requests per hour for localhost (A and AAAA records).
@paja, is this expected behaviour with the use of local_dns_server or perhaps a bug with 3.11.1? Up until the update and/or restart, my DNS server wasn’t being hit by the router, so presumably /etc/hosts was fine.
I haven’t dug into exactly what is making the queries on the router, but inserting an dummy entry in /etc/hosts and then using ping interactively sees the dummy IP get pinged so /etc/hosts is still being used there.
I thought local_dns_server means that DHCP instructs all clients to ask that address directly for all DNS, i.e. they will bypass Omnia in your case. Still, localhost is a special name that should never be asked across network, but that would be a mistake of the clients themselves.
There’s a separate option for the behaviour you’re describing (eg what DNS server gets sent to DHCP clients) and that’s dhcp.lan.dhcp_option='6,10.x.x.x'. In this case, the local_dns_server option is modifying (just?) the router’s own /tmp/resolv.conf. The behaviour in this case is that some part of the Turris Omnia is asking my DNS server to resolve localhost.
Interactively-invoked tools like ping are using and adhering to /etc/hosts so it’s something else. Starting to dig into it, looks as though it’s caused by HTTP requests to the router web interface; stopping lighttpd or closing all LuCI tabs stop the repeated DNS resolutions.
Edit: the DNS requests for localhost are being caused by any HTTP requests to LuCI. For instance, a request to https://router.example.com/cgi-bin/luci will trigger an A and AAAA lookup. The reason for my 1000s of requests is that the DHCP/DNS page in LuCI makes XHR requests every second to update the page’s content. Still unsure why LuCI is doing this at all; the hunt continues.
Edit2: Found it, finally! LuCI’s dispatcher imports all controllers for every request that gets made to LuCI. Turns out that the DDNS controller /usr/lib/lua/luci/tools/ddns.lua gets imported for every request which means its has_nslookup check gets called each time. This makes a DNS request for localhost, which by design, does not use /etc/hosts.
I opened a PR to LuCI upstream at https://github.com/openwrt/luci/pull/2384 (the file of which has been significantly rewritten compared to LuCI on Turris OS). This is now merged into LuCI. Is there something else I need to do to get this patch into Turris’ code base?
Edit: the DNS requests for localhost are being caused by any HTTP requests to LuCI. For instance, a request to https://router.example.com/cgi-bin/luci will trigger an A and AAAA lookup.
That’s a really good finding! For Turris OS 3.11.2, currently in RC branch, we have made some changes to Knot resolver and LuCI is responding a really fast. However, it could be implemented faster as I wasn’t aware of your post till your last edit, it got lost here.
As you said we haven’t have included the rewritten luci-app-dns, so I or colleagues will look at it. Unfortunately, it will not make into Turris OS 3.11.2.
Afaict this change in particular means that all the calls to these tools will be avoided which currently happens for every HTTP call to LuCI (including XHRs). So, it’s not just saving the DNS request I found but a whole tonne of load time too.