Domain name system security extensions (DNSSEC) is a protocol for securing the chain of trust that exists between the domain name system (DNS) records that are stored at each domain level, verifying each trust between the child level and its parent, all the way back to the root zone. Through this multi-level process, the integrity of the DNS records associated with a domain can be verified, thus ensuring to the client that the website or service requested and the one delivered are in fact, one and the same.

This article gives a brief explanation of how DNSSEC works and why your company should consider implementing it.

How does DNSSEC function?

To demonstrate, let’s consider that our website is hosted as test.themacjesus.com.

The first step in the process requires the “.com” name servers to verify the records for “themacjesus” (in a parent-child relationship). Second, “themacjesus” verify the records for “test” (also in a parent-child relationship). Third, the root DNS servers verify the .com records. Lastly, the records published by the root have their integrity verified using a private-public key pair, called a Zone Signing Key (ZSK). Additionally, a secondary key pair called the Key Signing Key (KSK) is used to validate the ZSK.

Just like DNS, DNSSEC is invisible to the user. However, in the background, the security extensions work by effectively signing the root zone for your domain, with each subsequent record requiring verification from its parent until the site being requested has been validated.

SEE: Network security policy (Tech Pro Research)

What does DNSSEC protect against?

Accessing validated websites and services is the aim of security extension-enabled DNS services. The goal here is to reach the intended servers hosting those sites or services. As far as protection goes, it ensures against malicious URLs designed to impersonate a site or service for the purpose of harvesting account names and passwords. This could come in the form of a maliciously injected record during a man-in-the-middle attack or as part of a known vulnerability, such as DNS-cache poisoning or spoofing attacks. In either case, DNSSEC will reply with a 404 error (website not found) in the event that a domain does not resolve due to DNS records that can’t be validated.

What are the limitations of DNSSEC?

Administrative overhead in the form of creating and managing additional records for each domain to be protected by DNSSEC can be both time consuming and costly depending on the number of domains. The scope can grow exponentially if additional services require coverage, such as MX records for email servers. Speaking of MX records, there are known issues that occur during MX record lookups protected by DNSSEC and versions of Microsoft Exchange 2013 and earlier, which can result in errors.

The configuration of sites that are set up for DNSSEC must be error-free. Any errors during the configuration process, such as misspellings, will likely yield records that do not match the domain it is protecting. In such cases, domain validation will fail and the website or service will not be resolved when requested.

DNSSEC provides integrity as part of the CIA security triad–it neither provides confidentiality nor availability of data. DNSSEC also does not protect against Distributed Denial of Service (DDoS) attacks. While these are not really limitations of the DNSSEC suite, it is still good to know, as it is sometimes incorrectly assumed that DNSSEC does provide these protections.

Why should your company implement DNSSEC?

DNSSEC will provide your organization and its users the peace of mind that the websites and services they use on a daily basis to accomplish their work are legitimate and not some malicious threat actor posing as such to obtain credentials and data from your company. By serving as a system of checks that span through the multi-level domains all the way back to the root DNS servers, the chain of trust between each link can be verified to ensure that communications being established between websites and services online and your organization have been vetted thoroughly and have had their integrity validated end to end.

SEE: 27 ways to reduce insider security threats (free PDF) (TechRepublic)

How do you enable DNSSEC?

Enabling DNSSEC for your organization’s DNS servers is generally a multi-step process that, while not complicated, will vary depending on your domain’s registrar, the top-level domain (TLD) extension for your site, and the nameservers’ configuration, whether managed internally or by a 3rd-party.

Some managed solutions, like CloudFlare, essentially allow DNSSEC to be enabled through several clicks of a mouse for users who utilize its fully managed DNS services. For self-managed nameservers, there is more to the configuration and setup that may require specific information to correctly implement DNSSEC. While a generalized setup is covered below in setting up DNSSEC, organizations should contact their IT support teams and any 3rd-party services they’ve contracted to manage domain services to understand exactly what the process will involve to successfully enable DNSSEC.

Setting up DNSSEC

  1. Verify that your TLD supports DNS Security Extensions.
  2. Speak to your IT department and 3rd-party domain service providers to obtain DNSSEC-specific requirements.
  3. Generate the zone signing key (ZSK) and key signing key (KSK) for your domain’s DNS zone.
  4. Sign your DNS zone to generate signed zone records for your domain(s).
  5. Generate the Declaration of Signing (DS) record, which contains hashed values for the cryptographic keys used to sign your DNS zone.
  6. Import the DS record(s) for your domain(s) to the self-hosted or fully managed nameserver, ensuring that the information obtained in step #2 is available, if needed.
  7. (Optional) Use Verisign Lab’s DNSSEC Debugger Tool to check each link in the chain of trust to diagnose any issues affecting the implementation of DNSSEC on your domain(s).

Also see:

Has your organization deployed DNSSEC? What pros or cons have you run into before, during, or after deployment? Share your comments with us below in the comments section.