The Domain Name System Security Extensions, also known as DNS Security Extensions or, more commonly called DNSSEC for ease, is a set of protocols that add a layer of security to the DNS records lookup and exchange processes.

Before diving deeper, one must know the functionality of the DNS.

Domain Name System (DNS) is the largest virtual database on the internet that facilitates a translation of the domain name into its corresponding IP address. This system has become integral in accessing the website on the internet.

On the internet, IP addresses identify Computer systems and digital devices. It's quite difficult for humans to remember the long and complicated IP address (numeric address) as humans easily understand and memorize simple alphanumeric phrases (domain name).

So, if you want to access a specific machine on the internet, you must know its correct IP address. Here, DNS plays an important role. Consider DNS as the "phone book of the internet" containing the information about domain names and the IP addresses associated with them: it tells computers where to send and retrieve data.

DNSSEC Development

In 1983 DNS was created, and after the Internet Engineering Task Force (IETF)'s creation, in 1986, it became one of the original Internet Standards. Security was not a primary consideration during its design. Several security vulnerabilities were discovered soon after its implementation. Before you connect to the website, your browser has to retrieve the website's IP address by using the DNS. There are chances that the attacker could intercept your DNS queries and inject incorrect/invalid DNS information, which in turn would cause your browser to connect to an inaccurate or malicious website. You may provide your information, like your username and password (maybe you are trying to access your bank's website), resulting in secure information and data leaks.

As a result, a security system was created in the form of an extension to add it to the existing DNS protocols. This security system (DNSSEC) was later approved and modified by the Internet Engineering Task Force (IETF).

After several tests and deployments, in 2010, DNSSEC was officially implemented on the root level, on the top-level domain addresses (TLDs) like .org. In late 2010, 2011, this system was implemented on the .com, .net, and .edu top-level domain addresses (TLDs). The implementation continues to even country-specific top-level domain addresses (ccTLDs). Sweden (.SE) enables DNSSEC in their zone, making ".SE" the first country-specific top-level domain address (ccTLD) to deploy DNSSEC.

How DNSSEC Works

DNSSEC aims to strengthen users' trust on the internet, protect and prevent them from landing on or redirecting to fraudulent websites and unintended addresses by verifying the digital signature embedded in the DNS data response, and protecting the user from counterfeit DNS data.

When the user enters the domain name in the browser, the resolver verifies the digital signature. If the digital signature matches the data stored in the master DNS servers, then the data is relayed to the client computer to make the request.

DNSSEC uses the public keys and digital signature to verify the data. You have to add the new records in your DNS, along with the existing records. These new record types are:

• RRSIG contains a cryptographic signature.
• DNSKEY consists of a public signing key.
• DS holds the hash of a DNSKEY.
• NSEC and NSEC3 for explicit denial-of-existence of a DNS record.
• CDNSKEY and CDS for a child zone requesting updates to DS record(s) in the parent zone.

These records use the public-key cryptography method to "sign" the domain digitally.

The DNSSEC also holds the two main types of keys.

• The Zone Signing Key (ZSK) contains both the private and public keys used to sign and validate the zone's record sets.
• The Key Signing Key (KSK) is used to validate the DNSKEY record.

DNSKEY record of the zone consists of Both of these keys.

So here's how the DNSSEC system works.

• When the user enters the domain name in the browser's search bar to get the domain name's IP address. The browser requests the local computer's DNS resolver/stub resolver to solve the query.
• If the local computer's DNS resolver/stub resolver has the IP in its cache, it will return it. Otherwise, it will contact the recursive resolver managed by the Internet Service Provider (ISP) to solve the query.
• If the recursive resolver managed by the Internet Service Provider (ISP) has the IP in its cache, it will return it. Otherwise, it begins a recursive query for the DNS server that holds the authoritative information about the requested domain.
• It starts contacting the root DNS server, which refers to the top-level domain (TLD) DNS server. If the user enters the example.com, the root DNS server will refer to the TLD DNS server for all .com domains.
• The TLD DNS server refers to the authoritative DNS server of the domain that contains the information about the requested domain name.
• At every stage, the resolver requests DNSSEC records associated with the DNS zone to verify that the server is authentic. The Recursive resolver also requests an authoritative DNS server for DNSSEC records for the DNS zone "example.com." The authoritative DNS server returns a DNS response with RRSIG records included in it.
• The recursive resolver validates the RRSIG record to verify that the authoritative DNS server's records are accurate. It then sends the validated DNS response to the DNS client.

However, the DNS records lookup and DNSSEC validation process vary depending upon the server types used to make or send the DNS query. Recursive name servers (often operated by the ISPs) use a different way for DNSSEC validation than servers running Microsoft Windows.

DS record

The DS record stands for Delegation Signer, and it consists of the unique string of your public key and its related metadata. The DS record consists of four fields.

1. Key Tag is the short numeric value, also called the ID of the key. It identifies the referenced DNSKEY record.
2. The Algorithm is the algorithm type of the referenced DNSKEY record.
3. Digest Type is the cryptographic hash function used to generate the digest value.
4. The Digest is the long string at the end (the cryptographic hash value of the referenced DNSKEY-record).

For example, the DS record looks like this.

example.com. 21599 IN DS 31589 8 2 CDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03E576343C

Here,

• example.com is the domain name.
• 21599 is TTL (time to live).
• IN specifies the protocol group of the information—the Internet class.
• 31589 is the Key Tag.
• 8 is the Algorithm type.
• 2 is the Digest Type.
• And, the long string at the end is Digest.

Note: DS records must comply with RFC 4034.

Advantages of DNSSEC

• Protect users from malicious activities like DNS spoofing/cache poisoning, etc.
• Increase the trust on the internet by preventing the users from redirecting to fraudulent websites.

Disadvantages of DNSSEC

• Increase in DNS query resolution time. Increase delay when performing an initial validation to about 300ms.
• Complex, time-consuming, and not a cost-efficient system.
• DNSSEC does not protect against DDoS attacks.

Note: DNSSEC is not only limited to the web and any other service or protocol on the internet, like the DNSSEC with email (SMTP), and instant messaging, etc., can use DNSSEC.

Is it recommended to activate DNSSEC for each domain?

Whether you want the DNSSEC for your domain, it's totally up to you. However, it is preferable to have the DNSSEC because it provides an additional layer of DNS security. It helps to prevent malicious activities, such as cache poisoning/DNS spoofing.

But keep in mind that all TLDs do not support DNSSEC. If the TLD allows it, it's better to activate the DNSSEC for better security measures.