| |||||||||||||
SlashdotSlashdotPosted Dec 8, 2012 18:17 UTC (Sat) by tialaramex (subscriber, #21167)In reply to: Stallman: Ubuntu Spyware: What to Do? by Lennie Parent article: Stallman: Ubuntu Spyware: What to Do?
Of course when you hit enter:
* The fact that you're connecting to that specific site is revealed to anyone handling your DNS traffic, or your IP traffic, or to anyone doing transit.
* Slashdot redirects you to their non-SSL page anyway
But yes, in theory this particular auto-complete feature betrays things you might wish not to make public.
(Log in to post comments)
Slashdot Posted Dec 8, 2012 18:26 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
> The fact that you're connecting to that specific site is revealed to anyone handling your DNS traffic, or your IP traffic, or to anyone doing transit.
The DNS traffic can be minimized with a caching DNS server. The external request(s) then go out every so often, not every time you try to access the site. And if you have an array of computers using the caching server, things should be hard to correlate. Of course, a proxy can be inserted which does additional DNS requests for any site referenced on downloaded pages as well to help add some "plausible noise" into the streams.
> Slashdot redirects you to their non-SSL page anyway
That's…yet another reason to avoid slashdot? I kid, I kid. Only half. Maybe.
Slashdot Posted Dec 9, 2012 1:48 UTC (Sun) by paulj (subscriber, #341) [Link]
A local, caching, fully capable recursive resolver (e.g. an actual nameserver) should be a default install on all machines really. Better for privacy, better for DNS-Sec (who is ever going to configure a stub-resolver with TSIG, and DNS-Sec validating stub resolver has to do all the work of a fully functioning recursive server), better for avoiding poisoning attacks on shared recursive nameservers.
yum install caching-namserver + beat NM into leaving resolv.conf alone somehow. +1
Slashdot Posted Dec 9, 2012 2:37 UTC (Sun) by Lennie (subscriber, #49641) [Link]
If everyone did that, then I hope you mean: local, caching, fully capable, forwarding recursor.
Because we really don't want every desktop talking to the root or top level domain servers.
Slashdot Posted Dec 9, 2012 6:45 UTC (Sun) by paulj (subscriber, #341) [Link]
Forwarding would just add latency and fragility. The .'s are a fixed set (in terms of the IPs), both the . and TLDs are quite a large set in terms of # of servers. The commonly contacted ones would be cached. Also, I've seen scribblings in the IETF journal once that questioned whether hierarchy of caching achieved much in the way of gains. Finally, the .'s and TLDs can handle the additional load - anycast is a powerful tool.
Slashdot Posted Dec 9, 2012 14:24 UTC (Sun) by Lennie (subscriber, #49641) [Link]
The average website has 14 domains linked from the first website people visit: http://httparchive.org/trends.php
You really want every device with a browser to talk to the TLD servers for each of these domains ? (yes many are the same domain: so let's say 7 per website you visit).
That's doesn't add up.
Slashdot Posted Dec 9, 2012 18:12 UTC (Sun) by paulj (subscriber, #341) [Link]
The roots and TLDs are *more* than capable of handling requests from every device on the internet, without caching. There is a simple proof for this: They *did so* - users will regularly make typos in their browsers, queries for these non-existent domains will go out to the "." and (if the TLD is valid) to the TLDs.
Perhaps this decreased a little since browsers started diverting things typed into the address bar to search engines.
However, the fact remains that the roots and TLDs *already* get hit by queries from *every* device with an interactive user, as well as any which happen to query for some misconfigured or no longer valid hostname. The . and TLDs are *already* setup to handle this kind of load, cause they already get it.
What the intermediate caches do is:
a) Not provide effective caching (distribution of queries is very long tailed) - see e.g. http://dl.acm.org/citation.cfm?id=581877 (and I think there's a more recent ISOC article that found the same thing)
b) Potentially add latency - it may take longer for your computer to get its answer.
c) Provide a huge, juicy target for attackers - a DNS poisoning attack is so much more efficient if you poison a widely shared cache.
Slashdot Posted Dec 9, 2012 10:19 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
You man: Beat NM into not using dnsmasq for this? (At least in Debian. Not sure about other distributions).
Slashdot Posted Dec 9, 2012 12:57 UTC (Sun) by hummassa (subscriber, #307) [Link]
Ubuntu, too. I was asking myself the same thing.
Slashdot Posted Dec 9, 2012 16:37 UTC (Sun) by cortana (subscriber, #24596) [Link]
AFAIK dnsmasq is used for the connection sharing feature. I'm using NM on my machines and it merely writes the DHCP- or user-specified name servers into /etc/resolv.conf.
|
|||||||||||||