Change default dnsmasq flags to not include --strict-order and disable caching

Bug #903854 reported by Stéphane Graber
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Mathieu Trudel-Lapierre

Bug Description

When using dnsmasq as a backend, Network Manager currently passes --strict-order.

This is a good way to get a similar behaviour to that of the libc's resolver where the DNS servers are being queried sequentially with a 2-3s timeout per server. However in the case where the first DNS server is down, this will delay all the DNS queries on the system.

Instead, I recommend this parameter be dropped which will fallback to the default dnsmasq mode to send the initial request to all servers and then continue with the first one that replies. This will increase the load on the upstream DNS servers quite a bit (though not as much as using --all-servers) but will ensure a proper fallback when some servers are down or very slow.

I think this added load is reasonable and shouldn't affect most DNS servers too much. For cases where it's a concern (heavily loaded corporate network for example), I'd suggest the user simply turns off the dnsmasq plugin in /etc/NetworkManager/NetworkManager.conf thereby reverting to the libc's behaviour of trying servers sequentially with a 3s timeout.

As discussed in for security reason (possible local cache poisoning), we also want to turn off caching for the LTS and reconsider caching (ideally with per-user caches) for 12.10.

Tags: patch
Changed in network-manager (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Stéphane Graber (stgraber) wrote :
summary: - Change default dnsmasq flags to not includ --strict-order
+ Change default dnsmasq flags to not include --strict-order and disable
+ caching
description: updated
tags: added: patch
Changed in network-manager (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager -

network-manager ( precise; urgency=low

  * debian/control: libnm-glib-vpn1 Breaks/Replaces libnm-glib2, to ease with
    upgrades from Lucid. (LP: #900509)
  * debian/rules: re-update the daily builds special case, we don't want to
    fail daily builds for new added symbols.
  * debian/patches/nm-change-dnsmasq-parameters.patch: change dnsmasq's params
    when it's started by NM to disable caching and not pass --strict-order.
    Thanks to Stéphane Graber for the patch. (LP: #903854)
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 09 Jan 2012 14:07:45 +0100

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
mcguire (jonathand131-gmail) wrote :

Hi guys,

I'm sorry but I'm one of the people that want caching and don't want to wait for the 12.10 :-D

Instead of disabling it by code, could this be made configurable with caching disabled by default to still honor this bug report ?

Revision history for this message
Shock (mmiron) wrote :

I'd enjoy me some caching, too!

Revision history for this message
Daniel J Blueman (watchmaker) wrote :

From the discussion [1] leading to the changes in this bug report, there are a couple of statements which aren't so robust:

1. "will greatly improve the reliability of DNS resolution on our desktop systems"
 > the reliability only increases if dnsmasq were vulnerable and an exploit was being exercised

2. "at the cost of a slightly higher DNS traffic to the upstream DNS servers"
 > I measure a O(1000%) increase of DNS traffic in general desktop use (browsing, email, IM), due to applications frequently re-evaluating DNS queries. What basis is "slightly" arrived at?

3. "the ... resolver must maintain a separate cache per user, to prevent privacy issues, and to prevent local users from spying on source ports and trivially performing a birthday attack in order to poison the cache for other users"
 > by what mechanism is privacy compromised for non-root users?
 > how and where is the detriment in local users "spying on source ports" if dnsmasq has the Rainbow attack mitigation?
 > how is a Birthday attack plausible when the known weaknesses exposing this were closed in 2008 [2]?
 > presenting the ultimate solution as needing per-user caching is missing the point, when the underlying issues need addressing

As it stands, dnsmasq is not vulnerable to Rainbow attacks after port randomisation was introduced, and there have been further hardening measures taken since; these changes remain Ubuntu-specific because the logic is incomplete.


Revision history for this message
Thomas Hood (jdthood) wrote :

> I'd enjoy me some caching, too!

In 12.10 you can run the standalone dnsmasq (with caching enabled, listening at in series with the NetworkManager-controlled dnsmasq (with caching disabled, listening at

Revision history for this message
Thomas Hood (jdthood) wrote :

The change suggested in this report was in fact implemented for 12.04 but it gave rise to bug #1003842.

Thus for the sake of performance improvements under unusual circumstances, some users experience inability to resolve private domain names under circumstances that are not uncommon.

My personal opinion is, therefore, that the change made here should be reverted until such time as a better solution is found for bug #1003842. But we can continue the discussion in #1003842.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.