> Our plan is to select a set of Trusted Recursive Resolvers (TRRs) that we will use for DoH resolution in Firefox. Those resolvers will be required to conform to a specific set of policies that put privacy first.<p>So can I manually set one myself to my local pi-hole instance? I have already been setting the TRR about:config values (ala [0]), will that remain?<p>I am wary of Mozilla becoming the arbiter of acceptable DNS providers for me, so I should be able to override it if I want.<p>0 - <a href="https://blog.stackpath.com/serverless-dns-over-https-at-the-edge-doh" rel="nofollow">https://blog.stackpath.com/serverless-dns-over-https-at-the-...</a>
I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause:<p>I work at a k12 school and I am involved on many k12 IT communities.<p>Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS.<p>There is a fine line between protecting yourself from your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content.<p>Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.<p>The only other option is going to full HTTPS MITM, forcing a root SSL cert to all computers that use our network, which is the last thing that anyone wants to do.<p><i>Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND removing Firefox from their computers.</i>
Note that with DoH on Firefox, your intranet domains do not work. Had issues with it before and had to disable DoH just to access our company printer. Also causes issues with DC.<p>That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.
I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed:<p><a href="https://youtu.be/OxFFTxJv1L4?t=2799" rel="nofollow">https://youtu.be/OxFFTxJv1L4?t=2799</a><p>After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.
I’ve begun to think that differences of opinion on the benefits and/or negatives of DoH come from two different perspectives on what DNS is for.<p>What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will).<p>Whereas people who tend to want privacy and the other features of DoH, perceive it as an application level concern (layer 7). In this context connectivity and discoverability of services is the aim, and knowing that the information for establishing connections to those services is correct is important to the foundations and guarantees of applications being built to utilize DNS.<p>In the application and services context, you may not even want a single set of recursive resolves or authorities for the system. And the reasons are to help ensure the data is focused on what you need in different contexts.<p>I believe that the network level concerns over DoH are a little disingenuous, and this is because there are many ways to circumvent DNS, DoH isn’t necessary, you don’t even need DNS to establish layer3/4 connections. Fighting over DoH for security that can’t truly be enforced in DNS, seems misguided.
"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and <i>3) limiting any potential use of the resolver to block access or modify content.</i>"<p>I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root.<p>If someone aiming to be on the TRR list sets up a remote resolver that blocks ads (or replaces them with blank images) perhaps using the same technique, it could allow Firefox users to get ad blocking by default, by using DOH.<p>I wonder if that would violate Mozilla's requirements?<p>Are ads considered "content"?<p>There is of course precedent for blocking undesirable content via DNS as a "service".<p>Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools.<p>This was offered as a fee-based service.<p>If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.
This has negative implications for security. For instance, one reason why DNS resolvers might block or modify requests is to blacklist domains used for malware operation (botnet C&C domains). Other things like DNS sinkholing and poisoning are also frequently used as tools to disrupt malware communication.<p>In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which security researchers discover the infrastructure of botnet networks.<p>Overall DoH is probably a net positive, but I don't see downsides like this being discussed.
(It's been a long time since I've actually set up a DNS server and am pretty fuzzy on some details - so I'm going to state this like a real nooby to hopefully get an ELI5 answer)<p>If I were to set up my own DoH server, would its queries to upstream (root??) servers (and subsequent recursed servers) be encrypted? (Simpler: does running a DNS server "on-premise", or even in the cloud, actually protect you from anything?)
Has anyone started contributing lists of all the public DoH resolvers on any of the block-lists? e.g. [1] [2]<p>[1] - <a href="https://iplists.firehol.org/" rel="nofollow">https://iplists.firehol.org/</a><p>[2] - <a href="https://github.com/firehol/blocklist-ipsets" rel="nofollow">https://github.com/firehol/blocklist-ipsets</a>
Also you can encrypt SNI in Firefox, just enable<p>network.security.esni.enabled<p><a href="https://blog.cloudflare.com/encrypt-that-sni-firefox-edition/" rel="nofollow">https://blog.cloudflare.com/encrypt-that-sni-firefox-edition...</a>
What is the justification for an app to resolve domain names differently than the services the operating system provides? I am really curious why this is a thing.
Glad that they allowed resolvers that filter content based on the user request in there. So good news that Quad9 and CleanBrowsing will be able to make the list.
pretty cool, I wished chrome did that. firefox is probably going to choose cloudflare (1.1.1.1).<p>I wonder how this plays out with local DNS (e.g. my ISP has some custom domains for me to use, and internal company network addresses)