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?
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.
0 - https://blog.stackpath.com/serverless-dns-over-https-at-the-...
There's no way we should take that information and centralise it into the hands of a few big providers. No matter how many pinky promises they make to not look at it.
Both of the above need to be urgently reined in to retain some sense of accountability and democracy. And these efforts including awareness are predominantly coming from outside the technical community.
When the problem is concentrated global monopolies and power how can centralizing more control be the solution? And yet these seem to be the only solutions from the community.
I work at a k12 school and I am involved on many k12 IT communities.
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.
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.
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.
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.
Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND removing Firefox from their computers.
The very least the new tech provides is that any silent helicopter parenting is becoming more visible and I'm grateful for that. Kids deserve internet privacy just as much as real-life privacy.
If you think that this is how it will go, you're very naive. If schools and parents can't block porn anymore, prepare for more legislation that blocks porn by default at the ISP unless you pay some kind of fee - like what the UK has proposed. Also look for a return of "content standards" for sites that want to be kept off the "porn list", like the old broadcast TV content standards.
And yeah the actual solution is "don't fucking give a six year old an Internet-connected device of any sort, obviously, you idiots" but they do, so monitoring and blocking are absolutely necessary.
What these schools need is to set up sensible group policies. Managing BYOD on a school with kids (as opposed to grown-up people whose jobs are on the line) is simply impossible.
This could become a major hassle if the number of devices and owners become large. There's not even a work around for this because I do not directly manage family members' devices (nor would they want me to).
I really like Firefox for they are the only real option these days. I use it and I encourage all those around me to use it. This change will require me to do a lot more manual work and likely lead to confusion over whether a service is down or not.
And whatever Gaming app the kids download? Suddenly it will become impossible to manage and maintain.
Not even talking about the troubleshooting nightmare.
DNS should be a system-level setting, not an App-level setting.
How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN?
ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed that to make this work, Mozilla / Google / etc. would serve DoH from the same IPs as some big services, so you wouldn't be able to block DoH without blocking something like Google's homepage.
OpenVPN isn't HTTPS based. It has TLS support, but AFAIK it's implemented as TLS-over-OpenVPN rather than OpenVPN-over-TLS, so it's still very distiquishable from a HTTPS connection. There are workarounds like using TCP mode over stunnel, though.
Won't prevent someone from setting up its own SSH-based proxy on port 443, but covers things that are accessible and easy to use by young students (talking about elementary school on our case).
Again, we are talking about a school network with young kids (under 12/13).
That's kind of the entire point of DoH. DNS-over-TLS (DoT) provides TLS encryption for DNS traffic, but runs over port 853 so network operators can control where queries go.
I guess a solution is MDM, but that's still getting students to install something on their device.
Firefox now has enterprise support where the administrator can force all desktops to use certain Firefox settings including enabling/disabling/configuring DoH.
See https://www.mozilla.org/en-US/firefox/enterprise/
And here's a link to details for configuration DNS over HTTPs. https://github.com/mozilla/policy-templates/blob/master/READ...
(I work at Mozilla)
DNS is a band-aid solution with side effects.
Worked in your arena for 5 years. Kids are creative and crafty. We had kids getting around the MDM/DNS blocks by changing the DNS/Proxy settings in their iPads. This is not easily overcome with existing MDM solutions AND letting the iPad be usable. BYoD is a whole different animal since you cannot legally "touch" their devices, you have to implement the federally-mandated blocks at the infrastructure level. Kids can use VPNs all day and there is nothing that can be done in reality.
At a previous job, believe it or not, I worked with a client with almost a zero budget who was having massive issues with malware/ads in their public space that offered free computer use. Being the budget was minimal (less and $100 to fix), I deployed two Pi-holes and taught the "admin" how to manage it. Cheap, effective, works. I set the whole thing up to fail back to the network's DNS should the Pi-holes fail. Still running almost two years later.
The Pi-hole can block about any content you would like it to block with almost zero-configuration. Easy to block a single domain or with a new rule set subscription.
Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.
The fact that it is enabling students (or anyone) to bypass restrictions is a good thing.
Why don't you try looking at this from another point of view. Firefox is a powerful important tool, and I want it to continue to be so, even if it is not ideal for everyone.
They deserve their internet privacy just as much as grown ups do even more so actually given their higher trust in others, if schools are scared of internet's dangers then schools should educate, not wrap kids into digital bubble wrap that will disappear when they leave school leaving them tech-illiterate and vulnerable.
If the school cannot be bothered to block content properly (ie, only via DNS block) then that is their own fault. The tools exist to block on an IP level.
For all computers the school owns, they SHOULD definitely do HTTPS MitM.
SNI filtering is a reasonable middle ground - it has its flaws but nowhere near invasive as full MITM filtering yet achieves most of the filtering objectives of the organisation. Ie it is “good enough”. Sadly ESNI may be the end of usefulness of this approach.
I expect that we'll see this sort of thing more and more.
As a consequence I would not use your network. This may also be considered success from your point-of-view.
DNS filtering was always easily circumvented; a time sucking cat and mouse game at best.
That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.
It's going to be particularly god-awful for devices that roam between networks where the "internal" DNS is visible and networks where it isn't. Ugh...
network.trr.mode
Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this to happen. 3 disables the system resolver.That’s part of the plan. From now everything is cloud only, and everyone doing anything differently gets thrown under the bus, with less and less control left for the user.
We’re progressing backwards into the future.
https://youtu.be/OxFFTxJv1L4?t=2799
After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.
Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that).
Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi-hole. Network at work is managed by yet-someone-else. I often use my mobile carrier (LTE tethering), and often use WiFi at coffee shops.
For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm 100% sure that my dns traffic today is being re-sold! I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.
Many DNS people are opposed DoH, but I think this train has passed. As a user of the internet I really do want encrypt everything these days. https://tools.ietf.org/html/rfc8404
If my corporate boss, or my ISP can mine less data about the malware I'm running - so be it. For me this is an acceptable cost of measurably improved privacy.
Not true.
They may be connecting directly by IP (it's typically not possible to determine if they did just from access logs). The web (or other application) server may also leak the name when connected to.
If you use TLS, which is likely, your domain names would leak through the certificate transparency logs.
...and there are surely more leak vectors than the above, so it's far from certain that the crawlers you see found their target by sniffing your DNS requests.
There are a number of other, perhaps more likely, reasons your hostnames have leaked.
Have you got any certificates for any of those names? Then they are in the public CT database which numerous people constantly scan for interesting data.
Are any of your DNS zones enumerable for some reason? Same thing. Any reverse DNS set up? What protocols and public services do you run? Do any expose hostnames in the protocol handshake? Then you are in the public Internet scan datasets.
As soon as you run any kind of SSL on any of your protocols your hostname is in the SNI header.
Host names are visible in a number of ways. It is best to consider them public data. I have seen a number of ISPs from the inside, and none of them has had any interesting in wiretapping their customer's DNS data. I'm not saying it doesn't happen, but it can't be very common. They have much more interesting data available to them should they want to go down that road.
But I am the owner of my own network, and DoH reduces my ability to protect it. That is the main (but not only) reason why I strongly object to DoH.
> I think this train has passed.
I suspect the battle has just begun. For example, my response to DoH has been to implement a MITM packet inspection system on my network to regain control over this. This means that DoH will not work from my network. I expect that we're going to see this sort of thing more and more.
Some schools already started to block Firefox from being installed 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.
There is a fine line between 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.
Unfortunately, on our school network, we also allow BYOD, so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.
Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.
That’s not a very good governance strategy.
>[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to some human rights violation team somewhere and so rather than tell you to use VPNs or tell you to use tor they decided to build DNS into the web
Requiring the average Joe to use a VPN service just so they can have some reasonable attempt at privacy isn't really an option, as we have seen. Privacy shouldn't be a luxury reserved only for those who can afford it. What I would really like to see is our lawmakers step up and make modern privacy laws with respect to technology and the data that results of it, but that clearly isn't happening. Unfortunately, DNS-over-HTTPS will very likely be used against the consumer in the long-run. Instead of using a pi-hole with port 53 blocked, I can see many devices will start using DNS-over-HTTPS to bypass those restrictions. Chromecast, rokus, and other devices already have hard-coded DNS addresses built-in, it won't be a very large step for them to switch to DNS-over-HTTPS to bypass my own network policies.
So the options are: * Make DoH illegal somehow * Take advantage of it as best we can
Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours.
DoH breaks that completely; and hence the network operator should have the final say.
As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine, I have to check which browser they use... that is the antithesis of the problem, because when DoH doesn't work but normal DNS does, then I'm flat out of options.
This is why I choose not to use Firefox or any of the DoH mainline providers (Cloudflare,) and I go out of my way to make sure users cant do it.
Dns over https creates more problems than it solves for 99% of end users.
And why is that an unreasonable position for a network operator to hold?
I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules.
Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.
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).
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.
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.
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.
DoH gains me nothing since I already tunnel the traffic to my resolver. What I really want is something like dnscurve.
1. content policies: blocking porn, censorship, etc (already easily circumvented by changing DNS or using a VPN)
2. preventing malware command and control: blocking domains that malware phones home to (already easily circumvented by including their own resolver, etc)
3. preventing malware infection: blocking domains serving malware (you might lump "ads" in this category too, e.x. Pi-hole)
IMHO the 3rd is the only use-case worth trying to solve with DNS blocking, because the user isn't actively trying to circumvent it.
Applications using their own resolvers do make that difficult to do. It seems like it would be best if operating systems implemented DoH at the system level, including DHCP support, so devices could use the network's DoH resolver which might do malware blocking.
Applications like Firefox could fall back to their own DoH resolver if they had a way to detect the system was not using DoH. This would also encourage network operators to support DoH.
They already do that. It’s called DNS.
I disagree. The problem with DoH is that it masquerades DNS lookups as web traffic. Other means of doing DNS lookups, encrypted or not, can be easily determined to be DNS lookups and handled according to the network policies.
By disguising the lookups as web traffic, it means that I can no longer leave web traffic alone. I have to MITM HTTPS now. If they were happening on their own ports, I would have less invasive methods available, such as running my own resolver.
The reason I made that statement has to do with the means by which DNS can easily be circumvented and direct encrypted connections used instead. This means using DNS introspection as a means for security doesn't buy you much, DoH just makes that more apparent.
I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root.
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.
I wonder if that would violate Mozilla's requirements?
Are ads considered "content"?
There is of course precedent for blocking undesirable content via DNS as a "service".
Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools.
This was offered as a fee-based service.
If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.
We have implemented DNS over HTTPS [RFC8484] and would like to
deploy it by default for our users. We intend to select a set of
Trusted Recursive Resolvers (TRRs) that we will use for DoH
resolution.
https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ...Presumably you can still configure your machine to use whichever resolver(s) you want.
The real question is if you're allowed to use your own resolver that conforms to your requirements if they differ from Mozilla's, even if a bit buried from the default list,
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.
Overall DoH is probably a net positive, but I don't see downsides like this being discussed.
Yeah, Erdoğan won't be able to block oppositions' web sites. That is a very big threat! /s
DOH can be implemented directly inside of the web browser application, since those browsers are obviously already doing everything over HTTPS. So the browser developers just have to build in a DNS client. From their perspective, I would see that being much simpler. And deployment is as easy as the next browser application update.
Are you sure? My experience so far has shown that only dnscrypt is widely supported.
Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it.
As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.
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?)
Recursive lookups from the resolver to authoritative DNS servers from the root down are not encrypted.
Really what you are doing is switching between telling your ISP all the domains you look up to telling Google/Cloudflare. Except your ISP can still see SNIs so you’re really just telling Google/Cloudflare in addition to your ISP.
I don't suppose there are any proposals to replace how SNIs are transmitted? (sans-vpn/tor, that is)
Does QUIC/HTTP[23] do anything different?
network.security.esni.enabled
https://blog.cloudflare.com/encrypt-that-sni-firefox-edition...
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)
Firefox will ignore your DNS settings and use his own (DoH)
The article talks about Firefox behavior when DoH is enabled. It's not enabled by default. The article doesn't say it's getting enabled by default, or under what conditions it might get enabled by default.
"Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH), a protocol which uses encryption to protect DNS requests and responses, with the goal of deploying DoH by default for our users."
https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ...
“4. The user will be informed that we have enabled use of a TRR and have the opportunity to turn it off at that time, but will not be required to opt-in to get DoH with a TRR.”