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.
See you're missing something. If you as the local network operator can't block porn than neither can any intermediate ISP. It's not like they have any more power than you do.
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.
In the case of BYOD, if you're not okay with your kid having an Internet-connected device and that they're going to use it responsibly then don't give him/her one or only allow it under parental supervision. If we're carefully watching and teaching kids kids when they're handling knives or matches, why not do so with internet connected devices?
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.
It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.
I would go even further: Any app trying to bypass the system-level network settings (like with DoH) should be considered malicious and possibly malware.
This is what spam-bots used to do back in the days. Now let’s add Firefox to the list.
In which case these applications are either broken or malware.
The application needs to fix that by using DNS supplied by the OS, as everyone should do.
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).
As school network admin in another life I came to the conclusion that there is no limit to the ingenuity of pupils even at that age. And I'm just thinking that even big hitters like Netflix have problems properly filtering out VPN services and the likes. Anything-as-a-service makes it all the more accessible to anybody even for free.
Try to disable DOH if you can for now while you prepare something more permanent and resilient. Kids viewing pornographic material in school is a lawsuit waiting to happen I think.
Hopefully for BYOD parents will take a bit of the load off. At least tech savvy ones tend to make sure the device is properly "insulated". Plenty of lockdown options out there for this.
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.
You're thinking of configuring a custom DNS server, which is not related to the hosts file. The hosts file replaces DNS so there would be no network traffic to block.
Theoretically a kid who really wants his porn could manually add the name-to-IP entries for his favorite sites to his local hosts file, completely bypassing any DNS based filtering you might have on the network.
[0] https://dxr.mozilla.org/mozilla-release/source/modules/libpr...
[1] https://dxr.mozilla.org/mozilla-release/source/browser/app/p...
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Ent...
[3] https://support.mozilla.org/en-US/products/firefox-enterpris...
I guess a solution is MDM, but that's still getting students to install something on their device.
- Cry about it and hope they change the policy (they won't)
- Accept using your cell data at school instead of their wifi (works, but is expensive)
- Bypass it using a VM (requires moderate technical knowledge, networking skills and possibly the ability to bypass vm detection)
- Reverse engineer it and crack it to behave the way you want (requires some pretty advanced technical skills)
As such, the vast majority of people will just go ahead and install it. This is the problem with these sorts of applications...
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 easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of <random shop> in reach.
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.
It isn't. Sorry my sarcasm didn't come through clear enough, but what you're saying and disagreeing with is my point.
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.
However, I'm not completely heartless. I also run an open WiFi AP that, although limited, is available for guests who aren't comfortable with my security measures. You can't reach the rest of my network through it, but it's there and will get you internet access.
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...
I had thought that internal networks these days would favor multicast resolution (LLMNR/mDNS), but that doesn't appear to be the case here. Admin work is not my wheelhouse, so I have no idea what standard practice is. What is the recommended setup for AD and name resolution configuration?
I don't like this one either, but often it is inherited from the past from other people and it is not going to change.
On the other hand, split-horizon DNS is going to stay with us, even if the AD domain is a subdomain of the public one. Records in the internal zone are not going to become public anytime soon.
network.trr.mode
If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.
Of course DoH will break this and leak. Enterprises everywhere will hate this and ban Firefox.
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.
If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it, rather than trying to prevent them from learning where it is?
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.
You're free to do whatever you like with devices that you own and you're also free to have an acceptable use policy on your network but breaking security and privacy to accomplish it is the exact wrong way to go about it.
In my ideal world school BYOD devices would either not be allowed at or be given a private single-device VLAN with a direct unfiltered connection upstream, and made clear in policy that the school doesn't own, support, or control any aspect of them. No different whatsoever than students using their cellular connection.
Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.
Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.
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.
But I don't understand the network argument. If you are perfectly fine with TLS traffic then insisting on seeing DNS traffic sounds weird to me.
At the same time, if you force TLS traffic to go through a proxy then that will immediately restore visibility of DNS as well.
I guess network operators still have to come to terms with the idea that in the future all traffic will be encrypted.
Yes, it is annoying if you can't see anything in wireshark. But plain text is just a thing of the past.
Even better corps should only allow TLS that they can successfully MITM.
It's basic security. If the endpoint/host can do whatever due to lack of firewall/enforcement, then it doesn't really matter what the network operator wants.
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?
If a network operator can change DNS, then the ISP, network hops, or a malicious twin AP can as well.
The user of the OS can then set their own DNS. If applications just ignore this and use their own it takes away power from the user. Sure Firefox lets you turn it off, but a lot of people won’t bother.
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.
Instead I ended up with these lines in /etc/config/firewall:
config rule
option target 'ACCEPT'
option name 'Allow router to perform DNS'
option family 'ipv4'
option src_ip '192.168.1.1'
option dest_port '53'
option src '*'
option dest '*'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN'
option family 'ipv4'
option dest_ip '8.8.8.8'
option target 'REJECT'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN (2)'
option dest 'wan'
option family 'ipv4'
option dest_ip '8.8.4.4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN'
option dest_ip '1.1.1.1'
option dest_port '443'
option target 'REJECT'
option proto 'tcp'
option family 'ipv4'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (2)'
option proto 'tcp'
option dest 'wan'
option dest_ip '1.0.0.1'
option dest_port '443'
option family 'ipv4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (3)'
option dest_ip '104.16.249.249'
option family 'ipv4'
option dest 'wan'
option target 'REJECT'
Router itself acts as a DNS-server via dnsmasq, and is allowed to do anything I decide I want.
On my network I have a pi-hole instance which then forwards queries to the router, so it also intercepts/looks up local LAN names correctly.
All clients on the network are provided the pi-hole as the canonical DNS-server to use via DHCP options.
Works for me.
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.
Currently DoH or DoT are only used and designed with the goal[0] to secure stub resolver <-> recursive resolver traffic. Someone has to operate that recursive resolver and you have to trust them. So you only shift the problem from having to trust your ISP to having to trust cloudflare/google/etc.
Dnscurve is intended to secure the recursive resolver <-> authoritative traffic, which means you don't have to rely on another party to secure your traffic. I guess dns over dtls could in principle fill the same role, albeit with more overhead.
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.
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.
I believe it's possible to do both direct DNS over QUIC and ((DNS over HTTPS) over QUIC).
https://android-developers.googleblog.com/2018/04/dns-over-t...
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.”