DNS Security: Threat Modeling DNSSEC, DoT, and DoH
This is the kind of analysis that makes sense if you read RFCs at face value, or columns from network engineers at CircleID. It does not reflect the real world.<p>Here&#x27;s a breakdown of the real world implications of these three protocols. They are in fact simpler than this analysis suggests.<p>DoT and DoH are related efforts. DNSSEC is unrelated to DoT or DOH.<p>DNSSEC is a ~25-year-old effort to sign DNS records, so that attackers who control caches can&#x27;t spoof records. In 25 years, through 3 revisions of the protocol, 2 of them major, DNSSEC has seen practically no deployment outside of Europe, where registrars enable it automatically (and thus control the associated keys). In particular: with the exception of Cloud Flare, which provides DNSSEC services, and some Paypal domains, no major tech companies sign their zones with DNSSEC.<p>For a bunch of reasons, DNSSEC is probably a dead letter (I&#x27;m not calling time of death yet, but I expect to within in the next 6 months). In particular: protocol-level defenses against record spoofing just aren&#x27;t very relevant. Much of the Internet runs on TLS (if you don&#x27;t, DNSSEC is the least of your problems). The WebPKI (TLS CA system) has in-progress mitigations against spoofing, and more in the pipeline, and all of them put together will cost a tiny fraction of what DNSSEC will cost. For a year or two, SMTP TLS was the great hope of DNSSEC deployment, the last major mainstream application that had a security gap addressable directly with DNSSEC. But then the major mail providers all (<i>all</i>) got together and came up with SMTP-STS to address that gap directly.<p>It is hard to think of a real threat that end-user adoption of DNSSEC would address. I like to joke that the DNSSEC root keys could end up on Pastebin today and network engineers around the world could sleep the resulting Jira tickets for a week or two before deciding whether to just backlog them. Except I&#x27;m not really joking about that at all.<p>Which brings us to DoT and DoH.<p>The problem you do actually have with DNS today, especially if you&#x27;re in the US, is that your large ISP is abusing DNS to monetize your traffic. I&#x27;m on AT&amp;T, and, with their standard DNS, if I type a nonexistent domain into my browser, I&#x27;m on an AT&amp;T landing page. ISPs are actively attacking DNS today for all their customers.<p>DoT and DoH tunnel DNS out of untrusted networks to a resolver on a hopefully more-trusted network (that is: there isn&#x27;t that much point to DoT&#x27;ing or DoH&#x27;ing to your ISP&#x27;s nameservers; you care about DoH&#x2F;DoT if you want to use a third-party resolver, which you should).<p>Both DoT and DoH use TLS to secure DNS lookups. Protocol nerds will have fascinating discussions about the tradeoffs between the two approaches, but from a practical perspective, for home users, here&#x27;s the real difference: DoT has a kill-switch for network operators, and DoH doesn&#x27;t. A network operator that doesn&#x27;t want you DoT&#x27;ing can stop you, because DoT deliberately runs on an oddball port. DoH, on the other hand, very deliberately runs on 443&#x2F;tcp, so that it costs more to filter.<p>Do you want a kill switch in your DNS privacy tunnel? That depends on who you are. If you&#x27;re an enterprise network operator, you want the kill switch, so you can (reasonably!) force your endpoints to funnel their DNS lookups through recursors you control and monitor. If you&#x27;re a home user, you very much do not want the kill switch; if you decide you want to use Google DNS rather than your In-Flight Wi-Fi provider&#x27;s DNS, it should not be up to your airline or their wifi provider whether you do that.