Do you have an effective plan in place for protecting the natural weaknesses of your domain name system (DNS)? If you don’t, then you’ll leave it open to DNS attacks that alter how your network functions.
While the DNS is easily targeted, it can be covered with the use of resources designed for DNS protection. The best tool for defending the DNS is domain name system security extensions (DNSSEC).
According to EfficientIP, a DNSSEC resource provides “verification of the integrity of each record, validation that the record originates from the authoritative DNS server for the record, and validation that the DNS server is trusted by upper domains in the DNS hierarchy.”
With this in mind, DNSSEC is certainly effective at patching the vulnerabilities in your DNS. To help you understand how this works, we’ll take a look at the main processes within DNSSEC below.
RRset Grouping
The first step in DNSSEC is RRset grouping.
All of the records in your DNS are categorized and placed into groups. Each group is called a resource record set (RRset).
These groups are determined by the record type, which is defined by the function it serves. There are dozens of different record types and it’s important to pull the correct one when needed.
This process is also significant because it means that records do not need to be individually signed. With RRsets, a whole group can be signed at once to expedite the process.
The other aspect of RRset grouping is that it compiles all existing records in your DNS. This means any false DNS records that are added in-transit will not be part of an RRset.
With this in mind, RRsets are a crucial first step toward streamlining and simplifying DNS record signatures.
Zone-Signing
Next, DNSSEC will initiate zone-signing keys.
Before a DNS record can be pulled, a digital signature must occur. This is to verify that the record in question is coming from the correct server and hasn’t been tampered with.
Fortunately, DNSSEC enables you to apply signatures in bulk rather than signing each record individually. This is where RRsets become extremely useful.
Zone-signing keys are done based on RRsets. Each RRset has two keys that are used to verify a record; a private and public key. The private key signs each RRset and the public key validates it.
With this in mind, both keys are essential for signing and verifying a record. This dual-layer of protection will filter out DNS records that don’t fit an RRset and those that don’t match zone-keys, both of which may be malicious.
Key-Signing
After zone-signing comes the task of key-signing keys.
This is almost the same process as zone-signing keys. Each RRset must be validated by a private and public key to ensure its accuracy and safety.
The main distinguishment between zone-signing keys and key-signing keys is how difficult it is to adjust key-signing keys. This is why the two processes are separated, allowing a simple method to resolve issues with signature verification.
Another complication with key-signing keys is that they are less trustworthy. Unlike zone-signing keys, key-signing keys validate themselves and this can create problems when you’re faced with a false key-signing key.
While key-signing keys may seem redundant, they are a core component of DNSSEC and add another layer of defense to your DNS.
Delegation and Chain of Trust
Two significant steps in the process involve delegation and chain of trust.
These two steps are closely related and consist of the trust transferring process of DNSSEC. This primarily relates to child and parent zones in your DNS, which are the subdomains and domains of your network.
When you want to assign trust to a child zone (subdomain) from a parent zone (domain), yet another record is required for verification. This is a delegation signer record (DSR).
A DNSKEY record is sent to the parent zone when transferring is initiated, which will produce the DSR. The DSR is also used to verify that a child zone is enabled for DNSSEC.
The other portion of this is chain of trust. A DSR is necessary to validate the transfer of trust from a parent zone to a child zone, but the DSR must also be verified.
DSRs are validated in the same way as RRsets. This means public and private keys are used to check that the record comes from the correct location and contains the proper information.
From here, the DNSSEC process repeats itself. Upon verifying a DSR, you might then need to go through key-signing and zone-signing to fully validate a request.
As you might imagine, this is a lengthy and complicated process. Fortunately, DNSSEC automates it and processes DNS requests seamlessly.
Explicit Denial of Existence
A final component of DNSSEC involves explicit denial of existence.
This is useful because it allows you to authenticate all DNS responses. A current problem with a standard DNS configuration is that searching for a non-existent IP address won’t give a response.
This is challenging because it doesn’t allow for response authentication. There isn’t a response to authenticate in the first place.
DNSSEC fixes this error by creating a function for responding to non-existent searches. This appears in the form of next secure (NSEC) records, which simply go to the next available record of similar value.
With NSEC records, every DNS query can be traced and verified. This provides a greater level of security to your network because no queries will go unchecked.
Closing Thoughts
To protect your domain name system, you need to use domain name security extensions (DNSSEC). This is a package of security features that add several layers of verification to DNS queries and records.
DNSSEC consists of four core processes. This includes RRset grouping, zone-signing keys, key-signing keys, and delegation/chain of trust. Explicit denial of existence is also available as an added convenience and safety function.
Setting up DNSSEC is the best way of keeping DNS attacks at bay. Take advantage of this and secure your DNS by initiating DNSSEC!
