Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OK, then you didn't answer my question either. I was not asking "which companies would you not trust, and by what rationale"? The question I asked was: "Whom do you believe would keep your DNS data private, and by what rationale do you find them more believable than Google?"

Telling me you wouldn't trust someone who meets some disqualifying criterion isn't useful if you have so many disqualifying criteria that you wouldn't trust anybody, which frankly is the impression I get reading people's comments on this issue. If you have an actual company that you would trust, and a clear rationale for doing so, that's where we can have a real discussion.



> Whom do you believe would keep your DNS data private

You presupposing that it is necessary to send all DNS traffic to one entity. I run a local recursive nameserver (unbound) instead of sending all of my queries to a different nameserver.

Combined with aggressive caching, any particular DNS server (from .ROOT-SERVERS.NET down to the specific authoritative nameservers for a specific domain) is only able to view a tiny subset of my browsing behavior. Most of the time the query to the final authoritative nameserver is to be followed quickly by a TCP SYN packet that reveals roughly the same information.

Yes, running the full recursive resolver locally can be very slightly* slower than asking e.g. the local ISP's server that probably has the query cached. Fortunately, local caching limits this (very minor) problem to only the first request for a domain.


Running a recursive resolver isn't really that great from a "trust no one" perspective, because the .com nameservers are getting a decidedly not tiny subset of your access activity.


The TLDs are only queried for the NS records of the second-level domain, and the A (or AAAA) records of the those NS names. This is cached, often for longer than the record's specified TTL. The rest of the traffic is with the 0delegated nameserver,


The second level domain under com is the important part 95% of the time.


> This is cached, often for longer than the record's specified TTL.

NS records don't change very often. They can see that I looked up the delegation data about "example.com" once every $CACHE_TTL (~months). They do not get repeated queries at the beginning of every session I have with a website.

A lot of security is about being in the habit of minimizing attack surface. The only thing a TLD (or ISP) nameserver needs to know if I want to use the Doomain Name System is "pdkl95 asked for example.com's nameserver once last month" Instead of giving Google (or whomever) an update e.g.:

    ;; ANSWER SECTION:
    news.ycombinator.com.  300  IN  A  209.216.230.240
...every 5 minutes. This is not trying to stop someone discovering that I have ever been a domain; I'm limiting the ability to model my pattern of life[1].

[1] https://en.wikipedia.org/wiki/Pattern-of-life_analysis


So what I get out of this is that your system protects your privacy because it uses a custom TTL, and not really because you run a recursive resolver. It helps reduce errors, but you could get almost the same effect with a pure cache.


No, I'm still requesting the A/AAAA records at the normal TTL rate. This doesn't expose useful information, because those queries are sent directly to the domain's nameserver. The domain learns that data point anyway from the TCP SYN packet I'm probably sending immediately after I learn the A/AAAA record.

Separating the requests allows for different cache policies. If you simply delegate the entire recursive resolution work to Google (or whomever), they get to record that you needed "www.example.com" every TTL (5min?). You don't even need to see the domain's NS records in that case, so there isn't an opportunity to choose a cache policy.


I'm not sure why you lead with "No" because you didn't disagree with anything I said.


> and not really because you run a recursive resolver.

"No", because the system depends on running a recursive resolver locally to separate queries onto different nameservers.


It depends on doing so to work better. But a similar not-quite-as-good system could do without that feature. It's not integral.


What is this system that prevents pattern-of-life analysis while still sending all DNS queries to one nameserver? I'm still sending frequent short-TTL (normal caching) DNS lookups for most hosts that would betray my pattern-of-life in aggregate. The vast majority of the security is from sending those requests to the domain-specific nameservers instead of aggregating it all through a single upstream nameserver.

Aggressive caching of NS records for TLDs doesn't do anything to prevent a single upstream nameserver from leaning your pattern of life from the frequent DNS lookups for A records that are not cached longer than normal.


> What is this system that prevents pattern-of-life analysis while still sending all DNS queries to one nameserver?

Setting $CACHE_TTL to "months" on everything, and doing nothing else.

> I'm still sending frequent short-TTL (normal caching) DNS lookups for most hosts that would betray my pattern-of-life in aggregate.

Your system does that. This theoretical mildly-inferior system would not have frequent DNS lookups for any record type.


> Setting $CACHE_TTL to "months" on everything, and doing nothing else.

That will break a lot.

DNS isn't static; IPs regularly change as servers move, CDNs are introduced/changed. Long-term caching only works on NS records because changing DNS delegations is relatively rare. NS record caching does cause problems, but they are infrequent. Caching the addresses of the actual servers will break some things within days, and most of the internet the next time each server is updated/moved/etc.


QNAME minimization is about to fix that.


I think much of the distrust stems from: "why is google doing this". It costs some amount of money to operate a DNS service, and it's pretty reasonable to think that Google is getting something in return. Pretty much every other service they offer for "free" pays for itself by monetizing usage patterns and content, so it's no leap at all that they are offering DNS services with a similar quid-pro-quo.

Even if they don't use your traffic history to help with personalized advertising, they could conceivably use it for other things (e.g., bot detection, usage stats).

Google discusses what they collect in their privacy policy (https://developers.google.com/speed/public-dns/privacy), but not how they use it.


The answer is that yes, I don't -- fully -- trust anyone or anything I don't personally know. With that said, there are criteria by which I decide to trust a given company more or less, such as their business model, age, track record, size, and target audience. For example, I have some trust in apple because their business model relies on selling hardware and they have a decent track record (apple v fbi). I also have some trust in microsoft because a significant portion of their target audience is enterprise -- banks run windows me, the economy runs on excel. They have enterprise software that come with certain guarantees, and if they break those guarantees for me, a $10 customer, then they'll lose the $10 million customers, so I feel secure in using their enterprise software. However, this is tempered by windows 10 spyware, and makes me more reluctant to use consumer versions of their software.


I'm seeing what amounts to a lot of complaints and negative comments about what you wouldn't do, but for some reason you're still not actually answering the question of what you would do. The question has been quite clear and concrete: which DNS servers you would rationally trust more than Google's, and why. So far all I see that you've said is that you don't trust Google, that you in fact don't fully trust anyone, and that you would trust Microsoft and Apple more than Google---all three of which dodge the actual question of whose DNS servers you would use and why you would rationally trust them more than Google. Apple and Microsoft don't have public DNS servers (AFAIK? if they have ones that you're advocating then by all means correct me) so it wouldn't make any difference even if you'd trust them with your newborn baby. Regardless of whom else you pick, it really does not make any difference whether that DNS server(s) is getting 1% of your trust or 99% of it -- it's still going to be the one getting your queries, and I'm trying to understand whose server(s) you're picking and why it's rational to choose theirs over Google's.


Most people pay for ISP service and get a DNS server included in the price. It's a clear quid-pro-quo. If they don't respect your privacy, or they generally behave badly, you can switch providers (assuming you're not one of the 50 Million US citizens with only one ISP provider).

Even if you have an evil ISP, and they're selling your data for $0.50/month, you're still paying them $50/month for service. A bunch of angry customers could change their policy quickly. Few ISPs would try to squeeze those extra quarters from you, given the potential blow-back (some do, and they'll get their comeuppance). However generally, ISPs incentives are to keep you as a customer and get your fitty beans every month.

However, with Google, it's not clear why they are giving DNS services away for free or what they're getting in return. It clearly costs them some money to do so, and they're not being paid for it directly. It's possible that they're doing it purely altruistically, but they also have an extremely long history of using data for advertising or other forms of monetization.

I'm not saying that if you use 8.8.8.8, you'll search ads will target you. But I would bet they use your anonymized browsing history to fight bots, test internet speeds at various locations, identify browser technology, and who knows what.


This is really going against the impression I've both personally gotten and seen from others here. Are you really saying you would trust Comcast or AT&T here more than Google with your DNS history?

And regarding this bit:

> I'm not saying that if you use 8.8.8.8, you'll search ads will target you.

Hm, well others here have been suggesting this would be the case.

> But I would bet they use your anonymized browsing history to fight bots, test internet speeds at various locations, identify browser technology, and who knows what.

Even if I take this at face value, how are these things you listed bad things? If my DNS queries are going to fight bots, by all means, please fight bots! If they're going to help them improve internet speeds, by all means, they should do that! That's what data is good for. Everyone here is freaking out about privacy, not improved service. (!)


Certainly Comcast and At&T are pretty untrustworthy when asked to do the right thing, and I'd pretty confidently say they're less trustworthy than Google.

That said, they are selling a service, and you're paying for it. Quite a bit for it. It would be pretty stupid for AT&T to use your DNS data and risk your $150/month cable, phone, internet subscription for an extra buck or two.

But with Google, you just don't know and their entire business model is predicated on selling your data. They are almost certainly using their DNS servers for some data-based operation.

And a last quasi-technical point... I'm sure AT&T and Comcast have good engineers on staff, but I'm even more sure that Google has better ones. I am less concerned about AT&T and Comcast because I honestly don't think they have the wherewithal and talent to come up with ways to monetize DNS. I'm pretty sure Google could.

And to your point, even if Google is giving away DNS services to only fight bots and measure internet speeds, they should at least say that in their privacy policy. They don't. They just say they keep detailed data temporarily and anonymized data long term. I don't use Google's DNS because I really have no clue what they're doing with it. In contrast, if my ISP does something, I can always try to sue them, or if that fails cancel my service.


Just some related stories:

https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

http://www.latimes.com/business/la-fi-lazarus-20150818-colum...

There is no point in discussing what companies might do in some theoretical framework - they do not care about your privacy, they monetize NXDOMAIN, etc. This isn't about what might happen - these abuses have already happened.


You asked by what criteria I would trust one company over another, which seems significantly more interesting but...alright:

My own ISP already knows all the ips I connect to, so telling them what the domains are doesn't tell them much, especially as the trend towards ipv6 means that multiple-domains-on-one-ip has gotten less popular.

Cloudflare's main prerogative isn't to sell clicks the way google's is, which earns it points already. In addition, if you believe the official documents, they permanently log a lot less[1] than google[2].

I would also, needless to say, feel ok hosting my own dns.

Quad9 and opendns both filter content, and as such I don't trust them because the fact that they're willing to do that means that they are willing to censor content if they so choose.

I don't know any other dns servers off the top of my head.

1: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... 2: https://developers.google.com/speed/public-dns/privacy


There we go! OK, so you'd trust your ISP and CloudFlare more than Google. Let's go through them.

> I would also, needless to say, feel ok hosting my own dns.

Yeah let's avoid options that 99%+ of people wouldn't find realistic.

> Quad9 and opendns both filter content, and as such I don't trust them because the fact that they're willing to do that means that they are willing to censor content if they so choose.

Right, I think I agree on that.

> Cloudflare's main prerogative isn't to sell clicks the way google's is, which earns it points already.

Sure, some points there for the increased likelihood of hypothetical data mishandling due to their incentives.

OTOH, don't forget it was Google who found this issue in CloudFlare, which earned Google some points and earned CloudFlare /quite/ the demerits in my book... and note that this was an _actual_ massive security incident, not a hypothetical one: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

> My own ISP already knows all the ips I connect to, so telling them what the domains are doesn't tell them much, especially as the trend towards ipv6 means that multiple-domains-on-one-ip has gotten less popular.

I find this to be quite the odd argument for most people (maybe you're in the 1% of people who uses unconventional ISPs or email/search/map/etc. sites). Not only do major ISPs (thinking e.g. Comcast, AT&T here) not exactly have a great reputation on the privacy or security front (wasn't it just a few days ago someone posted about your home address being linked to your IP on Comcast?) -- meaning whatever data they do collect is prone to being hacked even if you believe they're really honestly keeping it private, which I'm not sure I always would -- but for most people Google already knows pretty much their life. And on top of that, they do their own tracking with Google Analytics, so they already know what websites most people are visiting -- not just from home, but also from work and on the go. And unlike with your ISP, it's likely already linked to your personal identity, not just your household or work office.

Oh, and in case you would like your advice to apply to those who have, say, Comcast, may I point you to quotes like this [1]:

> Comcast today said it has "no plans" to sell its customers' individual Web browsing histories, but Comcast can still deliver personalized ads based on its customers' browsing history. Comcast, the nation's largest home Internet provider, said it will continue to offer customers a way to opt out of targeted ads.

I don't know about you, but I would be shocked if they did this solely based on IP and did not find DNS information to be important for this task.

[1] https://arstechnica.com/tech-policy/2017/03/comcast-we-wont-...


> OTOH, don't forget it was Google who found this issue in CloudFlare, which earned Google some points and earned CloudFlare /quite/ the demerits in my book

I don't quite understand this one. Are you saying that you have an expectation that all software be bug-free? That just doesn't happen, unfortunately. Cloudflare had a problem, they fixed it promptly and then published a post-mortem on it. That, imo, is exactly what should happen. And as for google, it was discovered by their dedicated team of security researchers. Having such a team arguably reflects well on google, but do remember that monolithic corporations such as google are rarely unified.


No, I never suggested "I expect all software to be bug-free". Google software has bugs too. You're completely muddying the waters with a strawman like this. What I'm saying is that it that calling a massive security incident a "bug" doesn't suddenly erase it. Maybe it was pure dumb bad luck that could've happened to Google too, maybe it was because CloudFlare is just younger and still learning about the whole "defense-in-depth" thing that prevents 1-2 bugs from massively screwing everything up, or maybe it's just the lack of money and/or being able to attract as much top talent... I can't know for sure, and maybe I'd even sympathize with them, but I'm not trying to determine guilt and figure out whom to throw in jail here—I'm just trying to decide whose service to trust, pay for, and use. I'd be completely nuts to disregard actual severe past mistakes and solely look at my impressions of their intentions and hypothetical scenarios. You might look at intentions when figuring out whom to blame, but you definitely need to look at the cold, hard facts when figuring out whom to trust. The fact that they did actually make a system that actually screwed up in keeping private data private simply has to be taken into account when figuring out how much I can trust them with private data, however good their intentions and post-facto reactions to it were.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: