DNSSEC is a complicated kitchen sink that doesn't do the fundamentals (encrypt DNS traffic). It is also very black-box with the current tooling (not by design, but by implementation) which makes deployment perilous and confusing.<p>It's really a PKI infrastructure masquerading as a secure DNS system.<p>There's value in a PKI infrastructure for domain names, but it probably won't look exactly like DNSSEC. And there's value in encrypting DNS, but that is definitely not DNSSEC. I helped invent and deploy DNSCrypt which is strong encrypted DNS, but doesn't provide the PKI components. There are plenty of ways to do that part, however, that would be much lighter in weight than DNSSEC.<p>I'm not motivated to do it now with my current day job (American Dynamism) but someone out there could.
<i>How can we measure DNSSEC adoption? We could take the Tranco top 1M domain names and poll them to see how many are DNSSEC-signed. A recent scan of this domain name list shows that 94,317 of these names are validly signed with DNSSEC, or 9.4%. The issue with this form of average statistic is that it equally weights all of these million domain names, whereas a more relevant statistic would be to weight each domain name by its relative “use” in some fashion. Perhaps there is a different approach that takes this relative use weighting between domain names into consideration.</i><p>It's so much worse than this, and I think he must know that. The Tranco list (which is very cool: it's like the Moz500 or other popularity-contest lists like that, but research-oriented, academic, and ostensibly rigorous) is <i>ranked</i>. The first domain on the list is Google, and so on.<p>He used the Top 1M for a reason. If he wanted to take the top 1000, he could just `head -1000` the list. But the impact on his 9.4% figure would be stark.
It's a common misconception that DNSSEC is not needed if you have TLS. Two reasons come to mind:
1) CAs will happy issue TLS certificates if you can spoof DNS. In the past you would have to spoof MX records, with letsencrypt (or other CAs that implement ACME) you have to spoof the A/AAAA of the domain you want to attack (and deny the existance of CAA). Surprisingly it is almost never mentioned that the security of TLS is completely dependent on an extremely insecure protocol like DNS.
2) The only thing that comes close to practical email security is DANE. With DANE you can tell the sending mail server that TLS is available (to prevent downgrade attacks) and what the certificate or key is. Even if you don't use email for communication, many systems include email verification as part of a password reset procedure.
Also worth noting how often DNSSEC causes outages. <a href="https://ianix.com/pub/dnssec-outages.html" rel="nofollow">https://ianix.com/pub/dnssec-outages.html</a>
What is purpose of DNSCrypt?<p>Prevent ISP from intercepting DNS queries? ISP cannot see the contents of the DNSCrypt encrypted DNS queries.<p>But person operating DNSCrypt cache where the queries are sent _can_ see the contents of the DNS queries.<p>DNSCrypt receives encrypted queries but then it sends these queries _unencrypted_ across the internet.<p>Morever the DNSCrypt cache receives _unencrypted_ DNS responses.<p>Anyone eavesdropping on the network can read and tamper with the contents of these packets, and impersonate packet senders.<p>What if ISP sets up a DNSCrypt cache somewhere on the internet? How would a DNSCrypt user know?<p>What makes it safe to share the contents of DNS queries with operator of DNSCrypt cache but not operator of ISP DNS cache?<p>What if the computer could send encrypted DNS queries to the authoritative nameserver for a domain name _directly_ instead of sending the queries to a DNSCrypt cache operator? What if the computer user could avoid using a third party intermediary: a DNSCrypt cache operator, an ISP, etc.?<p>As it happens someone designed a method for doing so, including the underlying cryptography.<p>That method expects that computer users run their _own_ caches instead of using one operated by third parties, such as an ISPs, DNSCrypt cache operators, OpenDNS, Cloudflare, Google DNS, Quad9, etc.<p>The creators of DNSCrypt copied that person's work to "invent" DNSCrypt.<p>Instead of using a local DNS cache bound to the computer owner's loopback that sends and recieves encrypted DNS packets directly to authoritative nameservers, they chose to require computer users to send DNS queries to _third party_ DNSCrypt cache operators as above.<p>If all packets carrying DNS data on the internet are to be encrypted it will require cooperation from authoritative nameservers.<p>I have run experiments on home network where I serve an entire zone from an authoritative nameserver fronted by a DNSCurve forwarder.<p>Others are running authoritative nameservers fronted by DNSCurve forwarder on the internet. AFAIK none of them have had any problems.<p>There is also a third party DNS service that runs DNSCurve forwarders in front of its nameservers.<p>Imagine a non-ICANN DNS registry that uses DNSCurve forwarders and only allows encrypted DNS.