Mozilla DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) Comment Period
blog.mozilla.org
blog.mozilla.org
(For more detailed complaints and arguments on this topic, I wrote a long comment about it a year ago.)
Emacs has been a decent haven for me in my search for privacy, interopability, programmability: my user agent.
Now, we're back to centralized systems- and I couldn't believe it when I watched the shift: What first caught my attention that this could get serious was gmail. Then g-office (whatever they called it then). Meanwhile a whole host of other services started.
I was developing a desktop app because I still wasn't convinced that people wouldn't prefer having their software and data "in hand," as it were.
I expect a new advantage will emerge and we'll want our machines and data back.
Even within the current era, render on server, render on client, ajax (the mix), etc.
We're seeing it now in gaming. Vidcards are the cost of a whole system now, games have become huge, and fast storage is still expensive; but bandwidth is increasing along with A/V streaming being perfected, so someone figured out how to minimize apparent control latency and now games are streaming. Once vidcards get cheap and SSD storage capacities catch up to 150GB games it'll flip back until the balance tips again.
I wouldn’t play really competitive shooters that way but it’s low enough to not bother me even in mouse/keyboard FPS (for the PC services). For controllers it’s completely negligible, like playing with a Bluetooth device or on a 2015 TV.
That said, I’m in Santa Clara County near one of the major Shadow datacenters, probably the others too, and I have gigabit. I am in the ideal situation you describe.
So is a lot of the world though. US is super rural for its economic weight but that’s not the norm. Most developed countries have much higher density and better networks. I think we’ll probably just end up dragging behind the curve until we mesh the flyover states better.
It may not be conceptually beautiful but it is one of the most practical and useful technologies we've ever created, like C compared to lisp. The Web is the new "Worse is Better"
Ideally then for all more involved software experiences native software would have to be shipped.
Stop with this stop political stuff in tech like root level zone server type of stuff.
Actually HTTP could directly handle DNS. Then you can decide between a cloudflare, google, akamai or amazon browser. Who needs more freedom if we can have security...
https://www.bleepingcomputer.com/news/security/microsoft-add...
The correct solution is a) do this at the OS so users can configure the behaviour, b) add support to pihole or similar for making DoH requests out to somewhere like CloudFlare, c) also add support for receiving DoH requests for those people using a pihole over untrusted networks.
The problem you are describing is nothing to do with DoH, it is simply a consequence of the fact that DNS is not meant to provide access control. It is not an endpoint security management solution.
That said, in fairness, not everyone sets up their own VPN mesh. Some people use commercial VPN providers. So in that case, it would assume my friend does not block access to that VPN provider.
[1] - http://tinc-vpn.org/
You could block your guest's VPN connections, but you don't do that.. why not? Aren't they subverting your protection by using VPNs?
> nor would I subject them to centralized DNS. Both are equally dangerous in my view.
I would argue that large providers like Cloudflare are the only ones who realistically have the resources to stand up to threats like government intervention (where it is possible). They have strong legal and financial incentives to maintain their privacy guarantees which smaller providers don't have.
Also you have the advantage of your data "hiding in plain sight" due to the high volume they deal with.
I certainly wish there were more providers available than just Cloudflare and Google though.
For my technical friends, that would be true. They can adjust their settings and be on their way. I won't block their choices aside from intercepting requests to the ISP DNS.
Most of my friends are not technical, have no idea how to tweak the settings in their browser and would not know they even need to care. So I think it is fair to say that a choice is being taken away. It isn't like browsers are going to prompt people and explain what is occurring. The masses will experience centralized DNS without any idea this is happening. I think we will fundamentally disagree here.
You could block your guest's VPN connections, but you don't do that.. why not?
My guests can choose to use a VPN if they wish, I would not take that choice away. That is an intentional move to protect their traffic. DoH is not an intentional choice. They did not choose this. If a technical friend chooses a DoH server, their laptop won't work and I will explain, if I had not already, that DoH servers are blocked. Anyone that knows me, would expect this behavior. Anyone that is my friend would accept this. We probably just have very different circles of friends.
Although if the only concern is that Firefox defaults to a poor choice (in your opinion), why not just block Firefox's default specifically? Why other public DoH servers too? Or why not just block the Firefox DoH canary domain which prevents it from defaulting to DoH unless the user specifically turns it on?
At work, we already control these settings in the browser and can easily control any future settings in the OS so it is not an issue there.
I hadn't looked into this recently but it looks like you can configure a pihole to use DoH for outbound requests:
https://docs.pi-hole.net/guides/dns-over-https/
So personally I plan to a) enable that so my outbound requests are encrypted, and then b) install a DNS blocklist so the hosts on my network will fall back to regular DNS and use the pihole.
Best of both worlds!
This is so obviously bad I don't understand.
So given that DoH has real and practical security and privacy benefits, and non-DNS based content blocking solutions are already available, are more common, and work more effectively, I don't see how it is such a nightmare to adopt those more secure defaults for everyone.
Furthermore I don't think anyone is suggesting "100 different applications" will each have their own resolvers embedded. It makes sense for browsers to be a special case since they are particularly in need of the additional privacy affordances that DoH can provide, and operating system vendors have been slow to implement it.
I think you're missing the point, here.
A lot of enterprises run their own delegating DNS server for a variety of reasons that have nothing to do with ad blocking.
DoH breaks that en masse.
Firefox has always struggled to gain adoption in corporate settings, and this looks like a nail in the coffin .
Of course that could be easily bypassed, but such a restriction could be easily bypassed by determined employees regardless of whether Firefox natively supports DoH or not.
Local intranet sites will still continue to work without any changes because by default it will fall back to the native resolver if DoH can't resolve the domain. So there should be no breakage by default besides for content blocking use cases.
I see a comment like this basically every time something about DoH comes up.
What I haven't seen: A plan how this should be implemented, a proposal to OS vendors and developers, ideally with patches.
This raises a few questions. How should the OS decide which server to use? It obviously can't be DHCP, because that's not a secure thing to begin with. How does this interact with things like captive portals if you have a disconnect between the DNS functionality and the gui application? Do you have good answers for these?
I’m sure others do too I just can’t say for certain.
macOS: same as iOS (a dedicated window pinging www.apple.com).
Firefox: Detects detectportal.firefox.com and asks the user if the want to access the captive portal.
Android: Detects connectivitycheck.android.com on Android 5 and connectivitycheck.gstatic.com on Android 6+. I don't know if it applies to all phones, but I'm sure (that except for phones on Android One or Nexus/Pixel) Samsung also does this for phones outside of China.
The same applies for your "home" environment. Since you usually don't want to run multiple DHCP servers, this would also work there.
option wpad-url code 252 = text;
option wpad-url "http://10.10.10.10/proxy.pac\n";
There is some work regarding this.
Why not? DHCP is supposed to be authoritative for the network you're connected to. If you don't trust that network, you should probably also not be using its advertised gateway. Where does that leave you?
Why not? Just make sure to use a VPN/etc to access services over the gateway.
I mean, this is the default case for everything going over the internet. Do you trust every router in the path?
If you're worried that your network upstream is intercepting your DNS requests (and if you're in the US on a mainstream ISP, you should be), this is the problem DoH is designed to solve, and it does so quite effectively.
Shame that I have 20 applications on several different users on two dozen different machines to configure
The fact is that there's nothing you can do to authenticate DNS records, and turning some silly "DNSSEC" feature on in your own stack won't do anything but make you feel better, because DNSSEC simply doesn't have meaningful adoption. However, enabling DoH does in fact immediately protect you from attacks that really do happen, like ISPs monetizing your DNS.
Exactly. That's what I said.
The problem is that DoH is not the solution, as you just change trust from resolver A to resolver B. With no indication that B is better than A.
If you fear that your ISP is selling your data you need to change your ISP. The ISP always know what sites you are accessing, regardless of DNS. DNS might be easier than SNI or IP lookups but the danger is still the same. Right now it might actually help but once encrypted DNS gets enough traction those methods will also adapt. (Assuming that ISPs still do that practice)
While I have strong normative beliefs here, I'm mostly just posting descriptively. DNSSEC isn't happening. Enabling DNSSEC in your local configuration won't meaningfully protect you, because you depend on the security teams of large companies to also participate in the system, and DNSSEC has been more or less rejected by the market. Meanwhile: there are specific problems that DoH does protect against, it's easy to roll out, and doesn't depend on the Stripe security team changing their mind about DNSSEC --- so DoH is on a path to become universal, even as DNSSEC whithers.
(I invite the curious to test my reporting out with the `host -t ds foo.com` command, for arbitrary values of "foo").
I know I sound like a sore winner about this, and I guess I sort of am, but it is a little alarming that there are still currents of sysadmin wisdom telling people to go out of their way to opt into DNSSEC, in the belief that it will somehow protect them from any kind of real attack. In reality: corrupted DNS records overwhelmingly come from phished registrar accounts, not the elaborate, geographically-specific DNS cache corruption attacks DNSSEC was envisaged to deal with. I think it's worth being plain with people about this stuff.
Of course. If you know that your ISP is doing that, you change to one that is not doing it. It's not ubiquitous. Besides that, what makes you think that your DoH provider (if not your ISP) is also not selling that data?
You think that DoH/DoT is somewhat a replacement for DNSSEC but it's not. Both are independent. Doesn't matter how much domains have it.
Seems more plausible to just run DoH for my DNS and then not worry about my ISP snooping on my DNS requests.
Personally when my laptop is connected to a network on a high latency link to the internet, I'd rather it used the local caching server rather than one half a continent away. Clearly if I don't trust that network provided DNS server I'll tunnel everything out to a trusted network, or I could specify a DOH.
I have no practical issue with DOH if it were implemented at the OS level and had standards around how to distribute recommended settings (just like my dhcp server distributes a recommended gateway, recommended ntp server, recommended tftp boot server, etc).
If you don't trust the network, then the OS should be tunneling to a trusted one. If you do trust it then it can go ahead and use the DHCP/etc provided name servers.
After all it can decide to enable/disable access to services (windows filesharing for example) based on this, there isn't any reason it can't decide to trust the local nameserver too.
Windows has support
https://techcommunity.microsoft.com/t5/networking-blog/windo...
You can put the proxy anywhere on the network and set up DHCP to point the clients to this proxy.
I agree that it would be better for DoH to be done in the operating system than in applications, but the reality is that today, operating systems don't do this, and it's better to do DoH in applications than to not do it at all.
Of those platforms that do support DoH, how many of them have it on by default, rather than requiring the user to know it exists and turn it on?
> Of those platforms that do support DoH, how many of them have it on by default, rather than requiring the user to know it exists and turn it on?
Being off by default is a feature. Those road warriors that do not trust their coffee shops can turn it on if they want it, but elsewhere it causes nothing but trouble.
The easy solution is for the well-kmown IP to be in the same pool that a major CDN uses, so it can't be blocked without major collateral damage.
As for being off by default, that's absolutely not a feature. Basically nobody who's non-technical will ever turn this on, even though it will improve privacy for no downside for most people. What "trouble" does it cause anyway?
I can imagine that there are players who are OK with that collateral damage. In the end it will end up exactly like when the cloud providers disabled TLS domain fronting.
> even though it will improve privacy for no downside for most people
It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
> What "trouble" does it cause anyway?
You don't know, so you will use scare quotes then?
It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
It has privacy implications that you didn't even began to think about.
Most networks are not coffeeshop wifi, where such behavior would be OK.
The problem with domain fronting was that it could be blocked by blocking the chosen "front" domain, which bad actors were often willing to do. In this new era of eSNI, they'd have to block all of CloudFlare, which would be a lot harder sell even for an entity like China.
> It won't. The big DoH providers will have nice behavioral data, on computer level, i.e. NAT is no longer a problem, they can distinguish separate device due to TLS session.
> Privacy-wise, it is net negative. Few big companies will be getting data they didn't have until now.
I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
> It has problems with DNS zones that only some resolvers can resolve, and/or are under ACLs so only local clients can resolve them. Your local network knows about them, the global ones don't.
Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> It has problems with split-horizon names. So now, instead of getting internal IP for a service, you will be getting external one, so your traffic will go to router and back.
With managed clients, you'd push out configuration to exempt the internal names from DoH. And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
> It has privacy implications that you didn't even began to think about.
Like what?
Entity like China are willing to block entire subnets if the subnet owner doesn't coooperate and doesn't separate the traffic. That would make the subnet owner's customer nervous, thus them pushing for cooperation in the first place.
> I trust CloudFlare more than my ISP with my privacy, and if you don't, then you can pick another DoH server that you do trust.
The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
> Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
> And what's the use case for split-horizon DNS with unmanaged clients? I've never seen that.
BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
>> It has privacy implications that you didn't even began to think about.
> Like what?
Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
[1] Though it has really no sense in trusted networks; DHCP can announce classic 53/udp service, the resolver can use DoT/DoH for the upstream, and the client would be none the wiser. In fact, many networks do exactly this today.
Once eSNI is widely deployed, in addition to CloudFlare, DoH could also be ran from anywhere in Azure, AWS, or GCP. At that point, China will have to choose between breaking all TLS, blocking almost all traffic to the US, or accepting DoH leaking.
> The thing is, I don't want to pick one single DoH server. I want to use the resolver that knows the local network, i.e. exactly how DHCP works today. I would be fine if there was a way to announce DoH/DoT via DHCP[1] and all the systems and apps would respect it.
But the network is the main adversary. It would just advertise a DoH server that does censorship or surveillance, and then we're back where we started.
> > Firefox will fall back to the local resolver for domains that fail to resolve with DoH.
> Just wait until ignorant people will start screaming about "DNS leaks" -- just like they do today with VPNs.
That feature is optional. It's easy to turn that off if you don't want it to happen. And even if that weren't the case, isn't most of your DNS requests being safe better than none of them being safe?
> BYODs. There are organizations (both for and non-profit), that have external co-workers, working with their own devices, that are not managed by GPO or MDM.
So just add one step to onboarding: after "here's the Wi-Fi password", it's "here's the subnet to add to the DoH exclusion list".
> Centralized service, preconfigured by default, used by many people, capable of discerning browsing habits per device even behind NAT. What could possibly go wrong.
A lot less that could go wrong with the current state of ISPs.
What it is about is that the defaults for pretty much all OSes are bad. Maybe if we lived in a world where DoH was shipping by default enabled in Linux/Mac/Windows and set to something private like Cloudflare, it would make sense not to even provide browser options at all.
But as it stands, the current solution (while a little unintuitive and hacky) give you the best of both worlds. If you're a normal user, you get secure defaults. If you're a power user, you can go into Firefox and point at your own DoH provider, or turn off DoH entirely if that's what you want. And if you're an admin deploying Firefox on a network, you can deploy it with a custom profile that sets its internal DoH/DNS settings to whatever you want.
Do you know of any references that describe how it determines if the DNS service offers a DoH option or not? I can't find anything more than vague descriptions.
You're essentially arguing that more flexibility is bad without real justification. Per application DNS/routing (split routing) is something most Operating Systems don't support today (or setting it up is incredibly complex).
Giving this kind of flexibility might open up a future where a competitor to ICANN-DNS could exist, and users could dogfood it via single browser/window/tab instead of having an all-or-nothing situation as per today.
But let's throw out incredible new capabilities that allow user flexibility/choice because it is different to how it was historically done.
https://firejaildns.wordpress.com/
and a survey of public DoH servers:
https://firejaildns.wordpress.com/2020/09/22/a-survey-of-pub...
Can anyone link to the part of the source tree containing their DoH implementation? I would like to test whether it is possible to distinguish Firefox DoH from unbound.
i.e. Smart TVs will do this to get around pi-hole style ad blocking.
However, as a system administrator, I don't see in Firefox the equivalent of dig and nslookup: if a user reports an issue with Firefox, how can I ask him to verify which IP address a domain name resolves to? If I ask for a nslookup or dig result, I can no longer be sure that the OS resolver is giving the same answers that Firefox is returning.
With the Firefox model I have to interrupt the user and ask them to become an active part of the troubleshooting process. I'd prefer fixing the problem "behind the scenes" without engaging the user, except to let them know when the problem is fixed. I consider it vastly more "user friendly" to enable support personnel to solve problems w/o distracting the user. I don't think very many developers consider that use case.
Tools that enable "concierge" support for VIPs, executives, Customers who will pay more to be doted-upon, etc, is a valuable attribute in software to me. Moving toward user self-service is laudable, but not if it's at the expense of dedicate support personnel's capabilities. In my experience, at least, the satisfaction and praise users express from having issues resolved without bothering them has been significant.
Some OSes have broken that for a while. I'm sure I've seen ping, dig and applications reporting different results.
The amount of sheer stupidity that goes into the "modern web" is just mind bugling.
DoH does absolutely nothing that helps privacy since the destination IP address is always clear and DoH only obscures that which it never should have touched with in the first place.
I have just about had it with the IT industry and the modern web!
There are multiple situations where destination IPs are shared across multiple websites, and DNS blacklisting is a common censorship technique in multiple firewalls and ISP blacklists.
This take is just completely wrong. Of course DNS records should be handled via HTTPS, of course it's a bad idea to do DNS via plaintext. This shouldn't be complicated, why are we still fighting over whether or not encrypting personal data in transit is a good idea?
I have seen more people on Hackernews than anywhere else on the entire web bash HTTPS encryption, and I genuinely do not understand how this forum, of all places, can be home to such a bad security take. Stop designing and advocating for Internet protocols to be monster-in-the-middled!
DoH is DNS done completely wrong. It's the worst patch solution to a problem that should have been solved correctly long ago!
...yes?
Holy crud, this is practically the most basic principle in security. If you don't want somebody to read it, encrypt it. This is exactly why we don't use email, unencrypted ftp, or SMS for anything that needs security or privacy. Don't send important information over plaintext!!
Furthermore, the destination IP address is ALWAYS in clear text when you use HTTPS. Which demonstrates exactly why this is so wrong.
DoH - is fake privacy, it's nothing more than extra sugar on Cloudflares spying cake - and more funding for Mozilla.
Wake up.
I mentioned this above, but there are plenty of shared hosting servers that don't have unique IP addresses for every domain. This is not an uncommon thing, and it's one of the reasons why DNS blocking is so common in firewalls, even at the ISP/nation-state level. DoH will also obscure the vast majority of subdomains for a given domain, which, again, are often sharing IPs with each other.
Aside from that, DNS leaking is also very common when inexperienced users set up VPNs, and DoH basically gets rid of plaintext DNS leaks entirely.
Look, would it be nice to get rid of IP addresses? Yes. Does anybody have a scalable solution for getting rid of IP addresses that can be deployed today? No. The closest we have is the Tor network, which is not fast enough or robust enough to handle everyone on the Internet. I have very little sympathy for the argument that because SNI encryption isn't completely rolled out yet and because everyone isn't on Tor that we should ignore solveable security/privacy problems in the meantime.
There are multiple privacy issues with the way we currently connect to websites, and DoH solves one of those issues with very little if any downside. It's worth doing.
> This is basic computer and network engineering. If you want to encrypt DNS, fine encrypt DNS, but flipping leave the HTTPS protocol out of it!
Why? Why not use a single protocol that's widely tested and trusted by security experts? I mean, we didn't come up with a brand new encryption strategy for FTP, we made FTPS.
Why on earth would we want to use 5 different encryption protocols in the browser? That's just pointlessly adding attack surface. What's wrong with HTTPS that means it's a bad fit for encrypting a DNS query? A DNS query is essentially at its core an HTTP request to a remote server, and HTTPS is already very good at encrypting HTTP requests. There's no need to reinvent the wheel here.
By and large, I have not seen any real criticism of using HTTPS for DNS from security experts based on the technology itself -- they all seem to think the technology is fine. Virtually all of the current criticism from industry is coming from corporate players and ISPs who are mad that they won't be able to monitor DNS queries any more. And the fact that they're mad about that is strong evidence that DoH does provide a security gain. Corporations and ISPs would not be complaining about a privacy feature with no benefit to consumer privacy.
> it's nothing more than extra sugar on Cloudflares spying cake - and more funding for Mozilla
This is just blatant conspiracy. It's no harder for anyone to set up a DoH server than it is for them to set up a DNS server. There is nothing in DoH that gives Cloudflare more control over the web other than that they currently sponsor one of (if not the) most private DoH servers on the web today.
You can go into Firefox today and use any DoH server you want with zero consequence or downside. Chrome, by far the dominant browser on the web, does not use Cloudflare's DoH servers by default. There are reasons to be skeptical of Cloudflare in general, but if DoH in particular is a power grab by Cloudflare, then it's a pretty ineffective one.
> Why on earth would we want to use 5 different encryption protocols in the browser? That's just pointlessly adding attack surface. What's wrong with HTTPS that means it's a bad fit for encrypting a DNS query? A DNS query is essentially at its core an HTTP request to a remote server, and HTTPS is already very good at encrypting HTTP requests. There's no need to reinvent the wheel here.
This is where you're wrong. A DNS request is far from the same as a HTTP request!
You don't seem to understand how the technology really works in the underlying protocol.
HTTPS is designed to encrypt HTTP traffic, it was never designed to be stuffed by other kinds of traffic. When you stuff DNS into HTTPS you not only get a destination IP in clear text, something you cannot get if you use DoT e.g.
Furthermore, DoH also completely ruins analysis and monitoring of DNS traffic for security purposes. Already DoH has been used in a worm to mask connections to its command-and-control server.
If you want to solve the obvious problems with DNS, you don't keep doing the same mistake over and over again by patching with the same half-baked solution.
DoH does not solve ANY of the issues it is set out to do! I have worked for a long time in the ISP industry, users gets tracked by source IP and destination IP mainly, and figuring out what particular website they have visited, even when the hosting provider has multiple websites running on the same IP, is so easy just by looking at a hash of the payload that it is ridiculous.
DoH is "fake privacy". Period.
No, I don't see what you're getting at. DoH is an almost strict upgrade over DoT, specifically because DNS queries get mixed in with regular traffic so they can't be separated and analyzed on their own.
I stand by my point, the differences between DNS and HTTP are not large enough to justify the kind of separation you're advocating for. This is not such a fundamentally different technology that we need to use multiple separate systems to handle it, and people definitely shouldn't be advocating for DoT over DoH. The fact that DoT uses a dedicated port is a weakness, not a strength.
For you to argue that DoH is fake privacy, and then to advocate for DoT of all things as a superior alternative makes me skeptical of rest of your arguments. We don't want user DNS settings to be subject to the whims of network operators.
> Furthermore, DoH also completely ruins analysis and monitoring of DNS traffic for security purposes. Already DoH has been used in a worm to mask connections to its command-and-control server.
> DoH is "fake privacy". Period.
DoH can't be both fake privacy and masking worms/ruining traffic analysis at the same time. Either it works or it doesn't, pick a lane.
The fact that ISPs, governments, and network administrators are complaining about DoH is strong evidence that it is an improvement over the current system, because the whole point of DoH is to prevent 3rd-parties from doing traffic analysis and blocking on DNS queries without the user's permission for any reason at all.
ISPs would not be complaining about this if it didn't affect their tracking and blocking capabilities. Network admins would not be complaining about this if it didn't make their jobs harder. The fact that they are complaining about this means we're doing something right.
It's great if your recursive resolver is trusted (maybe you trust cloudflare or nextdns), but what if you don't trust anyone and want to run your own TRR? From what I can see from my own TRR the queries to authoritative DNS are sent in the clear... Edit On further thought, I realize that querying myanimememes.com's authoritative DNS CAN reveal which site you're interested in, but I believe most sites delegate their authoritative DNS these days to third parties.
You can do that today. Run your own DNS server w/ DoH as an endpoint (dnscrypt-proxy provides an avenue, you can also use nginx to do this). Then have enterprise policies on your network to point DoH clients to use this resolver.
https://mailarchive.ietf.org/arch/msg/dns-privacy/Fv91jt_n2-...
The trust model in this change for improved security do not sit in the technical and operational aspects of DNS and DoH (assuming we trust the math involved in encryption that we already use for things like https). What the model depend on is the Trusted Recursive Resolver, and if we find those third-party to be more trusted than other alternatives. Mozilla is however not doing much work to convince and explain why that program should be trusted. Who verify that the logs and commitments are followed through? What is the consequences if someone fails? How can the individual user who is giving away their private data exercise control and agency?
In the linked document the only answer that I can find is this: The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion.
I personally do not think that is enough for me in regard to my own data. Where I live (EU) I at least got GDPR to use if my ISP decide to go rouge with my data. I also got a contract with the ISP. In additional my country have a few different government agencies that in theory could jump in. Neither of those would be an option if the data is shipped over seas.
https://wiki.mozilla.org/Security/DOH-resolver-policy
Mozilla publicly lists the policies which TRRs contractually agree to. In addition to the above, the contracts (some of which have become public) also contain third-party audit requirements.
> What is the consequences if someone fails?
They lose their TRR status, presumably.
> How can the individual user who is giving away their private data exercise control and agency?
DoH is surfaced in Firefox, you can choose not to enable it, or you can choose to configure it to explicitly use any DoH endpoint your choose. On my network I use a Pi-Hole which talks to DoH on the backend and everything on my network is forced through the PiHole and all other DNS/DoH is blocked. You can use similar mechanisms, and Firefox surfaces preferences for DoH.
Just like any other decision, a sensible default which serves users needs to be made, and advanced users can configure things. Firefox chooses the sensible default of using encrypted DNS to trusted resolvers for users, and if you want to do otherwise, you are free to do so. Nothing removes your agency as a user.
> I personally do not think that is enough for me in regard to my own data. Where I live (EU) I at least got GDPR to use if my ISP decide to go rouge with my data. I also got a contract with the ISP. In additional my country have a few different government agencies that in theory could jump in. Neither of those would be an option if the data is shipped over seas.
Nothing in the current implementation ships data outside your jurisdiction. DoH is only enabled in the US pointed at a US-based provider (CloudFlare). There are numerous providers in the EU that may sign up to the TRR program as Mozilla gets to the point of rolling out DoH in Europe. This comment period gives them an opportunity to get feedback prior to getting to that point.
I think perhaps you should send them your feedback directly.
That way the user could exercise control and agency under contract law, and the cost of breaking the obligations would be financially in addition to loosing TRR status. It would also not make the situation worse compared to keeping the default in EU to be the users own ISP.
At most the user would loose the protection given by national consumer agencies, which for me would be a loss but for the average in EU might be less so.
Would CloudFlare agree to do so, or would they just drop out of TRR if such requirement were made?
Instead of making the decision for people, make it a nice feature for then to use as they see fit. As toggleable feature, it could provide options for not just DoH but for VPN usage, TOR, maybe other things.
these days, this will be mostly some *.amazonws.com domain.
This has evolved into the universal compromise, since the VPN provider still gets to claim that they themselves aren't doing any logging. But of course their upstream ISP is now easily able to do so.
This is why mullvad intercepts all DNS queries (even to 8.8.8.8 or 1.1.1.1). Try using OpenNIC from behind mullvad: you won't get the extra TLDs.
Logging DNS makes it easy to selectively deanonymize people. All you have to do is get them to browse to a website that resolves a weird domain name.
First, read this: https://en.m.wikipedia.org/wiki/EDNS_Client_Subnet
And this: https://tools.ietf.org/html/draft-hardie-privsec-metadata-in...
Then, start a VPN provider and wait for the NSL to arrive, like Mozilla did.
Not a coincidence that they suddenly started pushing DoH hard shortly after launching their own VPN. Before that it was just another protocol; after the VPN they suddenly were in a big huge hurry to put people on DoH by default whether the system resolver supported it or not.
For the rest, encrypted SNI might help, but it's still a draft so not really in use. Also 95%+ of sites are identifiable by IP only.
If your VPN provider claims they "don't log" it just means they're tagging the query with your IP as it leaves their network and letting their upstream ISP do the logging.
Never, ever, send UDP/53 traffic into a VPN.
DNS setup is messy.
I can get torrents just fine ofc. More curious how Ziggo is intercepting the requests.
There’s absolutely no way for home gateway/DNS to defend against malicious use of DNSSEC proper through DoH at application level.
what does that mean?
Sadly not going to happen
- they want DNS over TLS [multiple reasons why].
- they want to work around "problems" in the architecture of DNS.
- they want to force new functionality [read: protocol changes] on users without other DNS infrastructure adopting it.
- they can.
If you love privacy more than freedom, DoH is great. If you want the internet (and local/private networks) not to resemble America Online, DoH should frighten you.
And DoH is harder to block once they go port 53 or https “incorrectly”.