What is DNSSEC?

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).

DNS Vulnerabilities & Attacks

Most of the vulnerabilities and exploits are a result of the way DNS as a protocol has been implemented.

• DNS Cache Poisoning: Cache poisoning is an attack form that leads to the DNS servers caching false information regarding the Domain-IP mapping; the users are redirected to websites that they did not intend to visit. The poisoned cache information can spread from one server to another and this makes Cache poisoning extremely dangerous. DNS is a distributed system of servers; it does not depend on a single server alone to respond to incoming DNS queries. Caching in DNS happens at multiple levels:
• Our Local machines
• Routers
• ISPs
• Nameservers for a Domain
• gTLD Servers

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: In DNS Hijacking, unlike cache poisoning, the DNS Cache is not altered. Hijackers update the DNS settings for a domain name to point to their own IPs. Once the DNS settings have been updated, the hijacker can redirect the users to his websites. This may also be used for phishing attacks or for making money by redirecting users to the websites which the hijacker wants them to visit.

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:

• RRSIG: Resource Record Signature -> The RRSIG record contains the signed Record. When querying a domain name for the A record on a signed zone, the A record is returned along with the RRSIG record. The RRSIG record contains the copy of signature used to verify it.

• DNSKEY: DNS Public Key -> DNSKEY is a record that holds the public key used to sign a Record or a DNS Zone. DNSKEY are of 2 types:
• Zone Signing Key (ZSK): It is used to sign records in a DNS Zone.
• Key Signing Key (KSK): It is used to sign the Zone Signing Key (ZSK) and create a chain of trust with its upper level.
• DS: Delegation Signer -> A DS record is present in the Parent Zone and it is used to verify the results returned when querying the Child Zone. For example, for the domain name: example.com, the DS record will be present in the .COM Zone.
• NSEC/NSEC3: Next Secure -> NSEC and NSEC3 are used for securely handling NXDOMAINS or Non-Existent Domain names in DNS. They are used to provide a signed response with a NXDOMAIN response stating there is no record.

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

• For DNSSEC implementation, the domain’s parent zone and the parent’s parent zone, all the way up to the ROOT must support DNSSEC. Currently, out of the 1531 TLDs in the ROOT zone, 1386 are signed.

• The Domain Name’s Registrar must allow uploading the DS records to the parent zone.
• The Domain’s Hosting provider must support DNSSEC and the Management interface provided must allow adding DNSKEY, RRSIG, DNSSEC and other DNSSEC related records.

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.

• When a Zone is DNSSEC signed, the zone’s creator generates a key-value pair. This key-value pair lays the foundation of Public key encryption or asymmetrical encryption. DNS Responses are validated using these digital signatures which are included with DNS Responses. In public key encryption, the private key encrypts the message whereas the public key can be used to decrypt the message. In the Domain Namespace, the DNSKEY record present in the Zone file contains the public key.
• The Resource Records (A, CNAME, AAAA etc.) are digitally signed using the RRSIG record every single time there is an update to the Zone.

• The image above shows how RRSIG record is used to digitally sign the Resource Records like A, CNAME, SOA, NS and AAAA. The DNSKEY record contains the public key.
• For a DNSSEC enabled zone, the RRSIG record is sent back to the resolving server along with the response to the DNS query. When this response including the RRSIG is received by the resolving server, it asks for the public key (that is the DNSKEY record) for decryption.
• As we know by now, the RRSIG record is a digest/Hash of the resource record which is then encrypted. The RRSIG record accompanies any DNS Response for a DNSSEC enabled zone. Once the DNS Response and the corresponding RRSIG record for the response have been received by the resolving server, it needs a public key to decrypt the RRSIG.
• The resolving server creates a Hash of the resource record requested and once it receives the public key, it decrypts the RRSIG or the signature using that key and compares the 2 hashes or digests. A match means a valid signature.
• It is possible for malicious entities to spoof the DNS Response and the RRSIG record along with the public key being used to their own key pair. This can be avoided in DNSSEC using the DS Records or the Delegation Signer Records. We will read more about it in the next section where we will be looking at actual DIG commands to understand how DNSSEC works outside theory

DNSSEC USING DIG COMMANDS

Let’s have a look at some DIG queries to understand how DNSSEC works.

• Let’s use a DNS resolver that doesn’t support DNSSEC to query the NS record of example.com.

Command: dig +short NS example.com

The response we get is:

• Now, let’s run the same query with DNSSEC enabled.

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.

• Now, the next step is to verify if the signature returned is valid. In order to verify the validity of the signature, the DNS Resolver needs to obtain the “DNSKEY” record.

Command: dig +short DNSKEY example.com

In the screenshot above, we dig for the domain’s (example.com) DNSKEY.

• If you have a look at all the records that the resolver has at this stage, you will see that it has the NS records for the domain: example.com, their signature (in the form of RRSIG record) and the public key (DNSKEY record). The question now is whether establishing a trust within the domain’s zone (in this scenario: example.com) is enough? The answer to this question is NO. DNS is a hierarchical system where Zones do not work independently. The mapping of a Domain name to an IP Address involves multiple hierarchies starting from the Root and going all the way down to Authoritative Nameservers for a Domain. It is extremely important in DNSSEC to create a “chain of trust” between the multiple hierarchies.
• In DNSSEC, a chain of trust amongst hierarchies is created using the “Delegation Signer Record,” or DS record. It allows building a chain of trust between the parent zone and a child zone. The DNSKEY record is hashed by the entity managing the Zone and is shared with the parent zone. The parent zone publishes it as a DS Record. The parent zone provides a DS record every single time a resolver is referred to a child zone.
• DS Record serves 2 very important functions:
• It tells the DNS Resolver that the child zone is DNSSEC enabled
• Helps in validating the child zone’s public KSK (Key Signing Key). It is hashed by the Resolver and compared with the DS record from the parent. If they both match, the resolver can assume that the KSK has not been tampered and that all the records present in the child zone can be trusted.
• Any change to the KSK (Key Signing Key) requires the DS Record at the parent zone to be updated.
• For the domain: example.com, the DS record will not be present in example.com’s zone but in the zone file for .COM. The .COM zone also will have a DNSKEY record and the DS record would have been signed using its private key and associated an RRSIG record with it.
• The ROOT zone will also have a DS record signed using its private key, a DNSKEY Record and a RRSIG record.
• This hierarchy of trust and validations that exist between multiple levels of the Domain Name System is called the “Chain of Trust.”

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.

In the next part of the blog, we will be looking at the possible applications of DNSSEC: DANE, TLSA Record and will be focusing on how to monitor DNSSEC efficiently using Catchpoint.