Live data from Hacker News

Improving DNS Privacy in Firefox

blog.nightly.mozilla.org

71–80 of 126 posts

Re: Improving DNS Privacy in Firefox

#71

No, no no and no. It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain. HTTP is a terrible protocol for anything time sensitive. (its a fairly bad protocol for anything fast or efficient full stop.) The better way to do this is encourage/provide DNSsec (so we know that a provider is who they say they are) and then encrypt dns queri…

I'd agree with you on principle, but Cloudflare has thus far been a very trustworthy company with regards to privacy.

The more paranoid (or prudent, depending on your perspective) among us would run their own DNS resolvers.

Re: Improving DNS Privacy in Firefox

#72
post #65

No, no no and no. It does not improve privacy, it just puts all your DNS history in the hands of one provider. Not only that it adds latency for no real gain. HTTP is a terrible protocol for anything time sensitive. (its a fairly bad protocol for anything fast or efficient full stop.) The better way to do this is encourage/provide DNSsec (so we know that a provider is who they say they are) and then encrypt dns queri…

And what happens when I stay at a hotel and need to access the login page of the local lan?

Firefox automatically disables DoH if captive portal is detected.

Re: Improving DNS Privacy in Firefox

#73
post #65

Earlier quoted context omitted.

And what happens when I stay at a hotel and need to access the login page of the local lan?

Firefox has both soft-fail and hard-fail modes.. for a soft fail it will fallback to traditional port 53 DNS. Its likely that will be the most common deployment - you need it to deal with captive portals (i.e. the hotel wifi) and other split horizon issues as well cloud uptime incidents. But there is a hard fail mode if that is suitable for your environment.

Firefox has separate captive portal detection code.

Re: Improving DNS Privacy in Firefox

#74
I hope they are not making this a default setting. What about GeoDNS load balancing/routing that a lot of companies are using? Some time ago I've tested Google DNS servers and got worse location from Akamai than using my ISP DNS servers. It was before Google introduced EDNS Client Subnet (rfc7871)[1] so I don't know how things are now but probably biggest CDN providers like Akamai now give exactly the same results as you would use your own ISP DNS servers. I don't know if smaller companies/CDN providers implement it tough.

How cloudflare is solving this with their 1.1.1.1 DNS server? Because if they don't then it can be really problematic for some percentage of users.

[1] https://tools.ietf.org/html/rfc7871

Re: Improving DNS Privacy in Firefox

#75
post #68
post #66

Earlier quoted context omitted.

In my opinion we don't want TLS at all, but rather a UDP based protocol, so that the latency advantages of DNS aren't lost. I believe DNSCurve solves this.

If you want UDP, DNS over DTLS also exists.

Doesn't really save you anything; DTLS still involves a connection with a handshake, so you have increased latency and memory overhead. Its usefulness is in low latency transport where head-of-line blocking would be detrimental (e.g. real-time streaming video; phone calls; VPNs).

DNSCurve, by comparison, is connection-less -- meaning no handshake latency, no connection overhead, and denial-of-service resilience.

Re: Improving DNS Privacy in Firefox

#76
post #57
post #24

Why would I want my browser to do this? My browser should use the DNS configured by my OS -- in my case, a local, caching resolving NS. If I want to use some kind of DNS-over-HTTP I'll tell my OS to do it. I don't want my browser making DNS decisions for me. What am I missing?

I used this at some point on my Fedora laptop. I had issues on some hotel APs where it didn't allow me to see the 'login page' of the AP. What's the way to circumvent this problem? I'm frequently on public wifi's, so I need to access AP login pages without issue.

Firefox tries to detect captive portals.

Re: Improving DNS Privacy in Firefox

#77

so, there's a concurrent post about how 1.1.1.1 had an outage. Does that mean web browsing won't work if that happens again? If not, does that mean it will fallback to unencrypted DNS if 1.1.1.1 is blocked? Making this a default means that Firefox users all bypass censorship in several countries, what do they expect to happen as a result of it? Firefox blocked? 1.1.1.1 blocked?

The post also notes that they won't be using the 1.1.1.1 address, though they'll be using Cloudflare. They'll likely be using another address which is less likely to be blocked.

Most likely because 1.1.1.1 still doesn't work on networks like AT&T.

Re: Improving DNS Privacy in Firefox

#78

Earlier quoted context omitted.

This isn't any different from if your normal DNS server is blocked, and 1.1.1.1 is not the only encrypted DNS provider. If whatever DNS you use doesn't work, then you cannot resolve any new domain names until you change to another DNS server or it gets fixed. Recently used domains will be cached in will thus still work.

> Recently used domains will be cached in will thus still work. Except for the many domains that set very low TTLs for load balancing and cloudiness reasons.

The point is, this isn't a new problem. This problem still exists in the current way of doing things.

Re: Improving DNS Privacy in Firefox

#79
post #53

I don't see how this improves privacy. Yes, my local ISP, whose DNS I'm using, knows the domains I'm connecting with. They most likely can also access this info in cleartext in other ways, if they care enough. For instance through SNI. Beyond my ISP, it's doubtful that unencrypted nature of DNS has any impact on my privacy due to heavy caching and the fact that my requests are merged together with requests from many…

There are plans to remove the SNI privacy leak as well.

Note that "your local ISP" means "whatever coffeeshop you are using wifi in", for laptop users, right?

You're right that if the resolver decides to keep and correlate logs that's bad. It's pretty key to use a resolver that you trust to not do that...

Post reply on HN