DNSSEC Missing

Understanding DNSSEC Protection

DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that the information really comes from your authoritative servers and has not been modified. When a zone is signed, resolvers can walk a trust path from the root, through the TLD, down to your domain and confirm that every DNS response is authentic.

Without DNSSEC, an attacker can intercept or spoof DNS responses. This can redirect users to fake websites, interfere with email delivery, or disrupt any service that depends on DNS lookups. DNSSEC prevents this by rejecting forged or altered responses.

How DNSSEC Prevents Attacks

DNSSEC protects you in two important ways.

Origin authentication and integrity. Every RRset in a signed zone has an RRSIG record. A validating resolver checks that signature using the DNSKEY set published in the zone. If the signature does not match, the data is discarded.

Authenticated denial of existence. DNSSEC signs negative responses too. When a name does not exist, the resolver receives an NSEC or NSEC3 record proving that fact. Without this, an attacker could forge NXDOMAIN responses or hide real records.

Together, these mechanisms prevent attackers from injecting false DNS data or hiding legitimate hosts.

DNSSEC Key Generation

A DNSSEC deployment starts with generating and managing keys. Your entire chain of trust depends on these keys being created and handled correctly.

Key Generation Process

You need two keys.

Generate the Zone Signing Key (ZSK):

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

Generate the Key Signing Key (KSK):

dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com

If supported by your DNS provider and registrar, you can also use Ed25519 for smaller, faster keys:

dnssec-keygen -a ED25519 -n ZONE example.com
dnssec-keygen -a ED25519 -f KSK -n ZONE example.com

Key Rollover Planning

Keys should be rotated regularly. A common baseline is:

• ZSK every 3 to 6 months
• KSK every 12 to 24 months
• Have an emergency rollover plan

The exact schedule depends on your environment and how much automation you use.

Zone Signing and Configuration

Once the keys are ready, sign your zone so it contains the DNSSEC records resolvers rely on.

Zone Signing Process

Example signing command:

dnssec-signzone -o example.com \
-k Kexample.com.+008+12345.key \
-S \
-3 1234ABCD \
-H 10 \
db.example.com \
Kexample.com.+008+54321.key

Explanation of the DNSSEC-relevant flags:

• -S lets the tool detect which key is the ZSK and which is the KSK
• -3 provides a salt for NSEC3, which makes zone enumeration harder
• -H sets the number of NSEC3 iterations

The result is a signed zone file, along with a DS file you can submit to your registrar.

Key Parameter Guidance

• Signature validity of around 30 days with refresh after about 7 days is common.
• Use NSEC3 if you want to make zone enumeration more difficult.
• Only use opt-out if you have many unsigned delegations and understand the tradeoffs.

BIND Configuration

BIND can automate signing, re-signing, and handling of DNSSEC metadata. The goal is to keep the zone signed without constant manual intervention.

Example zone configuration:

zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
key-directory "/etc/bind/keys/";
auto-dnssec maintain;
inline-signing yes;
sig-validity-interval 30 7;
dnskey-sig-validity 60;
update-policy {
grant example.com-key zonesub ANY;
};
dnssec-update-mode maintain;
};

What the DNSSEC-related directives do

key-directory
Tells BIND where your private keys live. BIND uses these to sign the zone.

auto-dnssec maintain
BIND automatically tracks key lifetimes, resigns records when needed, and handles rollovers when new keys are added.

inline-signing yes
BIND keeps a signed version of the zone internally while you maintain an unsigned zone file on disk. Any change triggers BIND to sign the updated parts.

sig-validity-interval
Sets how long new RRSIG signatures are valid and when they should be refreshed.

dnskey-sig-validity
Controls how long DNSKEY signatures remain valid. DNSKEY records change less often, so longer validity is acceptable.

dnssec-update-mode maintain
Ensures DNSSEC records are updated consistently during dynamic updates or key changes.

Global DNSSEC Options

These apply across the server.

options {
dnssec-validation auto;
dnssec-enable yes;
disable-algorithms "." { 1; 3; };
managed-keys-directory "/var/cache/bind/dynamic";
bindkeys-file "/etc/bind/bind.keys";
};

dnssec-validation auto
Enables DNSSEC validation and automatic trust anchor maintenance if BIND is also acting as a resolver.

dnssec-enable yes
Allows BIND to serve DNSSEC data for authoritative zones.

disable-algorithms
Disables weak DNSSEC algorithms globally so the server will not accept or serve signatures using them.

managed-keys-directory and bindkeys-file
Handle trusted keys and root anchors for DNSSEC validation.

DS Record Creation

The DS record connects your KSK to the parent zone and completes the chain of trust. Only publish the DS record after your zone is signed and serving DNSSEC data.

Generate DS records:

dnssec-dsfromkey -2 Kexample.com.+008+12345.key
dnssec-dsfromkey -1 Kexample.com.+008+12345.key

Verify DS publication:

dig +dnssec example.com DS @parent-ns-server

Publishing a DS for an unsigned zone will break resolution for validating resolvers.

Validation and Monitoring

After enabling DNSSEC, verify that everything works as expected.

Check for signed responses:

dig +dnssec example.com A

Check DNSKEY:

dig +dnssec example.com DNSKEY

Trace the chain of trust:

dig +dnssec +trace example.com A

Look for the AD flag from a validating resolver:

dig @8.8.8.8 example.com A

Check negative responses:

dig +dnssec nonexistent.example.com A

These checks confirm that signatures are present, keys are correct, and the trust chain is intact.

Ongoing Monitoring

Once DNSSEC is in place, you need to keep an eye on it. Most problems begin quietly. A signature might get close to expiring, a rollover may not have fully propagated, or a resolver might start dropping large DNSSEC responses because of fragmentation limits. These issues are easy to miss internally but show up as SERVFAIL for users behind validating resolvers.

Check your signature lifetimes regularly and make sure your automation is refreshing them on schedule. Track upcoming rollovers and confirm that both old and new keys are visible during the transition. If you use NSEC3, review your salt and iteration settings occasionally. External tools are especially helpful here. Running a quick DNSViz analysis can expose trust chain breaks, mismatched records between name servers, or a DS record that no longer matches your key.

Monitoring is about catching drift early so DNSSEC continues working smoothly.

Ongoing Maintenance

A DNSSEC deployment evolves over time. Keys age, recommended algorithms change, and DNS providers update their tooling. Small changes can create issues if no one is watching.

Automate your signing and rollover processes to avoid unexpected expiration. Treat validation errors in your logs as early warnings. Keep your private keys secure and backed up. Periodically review your algorithms and key sizes to make sure they match current best practices and are supported by your registrar. If your setup relies on NSEC3 for privacy, revisit the salt and iteration count from time to time to ensure it remains appropriate.

DNSSEC stays reliable when it receives the same routine maintenance you apply to the rest of your DNS.