What’s Next in Making Encrypted DNS-over-HTTPS the Default(blog.mozilla.org)
blog.mozilla.org
What’s Next in Making Encrypted DNS-over-HTTPS the Default
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
190 comments
> DNS is used by ISPs to sell user's data
Claims like these keep surfacing in every discussion. While it is good to contemplate what your ISP spying on you would look like and what you can do to minimize that risk, it is not good to present this as normal behaviour.
From my perspective I am absolutely certain that this is not something that is routinely done, not in established ISPs in democratic countries. The risks would be far too great for a tiny income. Who would you sell to? The advertising networks have their own data sources, and even the web giants with billions of users and trackers embedded in pretty much every web page you visit can't charge much.
Even if you wanted to do this, DNS would be a low value target considering it is cached at every layer. Data mining sFlow logs, which is something every ISP would use anyway for diagnostic purposes, would give you better view of which kind of services users connect to and for how long.
So please don't normalize something that is at best a niche for bad actors. That can lead to decisions for end users, many of whom would be wiser not sending their data off to a foreign third party.
Claims like these keep surfacing in every discussion. While it is good to contemplate what your ISP spying on you would look like and what you can do to minimize that risk, it is not good to present this as normal behaviour.
From my perspective I am absolutely certain that this is not something that is routinely done, not in established ISPs in democratic countries. The risks would be far too great for a tiny income. Who would you sell to? The advertising networks have their own data sources, and even the web giants with billions of users and trackers embedded in pretty much every web page you visit can't charge much.
Even if you wanted to do this, DNS would be a low value target considering it is cached at every layer. Data mining sFlow logs, which is something every ISP would use anyway for diagnostic purposes, would give you better view of which kind of services users connect to and for how long.
So please don't normalize something that is at best a niche for bad actors. That can lead to decisions for end users, many of whom would be wiser not sending their data off to a foreign third party.
> DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do.
Your ISP may do this, but mine does not, so why should Mozilla get to dictate IT policy of my machine (i.e., ignoring resolve.conf)? Or policy of the company where I help run IT?
Your ISP may do this, but mine does not, so why should Mozilla get to dictate IT policy of my machine (i.e., ignoring resolve.conf)? Or policy of the company where I help run IT?
DNS is a plaintext protocol. It's a new technology. Technically this is better.
It reminds me of this silliness I sometimes hear:
"I need to use NAT with IPv6 to protect my network"
Firefox will allow you to set up a DNS rule locally that forces the client to use local dns, if you need it.
You can also configure a DNS over HTTPs server as your DNS.
If you help run IT and care about security. Then you should be blocking direct access to the internet anyway.
All your traffic should be going through a proxy server.
Also defaults should help those that are in weaker security positions. Just because you're lucky to have a good ISP doesn't mean that other people shouldn't be protected by default.
You're knowledgeable enough to configure your DNS, you just gotta learn something different.
It reminds me of this silliness I sometimes hear:
"I need to use NAT with IPv6 to protect my network"
Firefox will allow you to set up a DNS rule locally that forces the client to use local dns, if you need it.
You can also configure a DNS over HTTPs server as your DNS.
If you help run IT and care about security. Then you should be blocking direct access to the internet anyway.
All your traffic should be going through a proxy server.
Also defaults should help those that are in weaker security positions. Just because you're lucky to have a good ISP doesn't mean that other people shouldn't be protected by default.
You're knowledgeable enough to configure your DNS, you just gotta learn something different.
Not if one trusts more his/her ISP more than Cloudflare. At least, an ISP is a contractual partner and under the same jurisdiction, in Europe including GDPR.
For what it's worth, I trust Cloudflare an order of magnitude more than I trust my ISP (Comcast).
Being in the same jurisdiction is bad: your ISP is THE place for your local law enforcement to get info on your browsing.
Or if you run your own resolver and don't want a completely unrelated third party like Cloudflare siphoning your traffic.
This. And I already have to deal with smart appliances that try to contact their own DNS (I’m looking at you, Samsung) and that break if I force their requests through my own resolver.
This will just allow all applications and appliances to bypass my privacy measures.
This will just allow all applications and appliances to bypass my privacy measures.
I mean this is pretty much the end goal. It’s a Samsung owned, controlled, and managed device.
You as the local network operator are their adversary and it’s in Samsung’s every interest to bypass. They want and expect a clean connection to the internet. Giving it anything else is a problem to them.
If you’re installing one of these spyware devices in your network and relying on DNS to keep your information private then that’s on you when it doesn’t work. DoH neither creates nor solves human problems.
You as the local network operator are their adversary and it’s in Samsung’s every interest to bypass. They want and expect a clean connection to the internet. Giving it anything else is a problem to them.
If you’re installing one of these spyware devices in your network and relying on DNS to keep your information private then that’s on you when it doesn’t work. DoH neither creates nor solves human problems.
I paid for the TV, why do we accept this practice?
who will write the article about the weird world we live in, where the person who is mitm'ing the network connection is me, and it's the non-mitm'ed connection that is untrusted and worrying.
at this point i expect to see talk of “the VPN”, a new network for hobbyists and academics, that's kinda like the old internet, and we only use devices that are wrapped in it.
at this point i expect to see talk of “the VPN”, a new network for hobbyists and academics, that's kinda like the old internet, and we only use devices that are wrapped in it.
I was just thinking this. It's crazy: we used to all be concerned about protecting the transport (HTTPS/TLS) but now the bigger problem seems to be the endpoints themselves being untrustworthy--"smart" appliances, Google, Facebook, Mozilla and CloudFlare with DNS-over-HTTPS. Untrustworthy endpoints using secure transport to hide malintent.
Take a look at Privoxy.
It's mostly useless now with everyone defaulting to HTTPS unless you install a root certificate on all your devices.
It's mostly useless now with everyone defaulting to HTTPS unless you install a root certificate on all your devices.
This is actually what I'm doing.
With some additional duct tape[1] I made privoxy work on https too. I run an instance for each host, though it could be possible to distribute a personal CA certificate.
[1]: https://maxwell.ydns.eu/git/rnhmjoj/privoxy-tls
With some additional duct tape[1] I made privoxy work on https too. I run an instance for each host, though it could be possible to distribute a personal CA certificate.
[1]: https://maxwell.ydns.eu/git/rnhmjoj/privoxy-tls
Cloudflare would also be under GDPR as it serves customers in EU.
Well, DoH effectively bypass DNS-filters set up by countries. While some are questionable, I believe it won't take long until Mozilla ends up with some bad press, and being an underdog it doesn't need that.
> But this is a win overall for privacy.
> DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do.
It's not a win for privacy, ISPs will still have that data and now third parties will have that data, state actors will have that data in a nice convenient centralized locations, governments will have an ability to force those centralized providers to do censorship for them. As for oppressive regimes - they don't care about DNS data, if they want to spy on people, they will one way or another.
> DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do.
It's not a win for privacy, ISPs will still have that data and now third parties will have that data, state actors will have that data in a nice convenient centralized locations, governments will have an ability to force those centralized providers to do censorship for them. As for oppressive regimes - they don't care about DNS data, if they want to spy on people, they will one way or another.
DoH does not imply centralization in any way. Any trusted party can provide their own DoH endpoint. I can run my own DoH server on a cheap VPS hosted in another country.
I live in an increasingly oppressive regime. Most of the blocking is done at DNS level. DoH is a great solution. Slamming DoH because they can anyway spy one way or another is a poor argument.
I live in an increasingly oppressive regime. Most of the blocking is done at DNS level. DoH is a great solution. Slamming DoH because they can anyway spy one way or another is a poor argument.
The issue is each application implementing DoH themselves. Now any software which you wish to use your own DoH resolver would have to be configured individually.
A better solution would have been for Mozilla to fund development of an enduser friendly DNS proxy application which would enable DoH system wide.
A better solution would have been for Mozilla to fund development of an enduser friendly DNS proxy application which would enable DoH system wide.
The ideal solution would be something that can be installed in any home router, but that's a non-starter because of total lack of home router configuration standards. Flashing a router is not user-friendly for anybody.
The next best solution would be your suggestion, but that too is not practical unless it comes preinstalled on all OSes because the average user won't even know they need something called a DNS proxy. I don't see OS vendors agreeing to preinstall it. Additionally, AFAIK, popular OSes like Android and iOS prior to some versions don't even allow such system-wide DNS proxy configurations.
The practical approach left then is to implement it in browsers, solving it at least for the most common use case on all devices. Everybody knows how to download and install and use browsers. In a discussion forum I frequent, average users ask for ISP censorship bypass solutions all the time. Since Chrome does not support DoH yet, among all the possible solutions - VPN, Tor, SSHproxy - using another browser is actually the most user-friendly, least expensive, most performant option. It helps that it's Mozilla's product because their trust perception is higher than Google/MS/Apple/VPN providers.
I feel Mozilla's taken a good approach overall within the scope of their area of expertise.
The next best solution would be your suggestion, but that too is not practical unless it comes preinstalled on all OSes because the average user won't even know they need something called a DNS proxy. I don't see OS vendors agreeing to preinstall it. Additionally, AFAIK, popular OSes like Android and iOS prior to some versions don't even allow such system-wide DNS proxy configurations.
The practical approach left then is to implement it in browsers, solving it at least for the most common use case on all devices. Everybody knows how to download and install and use browsers. In a discussion forum I frequent, average users ask for ISP censorship bypass solutions all the time. Since Chrome does not support DoH yet, among all the possible solutions - VPN, Tor, SSHproxy - using another browser is actually the most user-friendly, least expensive, most performant option. It helps that it's Mozilla's product because their trust perception is higher than Google/MS/Apple/VPN providers.
I feel Mozilla's taken a good approach overall within the scope of their area of expertise.
DNS-based censorship doesn't work well enough for governments to be useful, it's always just a first step towards much more aggressive censorship tech. You should not advice people to use DoH to circumvent censorship, Tor is a decent longer term solution, and so are private VPNs, proxies.
Although I find it suspicious that there is just DNS filtering on your ISPs side and no IP filtering. Is it at the stage where it's not even enforced, semi-voluntary censorship by ISPs? Otherwise once the government starts checking compliance it will force IP-based filtering too, where DNS filtering circumvention is useless. And governments don't care about how broad the filtering is. Russia, for example, blocked half of the internet once in an attempt to censor Telegram.
Although I find it suspicious that there is just DNS filtering on your ISPs side and no IP filtering. Is it at the stage where it's not even enforced, semi-voluntary censorship by ISPs? Otherwise once the government starts checking compliance it will force IP-based filtering too, where DNS filtering circumvention is useless. And governments don't care about how broad the filtering is. Russia, for example, blocked half of the internet once in an attempt to censor Telegram.
It is semi-voluntary and I don't think it's enforced for now - not heard of any end user getting punished by government for circumventing.
DoH is a simple solution that works for now. TorBrowser takes it to the other extreme - it's a good secure solution (I think), but not required as of now, and seen as slow with plugin and other usage restrictions. VPNs, proxies are not seen as good solutions because people prefer free to paid, and they are not as trusted as CF and Mozilla. Self-managed VPNs/proxies are not easy for the average person to setup.
DoH is a simple solution that works for now. TorBrowser takes it to the other extreme - it's a good secure solution (I think), but not required as of now, and seen as slow with plugin and other usage restrictions. VPNs, proxies are not seen as good solutions because people prefer free to paid, and they are not as trusted as CF and Mozilla. Self-managed VPNs/proxies are not easy for the average person to setup.
Meanwhile, dnscrypt-proxy, that has been doing exactly that since 2011, is still looking for help with developing MacOS and Android user interfaces.
The article is not clear about one issue: are all applications expected to disregard the OS DNS? Is there an option to tell all applications that they should not bypass it?
I will be pretty pissed if I wake up one day and find that Firefox decided to stop using my DNS server and instead started sending my requests to a third-party.
I will be pretty pissed if I wake up one day and find that Firefox decided to stop using my DNS server and instead started sending my requests to a third-party.
That's exactly what their plan is -- and if you have experiments enabled, they may have already started sending your DNS queries to Cloudflare.
I guess thats Mozillas new monetizing strategy, sell user data to cloudflare, and market it as privacy.
If you want privacy you better firewall everything your computer want to send to Cloudflare, Akamai, et.al.
If you want privacy you better firewall everything your computer want to send to Cloudflare, Akamai, et.al.
>...sell user data to cloudflare...
Cloudflare claims they "will never sell your data or use it to target ads."
You can read their 1.1.1.1 privacy policies here:
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Cloudflare claims they "will never sell your data or use it to target ads."
You can read their 1.1.1.1 privacy policies here:
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
Mozilla have a special deal with Cloudflare. According to Mozilla it will give even more privacy. It also seem that there is no money involved? So hopefully Mozilla is not selling DNS like they sell search. But I still think its a bad idea to centralize DNS and send all dns request to one actor, then it becomes very easy for anyone like the US gov to collect the data.
Then there is also performance. While Cloudflare has great coverage, using your ISP DNS will be much faster, due to it being physically closer in the network and using a more simple protocol.
That does not say they cannot use it for other purposes.
It says what they use, how they use it, how they won’t use it, who can use what (APNIC or if required by law), and how long they retain what. Your comment is misleading.
And policies never change. There is never a change of management, especially after a company goes public (which CF is planning to do). /s
Like what? Fixing bugs in their service?
Good luck with blocking Cloudflare and Akamai and still using the internet.
Which is why some people, like Paul Vixie (no DNS dummy, he), think that this is an absolutely terrible idea.
Mozilla is now basically dictating policy to organizations.
Mozilla is now basically dictating policy to organizations.
It's not that bad. Done it before. It's as if some sites are more like other paywalled sites.maybe noscript trained me well for it.
The article explicitly mentions the way to tell applications including Firefox not to disregard the OS DNS: blocking a canary domain. It even links to detailed instructions.
Frankly, given how much trouble I've had with systemd's DNS meddling, I look forward to applications taking DNS under their own control.
Frankly, given how much trouble I've had with systemd's DNS meddling, I look forward to applications taking DNS under their own control.
> blocking a canary domain
And how long will it take for most ISPs to block this domain when they realize that their DNS servers are not being used anymore? Some of them sell this data so they see it as a source of revenue.
At this point this canary domain will have the same fate as Do Not Track.
> I look forward to applications taking DNS under their own control.
I am sure I can find a hundred applications/programs resolving domains on my machine. It is unrealistic to configure all of them separately. At this point we are back to the OS providing the configuration for all of them.
And how long will it take for most ISPs to block this domain when they realize that their DNS servers are not being used anymore? Some of them sell this data so they see it as a source of revenue.
At this point this canary domain will have the same fate as Do Not Track.
> I look forward to applications taking DNS under their own control.
I am sure I can find a hundred applications/programs resolving domains on my machine. It is unrealistic to configure all of them separately. At this point we are back to the OS providing the configuration for all of them.
They already stated in the article that if the canary domain will be abused they will disable that check.
Yeah. Sounds like another do-not-track then.
I’ll keep my firewall-rules banning all DoH-traffic to Cloudflare, just in case.
I’ll keep my firewall-rules banning all DoH-traffic to Cloudflare, just in case.
I suppose you can block the IP 1.1.1.1, but Google serves THEIR DNS at `google.com` on HTTPS port. One of the design choices of DoH to make it look like HTTPS traffic.
It's gonna be difficult to block DoH traffic.
It's gonna be difficult to block DoH traffic.
> One of the design choices of DoH to make it look like HTTPS traffic.
Wait until encrypted SNI gets implemented everywhere was well.
Wait until encrypted SNI gets implemented everywhere was well.
Not a bad call, I guess.
It's a bad idea what it end up starting a cycle where every big application uses their own DNS. Some of them might not wven do it right
Do you mean Network manager? AFAIK systemD does not meddle with dns.
And there's a rather short conf.d stub you can create that disables NM's meddling with resolv.conf.
And there's a rather short conf.d stub you can create that disables NM's meddling with resolv.conf.
> Firefox decided to stop using my DNS server
In an ideal world, your probably want some sort of encrypted connection to your own DNS server (unless your LAN is 100% trusted). Maybe something like HTTPS would work... oh wait.
Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).
DNS over HTTPS seems like a net win for both types of users. Power users like you get way to encrypt your DNS traffic, and non-technical users get an encrypted connection to a potentially less-hostile DNS server. It sucks that there is now a second place to configure things, but hopefully seeing this work well will put pressure on the OS to adopt DNS over HTTPS natively, bringing the experiment to its final goal (at least, I assume this is the endgame).
In an ideal world, your probably want some sort of encrypted connection to your own DNS server (unless your LAN is 100% trusted). Maybe something like HTTPS would work... oh wait.
Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).
DNS over HTTPS seems like a net win for both types of users. Power users like you get way to encrypt your DNS traffic, and non-technical users get an encrypted connection to a potentially less-hostile DNS server. It sucks that there is now a second place to configure things, but hopefully seeing this work well will put pressure on the OS to adopt DNS over HTTPS natively, bringing the experiment to its final goal (at least, I assume this is the endgame).
> Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).
I know perfectly well who operates my DNS server: My ISP. If they are doing shady stuff, I can sue them, raise awareness or switch providers.
I can't do the same with hardwired DoH endpoints.
I know perfectly well who operates my DNS server: My ISP. If they are doing shady stuff, I can sue them, raise awareness or switch providers.
I can't do the same with hardwired DoH endpoints.
My ISP, at&t, sells my dns queries by default. I turned it off in the account privacy settings, but I still dont trust them and they are the only ISP that serves my house. As well, firefox lets you choose your dns over https provider in settings, its hardly "hardwired".
It's easier to switch ISPs than it is to just configure FireFox to use some other DoH provider?
So now we need to worry about making custom DNS config for every single app on a computer?! It’s absurd.
Does your OS allow you to configure global DNS-over-HTTPS settings? Then you can hardly blame apps for not importing them.
Yes, getting rid of shitty old standards means we have to live with multiple in parallel for a while and in the mean time bear additional complexity/work. Otherwise civilization will never advance.
Yes, getting rid of shitty old standards means we have to live with multiple in parallel for a while and in the mean time bear additional complexity/work. Otherwise civilization will never advance.
My OS (glibc, specifically) provides a way to resolve names (gethostbyname) using various means (hosts file, mDNS, DNS, directory service) configured by nsswitch.conf. Some distributions (e.g. Ubuntu) even move this to a separate daemon (systemd-resolved) which does stuff like DNSSEC validation and DNS-over-TLS (DNS-over-HTTPS is not (yet) supported natively, you need an extra program for this). I don't think moving common functionality from the OS into individual applications is "getting rid of shitty old standards", we will end up with multiple duplicated implementations.
I agree, an common, likely OS provided API to resolve names is in the theory the best way to go. Not least because it allows OS vendors to replace the implementation with more modern and secure variants over time by pushing sane standards. Sadly they didn't do their job and most DNS is still un-encrypted. Eventually others comes along and do it by themselves. Obviously not on the OS level, since they don't have control over that.
Yes, "multiple duplicated implementations" is the natural consequence of badly maintained software. But eventually I'd hope OS maintainers get their act together and implementations will start to converge again.
Yes, "multiple duplicated implementations" is the natural consequence of badly maintained software. But eventually I'd hope OS maintainers get their act together and implementations will start to converge again.
I feel like that’s a slippery slope that will probably never happen. Most likely you’ll have to configure your browser(s) and that’s it.
And how the hell is split-horizon DNS supposed to work if resolve.conf is ignored?
This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those?
Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DNS "should" work?
This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those?
Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DNS "should" work?
This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.
Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened?
I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free.
Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.
Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened?
I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free.
Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.
I think the underlying issue is absolutely a power struggle.
Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration.
In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network.
By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine.
This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself.
To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer.
I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.
I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.
Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration.
In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network.
By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine.
This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself.
To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer.
I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.
I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.
Wow, I had not considered the deeper power shifts from this perspective.
The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody.
Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option.
"My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems.
I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.
The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody.
Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option.
"My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems.
I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.
> ... but encryption is useless unless you know who you are talking to.
False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass":
* https://en.wikipedia.org/wiki/Room_641A
* https://en.wikipedia.org/wiki/PRISM_(surveillance_program)
For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C.
I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption:
* https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header
There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire.
The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.
False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass":
* https://en.wikipedia.org/wiki/Room_641A
* https://en.wikipedia.org/wiki/PRISM_(surveillance_program)
For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C.
I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption:
* https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header
There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire.
The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.
Sorry, I don't understand why this is. Can you not just set up your own DoH server, or use your ISP's (perhaps automatically via DHCP)? How is that different from what happens now, except the traffic is now encrypted?
To my knowledge, one of the defining characteristics of DoH is that it's not configured by the network.
There is a default setting managed by Mozilla which the vast majority of users are expected to use (currently Cloudflare's resolver). You can choose to disable DoH or set your own resolver - however that has to be done manually for every installation of Firefox.
Mozilla is offering a way for networks to signal "don't use DoH here" as described in this article, but Mozilla is intending this to be used for certain specific scenarios only (parental controls and corporate networks) and reserves the right to ignore the signal if it is misused.
To my knowledge, there is no "DoH" entry in DHCP, where a network could specify a local DoH resolver. All articles I've read about it also very much treat it like an application-level protocol, as opposed to the old mechanism where resolution was done centrally by the OS. If this approach is continued, then every application would have to decide for itself which resolver it uses.
There is a default setting managed by Mozilla which the vast majority of users are expected to use (currently Cloudflare's resolver). You can choose to disable DoH or set your own resolver - however that has to be done manually for every installation of Firefox.
Mozilla is offering a way for networks to signal "don't use DoH here" as described in this article, but Mozilla is intending this to be used for certain specific scenarios only (parental controls and corporate networks) and reserves the right to ignore the signal if it is misused.
To my knowledge, there is no "DoH" entry in DHCP, where a network could specify a local DoH resolver. All articles I've read about it also very much treat it like an application-level protocol, as opposed to the old mechanism where resolution was done centrally by the OS. If this approach is continued, then every application would have to decide for itself which resolver it uses.
Is this by design/intention, or just because DoH hasn't caught on yet so Mozilla is setting a sane default here?
I can see how it would be a drawback if the network administrator had no way to configure the setting for all clients.
I can see how it would be a drawback if the network administrator had no way to configure the setting for all clients.
The network administrator shouldn’t be able to change any setting at all on client devices. That’s the point! If you can just direct clients to a malicious DoH server then the project has largely failed.
The device administrator should be the one making the choice about what resolvers to use.
The device administrator should be the one making the choice about what resolvers to use.
I agree: the device administrator should be in charge. Essentially, I see this conversation as having spun into an awkward regime where there is an implicit and entirely incorrect assumption here that the options are 1) the network configures the DNS setup and 2) individual apps configure their DNS setup; what happened to 3) the owner of the computer (the device administrator) configures their DNS setup?
The status quo implementation has been that the operating system handled DNS, which actually did put the power in the hands of the device administrator: I don't think I have ever seen a device that wasn't clearly owned under some crazy MDM scheme where you couldn't choose your own DNS servers. Sure: recently, it happened to have a default to trust the network... but that was just a convenience, and is a "new phenomenon" brought on by DHCP being widely deployed. All of the software wasn't designed with that as an assumption.
So, if I want DoH, why am I not just setting up a custom resolver on my computer, that all of my apps use, including Firefox? The "power struggle" alluded to up-thread is actually much deeper: it is using network operators as an excuse to take power away from users, by moving what used to be an operating system feature into individual applications in a world where DRM via code signature is being deployed to lock users into curated application domains to prevent them from modifying that software to do what they want.
(That said, I mean... the way Firefox implemented this totally still gives the network administrator control, due to the opt-out provision? So in some sense a lot of this conversation is useless... for now.)
The status quo implementation has been that the operating system handled DNS, which actually did put the power in the hands of the device administrator: I don't think I have ever seen a device that wasn't clearly owned under some crazy MDM scheme where you couldn't choose your own DNS servers. Sure: recently, it happened to have a default to trust the network... but that was just a convenience, and is a "new phenomenon" brought on by DHCP being widely deployed. All of the software wasn't designed with that as an assumption.
So, if I want DoH, why am I not just setting up a custom resolver on my computer, that all of my apps use, including Firefox? The "power struggle" alluded to up-thread is actually much deeper: it is using network operators as an excuse to take power away from users, by moving what used to be an operating system feature into individual applications in a world where DRM via code signature is being deployed to lock users into curated application domains to prevent them from modifying that software to do what they want.
(That said, I mean... the way Firefox implemented this totally still gives the network administrator control, due to the opt-out provision? So in some sense a lot of this conversation is useless... for now.)
Network administrators don't have power over device administrators, so the premise is a bit false. Device administrators are the network administrators on their own devices.
> Network administrators don't have power over device administrators ...
They (possibly) do when they're both under the same Director of IT.
Security is everyone's responsibility in an organization, and the folks in Helpdesk (ideally) want to prevent intrusions just as much as the NetOps folks.
They (possibly) do when they're both under the same Director of IT.
Security is everyone's responsibility in an organization, and the folks in Helpdesk (ideally) want to prevent intrusions just as much as the NetOps folks.
> The device administrator should be the one making the choice about what resolvers to use.
No, the device owner should be the one. Which could the company/organization that bought the device in the first place, in which case that is delegated to the IT team.
And if the IT team does not want DoH, it is the IT team that gets the final word.
Mozilla has been nice enough to give options to disable that, and that can easily be done with GPOs on Windows, but not all the world is Windows, and if you have a large Mac or Linux use base that uses Firefox, how will disabling DoH be automated there?
And just because Mozilla has been nice enough, does not mean that other developers will be.
No, the device owner should be the one. Which could the company/organization that bought the device in the first place, in which case that is delegated to the IT team.
And if the IT team does not want DoH, it is the IT team that gets the final word.
Mozilla has been nice enough to give options to disable that, and that can easily be done with GPOs on Windows, but not all the world is Windows, and if you have a large Mac or Linux use base that uses Firefox, how will disabling DoH be automated there?
And just because Mozilla has been nice enough, does not mean that other developers will be.
Right? Because the core issue is that browser vendors (and eventually probably OS vendors) do not trust the local network operator. There will be GPO’s and Jamf profiles, and Ansible playbooks to configure this setting for the swarm of machines you ‘own’ but you are simply not a trusted party to any person that connects to your Wi-Fi access point.
> I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.
Tell that to the health and financial regulatory regimes that us some of have to work under to ensure people's privacy is respected. I work in health care, and we have data-at-rest and -in-motion encryption and firewalls and application-level ACLs & permissions all over the place in our internal network.
Not being able to resolve internal-only systems, which have absolutely no need/business being in external DNS, because of a change in behaviour in client software is just dumb.
People complain about the stupidity of (e.g.) power plant controls being directly connected to the Internet, or not being air gapped from the folks in Accounting, but then we seem to have developers writing software that will not work very well in these isolated/island networks.
I'm all for the general end-to-end principal (that IPv6 may help bring back) with protection being done by stateful firewalls, but there are all sorts of use cases for private, isolated networks that are behind NAT/NPT gateways that are given ULA addresses.
Tell that to the health and financial regulatory regimes that us some of have to work under to ensure people's privacy is respected. I work in health care, and we have data-at-rest and -in-motion encryption and firewalls and application-level ACLs & permissions all over the place in our internal network.
Not being able to resolve internal-only systems, which have absolutely no need/business being in external DNS, because of a change in behaviour in client software is just dumb.
People complain about the stupidity of (e.g.) power plant controls being directly connected to the Internet, or not being air gapped from the folks in Accounting, but then we seem to have developers writing software that will not work very well in these isolated/island networks.
I'm all for the general end-to-end principal (that IPv6 may help bring back) with protection being done by stateful firewalls, but there are all sorts of use cases for private, isolated networks that are behind NAT/NPT gateways that are given ULA addresses.
> When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.
What weakness?
> As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption.
Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018).
Why does yet another protocol have to be shoehorned into HTTP(S)?
What weakness?
> As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption.
Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018).
Why does yet another protocol have to be shoehorned into HTTP(S)?
It's amazing that you have such strong opinions about an article you didn't even bother to read.
First, they detect split horizon situations and explain how.
Second, if you as an admin want to force disable DoH across the network, they've provided a DNS-based way to do so.
Third, if this really bothers you, Mozilla provides GPO templates (and JSON based methods for other OSes) to configure all of these settings at an application level.
Maybe focus that outrage energy on reading the article before posting?
First, they detect split horizon situations and explain how.
Second, if you as an admin want to force disable DoH across the network, they've provided a DNS-based way to do so.
Third, if this really bothers you, Mozilla provides GPO templates (and JSON based methods for other OSes) to configure all of these settings at an application level.
Maybe focus that outrage energy on reading the article before posting?
Mozilla may be kind enough to have those settings, but that doesn't mean other software will do the same thing.
It's nice that Mozilla may allow setting other DNS servers for DoH, and perhaps will eventually use OS-level settings, but what happens when some dumb ass developer does not?
Perhaps if they implemented DNS-over-TLS (DoT) instead/as well, then we could have encrypted DNS that is still monitorable.
I'm waiting for the day when malware will start using DoH and use Cloudflare as the DNS server. As someone who works in IT, will I have to block CF to prevent that possibility? How many bots have been taken down over the years because their C&C domains were taken over?
It's nice that Mozilla may allow setting other DNS servers for DoH, and perhaps will eventually use OS-level settings, but what happens when some dumb ass developer does not?
Perhaps if they implemented DNS-over-TLS (DoT) instead/as well, then we could have encrypted DNS that is still monitorable.
I'm waiting for the day when malware will start using DoH and use Cloudflare as the DNS server. As someone who works in IT, will I have to block CF to prevent that possibility? How many bots have been taken down over the years because their C&C domains were taken over?
The silly assumption being made here is that "DoH" = "talk HTTPS to Cloudflare". I want DoH, but I need private domains. I would like to talk DoH to a thing I control.
It should be Opt-In.
Not Opt-Out.
Not Opt-Out.
> unless your LAN is 100% trusted
For 99% of the people out there, it is.
Can Mozilla stop interfering with my network and get back to doing useful things with Firefox now?
For 99% of the people out there, it is.
Can Mozilla stop interfering with my network and get back to doing useful things with Firefox now?
No kidding. Bypassing all the ad/malware domains in my HOSTS file, which practically all other applications on the system respect, feels disturbingly shady. Where's my privacy now!?!?
If Mozilla wants to, they are more than welcome to work on encrypted DNS or VPNs or whatever else, but those should be at the OS level. Disrepecting configured OS settings borders on actively malicious behaviour.
If Mozilla wants to, they are more than welcome to work on encrypted DNS or VPNs or whatever else, but those should be at the OS level. Disrepecting configured OS settings borders on actively malicious behaviour.
How exactly do you expect Mozilla to "work on encrypted DNS at the OS level"? How does Mozilla make Microsoft/Apple/Google implement it?
How do you think people write VPN clients? Encrypted DNS is very much within that category of software.
How does Mozilla make Microsoft/Apple/Google implement it?
It doesn't need to, the same way it doesn't need to (nor should it) make Microsoft/Apple/Google ship Firefox as the default browser.
How does Mozilla make Microsoft/Apple/Google implement it?
It doesn't need to, the same way it doesn't need to (nor should it) make Microsoft/Apple/Google ship Firefox as the default browser.
> For 99% of the people out there, it is.
99% of the people out there never connect to wifi in coffeeshops?
I'm not even sure you hit the 99% mark if you measure by time spent connected, though I would love to see some data.
(Disclaimer: I work for Mozilla, but have not really been involved with DoH.)
99% of the people out there never connect to wifi in coffeeshops?
I'm not even sure you hit the 99% mark if you measure by time spent connected, though I would love to see some data.
(Disclaimer: I work for Mozilla, but have not really been involved with DoH.)
Mozilla can only speak for their applications and they seem to eventually intend Firefox to use DoH as default and fallback to OS DNS under various failure conditions some of which are mentioned in the post. They also say:
"When DoH is enabled, users will be notified and given the opportunity to opt out."
"When DoH is enabled, users will be notified and given the opportunity to opt out."
> Is there an option to tell all applications that they should not bypass it?
Yes there is. If your internal recursive DNS servers return an NXDOMAIN for "use-application-dns.net", then Firefox will stick with gethostbyname(3) (or whatever). See:
* https://support.mozilla.org/en-US/kb/configuring-networks-di...
If you’re using NLnet’s unbound(8) as a recursive DNS server, it’s possible to use the “local-zone” directive to force an NXDOMAIN:
* https://serverfault.com/questions/625170/
For ISC’s BIND, the response policy zone (RPZ) mechanism does something similar on BIND 9.8+ (it’s more flexible, so more complicated to configure):
* https://jpmens.net/2011/04/26/how-to-configure-your-bind-res...
* https://downloads.isc.org/isc/bind9/9.9.5/doc/arm/Bv9ARM.ch0...
* https://dnsrpz.info
* https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz
* http://www.zytrax.com/books/dns/ch7/rpz.html
* https://serverfault.com/questions/618106/set-up-bind9-as-dns...
Yes there is. If your internal recursive DNS servers return an NXDOMAIN for "use-application-dns.net", then Firefox will stick with gethostbyname(3) (or whatever). See:
* https://support.mozilla.org/en-US/kb/configuring-networks-di...
If you’re using NLnet’s unbound(8) as a recursive DNS server, it’s possible to use the “local-zone” directive to force an NXDOMAIN:
* https://serverfault.com/questions/625170/
For ISC’s BIND, the response policy zone (RPZ) mechanism does something similar on BIND 9.8+ (it’s more flexible, so more complicated to configure):
* https://jpmens.net/2011/04/26/how-to-configure-your-bind-res...
* https://downloads.isc.org/isc/bind9/9.9.5/doc/arm/Bv9ARM.ch0...
* https://dnsrpz.info
* https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz
* http://www.zytrax.com/books/dns/ch7/rpz.html
* https://serverfault.com/questions/618106/set-up-bind9-as-dns...
>Are all applications expected to disregard the OS DNS?
I hope so if OS continues to use plaintext (none secure) DNS queries.
I hope so if OS continues to use plaintext (none secure) DNS queries.
At first, I was sceptical of DNS over HTTPS and thought that it gave Cloudflare, who already control too much access over the internet, even more control.
However, other DNS providers are available. For instance Google[1] and Quad 9 [2] both provide free DNS over HTTPS services.
[1] https://developers.google.com/speed/public-dns/docs/doh/
[2] https://www.quad9.net/doh-quad9-dns-servers/
However, other DNS providers are available. For instance Google[1] and Quad 9 [2] both provide free DNS over HTTPS services.
[1] https://developers.google.com/speed/public-dns/docs/doh/
[2] https://www.quad9.net/doh-quad9-dns-servers/
There are many more secure public resolvers than Google and Quad9 : https://dnscrypt.info/public-servers
> For instance Google[1] and Quad 9 [2] both provide free DNS over HTTPS services.
Using Google is giving your browsing history to an Ad company, why? At least Quad9 is non-profit. It also provides DNS over TLS, DoT service, which I'm using.
Using Google is giving your browsing history to an Ad company, why? At least Quad9 is non-profit. It also provides DNS over TLS, DoT service, which I'm using.
Because with Google you only have to trust one organization that flat out says in the FAQ that they do not "correlate or combine information from temporary or permanent logs with any personal information that [you] have provided Google for other services".
Quad9 is a conglomorate of "Threat Intelligence Partners" and three founding organizations: IBM, Packet Clearing House and Global Cyber Alliance https://www.quad9.net/about/ . What's that third one? I don't know, but it's founded by The City of London Police, NY District Attorney and the Center for Internet Security https://www.globalcyberalliance.org/who-we-are/ that third one is like a hundred "Partners", with such privacy champions as The US Secret Service. Over 100 organizations. What are their incentives? What role do all these organization play and how much access do they have? Who knows.
Compare their privacy policies. They're strikingly similar because Quad9 largely lifted theirs from Google's (I'm assuming, since theirs came later)
https://developers.google.com/speed/public-dns/privacy
https://www.quad9.net/policy/
Google's policy states they collect private information for 24-48 hours, keep "anonymized" information for 2 weeks and then randomly samples that data for permanent storage:
> Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.
> We delete these temporary logs within 24 to 48 hours.
> In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.
Quad9 collects effectively the same information (except AS) as Google's 2 week logs and says
> All the above data may be kept in full or partial form in permanent archives.
If you want a game theoretic, capitalist analysis, Google has an incentive to keep the web running and keeping it an awesome platform, to make sure humanity's information is created and shared in an open format that they know how to index and that they can freely index, instead of apps or some alternative web or some other walled garden.
But we're bombarded daily with "goog bad" by politicians and journalists, so Google must obviously be just brazenly lying and you should give your DNS history to an organization founded by The City of London Police instead that "share anonymized data on specific domains queried [...] with its threat intelligence partners".
Please double check my work, I didn't read the privacy policies too carefully (I think notably Google stores the AS number and Quad9 doesn't) because I don't actually care, I (along with roughly 100% of internet users) just give all my DNS history in plain text to my ISP.
Quad9 is a conglomorate of "Threat Intelligence Partners" and three founding organizations: IBM, Packet Clearing House and Global Cyber Alliance https://www.quad9.net/about/ . What's that third one? I don't know, but it's founded by The City of London Police, NY District Attorney and the Center for Internet Security https://www.globalcyberalliance.org/who-we-are/ that third one is like a hundred "Partners", with such privacy champions as The US Secret Service. Over 100 organizations. What are their incentives? What role do all these organization play and how much access do they have? Who knows.
Compare their privacy policies. They're strikingly similar because Quad9 largely lifted theirs from Google's (I'm assuming, since theirs came later)
https://developers.google.com/speed/public-dns/privacy
https://www.quad9.net/policy/
Google's policy states they collect private information for 24-48 hours, keep "anonymized" information for 2 weeks and then randomly samples that data for permanent storage:
> Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.
> We delete these temporary logs within 24 to 48 hours.
> In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.
Quad9 collects effectively the same information (except AS) as Google's 2 week logs and says
> All the above data may be kept in full or partial form in permanent archives.
If you want a game theoretic, capitalist analysis, Google has an incentive to keep the web running and keeping it an awesome platform, to make sure humanity's information is created and shared in an open format that they know how to index and that they can freely index, instead of apps or some alternative web or some other walled garden.
But we're bombarded daily with "goog bad" by politicians and journalists, so Google must obviously be just brazenly lying and you should give your DNS history to an organization founded by The City of London Police instead that "share anonymized data on specific domains queried [...] with its threat intelligence partners".
Please double check my work, I didn't read the privacy policies too carefully (I think notably Google stores the AS number and Quad9 doesn't) because I don't actually care, I (along with roughly 100% of internet users) just give all my DNS history in plain text to my ISP.
My history goes mostly to my carefully chosen, overseas VPN provider. Yes, there are no good choices, best you can do is to split your data between several parties, so its hard to correlate. Google has data on most people on the planet, unlike London Police, so giving Google your data is way more dangerous than other parties combined. And user data is Google primary business model.
And I wouldn't spend much time analysing policies, they are all "we pinky swear". Its is there a business incentive in using my data or not.
And I wouldn't spend much time analysing policies, they are all "we pinky swear". Its is there a business incentive in using my data or not.
If you want privacy, use Tor. Like Richard Stallman https://stallman.org/stallman-computing.html
Anything else like a "VPN" (which is really just a proxy under a cooler name) is somewhere between a half measure, a snake oil hobby or self-sabotage (if you picked the wrong VPN).
You don't trust a large multi national that works on encryption and tries to deny frivolous law enforcement requests when it outright says it samples a small amount of "anonymized" data and doesn't correlate it with anything else it has on you or sell it
>> Is any of the information collected stored with my Google account?
> No.
>> Does Google share the information it collects from the Google Public DNS service with anyone outside Google?
> No, except in the limited circumstances described in Google's privacy policy, such as legal processes and enforceable governmental requests. (See also Google's Transparency Report on user data requests.)
>> Does Google correlate or combine information from temporary or permanent logs with any personal information that I have provided Google for other services?
> No.
https://developers.google.com/speed/public-dns/faq
yet trust some small, anonymous group of people that set up a proxy that's netting them like $5/month of revenue per user in a highly competitive market?
> [policies] are all "we pinky swear"
Are they not legally binding? But yea, like I said, obviously they're just brazenly lying because of course they are. "goog bad" has been established. I'm not sure how or where... but everyone knows that.
Better be safe and give your data to an organization that lists the US Secret Service as a "Partner".
Anything else like a "VPN" (which is really just a proxy under a cooler name) is somewhere between a half measure, a snake oil hobby or self-sabotage (if you picked the wrong VPN).
You don't trust a large multi national that works on encryption and tries to deny frivolous law enforcement requests when it outright says it samples a small amount of "anonymized" data and doesn't correlate it with anything else it has on you or sell it
>> Is any of the information collected stored with my Google account?
> No.
>> Does Google share the information it collects from the Google Public DNS service with anyone outside Google?
> No, except in the limited circumstances described in Google's privacy policy, such as legal processes and enforceable governmental requests. (See also Google's Transparency Report on user data requests.)
>> Does Google correlate or combine information from temporary or permanent logs with any personal information that I have provided Google for other services?
> No.
https://developers.google.com/speed/public-dns/faq
yet trust some small, anonymous group of people that set up a proxy that's netting them like $5/month of revenue per user in a highly competitive market?
> [policies] are all "we pinky swear"
Are they not legally binding? But yea, like I said, obviously they're just brazenly lying because of course they are. "goog bad" has been established. I'm not sure how or where... but everyone knows that.
Better be safe and give your data to an organization that lists the US Secret Service as a "Partner".
The difference is, DNS-over-HTTPS seems to support cookies and identification. DNS only identified the IP of a person.
So it’s clearly an upgrade for Google.
So it’s clearly an upgrade for Google.
A really good presentation on the privacy implications of "modern DNS" by PowerDNS https://www.youtube.com/watch?v=V2F92orIEO8
> https://www.youtube.com/watch?v=V2F92orIEO8
So, given the talk, is the industry finally realizing what Mozilla, Cloudflare and Google are trying to pull off with DoH? I guess this is why the change of hearts from them and letting people block DoH within entire networks, hoping not to attract attention of how much control they want to take away.
So, given the talk, is the industry finally realizing what Mozilla, Cloudflare and Google are trying to pull off with DoH? I guess this is why the change of hearts from them and letting people block DoH within entire networks, hoping not to attract attention of how much control they want to take away.
Ooh, that's an interesting tack. I wonder if Firefox stores cookies or sends enough headers for fingerprinting DoH requests.
I didn't see it mentioned in the article. Has Mozilla said whose servers they will be sending unsuspecting users queries to by default? (IIRC, it was Cloudflare previously. Any reason to believe this has changed?)
---
If, like me, you already have a solution in place you are happy with and don't like the idea of others (deciding they know what's best for you and) circumventing it, simply ensure that your existing resolvers are configured as described in [0]:
> Network administrators may configure their networks as follows to signal that their local DNS resolver implemented special features that make the network unsuitable for DoH:
> DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver.
[0]: https://support.mozilla.org/en-US/kb/configuring-networks-di...
---
If, like me, you already have a solution in place you are happy with and don't like the idea of others (deciding they know what's best for you and) circumventing it, simply ensure that your existing resolvers are configured as described in [0]:
> Network administrators may configure their networks as follows to signal that their local DNS resolver implemented special features that make the network unsuitable for DoH:
> DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver.
[0]: https://support.mozilla.org/en-US/kb/configuring-networks-di...
If true that DoH can be disabled at network level, ad-blocking solutions like pihole should probably implement it by default.
Anyone have any idea if this is the case?
That would at least save me a lot of trouble and work.
Anyone have any idea if this is the case?
That would at least save me a lot of trouble and work.
Pihole is great because it can do all your non-browser activity.
But for a browser, an ad-blocking extension works better and is less than a minute to set up. Why force it to use the same DNS blocking?
But for a browser, an ad-blocking extension works better and is less than a minute to set up. Why force it to use the same DNS blocking?
Most mobile-browsers don’t support ad-blocking, especially on iOS.
They're not threatening to use DNS-over-HTTPS either.
But didn't iOS get browser adblocking capability in the last couple years?
But didn't iOS get browser adblocking capability in the last couple years?
Not for third-party browsers like Chrome or Firefox. In a classic Apple-move, it’s for Safari only.
Even though those browsers have to use a safari core anyway? How strange.
Technically speaking they are not using Safari, but a WebView.
Already proposed: https://discourse.pi-hole.net/t/support-for-returning-nxdoma...
Make that already merged: https://github.com/pi-hole/pi-hole/pull/2915
Pi-hole is awesome.
Pi-hole is awesome.
Already implemented in the latest dnscrypt-proxy version.
I wonder if UK ISPs that complained about DoH will block use-application-dns.net network-wide.
What I still don't see addressed is the question how this will affect non-browser applications.
It's nice that Firefox (currently) still offers options to turn off DoH and to keep using local domains. (although the way DoH and HTTPS-everywhere are structured show that non-internet sites don't seem to have much of a place in the web of the future)
However, now that we have public DoH endpoints available for everyone to query, what will keep non-browser apps and devices from using DoH without any way to opt-out?
Currently, tracking DNS requests seems to be a common way for security and privacy researchers to get some basic information what an app or device is doing on the internet. If DoH is widely deployed, all you'll probably be seeing is encrypted connections to IPs of shared hosters.
This seems like a perfect opportunity for apps and devices to cloak data tracking and other illegitimate requests.
It's nice that Firefox (currently) still offers options to turn off DoH and to keep using local domains. (although the way DoH and HTTPS-everywhere are structured show that non-internet sites don't seem to have much of a place in the web of the future)
However, now that we have public DoH endpoints available for everyone to query, what will keep non-browser apps and devices from using DoH without any way to opt-out?
Currently, tracking DNS requests seems to be a common way for security and privacy researchers to get some basic information what an app or device is doing on the internet. If DoH is widely deployed, all you'll probably be seeing is encrypted connections to IPs of shared hosters.
This seems like a perfect opportunity for apps and devices to cloak data tracking and other illegitimate requests.
The same thing that stopped it before DoH was standardized: nothing.
There are ways to make FW rules based on trusted DNS lookups (i.e. you can only do traditional DNS to a trusted DNS server with domain filtering and you can only connect to an IP if a DNS lookup has been performed) but this is extremely hard to maintain in any sort of foolproof way.
The truth is if you allow outbound connectivity then there all the sender needs to do is add 1 more level of obfuscation than you secure against.
There are ways to make FW rules based on trusted DNS lookups (i.e. you can only do traditional DNS to a trusted DNS server with domain filtering and you can only connect to an IP if a DNS lookup has been performed) but this is extremely hard to maintain in any sort of foolproof way.
The truth is if you allow outbound connectivity then there all the sender needs to do is add 1 more level of obfuscation than you secure against.
I am wondering, does DNS-over-HTTPS really helps since the way I understand it, after the domain name is resolved to an IP address, the client contacts the IP address so the ISP could still know the website visited especially since many if not most websites have dedicated IP addresses. So ISP could simply crawl the web and map domain names to IP addresses.
Is there anything in DoH mitigating this? Or maybe is this attack vector negligible in practice because most servers typically host multiple websites? At least this adds plausible deniability in a wide range of situations I guess. But is it really true? And for example, would it really help in a country where a website like Facebook is censored? (Since their IP addresses are dedicated).
Is there anything in DoH mitigating this? Or maybe is this attack vector negligible in practice because most servers typically host multiple websites? At least this adds plausible deniability in a wide range of situations I guess. But is it really true? And for example, would it really help in a country where a website like Facebook is censored? (Since their IP addresses are dedicated).
DoH definitely doesn't mitigate against your upstream provider doing traffic inspection and siphoning the IPs your network is connecting to. Ultimately, they have to route your IP packets, so they'll always have that visibility.
But this 1) adds a technical hurdle, 2) reduces accuracy of the data captured, and 3) adds a potential legal barrier, as the data is not theirs anymore
(before ISPs could claim that the use of their DNS gave them right to use the data collected)
But this 1) adds a technical hurdle, 2) reduces accuracy of the data captured, and 3) adds a potential legal barrier, as the data is not theirs anymore
(before ISPs could claim that the use of their DNS gave them right to use the data collected)
SNI allows hosting multiple SSL Certificates on one IP, but is itself a privacy problem, because https requests have the domain in plain text.
ESNI can solve this, by encrypting the SNI header while still allowing serving multiple https domains on one IP. But it’s currently mainly implemented by cloudflare.
ESNI can solve this, by encrypting the SNI header while still allowing serving multiple https domains on one IP. But it’s currently mainly implemented by cloudflare.
This! Just like https encrypting website that anyone can visit is not about privacy, DoH is also not about privacy. Anyone can visit the same https website you visit and see what you are reading. Anyone can resolve the same hostnames that you are resolving (or reverse IPs you are visiting to determine hostnames).
The benefit they do provide is authentication (ensure that google.com is really google.com) and protection against man-in-middle.
And those are great benefits!!
But it doesn't help anyone to misstate and/oversell the benefits of a new service/protocol.
The benefit they do provide is authentication (ensure that google.com is really google.com) and protection against man-in-middle.
And those are great benefits!!
But it doesn't help anyone to misstate and/oversell the benefits of a new service/protocol.
> Anyone can resolve the same hostnames that you are resolving
Yes, but your ISP (including "that coffee shop whose wifi you're using" in ISP here) can't necessarily tell which hostnames you are resolving, if you use DoH (subject to some limitations about what happens after you've resolved the hostname). This is in fact a privacy feature
Yes, but your ISP (including "that coffee shop whose wifi you're using" in ISP here) can't necessarily tell which hostnames you are resolving, if you use DoH (subject to some limitations about what happens after you've resolved the hostname). This is in fact a privacy feature
Yes, ISPs can know IP addresses and map domains to IP addresses, they can also know exact SNI names, all kinds of passive TCP-level information about your communications, can do active probing for all kinds of information on behalf of you, can use all that together to build a much more detailed profile of you, than available through DNS queries. There is an entire industry of commercial DPI solutions to do that. On top of that ISPs can always block DoH and force fallback to their own DNS servers. So, a minimum amount of privacy can only be achieved with a VPN (or a proxy), not DoH, DoH just leaks to and centralizes data on third parties, violating privacy, making it easier for state actors to spy on people, things like that, it might even give governments capabilities to do world wide censorship if all major browsers implement it. Mozilla, Cloudflare and everyone else involved are being very dishonest when it comes to DoH.
> they can also know exact SNI names
This is why ESNI is being rolled out, yes?
This is why ESNI is being rolled out, yes?
This is why IP itself is no longer a workable solution--it's point-to-point by nature. Take a look at Named Data Networking for possible approaches to this problem.
Can somebody point me to the place in the Firefox code where the "use-application-dns.net" canary domain is actually checked? I've tried searching the mozilla-central Mercurial repository and I'm not finding it. I'm clearly inept here.
I'm looking at what my Windows DNS servers return when I put in an empty zone for "use-application-dns.net" and I'd like to see exactly what Firefox is testing for. Windows 2012 R2, at least, returns the SOA and no NXDOMAIN for an "A" query to "use-application-dns.net" with an empty zone. If they're explicitly looking for NXDOMAIN then blocking DOH behavior with Windows DNS servers probably isn't going to work. >sigh<
I'm looking at what my Windows DNS servers return when I put in an empty zone for "use-application-dns.net" and I'd like to see exactly what Firefox is testing for. Windows 2012 R2, at least, returns the SOA and no NXDOMAIN for an "A" query to "use-application-dns.net" with an empty zone. If they're explicitly looking for NXDOMAIN then blocking DOH behavior with Windows DNS servers probably isn't going to work. >sigh<
The canary is not implemented yet, as far as I can tell.
I'd personally prefer to be greeted with a screen providing me with the option of multiple DNS-over-HTTPS providers, and the option of not using one at all, than being silently forced into handing CloudFlare even more of my data.
How about to save time, we could have this choice only once, and that would apply to every application on the machine. Say it could even be handled by the OS itself!
And to save users even more time, not having to configure this per machine, we could have such assignment be an automatic part of the network infrastructure...
We could call it DHCP and DNS! How about it?
And to save users even more time, not having to configure this per machine, we could have such assignment be an automatic part of the network infrastructure...
We could call it DHCP and DNS! How about it?
And DNSSEC all the way to the user!
I'd be pretty pissed if my network connection opted me into a DNSSEC-verifying resolver, since that is pretty much pure downside for users.
As someone not very knowledgable about DNSSEC, can you expand on this point? To the uninformed that sounds very counterintuitive.
Apart from the blog post, if you don't know anything about DNSSEC, I think the things you want to know are:
1. Almost nobody --- major tech companies, banks, privacy and security organizations --- uses it. It's decades old, and its adoption, at least in North America and in industry, is zero. There are lots of reasons, but you don't have to care right now.
2. Since almost nothing uses it, there's no real upside to enabling it. But there is a downside! If DNSSEC is misconfigured --- which is easy to do, and it won't get noticed quickly (see: point 1) --- then sites in the DNSSEC-signed zone silently drop off the Internet, as if they never existed. That happened, for instance, to HBO when they launched HBO NOW: nobody on Comcast could see it, because it turned out they'd screwed up DNSSEC, and Comcast had DNSSEC-verifying resolvers.
1. Almost nobody --- major tech companies, banks, privacy and security organizations --- uses it. It's decades old, and its adoption, at least in North America and in industry, is zero. There are lots of reasons, but you don't have to care right now.
2. Since almost nothing uses it, there's no real upside to enabling it. But there is a downside! If DNSSEC is misconfigured --- which is easy to do, and it won't get noticed quickly (see: point 1) --- then sites in the DNSSEC-signed zone silently drop off the Internet, as if they never existed. That happened, for instance, to HBO when they launched HBO NOW: nobody on Comcast could see it, because it turned out they'd screwed up DNSSEC, and Comcast had DNSSEC-verifying resolvers.
Same story as always with Google "innovations": "hey, we're preventing DNS queries to go to your ISP who is selling it" (to go to our service instead so we can profit from it).
It's scary that Moz sides with monopolies like Google and Cloudflare on this one.
It's scary that Moz sides with monopolies like Google and Cloudflare on this one.
In my Firefox settings I can choose any DoH provider I want, not just Cloudflare. Naturally something has to be set up as a default so it works. Why is adding DoH in the browser a bad thing?
Because if we’re replacing classic DNS with something new, it needs to be part of the OS.
Not reimplemented (and configured) per application. The user and OS should control the application, not the other way around.
Not reimplemented (and configured) per application. The user and OS should control the application, not the other way around.
Is any OS vendor working on something like that? Or do you expect Moz to jump into OS dev as well? I'd expect them to import settings from OS as soon as a major OS provides this for DoH.
The DNS has grown into a regulated service, with TLD authorities and protocols to follow for registrators, transparency for domain holders, many registrators to choose, etc. Do you want to replace it by a centralized system run by very few monopolies that track resolution queries by IP?
At the end, you still need to trust the resolver.
There is a proposal to improve this. Resolves won't know client IPs any more: https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/AN...
Reference client and server implementations should be ready in the next few days.
There is a proposal to improve this. Resolves won't know client IPs any more: https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/AN...
Reference client and server implementations should be ready in the next few days.
This is interesting as a lighter alternative to DNS over Tor. Where is the padding going to be? Basic clients won't add EDNS padding by default, but intuitively there has to be padding somewhere. It reminds me of https://odns.cs.princeton.edu (I haven't seen a working implementation of that one yet). The most difficult challenge is how to present the ultimate choice - use the relay and maybe get slower Internet, or don't use the relay and maybe get tracked. What hasn't been much explored yet is using resolvers just to obtain the delegation (nobody needs to know who the client is for that), but that itself is not without problems.
Indeed, we will need to make a choice between minimizing latency or using a relay.
But a lot of people use DNS over Tor already. For people concerned about privacy, a bit of extra latency is totally acceptable.
Anonymized DNSCrypt is lighter than Tor, has a very clear security model, and relays are less vulnerable to abuse than Tor exit nodes.
The server/relay part is going to be implemented in https://github.com/jedisct1/rust-dnscrypt-server
But a lot of people use DNS over Tor already. For people concerned about privacy, a bit of extra latency is totally acceptable.
Anonymized DNSCrypt is lighter than Tor, has a very clear security model, and relays are less vulnerable to abuse than Tor exit nodes.
The server/relay part is going to be implemented in https://github.com/jedisct1/rust-dnscrypt-server
The underlying DNSCrypt protocol does the padding already: https://dnscrypt.info/protocol
DNS queries and responses are wrapped, they are never modified. EDNS padding is a horrible hack.
DNS queries and responses are wrapped, they are never modified. EDNS padding is a horrible hack.
That's good, I missed that. Thanks for highlighting the project, I'll keep an eye on it!
Why don't they rather include a resolver in Firefox ?
This way, no privacy problems, you're directly contacting authoritarive servers. And you don't rely on a single dns-over-https provider.
Is the latency a big problem there? I would say that with caching it is not too bad.
This way, no privacy problems, you're directly contacting authoritarive servers. And you don't rely on a single dns-over-https provider.
Is the latency a big problem there? I would say that with caching it is not too bad.
1. The connection to the authoritative servers isn't encrypted, so the whole point of DoH is undermined.
2. There's plenty of networks that don't let arbitrary DNS traffic out, so this doesn't work without another fallbacks. Fallbacks for security features are bad.
I see that there are legit controversies around DoH. But these "Why don't you just do X?" comments aren't helpful. Try to understand the problem they're trying to resolve.
2. There's plenty of networks that don't let arbitrary DNS traffic out, so this doesn't work without another fallbacks. Fallbacks for security features are bad.
I see that there are legit controversies around DoH. But these "Why don't you just do X?" comments aren't helpful. Try to understand the problem they're trying to resolve.
I disagree that the OP's comment isn't helpful. Mozilla could have taken a tack that would have increased decentralization and promoted privacy (DNS-over-TLS exists). Instead, they went the way of a centralized protocol that just trades one set of potentially bad actors (ISPs) for another.
re: network policy - If you're paying to use a network with policy that you disagree with vote w/ your wallet. If you're using somebody else's network (i.e. a corporate network I'm paid to administer, for example) it's reasonable to accept that you're bound by the owner's policy-- it's their network.
re: network policy - If you're paying to use a network with policy that you disagree with vote w/ your wallet. If you're using somebody else's network (i.e. a corporate network I'm paid to administer, for example) it's reasonable to accept that you're bound by the owner's policy-- it's their network.
I’d love to use DoT, but afaik it’s currently mostly only supported by DNS resolvers (Google, CloudFlare and other privacy-exploiting companies) rather than authoritative DNS servers.
Well I'm asking because I'm trying to understand the drawbacks of a resolving server. Thanks for the explanation !
A local resolver using root hints and DNS-over-TLS would be a win for privacy and, at the same time, would not promote centralization of the Internet to DNS-over-HTTPS providers. It still suffers from the problem of overriding local network policy but it's better than just handing all the queries over to a single DoH provider.
How is DoT different from DoH? Do you have an issue with the format on the wire? Because otherwise you can use whichever resolver you want in either case.
I'm on mobile so rather than restate I'll just refer to a comment w/ a good link from an earlier discussion: https://news.ycombinator.com/item?id=19624136
Besides what the other commenters have said, it also just seems like a bad idea to add 170 million extra recursive resolvers, I don't know how well the dns infrastructure would cope with that extra amount of traffic.
Each of which individually generates really limited traffic?
Besides, the number of domains and relatively short TTLs mean that even the big resolvers will not have most requests cached except for the most popular domains.
Besides, the number of domains and relatively short TTLs mean that even the big resolvers will not have most requests cached except for the most popular domains.
[deleted]
So what will be « safer » ?
Using a pi-hole or equivalent, or using this ?
IIRC all DoH requests are sent to Cloudflare. Is there a way to host your own DNS server and use it with DoH instead ?
Using a pi-hole or equivalent, or using this ?
IIRC all DoH requests are sent to Cloudflare. Is there a way to host your own DNS server and use it with DoH instead ?
For now I'm blocking traffic to Google's and cloudflare's DNS and plan on also following the advice about that special domain from https://support.mozilla.org/en-US/kb/configuring-networks-di... that someone posted here.
They are not mutually exclusive. Pi-hole supports dns-over-https. My concern with this technology is my port 53 masquerade rule on my router will no longer grab all dns requests when this becomes common practice. I imagine there will be a solution but I'm not sure what it is.
I don't really see a solution without installing root CA's to MitM HTTPS traffic. I too would be interested in solutions for this.
Yeah, you can re-configure Pi-Hole to use DoH (with your preferred servers). unbound can be configured to use DoH as well.
For unbound, I just dropped this in my /etc/unbound/unbound.conf.d/02-block-doh.conf
local-zone: "use-application-dns.net" staticExactly what I did.
For forwarding yes, but not for recursive resolution.
AFAIK a pi-hole can use dns-over-https if configured correctly so there’s no either/or.
I tried forced-mode DoH in Firefox 68 and 69, on Debian 9 and 10. In all cases, it worked for a while then stopped to work after a few hours (at random it seems). The only way for me to make it work again was to disable DoH.
I guess a more long term solution is to have a local proxy dns-to-doh, but we are falling back in the solution that only a technical user can setup :
https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo...
https://facebookexperimental.github.io/doh-proxy/
And it means setting up firewall routing and filters, as some softwares don't have settings to add DNS proxy, or even bypass them (Google Chrome for example)
I guess a more long term solution is to have a local proxy dns-to-doh, but we are falling back in the solution that only a technical user can setup :
https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo...
https://facebookexperimental.github.io/doh-proxy/
And it means setting up firewall routing and filters, as some softwares don't have settings to add DNS proxy, or even bypass them (Google Chrome for example)
> Fall back to operating system defaults for DNS when split horizon configuration or other DNS issues cause lookup failures.
I hope we'll be given the opportunity to disable this, or at the very least show a warning (similar to cert warnings?) that something's off.
I hope we'll be given the opportunity to disable this, or at the very least show a warning (similar to cert warnings?) that something's off.
the network.trr.mode setting provides fine control
https://wiki.mozilla.org/Trusted_Recursive_Resolver
https://wiki.mozilla.org/Trusted_Recursive_Resolver
What is the latency for DoH compared to traditional UDP DNS?
Here's a whitepaper that did some benchmarks and a detailed analysis on it. Was posted on hn a few days ago.
https://arxiv.org/abs/1907.08089
They test various network conditions with some results showing DoH and DoT loading webpages faster than udp dns (due to tcp timing out faster than udp on lossy connections )
They test various network conditions with some results showing DoH and DoT loading webpages faster than udp dns (due to tcp timing out faster than udp on lossy connections )
Thanks!
I have DoH enabled (Cloudflare) and I can't visibly notice any latency compared to normal DNS (which was also Cloudflare). I haven't timed the requests though...
I wonder if this will break TP-Link's tplinklogin.net and tplinkrepeater.net for logging into their routers/repeaters? At least the latter is supposed to be intercepted by the device, and if it isn't, you get a message saying things are misconfigured.
Seems to me they should be able to keep this sort of working by resolving tplinklogin.net to 192.168.0.1 or such on their public DNS and ensuring the router always serves the web page from that IP.
Of course things will break down if a router is ever configured to use a different IP - but then again, the public DNS with local IP might trigger Firefox' heuristics and cause it to fall back to traditional DNS - so thinks may still work.
But the whole concept of using an on-device web page as config UI seems to become problematic, thanks to HTTPS-everywhere, as there appears to be no way to serve HTTPS from a local, unsupervised device that is frictionless and does not open a security vulnerability.
Of course things will break down if a router is ever configured to use a different IP - but then again, the public DNS with local IP might trigger Firefox' heuristics and cause it to fall back to traditional DNS - so thinks may still work.
But the whole concept of using an on-device web page as config UI seems to become problematic, thanks to HTTPS-everywhere, as there appears to be no way to serve HTTPS from a local, unsupervised device that is frictionless and does not open a security vulnerability.
Unfortunately, Mozilla are planning to leave DoH off by default for Firefox users in the UK. Almost certainly to avoid criticism from politicians and children’s charities about how DoH would interfere with the UK’s network level website blocking of ‘adult’ websites.
Hrhr. But talk about how it intends to prevent censorship...
DoH bypasses the OS and the /etc/hosts file. This breaks some workflows.
Oh no.
Maybe you can configure this? https://support.mozilla.org/en-US/kb/customizing-firefox-usi...
Or perhaps use their canary domain to force Firefox to use local DNS?
Or just configure it yourself?
It's not security if an application can still access the internet. Why not block all internet access except via a proxy server? Which is what a "real" enterprise would do because they can block what they want and have a secure network.
Maybe you can configure this? https://support.mozilla.org/en-US/kb/customizing-firefox-usi...
Or perhaps use their canary domain to force Firefox to use local DNS?
Or just configure it yourself?
It's not security if an application can still access the internet. Why not block all internet access except via a proxy server? Which is what a "real" enterprise would do because they can block what they want and have a secure network.
ISPs, OSs and Routers should effort at providing secure resolving themselves before every app out there thinks it knows better what DNS to use.
Why would Mozilla hurt Firefox's market share in such an obvioud and drastic way? Do they not have anyone at their meetings that brings up obvious and uncomfortable risks?
I use DoH on Firefox and love it but man, I myself would block Firefox in a corporate network I help oversee if this is the default. Matter of fact, web proxies already list DoH resolvers as anonymizing sites.
Even if this involves some profit with cloudflare,this is strategically terrible for long term goals.
I use DoH on Firefox and love it but man, I myself would block Firefox in a corporate network I help oversee if this is the default. Matter of fact, web proxies already list DoH resolvers as anonymizing sites.
Even if this involves some profit with cloudflare,this is strategically terrible for long term goals.
Can you run this service yourself easily?
We're getting an option to bypass TSP's DNS to a 3rd party over secure connection; be it DoH or DoT.
TSPs can easily map your usage behaviour to your identity while 3rd party DNS provider will have your behaviour alone. Albeit, TSP will still have IPs you've accessed for data transfer.
TSPs that honour their customers' privacy will allow 3rd party DoH/DoT, esp DoT(ie port:853).
TSP: Telecom service provider
TSPs can easily map your usage behaviour to your identity while 3rd party DNS provider will have your behaviour alone. Albeit, TSP will still have IPs you've accessed for data transfer.
TSPs that honour their customers' privacy will allow 3rd party DoH/DoT, esp DoT(ie port:853).
TSP: Telecom service provider
Could we have srv records as the default to alleviate/eliminate the ipv4 crisis?
Android + Chrome + DoH + AMP = ?
Edit: typo
Edit: typo
Big thanks to Mozilla for making internet a more secure place.
But this is a win overall for privacy.
DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do.
If you're technical enough to understand DNS then you are smart enough to change what the default is.
If you're a system administrator for a company. You should be able to push a profile down to the user's computer to configure DNS how you want.