Since the trunk builds of openwrt don't do HTTPS out of the box, I always have to run "opkg update" against the HTTP version of the openwrt package repo initially after installing a new trunk build, to download the requisite pieces for HTTPS.
Lately, "opkg update" fails frequently over HTTP on my openwrt router, even though wget the same HTTP links on a regular LAN host works fine. I have tracked this down to /etc/resolv.conf having "nameserver 127.0.0.1". It appears that dnsmasq is no longer answering DNS queries by default in the latest trunk builds, even though I've continued to use my trunk upgrade routines. I have not tracked down what and how to overcome that.
In the meantime, as a workaround, I try to temporarily replace "nameserver 127.0.0.1" in /etc/resolv.conf with "nameserver some.public.name.server". As the thread title makes clear, I find something is repeatedly resetting "nameserver some.public.name.server" back to "nameserver 127.0.0.1". So I have to open a second SSH session and repeatedly manually replace "nameserver 127.0.0.1" with "nameserver some.public.name.server" in /etc/resolv.conf, until "opkg update" finishes against the HTTP links.
So the most simplistic question is: What mechanism is regularly resetting /etc/resolv.conf, and how to make it stop, at least temporarily, for my purpose above?
Then, why is dnsmasq no longer acting as the name resolver on localhost by default? Is this a known behavior change?
I am not sure about your DNS resolution problems with dnsmasq, its the first report of this kind I heard of so at least it is not a widespread common issue with snapshots.
Maybe take a look at logread to see if there's obvious problems.
In the default configuration, /etc/resolv.conf (/tmp/resolv.conf) always points to 127.0.0.1. The locally running dnsmasq initially handles all resolutions. That process reads /tmp/resolv.conf.auto to find the next upstream nameserver. resolv.conf.auto is written by the DHCP client on the wan or by "option nameserver" settings in the network.
Thanks you both for the clarifications. Now I have a better idea of how to troubleshoot, and hopefully identify the root cause.
It sounds like the fact /etc/resolv.conf (/tmp/resolv.conf) was getting overwritten, repeatedly, means dnsmasq was reinitializing itself repeatedly (which logread should reveal). Am I understanding this correctly?
Realize that /tmp is a RAM disk so everything in it is rewritten by various scripts during every reboot. You can probably make /etc/resolv.conf permanent by making it a real file instead of a link, and removing all write permissions from it. But this is not really how OpenWrt is intended to work.
When a user process like ping tries to access an IP service by name instead of IP address, the kernel consults resolv.conf. Since it is 127.0.0.1, and dnsmasq holds port 53 on 127.0.0.1, the request goes to dnsmasq. If dnsmasq does not have the IP cached it proxies to the server in resolv.conf.auto.
These files are only read by dnsmasq. It is netifd that changes them.
What would be the consequence of removing the symlink for openwrt itself? I mean I presume that doing so dnsmasq would be bypassed (if nameserver 127.0.0.1 is removed) an then I should also configure dhcp option 6 so that clients receive a real DNS server instead of 127.0.0.1 but other than that what more should I know before doing that.