We just came back from CES event in Las Vegas, many people asked us about DNSSEC. It is often mentionned when it comes to securing the DNS protocol, or some kind of future technology for efficient naming and service discovery of internet resources. We will argue in favor and against DNSSEC.

DNS is a naming system based on authority, with private centralized services uniquely responsible for a node in the tree and everything beneath. DNS keeps with or without DNSSEC the security flaws and direct impact of arbitrary decisions that affect centralized systems. Because of 40 years of slow and retrocompatible security improvements, the biggest problem may be the cluelessness regarding which browser, client, DNS resolver or service provider applies which security patch. This translates into high costs and sometimes inefficient due dilligence requirements (in a B2B context), or poor user protection in case none is done. This is dappy’s blog, we welcome every discussions with researchers, security engineers and developers, feel free to hit us up by email or on discord.

How does DNSSEC works ?

DNSSEC is a signature-based protocol that allows resolvers to check for the integrity of the DNS data (A records, AAAA records, TXT records etc.). Unlike TLS, DNSSEC does not encrypt the channel, but instead parent nodes advertises a public key for the children nodes at each level of the pyramid, so that data (DNS records) supposedly sent by children nodes can be cryptographically verified, even if loaded through unencrypted UDP requests.

We’ll stop there as DNSSEC records and protocol is not easy to grasp, feel free to read in depth documentation and articles. Let’s focus on the issues with DNSSEC now, some of the issues also apply to DoH, Open CT and the overall DNS protocol.

Browsers don’t have a clue

DNSSEC stops at the DNS resolver level, it is an integrity verification protocol internal to the DNS network and services. Web browsers still plug to a single DNS resolver and rely blindly on a single source of truth, users rarely configure DoH and have no protection against cache poisonning. As an example Curve Finance (curve.fi) which was probably protected by DNSSEC in 2022, was DNS-hacked through cache poisonning, in total users lost 500k USD. The DNSSEC chain of trust was well established… too bad it does not reach the users.

DNS tree remains centralized and fragile

DNSSEC only strengthens the links between the nodes of the DNS tree, which is good under DNS trust structure context. It does not at all remove or lower the impact of arbitrary actions, censorship from ICANN, TLD registries or web hosting companies which host the 2nd level domain zones. In addition to arbitrary decisions, a hack to a single one of these services will also grand total control to the hackers, it happened in 2017, an entire bank’s online operations was hijacked through DNS registrar.

Service providers don’t have a clue

Let’s say you distribute B2B web portal that deal with 100M USD worth of operations per day, it is used to coordinate supply chain transportation programs with ships and planes. Your team has properly configured DNSSEC. There are 1000 clients from external companies that access this portal everyday, tomorrow there will be 2000, what DNS resolver do clients use ? Do they use DoH in addition ? A lot is unknown, that is why a great amount of due dilligences must be performed (cost and time are of course associated with it), protecting the customers is often synonymous of protecting the web service and company itself.

DNS is a poorly secure service discovery protocol with patches that eventually make it secure. Because of its slow evolution on over 40 years, with a constant and strong emphasis on retrocompatibility (we’re not saying this is bad or good here), there are in reality dozens of DNS protocols. A company that exposes a web service hardly knows about the security settings of its clients and users, do they use DNSSEC, DoH, Open CT checks ? It is all arbitrarily configured and of course unknown when it comes to public SaaS or websites like binance.com (that deal 1B+ trading volume day).

Dappy went around this issue by proposing that a new TLD .d serves as protocol indication. A service provider that exposes through .d, and a client that loads a .d website both know that they’re using a DLT, co-resolution based, no CA and fully encrypted service discovery and name system.

Conclusion

Those are some of the concerns we have with DNSSEC, and the reasons we think it is more a patch than a true breakthrough technology. We warmly invite you to check dappy’s whitepaper, and get familiar with the new dane and web3-inspired approach we propose. Service discovery in dappy is based on co-resolution and removes the need for DNSSEC, the CA based webPKI, in addition to adding resiliency and privacy to the service discovery operation.

Discord chat platform

Image by Nele-Diel on Deviantart