DNS Wars
potaroo.net
potaroo.net
Well this is false, and misleading. The connection to Sidefinder is a red herring -- sitefinder was applied Internet-wide, OpenDNS was a choice. Saying OpenDNS redirected www.google.com isn't accurate either. There was a URL that was redirected for a portion of users for a very short period of time because Google installed a hijacked version of the Google toolbar, and once we did this, they reverted their erroneous behavior and we reverted ours and we wrote about it extensively (https://umbrella.cisco.com/blog/2007/05/22/google-turns-the-...).
Geoff knows better, but is being lazy or sloppy while trying to provide a historical record. A shame, because it's a worthwhile topic to go over.
The real conclusion he fails to make is that between Android, Chrome, and Google Search, there is a total monopoly on navigation for the vast majority of the Internet. That's distressing, and until there is a major platform shift, it's hard to see that changing.
I thought that was his conclusion (basically).
It don't think it's entire unfair to say it was reminiscent in concept though. In both cases where someone would expect NXDOMAIN they were served something else just so a company could make money. Users did have more choice in using OpenDNS, and this was something that caused people to switch away from them.
Fair point on the google thing though. That should have been clarified.
https://old.lwn.net/2001/0208/security.php3
This event made the Internet realize that there was, at the time (early 2001), no viable open source DNS server besides BIND out there:
https://old.lwn.net/2001/0208/
Since then, MaraDNS came out, then NSD and its sister resolver Unbound came out, djbdns finally became open source [1], and Knot DNS came out this decade.
[1] As an aside, I don’t know of any currently maintained djbdns fork. N-DJBDNS has not had a formal release since 2014 ( http://pjp.dgplug.org/ndjbdns/ ), and the maintainer has not closed a bug since 2017 ( https://github.com/pjps/ndjbdns/issues?q=is%3Aissue+is%3Aclo... ). Perhaps @tptacek is willing to step up to plate and make an actively maintained version of djbdns. But I get the feeling I will end up maintaining both my own MaraDNS and a fork of N-DJBDNS.
* https://en.wikipedia.org/wiki/Internet_Systems_Consortium
I have no idea what the details were, but if you're going to make a buck off BIND by being a vendor of some kind, then paying for "early-access" is not crazy-unreasonable IMHO. As noted in the e-mail "Not-for-profit members can have their fees waived", so they're not trying to milk folks like the BSDs.
Vendors were free not to pay, but they'd only know about the issue when the public announcement went out with no advanced warning.
I find it interesting that it avoided DNSSEC, perhaps recognizing it as a skirmish rather than an episode of the greater war. This is probably accurate, DNSSEC has never actively steered DNS in any particular direction, it’s much more passive and therefore doesn’t represent something that needs to be directly fought. Pick your battles, this one is not worth fighting, probably because there’s nothing to gain or lose (from a control perspective) in it succeeding or failing.
Tying everything back together with the discussion of Westfalia is really interesting, because it raises an interesting topic. The ability to control the content that users have access to, and the ease of doing so. DoT and DoH make it much harder to easily intercept DNS packets and manipulate or deny responses to them (edit: to be clear it denies network operators this control, but of course the chosen resolver has even more ability to do so). It denies a method of control that network operators have over the users of that network. This control was never perfect, sophisticated (and not even that sophisticated) actors on the network could always circumvent this control of DNS. It really only prevents the majority of people, non-bad actors in general, from circumventing the network operators controls (when considering only DNS as that control mechanism).
This is probably a good thing for the user, because it will force the network operators and countries, to start treating good actors and bad actors the same, rather than only controlling and monitoring the unsuspecting normal user, while leaving the doors open for the bad actors. In the Westfalia time period, it would be the difference between the citizen relying on traditional imports vs. the smuggler to avoid all tariffs, because the coasts were large and it was somewhat easy to avoid the navy’s of the large states at the time.
I understand the approaches of DoT and DoH but people keep talking about privacy and tracking but it just seems like you can just run your own un-DNS server and get the same info by looking up the IP to get the DNS. You can still be monitored and controlled by IP, right?
DoH has the added benefit of hiding even the fact that you are making a query. That means your ISP can not block it and force you to use a non-encrypted algorithm.
You can still be monitored by IP, but:
- there isn't an exact 1 to 1 relation between IP and domain name
- it still stops the ISP from messing with the results
1) connection security, by which I mean, the DNS packets can not be actively manipulated. DNSSEC in theory helps with this too, but there's no way to distinguish in DNSSEC between a response that doesn't have any DNSSEC data vs. one that was modified to remove the DNSSEC data for nefarious purposes (i.e. allowing the response packet to have other unsigned records to be inserted in the response). DoT and DoH (and DNSCrypt before them) prevent this form of data manipulation.
2) Privacy, which you mention. This one is a little shaky, it protects you from the ISP or others monitoring the network traffic, from seeing the DNS request and response in the raw. If the next connection is TLS (for a website), until SNI is encrypted in TLS 1.3, then the name of the site is potentially disclosed in the raw on that next connection. Even so, the IP itself discloses a significant degree of information about that connection, though as more sites sit behind CDNs, the value of that information goes down.
At the end of the day, with DoH and DoT, the privacy and data authenticity responsibilities are being passed off the the chosen resolver, which the article mentions as Google or Cloudflare in many cases. So now you're trusting those entities, for better or worse, with all that information.
AFAIK, this is false. If you get a faked reply, you can see from the signatures of the parent zones that the reply should have been DNSSEC signed, and is therefore fake.
I will add, though, that as you walk the tree back to the roots, downgrades in the key strength do happen as you get to the root 1024bit keys, which is unfortunate.
Aside from that, if DNSSEC is detected to be blocked, or invalid, there’s currently not great mechanisms of signaling this to end users (in most software) to either opt into the security risk or notify them, beyond just failing the lookup.
I was under the impression that the root key is now 2048 bits, since October 2018, over a year ago.
> there’s currently not great mechanisms of signaling this to end users
Not unlike SMTP, but we seem to have managed to transition to mostly TLS-encrypted mail transport.
And yes, I should have been clearer in my time period reference.
That's a bunch of crap.
I am unaware of the affiliation of the author, so I’m not trying to defend that relationship or the entities mentioned.
Factually, it all seems accurate, though it could very easily be argued that it leaves some things out and leans in a particular direction on all of the issues it does cover.
Credit card fraud.
* https://www.youtube.com/watch?v=1hu6cNf0eDo&t=14m
He gave a similar talk at EuroBSDCon 2019 a little while ago. There were two other DNS talks at NANOG on the Wednesday: "DNS Transparency Project" (4h3m30s) and "Analyzing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web" (7h20m20s):
* https://www.youtube.com/watch?v=9JSG7RS8imk
* https://www.nanog.org/meetings/nanog-77/nanog-77-agenda/
After NANOG, the DNS folks got together for DNS-OARC 31, with various talks on DoT/DoH as well (amongst other things):
This culminated in RFC 8482, co-authored by Cloudflare, unsurprisingly legitimizing Cloudflare’s position.
Ironically enough, avoiding the "expensive" query type resulted in potentially doubling the amount of DNS traffic from a typical dual-stack client ("A?" + "AAAA?" instead of single "ANY?")
EDIT: ...or warranted adding laggy heuristics that eventually settles into either, as Avamander points out below.
On the other hand, deprecating "ANY" requests as standard, once percolated into BIND and other resolvers, would cut the attack[2] on the amplification stage (middle of the picture of [1]).
[1] https://www.cloudflare.com/img/learning/ddos/dns-amplificati...
[2] or at least significantly decrease choice and depth of large amplification factor requests available to the attacker.
Edit: Also seems to still be the case when you have your resolver set to a v6 address.
No, they explicitly say it was “too expensive”. The traffic amplification excuse is why they got away with doing it – they, themselves, do not benefit from that aspect. Note that most other DNS vendors in the world has kept ANY queries. Cloudflare removed ANY queries because it does not fit their data model of what DNS is, and faking the correct reply to ANY queries as the standard DNS data model would require would be hard for them, since they don’t operate that way, and they don’t see DNS like that.
The Client Subnet is meh. It would be nice. Just as Akamai providing a map. But if you want that extra privacy use a resolver that always passes its own subnet forward.
DNS push in the browser without DNSSEC. Wow. Now that's bad. But if it gets limited to subdomains of the current domain only, then no one will care.
I do not see how the two are equivalent.
DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point).
HTTPS does protect exact content (like SSH), but the fact that you are going to (say) wikipedia.org, eff.org, or torproject.org, is much more difficult to hide because at the end of the day, if you're not using VPN, the network operator can see where your Layer 3 addresses are going to and can make inferences about your actions. And in some places inferences are 'good enough' to get you in trouble, or at least flagged for further monitoring.
> DoH is also not meant to "hide" what you're doing as much as it is about enabling you to protect your DNS queries from manipulation.
Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;)
If that's the aim then I have to concur that DoH does nothing here. This is why I dislike the way Mozilla touts DoH as a privacy feature, because that's not what it (primarily) should be about, as far as I'm concerned.
> Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;)
Agreed. But that's exactly why you can pick a trusted resolver, right? One that you trust to correctly validate DNSSEC for you, so you simply trust the AD bit in the response instead of doing all this on each and every client. And one that you trust not to mess with answers in general. Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste.
Part of Vixie's talk was about the changing nature/position of the recursive resolver: when he started DNS stuff in 1988, it was often the case that there was a resolver right on the subnet that you were on, often living on the default gateway.
As time has gone on, it started moving "up" closer to the cloud (as we now call it): to being building-wide, then to the campus, and now generally the ISP. (Though local CPE routers have a caching resolver nowadays, they often go to the ISP's service.)
Now we're talking about having DNS 'in the cloud' (i.e., Internet) from some distant provider, often close (network/latency-wise) to the service that we will eventually connecting to once we get the look-up from.
And 99% of interesting traffic is over HTTP.
For email there's MTA-STS (basically HSTS for SMTP), for everything else... um, what's left actually? (P2P networks, but for that VPN is recommended anyway.)
Sure, inference from L3 data is still possible. But there's a big difference between looking at just "tumblr", "wordpress", "blogspot", or knowing that you look at which blogs.
Ultimately, I think any sort of content blocking is going to have to happen on client machines. Or at least via a mechanism which depends the client machine's active cooperation. Anything less just opens users up to interference from malicious third parties.
> The network isn't (usually) under the user's control, and as a result any reasonable threat model for software running on client machines should assume the network is actively malicious.
Yes, but there is nothing about DoH that solves this in any way.
"The Internet has been changed irrevocably from being a tool that allows computers to communicate to a tool that allows enterprises to deploy tools that are intended to monetise users in a highly efficient and effective manner."
Is there a problem with monocultures? Yes, of course, but our lives are now spread out over space and time a lot more. I'm writing this 19 hours after your comment, very likely from a different country. Just a few minutes ago I was looking at Skype (work, a full-remote team), and Messenger (friends, a group chat where accidentally everyone happens to be hundreds of miles from each other) before that.
It's not just a "communications" thing anymore. And it's distributed our lives in both space and time.
NAT and asymmetric connections beg to differ. Also email.
For DoH, I guess there are more pitfalls to avoid (http cookies, connection reuse, tls session cookies, etc), but those are all things you can avoid if you configure your client correctly. I don't see how using a centralised provider would automatically compromise your privacy.
(It's playing with fire though, I admit that)
That would estimate your friend's public resolver at serving about 20 users, though I guess could be anywhere between 1 and 300.
See also last week's NANOG 77 talk "Analyzing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web" (7h20m20s):
* https://www.youtube.com/watch?v=9JSG7RS8imk&t=7h20m20s
It focuses on the end-user impact / experience. Encrypted DNS can actually be as fast, if not faster at times, as plain DNS ("Do53") under certain conditions. Once a TCP/TLS session is setup, it can be kept up: you don't have to tear it down every time.
Do you know of any studies or released cost breakdowns that show this? Depending on your view, DNSSEC might be considered to be operationally more costly. But also modern equipment is pretty good at this task.
Even now many services use domain fronting. Law enforcement and IT/corp security alike need to focus on endpoints. Dragnet surveillance and perimitet filtering never did get the real bad targets.
>Oddly enough the result is that Google’s public DNS offering is now totally dominant in the open resolver space. If this was a three-way struggle between infrastructure-based DNS, Open Resolvers and Google’s Open Resolvers, then it looks like Google won that round.
https://xkcd.com/1361/ now sounds more true than ever
Russia and China would beg to differ. UK could totally dictate terms if they had protected their own market and infrastructure, but they didn't, so now Google/Apple/Mozilla call the shots.
Later in the wars I would expect ISP to once again regain their access to DNS data if DoH became default. CDN's must cooperate with ISP in order to be a content delivery network. It is very hard to operate an anycast network with server located near the edges without close relation with the operators of those edges. Most times the DoH server is going to sit at the ISP server hall, next to the ISP own resolver. In some places it can be the same physical machine and just separated by software. The border is not going to be very bright between the sovereign domain of the CDN and the ISP.
A CDN pays ISPs, carriers, and network operators for hosting its servers in their data centers. ISP do this because it provide them revenue and better service to their customers.