Hacker News new | past | comments | ask | show | jobs | submit login

Don't oversimplify the issue.

> it's trivial to change your DoH provider

Cloudfare is the default.

Cloudfare is the only provider listed.

Cloudfare will be On by default, so it will be that for 99.999% of Firefox users.

That ain't right no matter how well intended it is.




And for regular DNS, their ISP/employer/school will be the service provider for 99.9999% of users. Regular DNS is not exactly easy to find (on Windows, it's under Settings -> Network -> Change Adapter Options -> Adapter Name -> IPv4 -> Properties), which is arguably as hard as going to about:config. And there is no menu of providers listed--nor does it explain who would choose the "automatic" DNS server options (the one that uses DHCP).

So the status quo is no better than this, and at least this is encrypted and protected by a privacy guarantee.

Now I agree that ideally a user-visible preference should be created for the DoH resolver, but I don't think that's a blocking issue. Just like the accounts features uses a mozilla server, and chrome uses google accounts, and both use google safe browsing lists, browsers have always made the decision to hardcode various external service providers.


> So the status quo is no better than this

You're completely missing the point. Users have many different ISPs, and them knowing DNS queries is not a problem because it's the ISP anyway. Now a browser wants to change that behavior, and send ALL queries to one american company.


Indeed, I think that in this case, on the whole, more privacy is achieved by decentralization rather than by encryption...


So the solution could be to make it so that there are many DoH providers and a browser would choose one of them randomly (or by user's choice).


Or -- much better -- use DoT instead of DoH so port 443 isn't getting misused for DNS.


While that's an unpopular opinion I tend to agree, I'm still on the fence if that's really bad or if I'm just grumpy about change though. It really feels like instead of fixing the underlying problems we're duct taping the internet by moving HTTPS to OSI layer 4 and making TCP and the concept of ports obsolete for a majority of use cases - which in many cases implies a loss of control. I'm honestly not sure why our sector pushes HTTPS solutions over plain TLS, is it just because it blends in with web traffic and it's easier to grasp because more people are familiar with the basic concepts?

Of course there's arguments for and against these aspects in the case of name resolution, both technical and on a legislative level, but maybe a net win in terms of privacy protection for the majority of users is still worth it. And should Cloudflare or whoever decide to misbehave with the data we send, it'll at least be easy to switch to other providers when DoH is widely adopted.


You're right of course, but HTTP(S) only 'won' because of the web.


> Or -- much better -- use DoT instead of DoH so port 443 isn't getting misused for DNS.

DNS over TLS has other issues. There's a nice comparison there https://dnscrypt.info/faq/ I have been using local resolver on 53, that forwards all requests from my LAN into DNSCrypt (and sends that over a VPN tunnel). That way I maintain privacy, and decentralization as well as being able to simply use the DNS resolver built into my OS.

I have to wonder though with HTTP/3 https://en.wikipedia.org/wiki/HTTP/3 being QUIC based, will we see DNS over QUIC? https://en.wikipedia.org/wiki/QUIC

Seems like Firefox doesn't even support QUIC at the moment. https://bugzilla.mozilla.org/show_bug.cgi?id=1158011


The IETF QUIC isn't finished. Periodically the Working Group thinks it has stopped fiddling with the low-level bit layout and is ready to focus on polish, then somebody finds a show stopper that means revisiting the low-level bits. Maybe 2020? They missed all their advisory target dates (July 2019) for actually writing documents, and that isn't the end by any means for a protocol like this.

So Firefox could at most support either Google QUIC (internal prototype, now obsolete, who cares?) or a random draft that may end up not resembling the final product. If they haven't decided to do either it doesn't seem like a big deal.


> The IETF QUIC isn't finished. Periodically the Working Group thinks it has stopped fiddling with the low-level bit layout and is ready to focus on polish, then somebody finds a show stopper that means revisiting the low-level bits. Maybe 2020?

Ah yes you're right. Also Mozilla (M. Thomson, Ed) is on the author list there so I expect they will support it when it is finalized.

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

Hopefully then they also support DNS over QUIC, I expect they probably will once QUIC is finalized. I think DoH is just a stop-gap measure to be honest.

https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic...


Then it would be easier for an ISP to block encrypted DNS (by port number). It is better to masquerade everything as normal HTTPS to make blocking more difficult.


> Then it would be easier for an ISP to block encrypted DNS (by port number). It is better to masquerade everything as normal HTTPS to make blocking more difficult.

For most people, if you can't trust your ISP, you have bigger problems.

For people who can trust their ISP, why should we all by default be affected by the fact that the Mozilla developers seem to all live in a non-free or non-democratic country.

Maybe they should instead focus on fixing the US political system that results in their current situation, rather than trying to use technical means to solve political problems.


What if you can trust your ISP most of the times but not during a specific time? For example, when there are civilian protests/acts which the current government doesn't like?

I have a very specific case for this: in the days before and during the referendum for the Catalonia independence (Oct 1s 2017), all the spanish ISPs where blocking access to the websites related with the referendum, using DPI to look for the SNI hostname. One of the main reasons to enable DoH in FF is to enable the encrypted SNI feature https://miketabor.com/enable-dns-over-https-and-encrypted-sn...


That would break the internet for many innocent souls behind firewalls.


Tor has some nice papers about what happens if you try that: the NSA and KGB each run a server and content themselves with getting a sample of the population.


> the NSA and KGB each run a server and content themselves with getting a sample

Which is already a lot better than getting 100% from simply spying on CloudFlare or serving them with "National Security Letters".


The other viable doh provider is google. Other’s timeout is simply not worth the request, in my experience. How does one choose from these two?


No, the other viable option is not enabling DoH by default.


And that should surely be the default. What's Mozilla's intent to send DNS queries to Cloudflare by default, and require regular DNS resolution to be configured manually?


Yes, that's exactly their plan at the moment. Hence the whole brouhaha.


privacy-wise, plaintext is the worst option possible.


I disagree, at least in my situation.

My DNS requests traverse my ISP's network to my ISP's DNS server (or my employer's ISP's DNS server if I'm at work).

I live in a country where I have very strong privacy protections and what my ISP can and can't do with my DNS requests is extremely limited.

If my DNS requests are sent to CloudFlare or Google instead, my DNS requests are under American jurisdiction, where I have no rights and both American businesses and the American government can do whatever they please with no real recourse.


So it depends on the country. In my country (Russia) all Internet traffic is being recorded by the ISP for the last month and sites are blocked on political reasons. For me having DoH with Cloudflare is better.


Ditto in Australia

The reason why browsers are moving to features like DoH and eSNI as defaults is because it's every type of nation that is now instituting pervasive surveillance against its citizens

You also can't trust laws since ISPs can be hacked or infiltrated from the inside

In terms of personal protection encryption trumps law


> You also can't trust laws since ISPs can be hacked or infiltrated from the inside

Cloudflare isn't magically free from the same threats.


> I live in a country where I have very strong privacy protections and what my ISP can and can't do with my DNS requests is extremely limited.

There's very few countries with such strong privacy protections, even in the Western world.


From what I can tell, all countries covered by the GDPR heavily limit what an ISP can do with DNS queries. That covers 515M people, which is more than the populations of three mentioned countries (US, Russia and Australia) put together.


> which is more than the populations of three mentioned countries (US, Russia and Australia) put together.

Not sure it matters, but only by a small margin is that true. 500M vs 515M.


A lot of these countries currently have laws to record years of DNS logs for future analysis by the police. Due to the abuse these countries have done in the past about it, I do not want any record personally.


That’s a very good point. In fact all of them do, because the same EU that mandates GDPR also mandates data retention, which only differs in details in member states.


That's a very good point.

I'm not familiar with DoH. Would it allow CloudFlare to match domain names to IP addresses still? If so, then I don't see how it adds any value to the current solution. If anything, it creates a false sense of security which is worse than no security at all.

What's the point of encrypting the DNS lookup step if a middleman can still potentially see everything in plaintext?


Couldn’t your isp watch traffic to pull out SNI information?


the next step is eSNI and judging by the DoH rollout that will also be a new level of controversy advocating against it


What are the arguments against eSNI?


> What are the arguments against eSNI?

Institutions providing internet access, but with an obligation or operational requirement to block certain kinds of content (e.g. insufficient network capacity on the free WiFi at a hospital to allow streaming video for all visitors) would not be able to do it at all.

Privacy proponents seem to forget that there are sometimes reasonable reasons to allow traffic to be blocked, and instead of looking for a real solution, are imposing ridiculous "solutions" on all Firefox users.


Your request will hit CloudFlare edge node in your country and be served from there. Under your jurisdiction.


I can think of something worse: sending all your DNS queries to an unregulated third party.


This is already what happens. Your DNS queries have to go somewhere, and unless you control the DNS servers, there's a third party in the loop somewhere.


Not really, my DNS requests go to my ISP's DNS server. And the ISP sees the requests anyway since they are the one forwarding all the packets.

Now, Cloudfare will see them too. (if this would come to my country).


But your ISP won't see them. They'll see that some requests are being made to Cloudflare, but not anything about the content.


No I mean in my current situation if my ISP is also my DNS provider they will get the requests.

But they can already see what sites I visit because they are my ISP and carry my packets.

In Mozilla's new default implementation Cloudflare will also see them, without me ever knowing (as an average user).


With TLS1.3, encrypted SNI, encrypted DNS the ISP can only see the IP address you are connecting to, not a domain name. For Google's resources it only sees that you are connecting to Google's network, but is it Youtube or Gmail or Maps, they cannot tell (which is awesome by the way).


And down the toilet goes the (distributing and caching) Inter-Net. Long live to the new Cloud-Net. Cloudfare and Google are achieving what Compuserve and AOL could not.

Exaggerating slightly ... but not that much really. And all in the good name of privacy and security.

It is also amazing how people (Americans ?) are not willing to admit I want MY jurisdiction to apply. Not an American one. I want the choice.


Caching died with insecure HTTP, and that's okay.

> I want the choice.

Then turn it off. But the default protects more people than it harms.


Well, it's not really a choice if for security I must give up on jurisdiction ?

I don't doubt the intentions of Mozilla. But, I expect Mozilla to set the bar much higher.

> But the default protects more people than it harms. Sorry, not good enough for me. They should not be promoting a private company centralized solution. They really should be pushing for a decentralized and distributed solution that is yet secure for everyone involve and promote that.


SNI isn't super useful to profile customers by itself. Now of course encrypted SNI will be a welcome addition to the protocol, but it won't get rid of traffic profiling.

The destination IP is more than enough to build a customer profile. It's not terribly relevant if you visited Youtube or Maps. Just analyzing netflow logs will give much more information than what services you use, such as for how long you use them and if you stream any media during that time.

Should you wish to have more information than that on your customers you'd have to buy it from someone who runs code in most web pages you visit. There are plenty of those, too.


Hence your request goes to yet another party: your ISP (by necessity via IP destination in your IP headers), the site you want to go to, and to Cloudflare/Google as DNS provider and as fourth party. Whereas with regular DNS, your ISP's nameserver gets DNS queries, hence only three parties are involved. Eg what ndidi, apexalpha said.


With Tor ISP can't even see the final address, but maybe Tor has its own solutions for DNS?


Onion sites use a keypair as their "name"


ISP and government are that "unregulated third party".


ISPs are highly regulated, as opposed to Cloudflare and Google. The only effect here is that Google closes another "loophole" in their view where web visit signals are send to another party (other than Google), and Cloudflare wanting their share of the cake as well. Has Mozilla disclosed what Cloudflare is paying them for being listed as default DoH provider?


ISP's are highly regulated when it comes to DNS? Not here in the US they are not.


Well to buy a domain you need to go to an accredited registrar for the respective TLD. And DNS registrations, renewals, etc. are standardized (and have TLD-specific policies). Also, you're entitled to transfer your domain name to another registratr, etc., also with a public and transparent protocol. The registrar will then arrange for their nameserver being registered as authoritative for your domain on the TLD's root domain server, etc. What's the problem with US ISPs here? That they're selling DNS query records (with your IP) against their nameservers? That's in the same territory as Cloudflare and Google, and will only stop with proper privacy laws; certainly not by giving up on the decentralized nature of DNS and giving all traffic/signals to Cloudflare/Google.


aren't you still sending your data to unregulated third party with any ISP? (i dont live in the US so i am not aware if they're regulated in this regard)


Plaintext doesn't route every god damn request through Google or Cloudfare.


If you have a Chromecast, it's already sending the DNS requests to 8.8.8.8 unless you specifically block the IP.


> If you have a Chromecast

Why the hell would anyone buy hardware from an evil spyware company such as Google?

Of course you can never trust a private corporation to do stuff in the public interest.


I think you mistook it. I was talking about doh providers, not all options, and responded to a line completely tangential, if not unrelated to what you try to bring here. An answer looking for a question, I guess?


Even Quad9[1] or NextDNS[2]? Quad9 works well for me.

[1]: https://quad9.net/doh-quad9-dns-servers/ [2]: https://nextdns.io/


I'm on Firefox 69, it's disabled, I never touched it.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: