Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#611 - dnsmasq Ignore resolv file option forget at restart #5623

Open
openwrt-bot opened this issue Mar 9, 2017 · 9 comments
Open

FS#611 - dnsmasq Ignore resolv file option forget at restart #5623

openwrt-bot opened this issue Mar 9, 2017 · 9 comments
Labels

Comments

@openwrt-bot
Copy link

howl:

If you set up dnsmasq to ignore resolv file it will ignore it until reboot is performed. To make ignore it again the option must be uncheck and apply and then check and apply again.

I have /etc/resolv.conf as a symlink to /tmp/resolv.conf, when the router boots up the contents are the dns offered from dhcp over the wan interface. When the ignore resolv option is checked or unchecked the contens are overwrited to search lan and nameserver 127.0.0.1 but it doesn't seems to affect as if you uncheck ignore resolv the router resolv names, and when you check again the option it can resolv names even the contents still are search lan and nameserver 127.0.0.1.

I haven't seen yet any other change that can cause the reboot to make dnsmasq follow resolv file when the option is checked until you uncheck-apply and check-apply.

@openwrt-bot
Copy link
Author

howl:

I have been testing a little and I have found that dnsmasq always reads /etc/resolv.conf despite ignore resolv file is set or not. Also that if ignore resolv file is not set /tmp/resolv.conf.auto is read and if it's set it's not read. I suppouse /tmp/resolv.conf.auto is the default file for dnsmasq to look even if resolvfile value is empty.

So the problem is that dnsmasq always reads /etc/resolv.conf despite it's configuration.

I find this annoying.

I my use case I can remove the symlink /etc/resolv.conf -> /tmp/resolv.conf and create a new /etc/resolv.conf with search lan and nameserver 127.0.0.1.

@openwrt-bot
Copy link
Author

howl:

I have seen were seems to be the problem.

If we set option noresolv '1' it's suppoused that dnsmasq is not going to use resolv.conf file. It also logs this "daemon.warn dnsmasq[1500]: warning: ignoring resolv-file flag because no-resolv is set". So option resolvfile it's supoused to have no effect in that situation.

The problem is if you for example follows this manual https://wiki.openwrt.org/inbox/dnscrypt it comment out resolvfile. With noresolv 1 and resolvfile unset, dnsmasq touches /etc/resolv.conf instead of /tmp/resolv.conf.auto and makes both with the same contents, the auto dns from wan interface.

If you leave resolvfile with /tmp/resolv.conf.auto dnsmasq doesn't touch /etc/resolv.conf and it's contents stay as search lan and nameserver 127.0.0.1, but resolvfile option it's expected to be ignored with noresolv 1. Even more using LuCI, and checking noresolv makes the textbox for resolvfile disappear and setting it to blank, making only possible to avoid the issue editing manually /etc/config/dhcp.

@openwrt-bot
Copy link
Author

howl:

One last appointment, when resolvfile is empty it doesn't touch /etc/resolv.conf, but /tmp/resolv.conf instead. So the workaround that removes /etc/resolv.conf symlink and set it up as a text file with search lan nameserver 127.0.0.1, is valid and makes it possible to use the dnsmaq luci util because despite it blanks resolvfile option doesn't matter, as it edits /tmp/resolv.conf, leaves /etc/resolv.conf untouched, and uses /etc/resolv.conf file despite it should use no resolv.conf file.

@openwrt-bot
Copy link
Author

howl:

I think the could be a bugfix for this one https://git.lede-project.org/?p=source.git;a=commit;h=8e0775197a3a3cdcf9653d62c5195120b830efa1

I can't test it now but will try to do when I can and comment here.

@openwrt-bot
Copy link
Author

Tony-il-Capo:

I was having the exact same problem after following that OpenWRT wiki for DNSCrypt.
Shouldn't this have been fixed with that commit? My init.d file does not reflect those changes. I've updated dnsmasq recently in my extroot setup.

@openwrt-bot
Copy link
Author

cewatkins:

What I see, is that even when it's 127.0.0.1, lookups don't work from the router itself as a client. Unless, another server is put in resolv.conf.
Now, the interesting part is that nslookup to localhost works.
Having this just annoying to me, (and I have to do special builds anyway..)
I'm fairly convinced, that it's the default build options, but in my case I have >200k left &
that's after removing all the crud that isn't needed.
I can't remember not exactly what, I think It was tagging, but that's not compiled in either
and that requires a recomp or getting
dnsmasq-full, I would try that if you can overwrite it with just a package easily, that was
worked in the past on other platforms for me.
As to luci, well, Uh, only for a week or two every release do I bother.

@openwrt-bot
Copy link
Author

por:

When UCI option dnsmasq.noresolv is 1 (default 0), dnsmasq will not use the nameservers from a resolvfile which defaults to /tmp/resolv.conf.auto (option dnsmasq.resolvfile) with the WAN DNS configuration, if any). When dnsmasq starts, it normally declares itself as the local nameserver by re-writing /tmp/resolv.conf; /etc/resolv.conf used by the local clib resolver is a soft link to the latter (when unbound is deployed as local nameserver, it will also re-write /tmp/resolv.auto to declare itself as local nameserver).

So when noresolv is true, dnsmasq will need the have some up-stream nameserver declared in order to be able to resolve domain names; if none no name resolution (other than /etc/hosts) will happen. The up-stream nameservers are declared with the dnsmasq.server list options.

Concerning the OP of this issue, the above logic is applied every time dnsmasq is reloaded/started. If you still feel there is a bug, please attach your dnsmasq config file (/etc/config/dhcp) to this issue.

@openwrt-bot
Copy link
Author

por:

To complicate matters, dnsmasq will only declare itself the local nameserver when the resolvfile option is set to /tmp/resolv.conf.auto.

Put otherwise: pointing resolvfile to something else than '/tmp/resolv.conf.auto' should not be used to declare upstream nameservers, for that purpose use the dnsmasq list server option. Really, I do not know of any use-case that would be served by changing the dnamasq option resolvfile.

@openwrt-bot
Copy link
Author

howl:

I'm still using the method that removes the resolv.conf symlink and recreate the file with search lan and nameserver 127.0.0.1, but is not necessary nowadays for devices connected to the router. The only difference is to make the router itself for opkg update and other tasks to use the servers defined in dnsmasq instead of the resolv file.

In my use case I have to install dnscrypt-proxy2 and this "bug", make possible to first install it, and the do the resolv trick. If the router could try to access the dnsmasq defined server to update package list or similar would fail.

I don't know what could be the best approach for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant