© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
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:/
[2] http://