DNSSEC stops attackers from tricking users into visiting fraudulent websites by making sure DNS responses are authentic.
Imagine you’re trying to visit example.com. Your computer asks a DNS resolver, "Hey, where’s example.com?" The resolver might ask a root server, then a .com server, and eventually an example.com authoritative server. DNSSEC adds a layer of cryptographic signatures to this exchange, so your resolver can cryptographically verify that the IP address it received actually came from the legitimate example.com DNS server and hasn’t been tampered with.
Let’s see this in action. We’ll set up DNSSEC for a zone called dnssec-example.com.
First, we need to generate cryptographic keys. This involves a Zone Signing Key (ZSK) to sign the actual records in your zone, and a Key Signing Key (KSK) to sign the ZSK.
# Generate a ZSK (e.g., RSA/SHA-256, 2048 bits)
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE dnssec-example.com
# Generate a KSK (e.g., RSA/SHA-256, 4096 bits)
dnssec-keygen -a RSASHA256 -b 4096 -f KSK -n ZONE dnssec-example.com
These commands will create files like Kdnssec-example.com.+008+12345.key and Kdnssec-example.com.+008+12345.private. The .key file contains the public key, and the .private file contains the private key.
Next, you need to incorporate these keys into your zone file. You’ll add DNSKEY records for each public key.
$TTL 3600
@ IN SOA ns1.dnssec-example.com. admin.dnssec-example.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
@ IN NS ns1.dnssec-example.com.
@ IN NS ns2.dnssec-example.com.
ns1 IN A 192.0.2.10
ns2 IN A 192.0.2.11
www IN A 192.0.2.20
; DNSKEY records for the ZSK and KSK
; Example ZSK DNSKEY record (this will be generated by dnssec-keygen)
; dnssec-example.com. 3600 IN DNSKEY 257 3 8 AwEAAc...
; Example KSK DNSKEY record (this will be generated by dnssec-keygen)
; dnssec-example.com. 3600 IN DNSKEY 257 3 8 AwEAA...
The 257 flag indicates a KSK, 3 is the protocol, and 8 is the algorithm (RSASHA256).
Now, you need to sign your zone. This process generates RRSIG (Resource Record Signature) records for each existing record and NSEC or NSEC3 records to prove the non-existence of other records.
# Sign the zone using the generated keys
dnssec-signzone -A -N INCREMENT -o dnssec-example.com -K /path/to/your/keys dnssec-example.com
The -A option enables automatic re-signing, -N INCREMENT ensures the serial number is incremented, and -o specifies the origin. The output will be a new, signed zone file.
The crucial part for the rest of the internet to trust your zone is publishing your public KSK. This is done by creating a Delegation Signer (DS) record at the parent zone. Your domain registrar or DNS hosting provider will typically have a portal for this. You’ll need the algorithm, digest type, and the digest (a hash) of your KSK.
For example, if your KSK has algorithm 8 (RSASHA256) and digest type 2 (SHA-256), and the digest is abcdef123456..., you’d provide these values to your registrar.
The system works by establishing a chain of trust. The root zone is signed, and its KSK public key is known to resolvers. The root zone’s DS record points to the .com zone’s KSK, and so on, down to your zone. When a resolver queries for www.dnssec-example.com, it receives the signed records and the DNSKEY record for your zone. It then asks the parent zone (e.g., .com) for the DS record for dnssec-example.com. If the DS record matches the hash of the KSK it received, and the KSK verifies the ZSK, and the ZSK verifies the A record for www, then the response is trusted.
One thing most people don’t realize is that while DNSSEC guarantees authenticity, it doesn’t guarantee availability. A denial-of-service attack can still make your zone inaccessible, and the cryptographic signatures won’t prevent that. You still need robust infrastructure and DDoS protection.
The next step after setting up DNSSEC is managing key rollovers, which is a process designed to replace your ZSK and KSK periodically without disrupting service.