Dnsmasq does not reply to non-recursive queries with local data 19.07

Installing and Using OpenWrt
1

After upgrading a router to 19.07.3 (from lede) I'm having trouble with dnsmasq not resolving local entries when queried by BIND without the recurse option set.

I have two sites VPN'd together using OpenWRT and OpenVPN. When running the older dnsmasq, under the lede build, queries of the remote site's dnsmasq for local names assigned by dnsmasq was working fine.

After upgrading, from the main site, dig will resolve remote names to A records but querying the local bind which has the remote domain delegated doesn't work. If I use dig with +norecurse so that they query is the same as BIND would generate it fails.

I've found a Red Hat Bugzilla 1700916 which seems to match the what I'm seeing.

Previously, dnsmasq forwarded all the non-recursive queries to an upstream server, which led to different responses. With this update, the non-recursive queries to local known names, such as DHCP host lease names or hosts read from the /etc/hosts file, are handled by dnsmasq and are not forwarded to an upstream server. As a result, the same response as to recursive queries to known names is returned.

This issue is not present in 2.76 version in RHEL7, so it makes regression after upgrade. It can break especially setups from other recursive resolvers querying dnsmasq, because they do that always without recursion. Current dnsmasq forwards all non-recursive queries to upstream server, even when it serves correct answer with rd bit set.

It doesn't seem to matter whether the names local to dnsmasq are in /etc/hosts for a static DHCP assignment, or are fully dynaming assignments using the name from the DHCP request.

dnsmasq being queried by BIND:

12:38:21.107469 IP s1.52538 > whb.53: 53241 [1au] A? host1.remote.foo.org. (53)
12:38:21.108680 IP whd.53 > s1.52538: 53241 0/0/1 (53)

dnsmasq queried by dig (default options):

12:38:41.027996 IP s1.54632 > whb.53: 50290+ [1au] A? host1.remote.foo.org. (53)
12:38:41.028784 IP whd.53 > s5.54632: 50290* 1/0/1 A 192.168.1.120 (69)

From the dnsmasq change log it doesn't look like Red Hat's patch hasn't made it into dnsmasq yet.

Am I understanding this correctly?

I can't find any dnsmasq options that would change this behavior.

Any suggestions appreciated.

Thanks.

EDIT/Correction - It looks like an update from Red Hat did make it into dnsmasq's source tree Restore ability to answer non-recursive requests around 2020-02-11.

Looking at the dates on the git tags, this may have made it into 2.81 or 2.82. However, it didn't get mentioned in dnsmasq's change log.

If I'm reading things correctly, it looks like the current snapshot is using dnsmasq 2.82 is that correct?

1 Like
2

Yep, I confirm:

# dig @localhost -q localhost +short +norecurse
# dig @localhost -q localhost +short
127.0.0.1
# opkg list-installed dnsmasq\*
dnsmasq-full - 2.80-16.1
3 
root@mamba:/etc# cat openwrt_version 
r14149-6e7f40dff3
root@mamba:/etc# opkg list-installed | grep dnsmasq
dnsmasq-full - 2.82-4
4

Thanks @vgaetera - that's a great short test.

Any suggestions for working around this?

The answers I come up with so far are:

  • try the current snapshot of openwrt
  • try to build a custom 19.07.3 with updated dnsmasq
  • find a way to periodically do some sort of zone dump from dnsmasq
1 Like
5

@anomeome - could you please try the test @vgaetera showed above against the 2.82 you've got installed?

# dig @localhost -q localhost +short +norecurse
# dig @localhost -q localhost +short
127.0.0.1
6 
root@mamba:/etc# dig @localhost -q localhost +short
127.0.0.1
root@mamba:/etc# dig @localhost -q localhost +short +norecurse
127.0.0.1
7

Another host:

# dig @localhost -q localhost +short +norecurse
127.0.0.1
# dig @localhost -q localhost +short
127.0.0.1
# opkg list-installed dnsmasq\*
dnsmasq - 2.81-3
8

Running unbound: if I get an answer for both queries, it means it works as expected, right?

9

Running unbound: if I get an answer for both queries, it means it works as expected, right?

That's correct. Note:for me this happens with BIND in another domain querying dnsmasq.

The change that caused the problem was a security patch aimed at thwarting cache snooping.

1 Like
10

This should be the easiest way:
https://openwrt.org/docs/guide-developer/single.package

11

Thanks. I'll give that a try or maybe try running snapshot.

Is there any place I should report this as a known issue against 19.07.x?

1 Like
12

https://openwrt.org/bugs