I 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.
Inside Firefox’s DNS-over-HTTPS engine
111–120 of 134 posts
Re: Inside Firefox’s DNS-over-HTTPS engine
#112I 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.
Be aware that using it in 60 you may run into frequent crashes from https://bugzilla.mozilla.org/show_bug.cgi?id=1441131
Re: Inside Firefox’s DNS-over-HTTPS engine
#113I 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
#114I don't like the idea of this, but even the implementation is bad. If we're going to do DNS over HTTPS, then there should be a standalone application, and the system should be reconfigured to use it, so all running applications on the system use it. I 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 in…
Totally agree re: implementation details. And, like you said, this is a bad idea. Is there something wrong with efforts like DNSCrypt + DNSSec? That's supposed to provide authentication and encryption to DNS without sending everything over HTTP. Did Mozilla just totally ignore the work that's already been done in this area?
DNSCrypt is a niche protocol that basically does do what DoH does. Very few people use it. You can use it instead of DoH, if you like; just disable DoH in Firefox and set up DNSCrypt with your system resolver.
Re: Inside Firefox’s DNS-over-HTTPS engine
#115Earlier quoted context omitted.
One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter). Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.
Everything already works everywhere for everyone with regular DNS. The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies…
DoH provides confidentiality and query integrity now, without requiring a boil-the-ocean step where every DNS administrator on the Internet signs their records.
Re: Inside Firefox’s DNS-over-HTTPS engine
#116Also will the end goal be to have a new DHCP option so I can point my clients to my internal DOH server?
One of the nice things about this is I can make lookups authenticate. I hope the extend the update protocol into the HTTP context so we have a simple API for updating zones rather than nsupdate.
Re: Inside Firefox’s DNS-over-HTTPS engine
#117Here is a brief demonstration of how "DOH DNS servers" can be useful. Nevermind the idea of applications having their own DNS caches. 1. fetch page of html, e.g., hn front page curl https://news.ycombinator.com > 1.htm 2. extract urls from 1.htm yyt 1.txt (example scanner "yyt" provided below as t.l) 3. convert urls to hostnames g=1.txt k 1 (example script provided below as "1.k") 4. retrieve json dns data from doh d…
/ novice alert. this is probably 3x larger than necessary
h0:_getenv "g";h1:0:h0;h1:{:[(#h1[x] _ss "://")>0;h1[x];_exit 1]}'!#h1;h1:{*((h1[x] _ss "://[^/]")+3) _ h1[x]}'!#h1;h2:{h1[x] _ss "[^a-z^A-Z^0-9^.^-]"};h3:{*h2[x]};h1:{h3[x]#h1[x]}'!#h1;h1:?:/h1;if[0=#h1[0];h1:h1 _di 0];h0 0:h1;
\\Re: Inside Firefox’s DNS-over-HTTPS engine
#118Earlier quoted context omitted.
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.
No, he didn't. What he's done there is use a rhetorical style in which he uses your voice, that's what those quote marks are for. He's loosely paraphrasing your comment in order to ridicule it. 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.
Re: Inside Firefox’s DNS-over-HTTPS engine
#119I don't like the idea of this, but even the implementation is bad. If we're going to do DNS over HTTPS, then there should be a standalone application, and the system should be reconfigured to use it, so all running applications on the system use it. I 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 in…
Re: Inside Firefox’s DNS-over-HTTPS engine
#120What kind of headers get transmitted as part of the DNS query? With DNS, the nice thing is that it is not a chatty protocol, no authentication, no cookies, no user agent. https is exactly the opposite. It would be nice to know that it is not a new backdoor into tracking people. [edit]: plus isn't Stateless TLS Session Resumption effectively a cookie?
Even without tickets, having TCP sessions means that server operators can link multiple queries to a single device, even if multiple devices share the same external IP.
This gives server operators more data than plain DNS.
The DNSCrypt protocol can use a unique key for every query in order to prevent this. Since it doesn't use sessions, and all queries are independent, there is no latency overhead.
For DoH, dnscrypt-proxy has an option to disable TLS session resumption. But it introduces some overhead every time a reconnection is necessary.