Dnsmasq caches negative results if it starts before the network is up

[Jérôme Poulin]

Since NetworkManager uses dnsmasq to resolve its DNS names, it sometimes enables the system to use dnsmasq before the network connection has been successfully established. This causes dnsmasq to try and fail to resolve some hostnames, it then caches them to its negative DNS cache.

To prevent this from happening I had to add no-negcache to /etc/dnsmasq.d/network-manager

Should this be the default? I don't think any endpoint user benefits from negative DNS cache, not even network admins as the DNS system is robust enough to handle those.

[Stéphane Graber (stgraber)]

NetworkManager starts dnsmasq with caching completely disabled so that seems unlikely to be a problem with the NM spawned dnsmasq.

However the fact that adding the setting to /etc/dnsmasq.d/network-manager fixed it for you, shows that you're not using NetworkManager's dnsmasq but a system dnsmasq instead.

Can you confirm that you have the "dnsmasq" package installed and not only "dnsmasq-base"?

If so, then that bug is invalid as when you install "dnsmasq" on your system, that'll bypass NetworkManager's own instance and so will run with the default dnsmasq settings (including caching).

[Thomas Hood (jdthood)]

Stéphane wrote:
> Can you confirm that you have the "dnsmasq" package installed and not only
> "dnsmasq-base"?
>
> If so, then that bug is invalid as when you install "dnsmasq" on your system,
> that'll bypass NetworkManager's own instance and so will run with the
> default dnsmasq settings (including caching).

I don't fully understand what you say here.

1. If the dnsmasq package is installed alongside network-manager then
the dnsmasq server instance will not "bypass" NM's instance but will
forward queries to it.

2. But that's not the main issue. This report seems to be that dnsmasq
caches failed lookups as if they were NXDOMAINs. If that's true then it
could be regarded as a bug in dnsmasq.

You are right that this in no way implies a bug in NM.

[Stéphane Graber (stgraber)]

Well for 2), it clearly looks like a case of negative caching (dnsmasq has no upstream server, therefore it only uses /etc/hosts only, if the entry isn't in there, it considers it a NXDOMAIN), upstream also seems to be aware of that behaviour as they offer the option to turn off negative caching.

Anyway, I personally don't really care, I just want to confirm that this isn't related to what we have in a default Ubuntu install.

[Thomas Hood (jdthood)]

What do you think, Simon?

[Simon Kelley (simon-thekelleys)]

On 08/07/13 15:02, Thomas Hood wrote:
> What do you think, Simon?
>
> ** Changed in: dnsmasq (Ubuntu)
> Status: Incomplete => New
>

I'm confused: dnsmasq won't cache a negative answer if it has no
upstream servers. To cache a negative answer it has to _receive_ a
negative answer (and the negative answer has to have certain
information, notably an SOA record to determine the TTL for the negative
answer.

Whatever is going on, it's more complex. Maybe the problem is that
dnsmasq gets a negative answer from some upstream server, and then gets
a new upstream server which has the correct information? The solution
then is --clear-on-reload but I think NM sets that?

Cheers,

Simon.

[Simon Kelley (simon-thekelleys)]

 > Whatever is going on, it's more complex. Maybe the problem is that
 > dnsmasq gets a negative answer from some upstream server, and then
 > gets a new upstream server which has the correct information? The
 > solution then is --clear-on-reload but I think NM sets that?

.... but --clear-on-reload doesn't appear to do anything when the
upstream nameservers are set via DBus, maybe that's the underlying problem.

Simon.

[Thomas Hood (jdthood)]

Hi Simon,

I think we've established that the submitter is having a problem with dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would be interesting to know if clear-on-reload fixes the submitter's problem. (He already said that no-negcache fixes it.)

That clear-on-reload is ignored in the D-Bus case sounds like a distinct issue.

What about Stéphane's suggestion that dnsmasq treats failure to find a name in /etc/hosts as a NXDOMAIN?

[Simon Kelley (simon-thekelleys)]

On 24/07/13 20:33, Thomas Hood wrote:
> Hi Simon,
>
> I think we've established that the submitter is having a problem with
> dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would
> be interesting to know if clear-on-reload fixes the submitter's problem.
> (He already said that no-negcache fixes it.)
>
> That clear-on-reload is ignored in the D-Bus case sounds like a distinct
> issue.
>

Agreed, I'll fix that now.

> What about Stéphane's suggestion that dnsmasq treats failure to find a
> name in /etc/hosts as a NXDOMAIN?
>

No name in /etc/hosts and no upstream servers -> NXDOMAIN reply, but no
state changes: the same query repeated after installing an upstream
server would result in a query to the upstream server.

Simon.

[Thomas Hood (jdthood)]

 Jérôme, can you please see if clear-on-reload fixes the problem, without no-negcache?

[Jérôme Poulin (jeromepoulin)]

It seems to be working correctly now, thank you!

[Thomas Hood (jdthood)]

Jérôme, it's nice to hear that it is working correctly, but which of the following is the case?

1. Dnsmasq is working correctly in the standard factory configuration.
2. It is working with no-negcache mode activated.
3. It is working with clear-on-reload mode activated.
4. It is working and the circumstances under which the problem occurs haven't presented themselves again.

[Launchpad Janitor (janitor)]

[Expired for dnsmasq (Ubuntu) because there has been no activity for 60 days.]