"The DNS was co-opted in this effort and OpenDNS tried to achieve this with a recursive resolver that performed NXDOMAIN redirection into a search engine, in a reprise of Sitefinder. For a short period, OpenDNS also redirected the domain name www.google.com to a different search engine."<p>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 (<a href="https://umbrella.cisco.com/blog/2007/05/22/google-turns-the-page/" rel="nofollow">https://umbrella.cisco.com/blog/2007/05/22/google-turns-the-...</a>).<p>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.<p>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 am really surprised they did not mention when the Internet community got upset that ISC/BIND monetized their open source server by having a closed mailing list to discuss BIND security holes:<p><a href="https://old.lwn.net/2001/0208/security.php3" rel="nofollow">https://old.lwn.net/2001/0208/security.php3</a><p>This event made the Internet realize that there was, at the time (early 2001), no viable open source DNS server besides BIND out there:<p><a href="https://old.lwn.net/2001/0208/" rel="nofollow">https://old.lwn.net/2001/0208/</a><p>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.<p>[1] As an aside, I don’t know of any currently maintained djbdns fork. N-DJBDNS has not had a formal release since 2014 ( <a href="http://pjp.dgplug.org/ndjbdns/" rel="nofollow">http://pjp.dgplug.org/ndjbdns/</a> ), and the maintainer has not closed a bug since 2017 ( <a href="https://github.com/pjps/ndjbdns/issues?q=is%3Aissue+is%3Aclosed" rel="nofollow">https://github.com/pjps/ndjbdns/issues?q=is%3Aissue+is%3Aclo...</a> ). 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.
This is a great history of DNS. I didn’t really notice any inaccuracies. I especially like the way that client subnet was discussed, but of course that’s because I agree with the author.<p>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.<p>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 <i>easily</i> 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).<p>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.
As mentioned in the article, Paul Vixie gave the keynote at the recent NANOG 77 (October 2019 in Austin, TX) entitled "<i>DNS Wars: Episode IV - A New Bypass</i>" (about 14m in if the timestamp does not work; it's about an hour with Q&A):<p>* <a href="https://www.youtube.com/watch?v=1hu6cNf0eDo&t=14m" rel="nofollow">https://www.youtube.com/watch?v=1hu6cNf0eDo&t=14m</a><p>He gave a similar talk at EuroBSDCon 2019 a little while ago. There were two other DNS talks at NANOG on the Wednesday: "<i>DNS Transparency Project</i>" (4h3m30s) and "<i>Analyzing the Costs (and Benefits) of DNS, DoT, and DoH for the Modern Web</i>" (7h20m20s):<p>* <a href="https://www.youtube.com/watch?v=9JSG7RS8imk" rel="nofollow">https://www.youtube.com/watch?v=9JSG7RS8imk</a><p>* <a href="https://www.nanog.org/meetings/nanog-77/nanog-77-agenda/" rel="nofollow">https://www.nanog.org/meetings/nanog-77/nanog-77-agenda/</a><p>After NANOG, the DNS folks got together for DNS-OARC 31, with various talks on DoT/DoH as well (amongst other things):<p>* <a href="https://indico.dns-oarc.net/event/32/timetable/#all" rel="nofollow">https://indico.dns-oarc.net/event/32/timetable/#all</a><p>* <a href="https://www.youtube.com/DNS-OARC" rel="nofollow">https://www.youtube.com/DNS-OARC</a>
Something not mentioned is Cloudflare’s unilateral decision in 2015 to “deprecate” DNS queries of type “ANY”, simply because they thought it would be “too expensive” to follow that part of the DNS standard.<p>This culminated in RFC 8482, co-authored by Cloudflare, unsurprisingly legitimizing Cloudflare’s position.
The VPN over HTTPS vs DoH argument is interesting. But probably a lot more peoole will benefit from DoH if shipped by Mozilla, Google, Apple than by setting up a VPN manually. (VPNs are a lot more resource intensive than a DNS resolver. Plus they have serious legal consequences too, just like running a Tor exit node.)<p>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.<p>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.
This put into words something which to me is very unsettling about the latest DNS developments.<p>"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."
The most interesting part of this, for me, was "Episode 6 – Resolverless DNS Wars", as it is an episode that hasn't quite started yet (and so I don't already know a lot about it).
I am personally excited about DNS-over-HTTPS-over-TOR. No one can see what DNS you are requesting except for the TOR hidden DNS service which does not know who you are. Seems like the best possible mass-usage of TOR. Anyhow, that is my prediction where the next DNS war takes place.
Another point not mentioned in the article is that encrypted DNS (be it DoH or DoT) requires significantly more resources to run a public recursive resolver. You have to either monetize it somehow or fund it with money from your other business. So it means more centralization and less neutrality.
There is huge value in documenting the history of the internet in articles like this. I would love to see an article like this on other technologies like BGP, SSL, and Wifi for example.
>For a short period, OpenDNS also redirected the domain name www.google.com to a different search engine. Within a few weeks, Google launched their public DNS on quad 8 and based the service on absolute integrity of both positive and negative responses in the DNS. A ‘trustable’ DNS tat undertook to never lie.<p>>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.<p><a href="https://xkcd.com/1361/" rel="nofollow">https://xkcd.com/1361/</a> now sounds more true than ever
"<i>Part of the new world order is that the space defined by the actions of applications is well beyond the traditional domain of communications regulation and even beyond the domain of regulation trade and commerce.</i>"<p>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.
Looking at the last section of the article it brushes onto an other war between content delivering infrastructure. The current war for DoH dominance is between google and cloudflare, with chrome and firefox being the bannermen, but a more general perspective is that DNS data is becoming a war between CDN's.<p>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.