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 there is a difference between DNSSEC and DNS Security.
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, staging.bluecatnetworks.com, there are three different zone levels:
- (.) – the root
A client asks for the IP address of staging.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 staging.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 staging.bluecatnetworks.com. The authoritative server responds back with the IP address for staging.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!
A Quick Run-Through of DNSSEC
At a basic level, DNSSEC validates responses to DNS queries before they are returned to the client. Let’s look at each of the steps involved:
- A client requests an A record from staging.bluecatnetworks.com from its DNS server.
- The bluecatnetworks.com DNS Server replies back with A+ RRSIG.
- The client’s DNSSEC-enabled server then asks bluecatnetworks.com server for the DNSSEC Key RR (ZSK).
- The bluecatnetworks.com DNS server replies back with the key pair and RRSIG record.
- The DNS Server then asks the .com DNS server for DS record to verify the response it received in step three.
- The .com server replies back and verifies the KSK for bluecatnetworks.com with the DS record received from .org.
- The resolver then asks COM for its DNSKEY (ZSK) to verify the response in step five.
- COM server replies with Keys and RRSIG record.
- The client’s DNS Server then goes to the ROOT server to validate COM’s response.
- The ROOT Server replies back with RRSIG which should match the reply in step seven.
- The DNS server asks ROOT to verify the answer in step nine.
- Lastly, the ROOT server verifies its own response by supplying the key.
Image: DNSSEC-Enabled Resolution
How does DNSSEC actually work?
At the center 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”.
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.
As you can see, validation is performed by each level of the domain system. Once all of the above steps have been verified and all the answers are considered authentic, the answer will be sent to the client. If the chain of trust breaks at any point and a record cannot be verified, the DNS server will respond back with a SERVFAIL instead.
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.
DNSSEC does not encrypt DNS data, and it does not require SSL certificates or shared secrets.
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 standards.
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.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
Making Gateway Work For You | Better Self-Service
The starting point in any self-service journey is making simple tasks available to your end users. Many processes require careful attention, many clicks,…
GAO report shows how difficult IPv6 migrations really are
How difficult are IPv6 migrations? A recent GAO report on DOD’s transition plan provides some sobering conclusions.
Manage compute seamlessly with the BlueCat OpenStack Adaptive Plug-In
The BlueCat OpenStack Adaptive Plug-In provisions compute to support updates for DNS name resolution across the enterprise.
Drive DNS automation with the BlueCat Ansible module
The BlueCat Ansible module makes it easy to use playbooks to provision DNS, DHCP, and IPAM resources.