My current config is as follows:
ISP <---> WAN port --- (OpenWRT) --- LAN port <---> LAN network
Currently OpenWRT receives IP+DNS resolvers from the ISP, acting as DHCP client.
The DHCP server on OpeWRT is serving the LAN segment, and for DNS resolver, it sends its local ip (192.168.1.1).
How can I make OpenWrt to send the upstream DNS resolvers (the ones received from the ISP DHCP lease) as resolvers to the LAN clients, instead of sending 192.168.1.1 as resolver ?
Same answer as in, check the no 6 option.
Hello,
Thank you for the answer, but as far as I can understand, in order to use option 6, I have to know the DNS resolvers in advance, which is not my case.
I want the resolvers which I get from the lease coming from the ISP to be automatically send for the new leases in the LAN.
These resolvers are being changed from time to time, I can not just statically set them in option 6.
check the resolvfile option is set to, and if the file exists.
But if you want to avoid the headache, just put an external DNS there, like 1.1.1.1/1.0.0.1 or 8.8.8.8/8.4.4.8.
Unless your ISP's blocking external DNS calls.
The option resolvfile points at /tmp/resolv.conf.auto, the file is there and is populated with my ISP's resolvers, but as far as I understand dnsmasq uses this file to determine which resolvers to use for resolving, but is not sending them as option 6 in DHCP responses to the lan.
That's not answering the question.
Some users have good reasons to use local resolvers instead of Cloudflare or Google. Security concerns, access to local DNS zones, latency, as well as the one you touch: network access lists.
Configuring simple forwarding of assigned DNS servers from WAN to LAN clients should be much easier than it is today.
And it should also be the default, IMHO. Running a local DNS cache makes absolutely no sense. You might as well run a local SMTP relay. It's an open invitation of serious security issues, and provides exactly no benefit to the average user having anything better than a 9600 baud satellite WAN link
... hence the "if".
You can fetch and configure the ISP resolvers dynamically with hotplug, or better with DHCP scripts.
But this might be a bad idea since it's problematic to force DHCP update on the clients.
I don't think the ISPs are changing the nameservers very often. So it is safe to read the resolvfile and use the advertised servers in option 6.
Thank you for the suggestion. I will try it and it will probably work.
I expected that it is just a config option which I am unable to find, because I was using very old dd-wrt until now, and this type of config was a matter of clicking in the GUI.
To me, it makes perfect sense that the device dishing out IP addresses advertises itself as a default resolver, how else would you resolve local device names? There are other benefits of course, like using DoH/DoT on the router, ad-blocking, policy routing, etc.
Actually, the current defaults prioritize stable connectivity.
The ISP can issue a new DHCP lease with a different subnet, so the old resolvers become unreachable/invalid, and there are threads on the forum where this happens.
Moreover, both DHCPv4 and DHCPv6 are implicated.
Dynamic MWAN or VPN scenarios can also lead to a similar issue.
To force DHCP update on the LAN clients would require to reconnect them.
That doesn't look like a desirable method in general case.
Meanwhile, there's no problem to set up DNS forwarding or an upstream DNS provider.
On the other hand, although providing custom resolvers with DHCP is possible, the method is most suitable for public resolvers which connectivity is typically seamless for any ISP.
Personally I see both those as misfeatures. Resolving fake local names means that the resolver serves untrusted content. You might accept that, but it's a bad default for users which are unaware of this.
DoH/DoT should be used between client and resolver. Adding an extra resolver hop with an additional DoH/DoT to some upstream resolver does not improve security. It just adds latency and bugs.
Yes, using a local DNS resolver or proxy makes sense if the uplink varies, or you need to constantly switch upstream DNS resolvers for some other reason. I believe this is a special use case which does not apply to most users. It does not justify forcing additional latency and security issues on every OpenWrt user.
You really, really, really want working local DNS so you can easily access devices on your LAN. This is especially important in an ipv6 world because you're really not going to remember the ipv6 addresses of every device on your LAN. mDNS may be able to do this instead but then you're spamming your network with unnecessary multicast packets just to find out the address of your printer or network switch when your router already knows this.
I agree with you though that it's not ideal that in order to do this a resolver has to serve untrusted content. Ideally the resolver would sign the .lan zone and validating resolvers on your LAN could verify this but I have no idea how to go about doing this, you'd probably have to configure unbound because I doubt dnsmasq is capable of this.
Please provide references on how resolving local names is bad for users.
Here's why relying on ISPs resolvers (which you are promoting) is actually bad for unsuspecting users: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs
Unless you're willing to provide some facts as opposed to your opinions, I'm not going to participate in this conversation anymore. Better yet, if you're so certain that the current default behaviour is so dangerous, submit a PR to OpenWrt code and see if you can convince devs how bad the current behavoir is.
There are many devices which don't support DNS encryption.
It might also be limited to web browsers and too difficult to configure on a system-wide level.
It can help when we trust the local network and don't trust the upstream.
DNS on some devices doesn't support high availability and load balancing.
So, without Dnsmasq, even a small problem can lead to huge latency.
Reading the forum gives the impression that use cases for Dnsmasq are pretty common.
The assumption, that the default setup is more secure and protects you from bad ISP which is doing DNS hijacking is wrong.
The default dnsmasq config (just tested it with reset to factory defaults) is using directive:
resolv-file=/tmp/resolv.conf.auto
This file contains the DNS resolvers of my upstream ISP. Dnsmasq, just forwards the queries to them.
Apart from the local name resolving (if anyone uses it) I see no other benefits.
I don't know what led you to this assumption, but if you concur that protection from bad ISP is needed, how can you advocate pushing of bad ISPs to unsuspecting users is good?
This is turning into a pointless discussion. If you want something changed, create a PR with the change and back it up by some data why the current behaviour is bad.
This turned in pointless discussion in the moment when someone started explaining how I do not want to do what I asked, and why the current situation is perfect.
The topic was pretty much hijacked and In the moment in which I tried to comment a hijacker comment I became the one to blame. Rollback a little and you will clearly see, that it is not me, who made this a "pointless discussion".
The idea that someone is protected from DNS hijacking with the default setup was yours, I just commented on it, that this is wrong assumption, because the default setup is using your ISP's resolvers, so this is not a valid point for insisting on using the default config.