>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 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/903854 Title: Change default dnsmasq flags to not include --strict-order and disable caching Status in “network-manager” package in Ubuntu: Fix Released 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/903854/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
