
DNS Wars - r4um
https://www.potaroo.net/ispcol/2019-11/dnswars.html
======
davidu
"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."

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-...](https://umbrella.cisco.com/blog/2007/05/22/google-turns-the-
page/)).

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.

~~~
thayne
> 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.

I thought that was his conclusion (basically).

------
strenholme
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:

[https://old.lwn.net/2001/0208/security.php3](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/](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/](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...](https://github.com/pjps/ndjbdns/issues?q=is%3Aissue+is%3Aclosed)
). 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.

~~~
throw0101a
I can understand why people got upset, and more variety is a good thing, but
it should also be noted that ISC is a US non-profit, and they have to pay the
bills as well:

* [https://en.wikipedia.org/wiki/Internet_Systems_Consortium](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.

~~~
tptacek
Requiring payment for vulnerability fixes isn't reasonable; it _deliberately_
externalizes security problems BIND itself creates. If they couldn't provide
software for free with vulnerability fixes, they shouldn't have provided it
for free at all.

~~~
throw0101a
The fixes do not require payment (which would be hard to do with open source
software). What required payment was a type of support contract or membership
fee for early access.

Vendors were free not to pay, but they'd only know about the issue when the
public announcement went out with no advanced warning.

~~~
tptacek
I'm familiar with the "support contract" we're discussing, and it was for
"early" access to vulnerability details.

------
bluejekyll
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.

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.

~~~
zzzcpan
The author pushes one sided Cloudflare's line on both client subnets and DoH
(given APNIC maybe he should disclose affiliation). There is nothing accurate
about it. Client subnet extension doesn't violate any privacy in any threat
model you can imagine, Cloudflare just wants all the competing CDNs, which are
DNS based, to get more wildly inaccurate results on picking nodes. And DoH is
outright anti-privacy tech pretending to be about privacy, since a lot of
people have no clue that encryption is orthogonal to privacy.

~~~
jgrahamc
> Cloudflare just wants all the competing CDNs, which are DNS based, to get
> more wildly inaccurate results on picking nodes.

That's a bunch of crap.

~~~
kodablah
So is their sentence after that one.

------
throw0101a
As mentioned in the article, Paul Vixie gave the keynote at the recent NANOG
77 (October 2019 in Austin, TX) entitled " _DNS Wars: Episode IV - A New
Bypass_ " (about 14m in if the timestamp does not work; it's about an hour
with Q&A):

* [https://www.youtube.com/watch?v=1hu6cNf0eDo&t=14m](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.youtube.com/watch?v=9JSG7RS8imk)

* [https://www.nanog.org/meetings/nanog-77/nanog-77-agenda/](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):

* [https://indico.dns-oarc.net/event/32/timetable/#all](https://indico.dns-oarc.net/event/32/timetable/#all)

* [https://www.youtube.com/DNS-OARC](https://www.youtube.com/DNS-OARC)

~~~
autoexec
Thanks, I was just about to go digging for this stuff myself!

------
teddyh
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.

This culminated in RFC 8482, co-authored by Cloudflare, unsurprisingly
legitimizing Cloudflare’s position.

~~~
kees99
Cloudflare killed "ANY?" because it was a significant vector in DNS
amplification attacks.

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.

~~~
belorn
It would surprise me if cloudflare relied on blocking "ANY" for DDOS
mitigation. Most modern resolver have builtin response rate limiting, and I
would expect cloudflare to have multiple additional mitigation methods to
prevent malicious actors from exploiting their servers.

~~~
kees99
In a DNS-amplified DDoS attack, target (CF for example) would be on the
receiving end (right-hand side of [1]), and blocking, while necessary, would
not be terribly efficient there.

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...](https://www.cloudflare.com/img/learning/ddos/dns-
amplification-ddos-attack/dns-amplification-attack-1.png)

[2] or at least significantly decrease choice and depth of large amplification
factor requests available to the attacker.

------
pas
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.)

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.

~~~
karasu
I think the VPN vs DoH argument is a fallacy. You could argue the same way for
things like telnet vs ssh and it would make just as little sense. In addition
a VPN is much more complex than simply using DoH or DoT. 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. The only difference to the more direct
approach (DoT) here is that DoH acknowledges the reality we live in where
networks where DoT makes the most sense block anything but http/https traffic.

~~~
throw0101a
> _I think the VPN vs DoH argument is a fallacy. You could argue the same way
> for things like telnet vs ssh and it would make just as little sense._

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. ;)

~~~
karasu
> 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).

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.

~~~
throw0101a
> 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.

------
jacobush
This put into words something which to me is very unsettling about the latest
DNS developments.

"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."

~~~
pas
The basic Internet is still there. Of course the purpose changed from a
defense experiment to an academic communication tool to a general
communication substrate to a basic building block of a highly distributed
world/society/era.

~~~
jacobush
Highly distributed? Facebook, Google, Amazon and to some extent Apple dominate
and they are extremely _centralized_.

~~~
pas
Fb, G, MS, Twitter, Atlassian, Reddit, and a lot of companies provide the
infrastructure that literally billions of people use to better their lives.
They are able to organize, communicate, collaborate, share, search, store,
work, supervise, have fun, discuss, learn online.

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.

~~~
jacobush
So, you agree and list a bunch of benefits to the centralization.

~~~
pas
What? Okay, let's forget for a moment the companies and the "implmenetation"
of these functions. What I'm trying to say is that the "internet" as such is
now a fundamental, essential, non-separable part of many of our lives.
Companies run on slack/skype/JIRA, email, voip, businesses depend on the
internet, webshopping is basically the default for millions, sports groups
live on the internet (StarCraft, DotA), content creators live on the internet,
citizen politics depends on the internet a lot of times in turbulent regimes
(streaming rights violations).

It's not just a "communications" thing anymore. And it's distributed our lives
in both space and time.

------
saurik
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).

------
really3452
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.

~~~
zzzcpan
Connecting to a centralized DNS provider over tor defeats the purpose of tor
and makes it easy to deanonymize your traffic completely.

~~~
xg15
Does it? If you use regular DNS, how would it identify your requests? (as it
cannot rely on the IP address)

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)

------
ComodoHacker
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.

~~~
jstanley
A friend of mine runs a public DoH server at
[https://doh.li/](https://doh.li/), and is "currently handling ~220k req/day
with a $10/mo DO instance, no optimisation at all, CPU load is at 20%" so I
don't think running a public resolver is at all beyond the reach of a
hobbyist.

~~~
labawi
Well, checking my resolver statistics from a random day, it clocked about 8000
queries. Discounting some for mail, it leaves 7+k from my own browsing.

That would estimate your friend's public resolver at serving about 20 users,
though I guess could be anywhere between 1 and 300.

------
jstewartmobile
" _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._ "

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.

------
badrabbit
We have a different kind of DNS war these days with DoH and DoT and everyone
who does not know what SNI in TLS is.

~~~
bluejekyll
The article does mention SNI encryption coming in TLS 1.3, and if I remember
correctly, discusses how this will make the DoH and DoT privacy story
stronger.

~~~
badrabbit
Makes sense to block eSNI than DoH/DoT then?(for people that desire the
blockage). Even without eSNI sites can use CDN s with CNAME records being used
for the TLS SNI (e.g.: site.com has xxx.cloudfront.com as CNAME,browser
connects to cloudfront with CNAME record in SNI but requests site.com in the
http Host header to get the correct site...essentially domain-fronting).

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.

------
Yuval_Halevi
Make great infrastructure. Not war.

------
iooi
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.

------
noway421
>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.

>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/](https://xkcd.com/1361/) now sounds more true than
ever

------
auslander
Is DoH capable of storing and serving cookies? I always wondered.

------
belorn
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.

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.

~~~
wbl
Why do ISPs need to see DNS data?

~~~
belorn
ISP use DNS data for monetization, like selling it to advertisers. There is
also a political aspect for many ISP where there is close cooperation with
local government, and the need to comply to request of filtering is pretty
high in some countries.

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.

