OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Kevin Darbyshire-Bryant - 14.06.2017
Last edited by Hans Dedecker - 28.06.2017

FS#847 - resolv.conf no longer points at local dnsmasq instance

On recent builds /etc/resolv.conf now contains external nameservers and no longer points at or ::1. Thus the router is unaware of internally handled name/ip mappings handled courtesy dnsmasq.;a=commit;h=a53f8ba6771de64c9c82a2e6867791226f3003cb looks suspicious. I have no idea what problem it is trying to solve. I suspect the dnsmasq init script has achieved sentience and this is the beginnings of skynet.

I’m happy to provide configs, but not via this bug tracker.

Closed by  Hans Dedecker
28.06.2017 08:23
Reason for closing:  Fixed
Additional comments about closing:  

Patch introducing the issue ( https://git.lede-;a=commit;h=a53 f8ba6771de64c9c82a2e6867791226f3003cb) has been reverted

Paul Oranje commented on 14.06.2017 18:22

Seems kind of nightmare is developing around

The referred commit had been commented on earlier by @kdarbyshirebryant (KDB).
He questioned the wisdom/assumption that the resolver listening on 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, 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, 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 ?

Kevin Darbyshire-Bryant commented on 14.06.2017 23:00

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.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'.

Project Manager
Hans Dedecker commented on 15.06.2017 08:25

I've reverted commit;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
Next I would like to see a proper tested patch as too many iterations are required now to get it properly working

Paul Oranje commented on 15.06.2017 09:05

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.


Available keyboard shortcuts


Task Details

Task Editing