The Domain Name System (DNS) is a critical part of the internet, translating domain names (like example.com) into IP addresses (like 192.0.2.1) that computers can use to locate one another. However, traditional DNS has some inherent security vulnerabilities, such as DNS spoofing, which can be exploited by malicious actors to redirect users to fraudulent websites or manipulate DNS responses.
DNS Security Extensions (DNSSEC) were introduced to mitigate these risks by adding an extra layer of security to DNS.
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) adds security to the Domain Name System (DNS) by protecting against attacks that compromise data integrity and authenticity. It ensures that DNS responses are authentic and untampered by digitally signing DNS records with cryptographic signatures.
DNSSEC relies on public-key cryptography, which involves two key components:
- Private Key: Used by authoritative DNS servers to sign DNS records.
- Public Key: Used by DNS resolvers to verify that the DNS data is intact and has not been altered.
Key Components of DNSSEC
Resource Records (RRs)
In DNS, information is stored in Resource Records (RRs), which contain various types of data, including:
- A: Maps a domain name with its corresponding IPv4 address.
- AAAA: Connects a domain name to an IPv6 address.
- CNAME: Provides an alias from one domain name to another.
- MX: Mail exchange record directing email to the correct mail server.
- TXT: Holds text data, often used for verification and policy purposes.
RRsets
An RRset (Resource Record Set) is a group of records of the same type associated with a domain name. For example, all A records for example.com form an RRset. Each RRset can be signed with a cryptographic signature to verify its authenticity.
Key DNSSEC Record Types and Their Functions
DNSSEC introduces several new DNS record types to support this cryptographic process, which include:
DNSKEY
The DNSKEY holds the public key used to verify DNS record signatures. Each DNS zone has one or more DNSKEY records, and these are critical to verify the authenticity of DNS responses.
DNSKEY records are of two types:
- ZSK (Zone Signing Key): Signs DNS records in a zone.
- KSK (Key Signing Key): Signs the DNSKEY records themselves, ensuring that the public key provided by the zone is authentic.
RRSIG
The RRSIG (Resource Record Signature) record contains the digital signature of a DNS record set. This signature is generated using the private key associated with the DNS zone and is verified by DNS resolvers using the DNSKEY record.
Each DNSSEC-protected DNS record has an associated RRSIG record that is signed using the zone’s private key.
DS (Delegation Signer)
The DS (Delegation Signer) record is used to establish a chain of trust between a parent zone (e.g., .com) and a child zone (e.g., example.com). The DS record in the parent zone contains a cryptographic hash of the child zone’s DNSKEY, allowing DNS resolvers to verify that the child zone’s DNSKEY is legitimate.
NSEC/NSEC3
The NSEC (Next Secure) and NSEC3 records are used to provide proof of non-existence for DNSSEC-signed zones. They ensure that when a DNS resolver queries a non-existent domain (such as nonexistent.example.com), it receives a cryptographically signed response proving that the domain does not exist, rather than simply receiving an error.
- NSEC: Lists the next valid domain name in the zone to prove that a queried domain does not exist.
- NSEC3: Similar to NSEC but adds cryptographic hashing to protect the privacy of zone contents.
CDS/CDNSKEY
The CDS (Child DS) and CDNSKEY records are used to automate the DNSSEC signing process for child zones. When a zone wants to be DNSSEC-enabled, these records are used to inform the parent zone of its DNSKEY without requiring manual intervention.
How DNSSEC Works
DNSSEC operates by using digital signatures to authenticate DNS responses. Here’s a step-by-step breakdown of how DNSSEC works:
DNS Lookup Request
When a user tries to visit a website by entering a URL (e.g., www.example.com), the request is sent to a DNS resolver. The resolver then contacts the authoritative DNS server for that domain to retrieve the necessary DNS records.
Digital Signatures in DNSSEC
When DNSSEC is implemented, each DNS zone (a segment of the DNS namespace, such as example.com) is equipped with a pair of cryptographic keys: a public key and a private key. The private key is used to generate a digital signature for each DNS record (A, AAAA, MX, etc.). As mentioned, this digital signature is stored in a DNSSEC-specific record known as an RRSIG (Resource Record Signature). The corresponding public key is stored in a DNSKEY record.
Zone Signing
The zone signing process involves the authoritative DNS server generating digital signatures for all the DNS records in its zone. For example, if you have an A record pointing to an IP address, DNSSEC would create an RRSIG record for that A record using the private key.
Chain of Trust
One of the critical features of DNSSEC is the concept of a “chain of trust.” Each DNS zone has its own public/private key pair, but the authenticity of a DNS record is validated through a hierarchy of trust starting from the root zone (the top of the DNS hierarchy). The root zone’s DNSKEY record is signed with a root key known as the Root Zone Key Signing Key (KSK), and all lower zones (e.g., top-level domains like .com, .org, etc.) are signed by their respective parent zones.
For Example: “www.example.com“
- User Query: A user enters “www.example.com,” which is sent to a DNS resolver.
- Root Server: The resolver asks the root server for information about the “.com” TLD.
- TLD Server: The resolver queries the “.com” TLD server for “example.com’s” authoritative DNS server.
- Authoritative Server: The resolver contacts the authoritative DNS server of “example.com” for the A record (IP address).
Chain of Trust Process
- Root Zone: The root DNSKEY is signed by the Root Zone KSK, creating trust at the top
- TLD Zone: The TLD’s DNSKEY (.com) is signed by the root
- Domain Zone: “example.com’s” DNSKEY is signed by the TLD
- DNS Record: The A record is signed by “example.com’s” DNSKEY
Key Delegation
When a domain is delegated to a subdomain (for example, example.com to sub.example.com), DNSSEC creates a Delegation Signer (DS) record. As shown in above image the DS record contains a hash of the child zone’s DNSKEY and is signed by the parent zone. This process ensures the chain of trust continues through different levels of the DNS hierarchy.
DNSSEC Validation
When a user types “www.example.com,” the recursive DNS server sends a query to the authoritative DNS server for “example.com” to retrieve the corresponding A record (which maps the domain name to an IP address).
When the recursive DNS server queries it, the authoritative DNS server responds with both the requested A record and its associated RRSIG record (the digital signature). Along with the A record and RRSIG, the recursive server retrieves the DNSKEY from the authoritative server for “example.com.” This DNSKEY contains the public key, which is necessary for verifying the RRSIG. If the signature matches, the resolver knows that the record has not been tampered with and is authentic.
If at any point in this validation process the signature does not match or the chain of trust is broken, the resolver will not accept the DNS response. Instead, it will return an error, ensuring that users are not misled by spoofed DNS information.
DNSSEC Deployment
DNSSEC deployment is done in stages, and different levels of the DNS hierarchy must support DNSSEC for it to be fully effective. Here are the critical steps in deploying DNSSEC:
Sign the Root Zone
The first and most crucial step in deploying DNSSEC was to sign the root zone, which was completed in 2010. The root zone is signed with a Key Signing Key (KSK), which is managed by ICANN, and this key is critical to the overall security of the DNSSEC system.
Sign Top-Level Domains (TLDs)
After signing the root zone, top-level domains (e.g., .com, .org) began implementing DNSSEC. Today, most major TLDs are signed and support DNSSEC.
Sign Second-Level Domains
Organizations and individuals that own second-level domains (e.g., example.com) can choose to enable DNSSEC for their domains. This involves generating DNSKEY and RRSIG records and ensuring that their domain’s parent zone (e.g., .com) has a corresponding DS record.
DNSSEC Validation by Resolvers
For DNSSEC to be fully effective, DNS resolvers must validate DNSSEC signatures. Many public resolvers, such as Google Public DNS, now support DNSSEC validation, but it must be enabled on the resolver side to provide complete protection.
DNSSEC Challenges and Limitations
While DNSSEC offers significant security improvements, it also comes with some challenges:
- Complex Deployment
DNSSEC implementation requires careful planning and management of cryptographic keys. Incorrect configurations can lead to validation failures, effectively making a domain inaccessible. - Lack of Universal Adoption
Despite its benefits, DNSSEC adoption is still not universal. Many domains and DNS resolvers do not support DNSSEC, limiting its overall effectiveness. - DDoS Mitigation
DNSSEC adds additional data to DNS responses, increasing the size of DNS packets. This can lead to larger DNS queries and potentially slower response times in some cases. The larger DNSSEC responses require more bandwidth and processing power on both the DNS servers and resolvers. During a DDoS attack, the target’s DNS infrastructure may struggle to handle the increased load from legitimate queries, exacerbating the situation. - Key Management
Managing and rotating cryptographic keys securely can be challenging for administrators, especially for large organizations with many domains.
How AppTrana WAAP DNS Management Helps
AppTrana’s DNS management simplifies the complexities of enabling and maintaining DNSSEC. The Managed Security Services (MSS) team handles the DNSSEC enablement process, eliminating concerns about configuration errors that could lead to service outages. The DNSSEC infrastructure also streamlines key management, relieving administrators of this burden and ensuring that all essential records—such as RRSIG, DNSKEY, and DS records—are accurately configured.
In addition, AppTrana’s built-in DDoS protection offers a comprehensive multi-layered defence strategy against even the most complex DNS-based DDoS attacks.
Users can easily oversee all DNS records and hosted zones, while the DNSSEC protocols provide enhanced security against potential threats. The reporting feature in AppTrana provides a visual snapshot of domain requests and errors, allowing customers to:
- Track the total requests served
- Review the number of errors recorded
- Spot NX domain errors (when DNS queries can’t map a domain name to an IP address)
- Monitor server failures (when the domain name fails to connect to an IP address)
This information allows customers to assess domain traffic, identify DNS problems, and implement fixes to ensure smooth operations.
