por:

Seems kind of nightmare is developing around 127.0.0.1#53.

The referred commit had been commented on earlier by @kdarbyshirebryant (KDB).
He questioned the wisdom/assumption that the resolver listening on 127.0.0.1#53 is to be regarded the main instance, being the instance that manages the resolver file (resolv.conf). KDB wrote that the local resolver not necessarily listens on #53 because requests to #53 (by the local C lib resolver routines) may be re-written by DNAT rules.
Not surprisingly this scenario had not been considered when writing the patch (resolv.conf does not offer a way to specify the port to query on the nameserver).

The patch was committed by @dedeckeh before I got to re-think the idea - happy me, but so it did create a problem for KDB, probably breaks existing set-ups, definitely not intended.

The change came forth from FS#785.
That issue had to do with the resolver file not being handled when noresolv was true (which happened when unbound is run as the (main) nameserver with dnsmasq to service dhcp and local dns requests).
Whether dnsmasq uses upstream nameservers listed in the resolver file (noresolv) is unrelated to dnsmasq being the nameserver to be named in the resolver file.

Since multiple instances of dnsmasq can be run, some criterium is needed to distinguish the instance of dnsmasq that should be listed as nameserver in the resolver file. The patch did so by designating as that nameserver the resolver that listens on 127.0.0.1#53, of which there can be only one.

When the issue here at hand is caused by that criterium not working because dnsmasq does not listen on 127.0.0.1#53, but is made accessible via some DNAT rule and if that must be supported, then some other criterium will be needed to figure out which instance is to listed in the resolver file (and to manage that file). A new dnsmasq UCI option that explicitly indicates that instance (if any) would than probable be needed.

Any suggestions ?

None:

Am confused 'cos I didn't mention anything about DNAT port rewriting.

My setup is straightforward in that there's a single dnsmasq instance handling dns,dhcpv4&v6 across a few interfaces/subnets. It listens on port 53 on all subnets.

With the commit in place, /etc/resolv.conf is sym linked to /tmp/resolv.conf which is symlinked (in error) to /tmp/resolv.conf.auto

resolv.conf.auth points at the upstream recursive resolvers (google in this case, both ipv4 & v6)

Based on your rules/explanation (there's only 1 instance of dnsmasq), I don't understand why /tmp/resolv.conf doesn't point at 'loopback'.

dedeckeh:

I've reverted commit [[https://git.lede-project.org/?p=source.git;a=commit;h=a53f8ba6771de64c9c82a2e6867791226f3003cb]] for now as too many issues are raised. First I would like to understand which issue KevinDB hits; maybe the problem is related to [[http://lists.infradead.org/pipermail/lede-dev/2017-June/007981.html]].
Next I would like to see a proper tested patch as too many iterations are required now to get it properly working

por:

First, I understand that the commit has been reverted - way to many problems.

Second, I found the cause of the problem Kevin encountered, it is in dnsmasq_ismain().
The line
[ -n $notinterfaces ] && list_contains notinterfaces "loopback" || return 1
should be
[ -n $notinterfaces ] && list_contains notinterfaces "loopback" && return 1

(it looks like something went wrong in my work-flow, between test and commit, I'm truly sorry).

Last, about who made the remark on possible DNAT rewrites of the port listened on, I was mistaken, it was Hans, not Kevin, who made that remark.