What is DNSSEC?
DNSSEC stands for Domain Name System Security Extension. It is a mechanism that uses cryptography to provide authentication and integrity for DNS queries.
When DNSSEC is enabled, it helps the DNS server answer the following questions:
- Is the root or authoritative server authorized to provide a query response?
- Can I trust the content of the query response?
- Can I trust the response was not modified in transit?
Because DNS was not designed to be secure, DNSSEC is a requirement for your DNS Security tool belt.
It is important to note that DNSSEC is not DNS Security. To learn more about the difference between the two, read our blog.
Normal DNS Resolution vs. DNSSEC-Enabled Resolution
A DNS query begins when a person decides to go any website. For example, when a DNS server resolves for the BlueCat website, www.bluecatnetworks.com, there are three different zone levels:
- (.) – the root
A client asks for the IP address of www.bluecatnetworks.com by querying its designated DNS server (resolver). Assuming the answer has not already been cached (stored) the resolver starts a recursive query (queries other servers on behalf of the client) by asking the root name server where www.bluecatnetworks.com is. The root name server responds with a referral to go to the .com server. The resolver then gets a referral from the .com server directing to the authoritative servers for www.bluecatnetworks.com. The authoritative server responds back with the IP address for www.bluecatnetworks.com, the resolver caches the IP address, then sends the IP address back to the requesting client.
Image: Normal DNS Resolution
That’s all there is to a normal DNS resolution – the mechanics are pretty simple. Unfortunately, in this case simple also means naive. DNS was not designed to be secure.
As long as the resolver receives data that serves the purpose of its request, it will continue with the query until it can send an IP address back to the client. A normal DNS resolution cannot answer the three questions that we stated earlier.
This makes standard DNS queries susceptible to “man in the middle” attacks. These attacks happen when a rogue server mimics another server (also known as spoofing) with the objective of sending a person to a bad site. For example, a bad site can be set up with the same services as the legitimate site, which means an end user would not know that they are on a bad site.
Image: Corrupted DNS Resolution/Man in the Middle Attack
Without DNSSEC enabled, the bad site is also cached in the resolver and other devices using the same resolver will go to the bad site. It stays in the cache until its pre-determined time-to-live (TTL) expires, potentially affecting countless devices.
This is why you need DNSSEC in your security tool belt!
How does DNSSEC actually work?
At the centre of DNSSEC is public-key cryptography. The validating resolver acts as a decoder. Each zone has a public key and a private key. The Public Key, as the name suggests, is available to everyone and provides the means to decrypt messages signed by the corresponding Private Key (this is why they are known as a “key pair”). Although we won’t get into the details here, let’s look at how those components work collectively to create the “Chain of Trust”.
Image: DNSSEC-Enabled Resolution
The resolver already has the necessary key for the validating responses from the Root server. This key, called a Root Key Signing Key, and known as the “Trust Anchor”, is built-in to DNSSEC-aware resolvers. Once the response from the Root is validated, each server provides the Public Keys for the server below it in the chain. In other words, it obtains the public key to validate that the data is from its respective zone. The public key is then authenticated by a private key. A thing of note here is the private key comes from the parent zone. Each parent zone has a private key that signs the respective child zone public key.
Each cryptographic key signs a subsequent cryptographic key, hence the term “Chain of Trust.”
When DNSSEC is enabled, the normal resolver becomes a validating resolver. It is programmed to detect DNSSEC queries, its responses, and has the ability to process them. Servers communicate the same DNS information with the addition of cryptographic data that can be validated with a validating resolver. It acts as a digital signature and contains information that authenticates the subsequent digital signature the resolver receives in the recursive query. Because each server works together to validate the next, it creates the aforementioned "Chain of Trust".
If there’s an attempted man in the middle attack while DNSSEC is enabled, the validating resolver rejects the response from a rogue server because it does not have the cryptographic data that validates its origins. The bad site does not get cached in the resolver and the client is never connected to the rogue site.
Image: DNSSEC-Enabled Resolution & Man in the Middle Attack
The Cost(s) of Security
Any public-facing domain can reap the value of DNSSEC. When more domains enable DNSSEC, it creates are more secure internet experience for everyone. Due to the nature of website activity, some top-level domains are already required to enable DNSSEC in accordance with security compliance.
But more often than not, DNSSEC is implemented out of basic self-interest. DNSSEC protects businesses and their brand. A man in the middle attack puts a business at risk of losing the trust of their customers. Consider the personal information that is entered into a website on a daily basis. Whether it is ecommerce and online health services or simply browsing the internet, there is much at risk.
BlueCat's Easy Button
In the absence of a centralized, automated DNS infrastructure, implementing DNSSEC can be challenging. It is a complex subject that requires an in-depth understanding to effectively put in place, particularly on networks with decentralized DNS. There’s also a high administrative overhead cost on decentralized networks that includes record maintenance and key rollover (periodically updating the key to curb the chances of the key getting decrypted).
At BlueCat, we understand the value of DNSSEC. That’s why we’ve automated the processes to make DNSSEC easy to implement and maintain. When you centralize your DNS infrastructure with BlueCat, all of these DNSSEC-related tasks happen in the background, automatically:
- Generate a cryptographic key pair
- Sign the zone and all associated DNS records
- Deploy the zone records to the Registrar
- Seamlessly rollover key-signing keys (KSK) and zone-signing keys (ZSK) on a defined schedule
- Send DNSKEY to the parent zone for secure delegation
- Generate new KSK and/or ZSK in the event of an emergency rollover
- Monitor key generation success and failure
- Manually generate new key pairs in the event of an unsuccessful auto-generation
Automating DNSSEC means adding another tool to your DNS Security tool belt with ease. Businesses have another line of defense against man in the middle attacks while contributing to the overall internet security for the general public.