DNSSEC and DNS Security

DNSSEC (Domain Name System Security Extensions) is a suite of IETF specifications (RFC 4033, 4034, 4035) that add cryptographic authentication to DNS responses. The core problem DNSSEC solves is that standard DNS queries and responses are sent in cleartext, with no integrity checking. An attacker can intercept a DNS query and forge a response, redirecting a user to a malicious site. This is known as DNS cache poisoning (or DNS spoofing). DNSSEC does not encrypt DNS data; it only provides data origin authentication and data integrity. It ensures that the response you receive is exactly what the domain owner published and that it hasn't been modified in transit.

For SY0-701, you need to understand the threat DNSSEC addresses, its core components (RRSIG, DNSKEY, DS, NSEC/NSEC3), and the chain of trust. You will not need to configure DNSSEC in depth, but you must know how it works mechanically and what attacks it prevents.

DNSSEC works by adding four new resource record types to the DNS:

The validation process works as follows:

Without DNSSEC, attackers can perform:

DNSSEC prevents cache poisoning and MITM attacks by requiring digital signatures. An attacker cannot forge a valid signature without the zone's private key. Even if the attacker can intercept the query, they cannot produce a valid RRSIG for a spoofed record.

However, DNSSEC does not protect against:

To check DNSSEC validation, you can use dig with the +dnssec flag:

dig www.example.com +dnssec

Look for the ad (authenticated data) flag in the response. If it's set, the resolver has validated the DNSSEC chain.

To view the RRSIG record:

dig www.example.com RRSIG

To view the DNSKEY record:

dig example.com DNSKEY

To view the DS record in the parent zone:

dig example.com DS

You can also use delv (domain entity lookup and validation) which performs DNSSEC validation:

delv www.example.com

On the server side, popular DNS software like BIND supports DNSSEC signing. A signed zone file would include directives like:

zone "example.com" {
    type master;
    file "example.com.signed";
    auto-dnssec maintain;
    inline-signing yes;
    key-directory "keys";
};

The keys are generated using dnssec-keygen:

dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

This creates a KSK. A ZSK is created with a shorter key length:

dnssec-keygen -a RSASHA256 -b 1024 -n ZONE example.com

Deploying DNSSEC requires careful planning: - Key Rollover: Keys must be rotated periodically. KSK rollover is complex because the DS record in the parent zone must be updated. The parent zone's registrar must support DS record management. - Resolver Support: Both the authoritative server and the resolver must support DNSSEC. Many public resolvers (Google, Cloudflare) validate DNSSEC by default. Enterprise resolvers may need configuration. - Performance Overhead: DNSSEC increases DNS response size due to additional records. This can cause fragmentation issues over UDP (limit 512 bytes or 4096 with EDNS0). Some firewalls may block large DNS packets. - Zone Walking: With NSEC, an attacker can enumerate all records in a zone. Use NSEC3 to mitigate this, though it adds computational overhead.

DANE (DNS-based Authentication of Named Entities) uses DNSSEC to bind X.509 certificates to domain names. It allows a domain owner to publish a certificate association in a TLSA record, reducing reliance on Certificate Authorities. For SY0-701, understand that DANE requires DNSSEC to be secure.

A large enterprise uses internal DNS resolvers (e.g., Infoblox or Windows Server DNS). After a routine key rollover, users report that they cannot access several external websites, receiving 'DNS resolution failed' errors. The SOC analyst checks the resolver logs and sees many 'validation failure' events for domains like example.com. The analyst uses dig +dnssec example.com from a test machine and sees no RRSIG records. Further investigation reveals that the zone's ZSK was rotated but the new signature was not propagated to all authoritative servers. The correct response is to contact the domain owner to ensure all servers serve the new RRSIG records. A common mistake: the analyst assumes the resolver is misconfigured and disables DNSSEC validation, which would weaken security. Instead, the analyst should verify the chain of trust using delv and check the parent zone's DS record.

A security engineer at a financial institution monitors DNS traffic. They notice a sudden spike in queries for bank.com from internal clients. The engineer uses Wireshark to capture DNS responses and sees that some responses have an invalid RRSIG. The engineer confirms that the resolver has DNSSEC validation enabled. The logs show 'validation failure' for bank.com. The engineer traces the source IP of the malicious responses to an external attacker trying to poison the cache. Because DNSSEC is enabled, the resolver rejects the forged responses. The correct response is to block the attacker's IP and ensure no internal clients were affected. A common mistake: the engineer might think the resolver is malfunctioning and temporarily disable validation, allowing the attack to succeed.

A company wants to secure its email server using DANE (RFC 7671). The administrator creates a TLSA record for smtp.example.com in the signed zone. The record specifies that the server's TLS certificate must match a given hash. When an email client connects, it queries the TLSA record via a DNSSEC-validating resolver. If the record validates, the client compares the server's certificate to the hash in the TLSA record. If they match, the connection proceeds; otherwise, it aborts. This prevents man-in-the-middle attacks even if a CA is compromised. A common mistake: the administrator forgets to include the TLSA record in the signed zone or uses an incorrect hash, causing legitimate email delivery failures. The correct response is to test the TLSA record using dig +dnssec _25._tcp.smtp.example.com TLSA before deploying.