DNSSEC: A Good Security Protocol to Domain Name Service System
By Sunny, Product Operator @Namefi.io
Define DNSSEC and DNS and outline the security problem DNSSEC solves
DNSSEC, or Domain Name System Security Extensions, is a good* security protocol that aims to address vulnerabilities in the DNS system.
DNS, or Domain Name Service, is a critical component of the Internet infrastructure, serving as the standard naming convention between human-readable domain names and machine-routable IP addresses of Internet resources.
The inherent vulnerabilities and insecurities of DNS lie in its distributed, fault tolerant design, which is devised to avoid single point of failure.
There have been several attempts to counterattack the DNS attacks in the past including various randomisation approaches in query IDs (QIDs) or domain naming. DNSSEC is an approach originally invented in 1999 to ensure the authenticity of DNS responses through public key asymmetric cryptography.
This article will go through the design of DNS and the mechanism of DNSSEC while highlighting the real life incidences of DNS attack and the importance of cryptography in the maintenance and usage of the Web today.
DNS security problems: The mechanisms of DNS and DNS cache poisoning
In the Internet’s infrastructure, DNS structure is ubiquitous, crucial, and fundamental. Therefore, understanding basically how DNS works serves the basis for knowing how the Internet operates at the axiomatic level. DNS uses an inverted tree structure as its distributed system design with the top layer being the root domain, followed by top-level domains, second-level domains, sub-domains, and hosts. DNS data is stored using a simple data structure called a Resource Record (RR).
In simple language, DNS serves to communicate between machine-routable IP addresses and human-readable domain names. Initially, before the emergence of the World Wide Web (WWW) (thanks to Tim-Berners Lee), Internet resources/devices communicate with each other through machine-routable numbers. Then, with the creation of the Web and its popularization by personal computers (thanks to Steve Jobs and Steve Wosniak), people actually realize the importance of implementing human-readable code (yes, human language!) to surf the web rather than memorizing bazaar strings of IP addresses. So, DNS came along…
How does DNS achieve such communication through the aforementioned inverted tree structure (whatever that is)? Imagine you as a web surfer typing Google.com in your “Http://” browser (be it Chrome, Brave, or DuckDuckGo), your goal is to get to Google.com. Between the moment you typed in and the moment you entered Google’s web page, a series of events occurred. Your personal computer sends the domain name to the Name Service (NS), which then sends the domain name to the root domain. Under the root domain, it is sent to the top-level domains, second-level domains, and finally the authoritative domains. Each domain captures the part of the domain name and makes a referral to the next domain until the full correct IP address is returned to the name server. The request is recorded and remembered by the system through a query ID (QID) tagged to the domain name.
As can be seen, the mechanism of how DNS works is that of a distributed database. However, since there is a time lag for the matching of IP addresses and domain names because of the distributed design (and also no verification between servers!), a nefarious player/server can come along and hijack the DNS process. By bombarding the QIDs with bootstrapped QID guesses, the inverted tree system can be hijacked by a pseudo (nefarious) QID. The nefarious player can not only hijack the DNS process but also the memory of the system by storing itself into the cache of each domain name server. In summary, the number of server levels within the system determines the types of attacks: DoS (denial of service), cache poisoning, and false authoritative servers.
What can happen if DNS gets hijacked? In either case, you will get no answers at all, fake sites, disclosure of login credentials, false data given, or eavesdropping on sensitive communications. Major real life incidents include the Oct 2016 Brazilian bank attack, the Aug 2017 WikiLeaks, the April 2018 MyEtherWallet attack, and the 2018 DNSpionage. Yes, cryptocurrencies can be stolen due to low DNS security measures. Even in Web3, the internet of value, we are still operating on the Web. So, DNS security measure is crucial.
DNSSEC mechanism and cryptography
DNSSEC has a cryptographic design but has undergone a lengthy development process. The Internet Engineering Task Force (IETF) spent over a decade and several protocol revisions to develop DNSSEC, and its deployment is still in the early stages. DNSSEC is designed to add cryptographic protection to the Internet’s name resolution service, aiming to protect the integrity and authenticity of DNS data. It provides response integrity by defining mechanisms to cryptographically sign zones, allowing end users to verify the correctness of replies. Additionally, DNSSEC responses are large and often fragmented, which can harm DNS functionality and cause inefficiency and vulnerabilities. However, a cipher-suite negotiation mechanism has been proposed to reduce response sizes, solve interoperability problems with DNSSEC-signed responses, and prevent reflection and cache poisoning attacks.
In short, DNSSEC counterattacks the DNS system failure by adding a centralized chain of trust mechanism and allows each name service domain to provide successive verifications through signatures. The chain of trust in DNSSEC is a critical component of its security infrastructure. It is based on the cryptographic validation of the public key, which is established through a hierarchical chain of trust. This chain of trust begins from a secure entry point, such as the root name server, and extends down to the queried zone, with successive verifications of the signature of the public key of a child by its parent. The DNS tree builds this chain of trust from the root to the authoritative server, with each node acting as a certificate authority for its child nodes to avoid blind spots that can be attacked by nefarious players. To trust a zone key, DNSSEC utilizes the DNS-tree model to establish this chain of trust, ensuring the integrity and authenticity of DNS data.
N.B. The chain of trust of DNSSEC is not to be confused with the cryptographic measures used for consensus mechanisms for blockchain (decentralized ledger system). The chain of trust in DNSSEC and the cryptographic mechanism of a decentralized ledger system, such as blockchain, exhibit fundamental differences in their design and application.
In DNSSEC, the chain of trust is established through a hierarchical model, starting from a trusted name server and extending down to the current source of response through successive verifications of the signature of the public key of a child by its parent. This ensures the integrity and authenticity of DNS data and is crucial for the overall security and reliability of the DNS infrastructure .
On the other hand, a decentralized ledger system, like blockchain, operates on the principle of a distributed and immutable ledger, where transactions are coded into blocks and linked to each other in the form of a chain. This enables disparate parties to transact securely without the need to trust each other or a trusted third party, forming the basis of its efficiency in developing decentralized trustless systems .
The importance of DNSSEC in DNS and its role in bridging DNS to ENS— the beauty of combining Web2 and Web3 to orchestrate both information and value
Web3 stands for the web of value built on the premise of trust technology/blockchain. Web2 stands for the web of information built on the foundation of the Internet. Historically, the Internet appeared first during the cold war and then the web came along. The whole Web is built on top of the axioms of the Internet and the Web. Thus, a Web3 without Web2 would be like building a castle on the air. Here is an interesting example to illustrate:
Ethereum Domain Service (ENS) is the largest Web3 domain name service registrar built on Ethereum. It allows users to register human-readable domain names on Ethereum virtual machines instead of naming themselves hexadecimal addresses. The registered domain names then belonged to the registrants and can be traded without manual brokerage on decentralized marketplaces like OpenSea. However, in order to deploy a Web2 domain name on chain, things can get complicated.
On ENS, if one types in London.wtf (a web3 domain name), one needs to manually enable DNSSEC to allow offchain authentication by submitting a text proof of the public key for the domain you want to deploy. Such that ENS can allow bridging of domain names between off chain world and onchain world.
Resolving DNS in ENS would require user to enable DNSSEC on the Web2 domain registrar and upload a txt record.
What DNSSEC does not solve (no encryption), Where does the DNS security’s future lie…
DNSSEC, while a sufficiently good advancement in securing the Domain Name System (DNS), has several limitations.
*DNSSEC is only a good protocol as opposed to a critical protocol to DNS. According to Paul Hoffman, a Principal Technologist at ICANN with extensive authorship in the areas of DNSSEC, “After 13 years, only about a third of zones sign with DNSSEC, and a third of DNS users rely on a resolver that verifies DNSSEC. Thus, it is not a “critical” security protocol at all: it was a very good attempt that has only mildly succeeded.”
This limited adoption hinders the widespread effectiveness of DNSSEC in enhancing the security and integrity of the DNS. Additionally, DNSSEC has been abused in some of the largest Denial of Service (DoS) attacks, indicating vulnerabilities and potential misuse.
Furthermore, the validation of resolvers and the limited number of users being protected by DNSSEC have raised concerns about its overall effectiveness in mitigating DNS-related security threats.
To address some of the limitations of DNSSEC, the role of DANE (DNS-based Authentication of Named Entities) has been proposed. DANE leverages DNSSEC to associate digital certificates with domain names, providing a more secure and authenticated approach to establish encryption for internet services.
By using DANE, organizations can directly specify the keys and certificates that are authorized to represent their domains, thereby enhancing security and mitigating some of the limitations of traditional certification authorities.
In conclusion, the limitations of DNSSEC, including its limited deployment, susceptibility to abuse in DoS attacks, and concerns about the effectiveness of validation and user protection, highlight the need for complementary technologies like DANE to address these shortcomings and further enhance the security of the DNS.
Reference:
- https://www.youtube.com/watch?v=MrtsKTC3KDM (F5 DevCentral)
- https://www.youtube.com/watch?v=WrHrtXvO1qM (NANOG)
- https://www.youtube.com/watch?v=uOfonONtIuk&list=PLPGftYF5tAibl2kKU2hmhJ7WxBpDpa3k1 (Numberphile)
- https://www.youtube.com/watch? v=7MT1F0O3_Yw&list=PLPGftYF5tAibl2kKU2hmhJ7WxBpDpa3k1&index=2 (Numberphile)
The research of the article is supported by scite.ai:
Anagnostopoulos, M. Το πρωτόκολλο dns ως πολυλειτουργικός φορέας επίθεσης.. https://doi.org/10.12681/eadd/41026 Ateniese, G. and Mangard, S. (2001). A new approach to dns security (dnssec).. https://doi.org/10.1145/501983.501996 Chandramouli, R. and Rose, S. (2010). Secure domain name system (dns) deployment guide.. https://doi.org/10.6028/nist.sp.800-81r1 Guette, G., Cousin, B., & Fort, D. (2005). Algorithm for dnssec trusted key rollover., 679–688. https://doi.org/10.1007/978-3-540-30582-8_71 Guette, G., Cousin, B., & Fort, D. (2005). Gds resource record: generalization ofthe delegation signer model., 844–851. https://doi.org/10.1007/978-3-540-31957-3_95 Herzberg, A. and Shulman, H. (2012). Security of patched dns., 271–288. https://doi.org/10.1007/978-3-642-33167-1_16 Herzberg, A. and Shulman, H. (2013). Dnssec: security and availability challenges.. https://doi.org/10.1109/cns.2013.6682730 Herzberg, A. and Shulman, H. (2013). Socket overloading for fun and cache-poisoning.. https://doi.org/10.1145/2523649.2523662 Herzberg, A., Shulman, H., & Crispo, B. (2014). Less is more.. https://doi.org/10.1145/2664243.2664283 Jalalzai, M., Shahid, W., & Iqbal, W. (2015). Dns security challenges and best practices to deploy secure dns with digital signatures.. https://doi.org/10.1109/ibcast.2015.7058517 Kang, A., Spaulding, J., & Mohaisen, A. (2016). Domain name system security and privacy: old problems and new challenges.. https://doi.org/10.48550/arxiv.1606.07080 Kang, A., Spaulding, J., & Mohaisen, A. (2016). Domain name system security and privacy: old problems and new challenges.. https://doi.org/10.48550/arxiv.1606.07080 Ma, T., Xu, C., Yang, S., Huang, Y., Kuang, X., Tang, H., … & Grieco, L. (2022). An intelligent proactive defense against the client‐side dns cache poisoning attack via self‐checking deep reinforcement learning. International Journal of Intelligent Systems, 37(10), 8170–8197. https://doi.org/10.1002/int.22934 Osterweil, E., Pappas, V., Massey, D., & Zhang, L. (2007). Zone state revocation for dnssec.. https://doi.org/10.1145/1352664.1352677 Osterweil, E., Ryan, M., Massey, D., & Zhang, L. (2008). Quantifying the operational status of the dnssec deployment.. https://doi.org/10.1145/1452520.1452548 Osterweil, E., Tehrani, P., Schmidt, T., & Wählisch, M. (2021). From the beginning: key transitions in the first 15 years of dnssec.. https://doi.org/10.48550/arxiv.2109.08783 Sun, Y., Liu, R., & Liu, Y. (2010). Research and implementation of dnssec monitoring system.. https://doi.org/10.1109/icmlc.2010.5580489 Trostle, J., Besien, B., & Pujari, A. (2010). Protecting against dns cache poisoning attacks.. https://doi.org/10.1109/npsec.2010.5634454 Wang, Z. (2014). Seamless transition of domain name system (dns) authoritative servers. Scientific Research and Essays, 9(12), 566–570. https://doi.org/10.5897/sre2013.5741 Wessels, D., Heidemann, J., Zhu, L., Mankin, A., & Hoffman, P. (2016). Specification for dns over transport layer security (tls).. https://doi.org/10.17487/rfc7858 Yang, H., Osterweil, E., Massey, D., Lu, S., & Zhang, L. (2011). Deploying cryptography in internet-scale systems: a case study on dnssec. Ieee Transactions on Dependable and Secure Computing, 8(5), 656–669. https://doi.org/10.1109/tdsc.2010.10 Yuan, L., Chen, C., Mohapatra, P., Chuah, C., & Kant, K. (2013). A proxy view of quality of domain name service, poisoning attacks and survival strategies. Acm Transactions on Internet Technology, 12(3), 1–26. https://doi.org/10.1145/2461321.2461324
