> It also makes it easy to use a name server of your choice for a particular application instead of the one configured globally (often by someone else) for your entire system. I can see app developers wanting this, but as a user, I really hope, this doesn't happen. It's bad enough that many applications today manage their own certificate stores, making the next part of internet infrastructure app-specific seems to me…
Inside Firefox’s DNS-over-HTTPS engine
71–80 of 134 posts
Re: Inside Firefox’s DNS-over-HTTPS engine
#72Earlier quoted context omitted.
It's been 30 years and DNS is still a major security and confidentiality flaw in all widely used OSes. I welcome my browser doing something about it. If in the future OSes and ISPs provide better alternatives, this feature can always be turned off.
I do want to use this on all my devices, not that I'm criticising the DoH concept per se. Only that it seems to me that the browser is not the correct place for the DNS resolver; thus I wonder why it's not the OS but the browser that gets the new features.
Re: Inside Firefox’s DNS-over-HTTPS engine
#73Earlier quoted context omitted.
Daniel is not responsible for the decisions made by other Mozilla managers who already used their powers to deliver an unsolicited ad to the millions using the means presented as having apparently other purposes. Daniel’s own decisions aren’t in question here. If he works for Mozilla he is not more powerful than the whole company. Having “off” and “off when selected by user” but not other variants still points to the…
It’s worth noting that Daniel is the GP here. You’re talking about him in the third person.
Re: Inside Firefox’s DNS-over-HTTPS engine
#74I am in Indonesia where Reddit, Vimeo, The Pirate Bay and other sites are blocked. I just enabled TRR in Firefox 60 (They mention best support is in 62) and now I have full unblocked access to all those sites. Awesome.
Using an alternative DNS resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) could solve that already, and not only in Firefox.
Re: Inside Firefox’s DNS-over-HTTPS engine
#75I am in Indonesia where Reddit, Vimeo, The Pirate Bay and other sites are blocked. I just enabled TRR in Firefox 60 (They mention best support is in 62) and now I have full unblocked access to all those sites. Awesome.
Using an alternative DNS resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) could solve that already, and not only in Firefox.
Re: Inside Firefox’s DNS-over-HTTPS engine
#76I am in Indonesia where Reddit, Vimeo, The Pirate Bay and other sites are blocked. I just enabled TRR in Firefox 60 (They mention best support is in 62) and now I have full unblocked access to all those sites. Awesome.
Ok that is news to me, why Indonesia blocks it?
Re: Inside Firefox’s DNS-over-HTTPS engine
#77If this passes, it's going to be a nightmare to system administrators. Basically, each and every split horizon will be broken.
But, promoting DNS-over-HTTPS in the browser and providing an easy-to-install, separate tool for Windows/OSX to solve through DNS-over-HTTPS is something I could get behind.
Like how on my network I do use dnscrypt-proxy, so everything is already using DNS-over-HTTPS.
Re: Inside Firefox’s DNS-over-HTTPS engine
#78> It also makes it easy to use a name server of your choice for a particular application instead of the one configured globally (often by someone else) for your entire system. I can see app developers wanting this, but as a user, I really hope, this doesn't happen. It's bad enough that many applications today manage their own certificate stores, making the next part of internet infrastructure app-specific seems to me…
One reason to desire separate trust stores is that your model of trust is almost certainly not "I wish my application trusted exactly the same CAs as [say] the Firefox web browser and I will incorporate all the same special rules and exception as that browser".
Example: Back in 2016 the US government expressed interest in operating its own public CA. This probably won't happen under Trump of course, but in Firefox this would have been no problem if they met its other criteria, it's easily able to accept a new CA and apply constraints to it. So that in Firefox a US Federal Web PKI cert for whitehouse.gov works, but one for gov.uk or google.com does not. But does your application have that logic? Or would it just blindly trust the new CA because Mozilla added it to their trust store?
The other reason is that your application is (especially if you aren't on the ball enough to run your own trust store) probably not able to keep up with the security treadmill, and falling off may be painful.
Example: If your system depended upon SHA-1 certificates to function, but you used the Web PKI CAs from somewhere like Mozilla's NSS store, magically in 2016 no more new certificates were available. No problem for the browser vendors, they had voted for exactly this outcome. Too bad for your application.
Re: Inside Firefox’s DNS-over-HTTPS engine
#79I mean, do we really want all of our desktop applications to have their own built in custom ways of mapping domain names to IP addresses?
[edit] E.g on Linux, it could install an application with a DNS interface listening on localhost port 53, which would then convert the request into a "DNS over HTTPS" request, and resolv.conf would be updated to use that resolver.
Re: Inside Firefox’s DNS-over-HTTPS engine
#80Earlier quoted context omitted.
It’s worth noting that Daniel is the GP here. You’re talking about him in the third person.
It’s worth noting that I know that but that he started this style of referring to him(self) in this thread! So it wasn’t accidental or due to unawareness in any its occurrences.
That's arguably rude, but then your follow-up is exactly the type of conspiratorial bullshit he's implicitly accusing you of, so it was just foresight after all I guess.