DNSSEC & It's Importance
DNS is a fundamental building block of the Internet. Its responsibility is to locate and translate domain names to its corresponding Internet Protocol Addresses (IPv4 and IPv6). Changes and adaptations in the industry have occurred over time; more top-level domains, registries, and registrars have come into existence, mankind witnessed the “Dot-Com” bubble, and the Internet was adopted by more and more people. Despite all these events, the fundamental theory that governed the translation of a domain to an IP address remained valid and largely unchanged.
The Domain Name System was not primarily designed with security in mind. It was designed to be a scalable, public database which did not restrict access to its data. This exposed a lot of vulnerabilities in the system and led to multiple exploits.
The past few years witnessed an unprecedented increase in the number of DNS related exploits (spoofing, cache poisoning, DNS hijacking). This led to the development of security extensions for DNS called Domain Name System Security Extensions (DNSSEC).
When setting up monitoring strategies, DNS is always the first and the most important of all the systems that I start with. In today's world, ensuring that it is up and running is not enough. Security plays a key role in the monitoring strategy when it comes to DNS and that's exactly where DNSSEC and monitoring the validity of the chain of resolution becomes important.
Image showing resolution times for DNS from all the major continents for a key domain name:
The view above definitely helps one understand the performance from a DNS resolution perspective. However, what makes this dataset even more powerful is the ability to validate the DNSSEC (chain) for all the resolutions from a security standpoint.
DNS Vulnerabilities & Attacks
Most of the vulnerabilities and exploits are a result of the way DNS as a protocol has been implemented.
Now, what happens if an attacker gains access to one of the servers in the DNS system and changes the information on that server?
The poisoned entry is propagated across servers and may end up getting cached on the end user’s device.
The issue is not hypothetical. In the recent past, there have been multiple real instances. One such incident happened in 2010 when an ISP outside China configured its DNS Servers to fetch information from DNS Servers located in China. “The Great Firewall”?of China is known for using Cache poisoning (poisoning its own cache) to redirect users of some websites to incorrect IP addresses. In this case, the ISP cached the response it received from a server in China which was later cached by other servers.
The poisoned cache spread from system to system and ended up blocking access to websites like Facebook, Google, and Twitter for some users in the US and Chile.
DNS Hijacking and Cache poisoning/spoofing are two of the most commonly used forms of DNS attacks. There are attacks such as DDoS (Direct Denial of Service) and Amplification attacks which also exist.
Now we all know that DNS was not built with security in mind. We also know that it does not verify any credentials before accepting an answer. So, how do we make DNS more secure and robust with all these vulnerabilities and exploits around?
One of the most important steps that was taken to make DNS secure was the introduction of DNSSEC. In the sections below, we will read more about it and how it works.
DNSSEC
DNSSEC (Domain Name System Security Extensions) adds security to the Domain Name System by enabling the validation of DNS Responses. Correct implementation of DNSSEC makes DNS less vulnerable to a very common type of attack called DNS Spoofing.
DNSSEC uses public key cryptography to digitally sign the DNS records at the authoritative DNS server. Digital signing ensures that the DNS response originated from the stated source and allows us to validate the origin of the DNS record. It guarantees that we, the users of the system, get the correct IP address associated with a Domain name. It adds cryptographic signatures to the existing DNS resource records at the Authoritative DNS Servers.
DNSSEC as a protocol is not encrypted. The keys are used to sign the records and build a chain of trust. However, the packets are not encrypted as DNSSEC does not provide encryption.
DNSSEC works by establishing a chain of trust. This chain starts at the root “.” name servers. A copy of the root’s public key is held by DNSSEC enabled recursive nameservers. The Root servers form a trust with the TLD (Top Level Domain) servers and the TLD servers form a trust with the Authoritative servers of the Domain name.
The following Resource Records were introduced to aid signature validation under DNSSEC:
领英推荐
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). The public keys are stored in DNSKEY resource records and are used in the DNSSEC authentication process. A zone signs its authoritative RRsets by using a private key and stores the corresponding public key in a DNSKEY Resource Record. A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus to authenticate them.
Requirements for DNSSEC Implementation
How DNSSEC Works?
DNS Zones can be secured with DNSSEC using a process called “Zone Signing.” For this, DNSSEC should be supported by the Authoritative Nameserver as well as the local resolver which in most of the cases belongs to the ISP.
DNSSEC USING DIG COMMANDS
Let’s have a look at some DIG queries to understand how DNSSEC works.
Command: dig +short NS example.com
The response we get is:
Command: dig +short +dnssec NS example.com
Output:
a.iana-servers.net.
b.iana-servers.net.
NS 8 2 86400 20170601015854 20170511071922 61845 example.com. iM/F025H0BdVCjRkpt/IQfZRAfFHFGsPqS7fxJ+JwLMqeakpnHBDN3Mf 7U/O+ZoNrVFC+mvdeSJ351OiXymffnoD3X1Wp0J7xj6F33sD/gbEpw1d F8M1MNSTih31U+unIDEzNt0uPCghxfXuh2zLdEr9QmtBGBTPMKV16Pwl ikrV6s4=
As you can see, in this case, we received not just the NS record for the domain: example.com but also the RRSIG (Resource Record Signature). For any DNSSEC signed zone, each record set (RRset) has one or more RRSIG record. RRSIG records basically contain a signature which is generated after signing the result with the private key.
Command: dig +short DNSKEY example.com
In the screenshot above, we dig for the domain’s (example.com) DNSKEY.
DNSSEC is not a new concept, it was developed in 1994 but whether the cost and resources involved in its implementation are justified is still hotly debated. The?Kaminsky bug?in 2008 highlighted the importance of security with respect to DNS and created a buzz around “DNSSEC.” More than a couple of decades after its development, we are still arguing about its pros and cons.