How DNSSEC Works

DNSSEC stands for Domain Name System Security Extensions. It is a set of extensions to DNS (Domain Name System) intended to provide security to the DNS protocol by enabling DNS responses to be validated. DNS is a critical component of internet infrastructure, translating human-readable domain names like www.example.com into IP addresses that computers use to identify each other.

Why it was Invented:

DNSSEC was invented because the original DNS protocol had numerous vulnerabilities and lacked mechanisms to ensure the integrity and authenticity of the data it provided. Without security, DNS can be susceptible to various attacks, like DNS spoofing and cache poisoning, which can misdirect internet users to fraudulent websites. Such attacks can lead to the theft of sensitive information like login credentials and personal information.

How DNSSEC Works:

DNSSEC adds a layer of security to DNS by employing a system of public keys and digital signatures to ensure the integrity and authenticity of DNS data. Here’s a simplified explanation of how it operates:

Zone Signing: Domain owners generate public and private key pairs for their domains and sign the DNS records with their private key. The resultant digital signatures are then stored in DNS alongside the original records.
Chain of Trust: The public key used to sign a domain’s DNS records is also signed by the domain’s registrar and, in turn, by the domain's Top-Level Domain (TLD) operator (e.g., .com, .org). This continues up to the Root DNS Servers, creating a “chain of trust.”
Validation: When a DNS resolver receives DNS information, it can follow this chain of trust, using the public keys at each level to verify the digital signatures and ensure the DNS data has not been tampered with.
Key Rollover: DNSSEC employs mechanisms for periodically changing the keys used to sign DNS records, known as key rollover, to mitigate the risk of keys being compromised.

Advantages of DNSSEC:

Integrity Verification: DNSSEC ensures that the data received from the DNS is identical to the data on the authoritative DNS server.
Authenticity Assurance: DNSSEC guarantees that the DNS data comes from the legitimate, authoritative source and has not been altered during transit.
Protection Against Spoofing and Poisoning: By validating the digital signatures, DNSSEC prevents DNS cache poisoning and spoofing attacks, protecting users from being misdirected to malicious sites.

Challenges and Limitations:

Complexity: DNSSEC adds complexity to DNS management, requiring additional configuration, key management, and maintenance.
Deployment Barriers: Full adoption of DNSSEC requires implementation at every level of the DNS hierarchy, and many domains and DNS resolvers do not yet support DNSSEC, limiting its overall effectiveness.
Does Not Encrypt Data: DNSSEC does not provide confidentiality of DNS data; it doesn't encrypt the data but only verifies its integrity and origin.

DNSSEC was developed to overcome the inherent security limitations in the original DNS protocol by providing a means to ensure the authenticity and integrity of DNS data, and thereby safeguarding against various types of cyberattacks that exploit DNS vulnerabilities. Despite its challenges and limitations, DNSSEC is crucial for maintaining trust in DNS and protecting users from fraudulent and malicious websites.

DNSSEC has its own set of terminology that is essential for understanding how it secures the DNS infrastructure. Here are explanations for RRSET, RRSIG, ZSK, and some additional crucial terms related to DNSSEC:

1. RRSET (Resource Record Set):

An RRSET is a group of DNS records with the same label, class, and type, but possibly with different data. For example, if a domain has multiple A records, they would collectively form one RRSET. DNSSEC signs RRSETs, not individual records.

2. RRSIG (Resource Record Signature):

RRSIG is a DNS record that stores the digital signature of an RRSET. This signature is generated using a private key by the entity responsible for the zone and can be validated by the resolver using the corresponding public key. An RRSIG record exists for each RRSET in a zone that is signed with DNSSEC.

3. ZSK (Zone Signing Key):

ZSK is one of the two types of keys used in DNSSEC. It is a key pair used to sign the RRSETs within a DNS zone. It usually has a shorter lifetime and is rotated more frequently compared to the Key Signing Key (KSK).

4. KSK (Key Signing Key):

The KSK is another key pair used in DNSSEC. It is used to sign the DNSKEY RRSET, which includes the ZSK. The KSK usually has a longer lifetime than the ZSK and its public component is placed in the DS record in the parent zone, establishing the chain of trust.

5. DS (Delegation Signer):

The DS record is used to create a chain of trust between a child and a parent zone in DNSSEC. It is placed in the parent zone and contains a hash of the child zone's KSK. It helps in verifying the authenticity of the DNSKEY record received from the child zone.

6. DNSKEY:

The DNSKEY record holds the public keys (both ZSK and KSK) that are used to verify the signatures in the RRSIG records. DNSKEY records are found at the zone apex and are used by resolvers to validate the authenticity of DNS data received.

7. NSEC/NSEC3:

These records are used to provide authenticated denial of existence. They are used to securely indicate that a certain name does not exist in the zone. NSEC3 is a more secure and modern version of NSEC, providing additional protection against zone enumeration attacks.

Recap:

RRSETs are groups of similar DNS records that are signed in DNSSEC.
RRSIGs are the digital signatures of those RRSETs.
ZSKs are used to sign RRSETs within a zone.
KSKs are used to sign the DNSKEY RRSET and establish a chain of trust with the parent zone via the DS record.
DNSKEYs store the public keys used for DNSSEC verification.
NSEC/NSEC3 records provide secure, authenticated denial of existence for DNS records.

The Chain of Trust

The Chain of Trust in DNSSEC refers to the hierarchical trust relationship established from the root zone down to the final domain's DNS records, ensuring the integrity and authenticity of DNS data. It's essential for validating DNS responses, confirming that the provided information is correct and hasn't been tampered with. Each level of the domain name hierarchy must validate the level below it, establishing a continuous chain of trust.

Formation of Chain of Trust:

Root Zone: The chain of trust begins with the Root Zone, which is signed with DNSSEC, and the trust anchors (public keys) for the root zone are widely distributed and embedded in DNS resolvers.
Top-Level Domain (TLD): The Root Zone contains DS (Delegation Signer) records for the TLDs (e.g., .com, .org) it delegates to, establishing a trust relationship with the TLDs.
Second-Level Domain: TLD zones contain DS records for the second-level domains (e.g., example.com) they delegate to, continuing the chain of trust down the DNS hierarchy.
Subdomains: The process continues for any subdomains, with each level containing DS records pointing to the next level in the hierarchy, ensuring the integrity of the entire domain structure.

Validation Process:

DNS Resolver Queries: When a DNS resolver gets a DNS response, it follows the chain of trust, from the root zone downwards, to validate the DNSSEC signatures.
DS and DNSKEY Verification: The resolver checks the DS record in the parent zone against the DNSKEY in the child zone, and if they match, it confirms the authenticity of the DNSKEY.
RRSIG Verification: The resolver then uses this validated DNSKEY to check the RRSIG (Resource Record Signature) for the queried DNS record, ensuring the DNS record is intact and hasn’t been altered.
Successful Validation: If the resolver can follow and validate the chain of trust all the way from the root to the specific DNS record, it can be assured that the DNS response is authentic and hasn’t been tampered with.
Failed Validation: If any validation step fails, the resolver will return a SERVFAIL error, indicating that the DNS data couldn’t be authenticated, protecting users from potentially malicious data.

Importance of Chain of Trust:

Integrity and Authenticity: It ensures that DNS data is accurate and originates from a legitimate source, protecting against attacks like DNS spoofing and cache poisoning.
Hierarchical Trust: By establishing trust hierarchically from the root zone down, it ensures the reliability of DNS data across the entire DNS infrastructure.
User Protection: Users are protected from malicious attacks like phishing, where attackers might redirect users to fraudulent websites to steal sensitive information, by ensuring that the DNS responses are authentic.

The Chain of Trust in DNSSEC is fundamental to maintaining the security and reliability of the DNS infrastructure. It links the trust from the root zone down to the individual DNS records, ensuring that every piece of DNS data can be validated and is trustworthy, providing a safeguard against a wide range of DNS-based attacks.

Steps to Check DNSSEC Support and Validation:

To determine if a given domain supports DNSSEC and its records are valid, you generally need to perform multiple checks. You should verify the presence of DNSSEC related records like DNSKEY, DS, and RRSIG and ensure that the resolver you use supports DNSSEC and can validate the records.

1. Check for DNSKEY and DS Records:

Verify the presence of DNSKEY and DS records which indicate that DNSSEC is configured for the domain.

💡

Here we are using Cloudflare's DNS server 1.1.1.1 with support of DNSSEC to proxy our requests

dig DNSKEY icann.org @1.1.1.1

dig DS icann.org @1.1.1.1

If DNSKEY and DS records are present, it means the domain has DNSSEC configured.

2. Check for RRSIG Records:

When querying for any other type of record (like A or AAAA), check for the presence of RRSIG records.

dig A icann.org +dnssec @1.1.1.1

If you receive RRSIG records in the ANSWER SECTION, DNSSEC is active for that record type.

3. Check the AD (Authentic Data) flag:

If the resolver supports DNSSEC and is able to validate the signatures, the ad flag will be present in the flags section of the dig output.

dig A icann.org +dnssec @1.1.1.1

If the ad flag is present, it means the resolver has validated the DNSSEC signatures successfully.

4. Check for SERVFAIL Status:

If the domain's DNSSEC configuration is invalid or the signatures can’t be validated, you might receive a status of SERVFAIL in the dig output.

dig A example.com +dnssec @1.1.1.1

If you receive SERVFAIL, it indicates a problem with DNSSEC validation, which could be due to an incorrect configuration or an invalid signature.

Notes:

Ensure you use a DNS resolver that supports DNSSEC for these checks, such as 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google).
In a correctly configured DNSSEC domain, the presence of the ad flag and the RRSIG records in the dig output typically indicate that the domain’s DNSSEC records are valid.
Remember that the absence of the ad flag could also mean the resolver is not configured to validate DNSSEC, even if the DNSSEC records (DNSKEY, DS, RRSIG) are present.

Finally, if you want to automate or perform bulk checks, various online tools and services can analyze DNSSEC configuration and validation for given domains.

Online tools to analyze the DNSSEC configuration

Below are several online tools that you can use to analyze the DNSSEC configuration for a domain:

1. DNSViz

DNSViz is a highly regarded tool for DNSSEC visualization and analysis, providing detailed and graphical analysis of DNSSEC configuration, errors, and status.

2. Verisign Labs DNSSEC Analyzer

Verisign’s DNSSEC Analyzer is another well-known tool, which provides a textual representation of the DNSSEC chain of trust, highlighting any errors or misconfigurations.

3. Internet.nl

Internet.nl's DNSSEC Test is a part of their suite of tests to check the modern internet standards support, including DNSSEC, for domain names and mail servers.

4. MXToolBox DNSSEC Lookup

MXToolBox offers a DNSSEC Lookup tool that can provide information on DNSSEC configuration along with a suite of other DNS, Email, and Domain analysis tools.