Inside Firefox’s DNS-over-HTTPS engine
daniel.haxx.se
Inside Firefox’s DNS-over-HTTPS engine
1–10 of 134 posts
Re: Inside Firefox’s DNS-over-HTTPS engine
#2"Caveats
TRR doesn't read or care about /etc/hosts
There's no way to exclude or white list specific domains"
For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads.
This seems to remove all control a user might have through controlling such lookups. Yikes.
I think DOH is useful but in a different way. For example, it is useful for retrieving bulk DNS data using RFC 2616 pipelining, alleviating dependence on piecemeal DNS lookups, thus increasing speed and privacy. Data can be stored locally and refreshed periodically, if necessary (I have been doing this witout problems for 15 years). It's also useful for retrieving data from a variety of caches, allowing answers to be compared.
Re: Inside Firefox’s DNS-over-HTTPS engine
#3"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers.
[1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https
Re: Inside Firefox’s DNS-over-HTTPS engine
#4"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers. [1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https
I think there’s great value in DOH caching servers running on home routers; all the benefits of DOH but “regular DNS” between clients and your home router.
Re: Inside Firefox’s DNS-over-HTTPS engine
#5"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
[deleted]
Re: Inside Firefox’s DNS-over-HTTPS engine
#6"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
TRR doesn't read or care about /etc/hosts
There's no way to exclude or white list specific domains
Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic).
Applications should not contain their own encapsulated resolvers, let alone resolvers that default to sending all of my DNS traffic to for-profit companies that have previously experienced massive data leaks (and fun CF fact, they invited the then-CTO of Cambridge Analytica to talk at their Internet Summit event in SF last year).
Re: Inside Firefox’s DNS-over-HTTPS engine
#7"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers. [1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https
You think regular end users having to set up and maintain server software in order to force a name for an IP is going to become a widespread pattern? That's horrifying. I don't want to live in that world.
Re: Inside Firefox’s DNS-over-HTTPS engine
#8"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic). Applications should not contain their own encapsulated resolvers, let alone resolver…
> will be an absurd hassle for a very large number of organizations
they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file
Re: Inside Firefox’s DNS-over-HTTPS engine
#9Earlier quoted context omitted.
TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic). Applications should not contain their own encapsulated resolvers, let alone resolver…
> will be an absurd hassle for a very large number of organizations they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file
This isn't an acceptable compromise.
In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of all internet access that has existed in the same form for 40 years.
Re: Inside Firefox’s DNS-over-HTTPS engine
#10"Caveats TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains" For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads. This seems to remove all control a user might have through controlling such lookups. Yikes. I think DOH is useful but in a different way. For example, it is useful for retrieving bul…
TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic). Applications should not contain their own encapsulated resolvers, let alone resolver…
They're trying to improve the security of a fundamental protocol - if we waited for committees every time we wanted something new, we wouldn't have HTTP2, HTML5 or a dozen other technologies.
I agree they shouldn't take away the "god-mode" /etc/hosts, which is only ever populated very intentionally by sysadmins and power users. If anything, that should be a flag just like the various modes of using TRR.
And finally - it's an open protocol in development, and anyone can set it up who wants to. If you don't want to use Google or Cloudflare, you don't have to. And FWIW millions of people are already using 8.8.8.8 and 1.1.1.1 and Cisco's OpenDNS as their primary resolver. That GOOG and CF are at the forefront of another increment of Internet standards should not be surprising.