Here[1] is their reason; "The reason for this radical change is twofold: 1) I want encourage adoption of encrypted and authenticated DNS, and 2) I am sick of fighting UDP amplification attacks."
1. https://blog.uncensoreddns.org/blog/39-the-unfriendly-intern...
If anyone has the idea that traditional 512-byte UDP-based DNS is now useless, then I think that's crazy. I still use it all the time, particularly on the home network. I would be willing to bet some (not all) DoH providers are using traditional 512-byte DNS for their backend queries. I use remote DoH heavily outside the browser. I also run DoH servers on local computers.
You are correct. In fact they have no choice in this matter unless they are just daisy-chaining to other DoH/DoT servers. The real internet still uses plain unencrypted UDP and there is no guarantee the server one is talking to supports EDNS. The root servers do not support DoT/DoH and most corporate DNS servers do not support DoH/DoT. Some of those also do not support EDNS. A small handful of the paid DNS providers offer DoT but it isn't like clients would know to use that by default. Some cell phones and some browsers are the only clients that to my knowledge will try to enumerate if DoT/DoH is available.
Regarding 512 byte queries, EDNS is opportunistic. Not everyone supports it and one can not assume it is supported. That is negotiated. DNS Flag day(s) [1] were supposed to encourage everyone to enable EDNS and standard size limits of 1232. Without EDNS some traffic will revert to TCP and not everyone has that enabled to my surprise.
I have a handful of DoT servers and they just talk plain UDP to the root servers. I've thought about making some of them public as a learning exercise to see what riff-raff shows up though I suspect I will be spending some time tuning rate limits and firewall rules.
As a side note, I was actually surprised to find that Android figured out I had DoT on my home network and I didn't even git it any hints. Seems it just probed the gateway for 853 and got lucky.
It is one thing to use DoH if port 53 is being filtered, but that is a relatively small population of internet users. Forcing everyone to use DoH inside an ad-sponsored application like a web browser or a corporate OS like Android, versus providing it as an option, is questionable, IMO.
Do you use OpenWRT. OpenWRT routers with mwan3 enabled by default are pinging open resolvers, public DNS caches, like GoogleDNS, Cloudflare and Cisco OpenDNS to check for connectivity. These are considered "reliable IP addresses to ping".
https://web.archive.org/web/20220629175529if_/https://github...
https://openwrt.org/docs/guide-user/network/wan/multiwan/mwa...
Why not ping a root server instead. Even a com nameserver is more important than Google LLC.
EDNS is opportunistic but we can disable/remove it altogether before compiling our DNS servers. Or we can use DNS software, e.g., djbdns, that will never support it.
They may have an abuse@opennic address they've never opened. An ignored problem isn't a problem, well until it is.
Or they may deal with it and not mention the costs of doing so.
Opening port 53 means having to set up a system to prevent abuse. Multiplication attacks through DNS are still as common as ever and mitigation can be incredibly difficult if a botnet is attacking a wide range of IP addresses.
Putting everything behind encryption not only makes life just a tad more private (especially when using ODoH, using which your DNS server can't even know what domains your IP is visiting, though I'm not sure if they support that) while also reducing the complexity of the service they're running.
There are downsides for sure, but I think they don't outweigh the benefits.
It's like, if in response to cars on a certain stretch of road hitting bicycles, you know building a protected bike lane is the best solution. But it's expensive, and it may limit parking, or the amount of lanes for cars, or their max speed. So instead you require everyone to put their bicycle in a car, or just bike on the street and risk being hit.
Nobody wants to deal with the real problem, so we instead institute hacks and try to ignore the problem as long as we can. Anything to avoid expense, cooperation, re-building.
DNS over TCP is actually slower in many configurations, at least the ones I've tested. HTTP libraries and servers have been developed for fast opens with (probably protocol violating) workarounds for getting rid of the handshake in any way they can but DNS implementations seem to care very little, especially on the client side. 1-RTT TLS fixes serious connectivity annoyances while also providing security benefits at minimal overhead.
I personally prefer DoT over DoH, but the industry is moving away from DoT. Taking DNS, which is a fine protocol lacking encryption and sessions and adding encryption and settings is a very simple solution. An nginx stream proxy forwarding TLS traffic for port 853 to 53 is enough to set it up if you're not bothered by the handshake time that can be negligible in the age of 5G and fiber connections if you live in the right area.
Sadly, the "let's turn everything into JSON so I don't have to learn what bytes are" crowd won and becoming an old man yelling at the cloud doesn't solve anything. At least ODoH provides some additional benefits that just encrypting DNS doesn't at the cost of extra latency, though I'm disappointed with how its rollout is going.
Personally, I use DNS over UDP to my local PiHole which deals with all the secure DNS lookup protocols. This way only one device needs to maintain connections and deal with session resumption while every other device can rely on the simplicity and speed of UDP connections. Not exactly a defence-in-depth approach but it works well enough for me.
A real solution would be to meaningfully extend DNS in some way but doing so would require backporting this new protocol to at least ten years of computers, tablets, smartphones and IoT devices. I'd welcome a new protocol that fixes these issues if all I'd need is install another app or set up a forwarding service for legacy software, but most of the world wants something that Just Works(TM) and that Windows 7 server in the basement everybody hides when the auditor visits still needs to work.
DoH uses raw bytes for DNS answers and not json: https://www.rfc-editor.org/rfc/rfc8484#section-6
The idea behind it remains the same. HTTP/http2/http3 as a carrying mechanism for an existing binary format makes no sense when none of the benefits of the new format are actually coming from the HTTP protocol. This only increases the attack surface and complexity of the protocol. I don't know, maybe there's a benefit to setting cookies and language headers for DNS requests but I'm not seeing it. The only potential benefit touted in the RFC is that web applications can now do DNS lookups in a standardised way and I don't see how that's a benefit for anyone but user hostile companies.
Now we've reached the situation where HTTP/2 server push has been deprecated in almost all browsers but is still part of the DoH spec. I don't see the benefit of including server push support in the first place but because it's part of the standard we'll have to deal with potential servers relying on features disabled in libraries or unmaintained code in libraries that lays dormant because the major consumers of HTTP have stopped calling their methods.
And pretty much anyone can run a personal DoH stub resolver for ~$0: https://github.com/serverless-dns/zero
Just DoH won't save you from an oppressive government and neither will DoT. You can run DoT on port 443 and it'll appear as normal TLS traffic as well. Unless the state actors are doing extensive fingerprinting (that will expose DoH servers as well) I doubt it'll make a difference in situations where DoH makes sense. In areas where occasional government TLS MitM attacks are common, neither DoH nor DoT will protect you.
Almost certainly. Mullvad is way out there when it comes to privacy. They recently got rid of recurring subscriptions because they said they didn't want to store any PII.
as much as this may be a noble goal, as a user i want to have the option of a recurring subscription, especially if i pay monthly (which i prefer to, unless i'm really committed to a service or the yearly subscription is cheap enough that i'm sure i won't regret it). if it's just one or two services doing this it's not a huge deal, but imagine getting emails from tens of different services each month to renew, especially if you have to log in and enter your credit/debit card details on each one separately. is there a reason they can't simply store a token from stripe/paypal/etc, or is that still considered PII?
They do still accept those payment methods, and that is exactly what they do for them[0], but recurring payments forced them to retain that data for longer than they were comfortable with, and they decided that the cost to privacy outweighed the convenience recurring subscriptions offered[1].
Another thing to note is that you won't be getting any e-mails from them reminding you to renew your plan, since they never had your e-mail in the first place (Mullvad "accounts" are anonymous numeric tokens).
[0] https://mullvad.net/en/help/no-logging-data-policy/#payments
[1] https://mullvad.net/en/blog/2022/6/20/were-removing-the-opti...
It's very unusual. The vast majority focus primarily on getting this to work as friction-less as possible.
You're right. They are doing this to better protect their users, just like when they stopped accepting recurring payments.
> Some people will surely switch to the encrypted versions, but others will just go looking for a different dotted quad to drop in, one possibly less secure.
I feel like almost everyone who already went out of their way to use Mullvad in the first place will do the former.