Past the upgrade from LEDE 17.01.0-rc2 to LEDE 17.01 stable on WRT1900ACS v2, I am having issues with dns forwarding
list address '/example.com/192.168.1.202'
But this is not functioning anymore.
I have rebooted the router and have also reloaded dnsmasq with
/etc/init.d/dnsmasq reload to no avail.
Is there a way to force a new DHCP lease to all WLAN clients through the router as I cannot renew the DHCP lease on mobile devices.
Try to also disable the rebind protection.
@jow please guide me as I never did such.
In the same dhcp configuration file, change
option rebind_protection '1' to
option rebind_protection '0'.
@jow I had done the
option rebind_protection '0' as you suggested, it worked great until yesterday as the forwarding started to play foul again.
Is there anything I can do to stablise the dnsmasq list address....
This is my config file
option domainneeded '1'
option boguspriv '1'
option localise_queries '1'
option rebind_protection '0'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option localservice '1'
list address '/domain1.com/192.168.1.254'
list address '/domain2.com/192.168.1.202'
option sequential_ip '1'
option nonwildcard '0'
Gosh, I updated to LEDE Reboot 17.01.1 r3316-7eb58cf109 to find out that dnsmasq is less stable that the previous stable built. Now I find my self rebooting the router every two hours to have domain forwarding working.... Really upset
Would you mind elaborate what you're expeting to happen as a response to which request?
You're asking about forwarding, but you didn't configure any forwarding rule. Instead, you configured a static host. When you do
nslookup example.com it will be resolved to 192.168.1.202 according to your initial posts setting. As long as the local dnsmasq can provide answer for a certain question, it most likely doesn't as an upstream server. So that's no forwarding.
You disabled rebind protection. This means an upstream DNS server (like 18.104.22.168, if you ask google) is allowed to respond with an IP of RFC1918 (192.168.0.0/16, 172.16.0.0/12 or 10.0.0.0/8). This is forwarding, or more precisely, it's a strategy to handle potentially bogus responses from a forwarded request. But it has nothing to do with
list address in the first place.
In your initial post you asked if you could force clients to renew DHCP leases. That's not possible since that's the whole point ot any TTL. If you're in testing mode, decrease your lease time to a couple of minutes until you're done and happy with your current state of configuration.
local '/lan/' which means requests to resolve
whatever.lan will never get passed to an upstream server.
If you want dnsmasq to perform lookups to an upstream server, you can do things like this:
list server '22.214.171.124' will forward any request to googles DNS server.
list server '/example.com/126.96.36.199' will only forward DNS requests resolving example.com to googles DNS server (which imho means both, example.com as well as foo.example.com).
I use dnscrypt which leverages dns forwarding. To get it to work, I had to put the forwarded address in 2 times, and then it started working.