Earlier quoted context omitted.
> I welcome my browser doing something about it. Can we please go easy on the newspeak? Centralizing resolving to a handful of actors will not improve privacy for the most part of end users.
Resolving is already centralized: your ISP has 100% control over what you resolve, and you can't do anything about it. This is doing the opposite - by securely implementing resolution in a user agent, in a tamper-proof way, under the control of the user.
Inside Firefox’s DNS-over-HTTPS engine
101–110 of 134 posts
Re: Inside Firefox’s DNS-over-HTTPS engine
#102While I'm sure it's true that Firefox's implementation does this (presumably it provides a setting in the UI whereas it didn't before), there was nothing preventing this with regular DNS. It isn't something that DNS-over-HTTPS makes possible.
Specifying your own DNS server instead of using the system default is a feature that the nslookup command has offered for like 25 or 30 years, so I'm sure a web browser could offer it too.
Re: Inside Firefox’s DNS-over-HTTPS engine
#103Earlier quoted context omitted.
There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.
Regular users use a browser extension like ublock or Adblock to block ads. Not improving DNS security for the sake of a few users obscure Adblock mechanism would be pretty silly.
Re: Inside Firefox’s DNS-over-HTTPS engine
#104Earlier quoted context omitted.
I believe that big DNS responses will be faster because instead of establishing a TCP connection there is already a warm one ready to go. But yes, for the common case the performance will be the same.
UDP doesn't require any connection at all
Re: Inside Firefox’s DNS-over-HTTPS engine
#105This further drives centralization of the Internet and the idea that the Internet == Web == Browser. It's disappointing to see this coming from someone so steeped in Internet contributions and history and believing it to be a good idea. Bypassing system DNS is not just an enterprise no-go, it probably will end up reducing privacy. The idea that ISPs sniff DNS is largely a red-herring, and further it's already easily…
Furthermore, ISPs in some countries like India forces all port 53 traffic to their own censored servers. DNS over TLS won’t solve that.
Re: Inside Firefox’s DNS-over-HTTPS engine
#106This further drives centralization of the Internet and the idea that the Internet == Web == Browser. It's disappointing to see this coming from someone so steeped in Internet contributions and history and believing it to be a good idea. Bypassing system DNS is not just an enterprise no-go, it probably will end up reducing privacy. The idea that ISPs sniff DNS is largely a red-herring, and further it's already easily…
My ISP in Australia already censors various domain names due to copyright lawsuits. ISPs tampering with DNS is not a red herring, but a real issue. Furthermore, ISPs in some countries like India forces all port 53 traffic to their own censored servers. DNS over TLS won’t solve that.
Re: Inside Firefox’s DNS-over-HTTPS engine
#1071. 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 dns server, efficiently, over a single connection
see https://news.ycombinator.com/item?id=17228745
5. convert json dns data to csv see https://news.ycombinator.com/item?id=17228473
6. import csv into database e.g. sqlite3, kdb+, export to /etc/hosts, export to zonefile for localhost auth dns server, etc.now, when user is reading hn front page, no dns lookups are needed. user already has the dns data. there is no network usage for dns requests, increasing hn front page browsing speed for the user. there are no piecemeal dns requests sent, increasing user privacy.
7. track ip address changes over time, compare answers from different caches, etc. retrieve type 2 (NS) instead of type 1 (A) records, then compare to NS records provided in public zonefiles from icann, public internet scans, etc.
cat t.l
#define p printf("%s\n",yytext);
%%
\200|\201|\204|\223|\224|\230|\231|\234|\235
http:\/\/[^ \n\r"#'|]* p;
https:\/\/[^ \n\r"#'|]* p;
ftp:\/\/[^ \n\r"#'|]* p;
.|\n
%%
int main(){ yylex();}
int yywrap(){}
/* compile with something like:
flex -Crfa -8 -i t.l
cc -pipe lex.yy.c -static -o yyt
*/
cat 1.k /k3 (novice level)
/usage: g=f k 1 where f is list of urls
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;h0 0:h1;
\\Re: Inside Firefox’s DNS-over-HTTPS engine
#108I 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
#109Earlier quoted context omitted.
Resolving is already centralized: your ISP has 100% control over what you resolve, and you can't do anything about it. This is doing the opposite - by securely implementing resolution in a user agent, in a tamper-proof way, under the control of the user.
Every user is free to run their own resolver or use any of their ISPs or third parties, which is pretty close to the definition of something decentralized.
Besides, I don't see how adding an option for DoH to Firefox is centralizing anything, you're free to set the DoH URL to whatever you like, and you're free to run your own DoH resolver, just like you're free to run your own vanilla DNS resolver.
Re: Inside Firefox’s DNS-over-HTTPS engine
#110I'm not very happy we're now going to send all DNS traffic to 6 centralized DNS-over-HTTPS servers[1]. We can't trust our ISP, but we can trust Google and Cloudflare? I also noticed that when I configure my Android's proxy settings to point at a Privoxy container that routes through a VPN, I still get DNS-hijacked to my provider's "thepiratebay.org has been blocked for you" page -- this only happens in Chrome mobile,…