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).
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."
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.
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.
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.
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.
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.
The problem is that it's not realistic to expect client machines to be able to distinguish between blocking for "good reasons" or "bad reasons". 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.
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.
On the flip side; the client device is increasingly outside the control of the user (phones, smart speakers, TVs etc). So there's the question of how a user protects themselves against a device that may be actively or incidentally malicious.
> 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.
Network is under user control, pretty much all devices require active cooperation to connect device's internal network to any external network, it doesn't happen on its own.
> 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. ;)
> 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.
> 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.
Mozilla cares about HTTP security first and foremost, as they are a browser vendor. And TLS with ESNI takes care of that. But it punts the problem at DNS. And DoH solves that.
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.
I could see a business argument for a CDN to provide a free VPN for the browser, just like cloudflare is doing with DoH. If everyone is connecting to their server first, and keeps the connection alive, then websites hosted at them will gain a small performance boost. The CDN would also gain massive relative speed, as accessing services outside of the CDN would be comparable slower.
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.
My point that I was trying to make is that DNSSEC being focused on authenticating the existing DNS record data, and not on the control and protocol plane, leaves it out inside of control issues. Sure it enshrines the existing roots and the ultimate authorities for the correctness of DNS, but this is already true, and going against it means a fork of DNS in a sense which doesn’t seem like anyone really wants.
It's a good typo. Sometimes all the Sturm und Drang surrounding DNS feels like a consequence of DNS people having started to un-ironically view their (important, no doubt) work in terms of the Peace of Westphalia instead of the Volkswagen Westfalia camper van.
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.
By accurate I didn’t mean unbiased, the client subnet discussion clearly shows a bias against the feature. I wouldn’t say it was inaccurate—though, the article definitely comes down strongly against it.
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.
"DoH is outright anti-privacy tech" in what way? DoT and DoH are functionally equivalent, the only practical difference being that DoT can be filtered by ISPs and network operators, and DoH can't. DoH is simply DoT without the kill switch.
Dumb question: What does encrypted DNS really solve? Is it just that you know the DNS will be resolved by the server you chose and not modified?
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?
It stops your ISP from messing with the DNS results, including from removing the DNSSEC information. It also stops them from reading all your DNS queries, even if you create a local cache you'll still need to query the network at least once on every domain you connect, encrypted DNS hides that one query from your ISP.
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
There are two things it helps solve, but doesn't solve completely.
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.
> 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
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.
The resolver has, hard coded, the root zone keys. If the resolver is denied the NS records from the root zone, a resolution is not possible. If the NS records are returned, they are signed and include the lower signature keys. If the NS records are stripped of keys, the signature of those responses is invalid. People have put some thought into the design of DNSSEC, you can’t simply invisibly block it and force a protocol downgrade.
I’ll have to consider this in my own implementation. That is a reasonable way to detect invalid records. Thanks for the correction.
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.
There have in fact been downgrade attacks on DNSSEC; for instance, relatively recent BIND versions would cache unsigned records in the Additional Data section of response packets. Part of the problem is that avoiding downgrade attacks is a shared responsibility between resolvers and authority servers and DNSSEC simply hasn't been fielded enough (and probably never will be) to receive the kind of sustained attention it takes to shake out these kinds of bugs; part of the problem is DNSSEC's incoherent cryptographic design (you can strip all the signatures out of a DNSSEC response and end up with a valid DNS response).
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.
Isn't this a really odd point? Right now, you can hardly run a public resolver in the traditional sense as UDP resolvers are prone to be used for DNS amplification attacks and TCP isn't supported/configurable on all clients. On the other hand, running a DoH or DoT resolver is no more ressource intentive than, say, hosting your own website and even Android allows you to set a DoT resolver nowadays.
> requires significantly more resources to run a public recursive resolver.
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.
Not for еDNS, but I've seen such reports about HTTPS when it was in the process of wide adoption. In case of DNS, not only more CPU is consumed on encryption, but more memory too, since it's stateful. And all this both with client and upstream.
Why do you say that it requires significantly more resources? Running a public recursive resolver has never been something to take lightly - keeping your resolver immune to DDoS, cache poisoning, general security bugs (depending on which DNS server software you run) etc has always been a major undertaking.
A friend of mine runs a public DoH server at 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.
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.
>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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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]).
> Cloudflare killed "ANY?" because it was a significant vector in DNS amplification attacks.
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.
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.
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.
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.
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.
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):
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):
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.
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.
"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-...).
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.
> 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.
> Well this is false, and misleading. The connection to Sidefinder is a red herring -- sitefinder was applied Internet-wide, OpenDNS was a choice.
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.
"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.
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.
89 comments
[ 3.5 ms ] story [ 161 ms ] thread"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.
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.
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.
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.
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.
Source: https://registro.br/dominio/categorias/
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.
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.
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.
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.
>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
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.
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.
Edit: Also seems to still be the case when you have your resolver set to a v6 address.
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.
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.
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.
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.
* 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):
* https://indico.dns-oarc.net/event/32/timetable/#all
* https://www.youtube.com/DNS-OARC
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)
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.
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.