Bug 1755610

This is actually exactly the same bug #1700916 that is reported only on RHEL8. Not sure why it should SERVFAIL.

Fix for it already exists, but without any reply from upstream.

Ok, when reading the expectation again, there is a difference. Is this about DNS cache snooping only [1]?

Current unbound for example refuses dig +norec queries with REFUSED error. It should not definitely respond with SERVFAIL. That is used when the server tried, but was unable to fetch any response. In case it is not willing to respond to the request, it should respond with REFUSED.

Dnsmasq is not full recursive DNS server, like are unbound and bind. It is a more smart cache with some features on top. It is not able to synthetise answer for every request. It works around it by passing some queries to full recursive server, which it calls upstream. That are servers configured by --server directive or configured via d-bus. It does this on purpose with all queries that do not have recursion desired flag set. That was changed from original behaviour introduced by commit [2] to current behaviour by commit [3]. That moves response to upstream server. In case of unbound, it would return REFUSED.

But not everyone agrees it is useful [4]. Timing could be used as well, with high success rate. That is reason why bind does not provide configuration to refuse queries without recursion bits.

I admit I do not know, how are machines in Open Stack connected to central DNS recursor and what configuration is possible there. There is no point preventing checking names of local machines. And it depends on configuration of upstream servers for every subnet. Have to find correct terminology used on Open Stack.

My point from comment #2 matches only queries for names served by dnsmasq itself. It does not affect cache snooping, since it is authoritative for these names. So it is probably unrelated.

1. https://kb.isc.org/docs/aa-00482
2. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=087eb76140725f8f1892ba6f251ea052d3440966
3. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495
4. https://kb.isc.org/docs/aa-00509

If dnsmasq is used only for internal names as authoritative server for them, there is absolutely no reason to not respond to non-recursive queries. Non-recursive queries should get reply either with authoritative answer, ie. address or NXDOMAIN status, if given name does not exist. The only other option is delegation. By delegation answer, the server does not tell correct address, but would tell name of servers (and their IP addresses) that might know more. Several iterations of delegation query followed might be required and dnsmasq cannot do that. It relies on other servers to do that.

DNS cache snooping uses this feature. Either answer was already cached and positive or negative response arrives. Or it was not in cache and delegation arrives.

According to [1], dnsmasq passes all other queries to default name servers or SkyDNS. Default servers should be specified in /etc/dnsmasq.d/origin-upstream-dns.conf. Those servers should be responsible for correct handling of (non)recursive flag queries and their responses. Dnsmasq cannot do it and should not do it.
It should be addresses specified in /etc/resolv.conf on the host, according to [2]. I am not a expert on Open Shift configuration, please contact support to verify its configuration.

1. https://www.redhat.com/en/blog/red-hat-openshift-container-platform-dns-deep-dive-dns-changes-red-hat-openshift-container-platform-36
2. https://docs.openshift.com/container-platform/3.11/install/prerequisites.html#prereq-dns

I think dnsmasq would forward such queries to upstream resolver. But it does not accept REFUSED from forwarder as valid answer and respond with it, even if it is the only forwarder available.

Used default configuration of unbound, then started dnsmasq:

# dnsmasq -d --server=127.0.0.1 --no-resolv --log-queries --bind-interfaces -a 127.0.0.2 &
# dig @127.0.0.2 +norec redhat.com

It tried and result is refused, but does not ever pass REFUSED to the client.

So overall result is quite strange and not ok. It does not return any answer to dig, not even SERVFAIL. It always timeouts.

Tried with dnsmasq-2.76-10.el7_7.1.x86_64

It seems upstream commits 9396752[1] and [2] are required.

1. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9396752c115b3ab733fa476b30da73237e12e7ba
2. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=68f6312d4bae30b78daafcd6f51dc441b8685b1e

But it is not so easy, incorrect handling of REFUSED response is just one part of a problem. It would still show its own cached responses once it caches them. To refuse also such queries, it would need upstream commit [3], but that made a regression addressed recently in RHEL8 under bug #1700916, fixed later by my commit [4].

3. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495
4. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=29ae3083981ea82f535f77ea54bbd538f1224a9e

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: dnsmasq security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3878