Ubuntu
network-manager package

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

Bug #903854 reported by Stéphane Graber on 2011-12-13

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Ubuntu)	Fix Released	High	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 https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving 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.

See original description

Tags:

Related branches

lp://staging/ubuntu/precise/network-manager

Mathieu Trudel-Lapierre (cyphermox) on 2011-12-13

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 on 2011-12-13:

Remove --strict-order and replace it by --cache-size=0 Edit (525 bytes, text/plain)

summary:	- Change default dnsmasq flags to not includ --strict-order + Change default dnsmasq flags to not include --strict-order and disable + caching
description:	updated

Ubuntu Foundations Team Bug Bot (crichton) on 2011-12-14

tags:

added: patch

Mathieu Trudel-Lapierre (cyphermox) on 2012-01-09

Changed in network-manager (Ubuntu):
status:	Triaged → In Progress

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-01-09:

This bug was fixed in the package network-manager - 0.9.2.0+git201112151936.6b31828-0ubuntu2

---------------
network-manager (0.9.2.0+git201112151936.6b31828-0ubuntu2) 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 on 2012-04-01:

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 on 2012-05-02:

I'd enjoy me some caching, too!

Revision history for this message

Daniel J Blueman (watchmaker) wrote on 2012-10-07:

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.

[1] https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
[2] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002148.html

Revision history for this message

Thomas Hood (jdthood) wrote on 2012-12-11:

> I'd enjoy me some caching, too!

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

Revision history for this message

Thomas Hood (jdthood) wrote on 2012-12-11:

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.