DNSSEC Validation

Check if your domain has Domain Name System Security Extensions (DNSSEC) enabled and verified to prevent DNS spoofing.

Evidence ASSESSED

Checked against: DNSKEY and DS chain of trust · RFC 4033-4035

RED TEAM 0 findings BLUE TEAM control did not hold

Our DNSSEC Checker determines whether a domain is cryptographically signed and whether the chain of trust validates from the root zone down. DNSSEC is what prevents an attacker from forging DNS answers for your domain.

What is DNSSEC?

DNSSEC adds cryptographic signatures to DNS records so that resolvers can verify an answer genuinely came from the authoritative source and was not altered in transit.

Plain DNS has no authentication whatsoever. A resolver asks a question and believes whatever answer arrives first, which is why cache poisoning attacks exist — an attacker who can inject a forged response can redirect your visitors to a server they control, and nothing in the protocol detects it.

DNSSEC solves this with a chain of trust. Each zone signs its records, and the parent zone publishes a DS record fingerprinting the child signing key. The chain runs from the root zone, through the TLD, to your domain. A resolver that can follow that chain knows the answer is authentic; a break anywhere in it means validation fails.

Adds cryptographic signatures to DNS records
Prevents cache poisoning and forged DNS answers
Builds a chain of trust from the root zone downwards
Requires a DS record at the parent zone to link the chain
Provides authentication and integrity, not confidentiality

Why DNSSEC Matters

Without DNSSEC, DNS answers are unauthenticated. An attacker positioned to inject responses — on a shared network, at a compromised resolver, or through cache poisoning — can point your domain anywhere. Visitors reach the attacker server believing they are at yours, and the browser shows nothing unusual until a certificate error appears, if one appears at all.

DNSSEC also enables mechanisms that depend on trustworthy DNS. DANE, which publishes certificate constraints in DNS, is only meaningful when those records can be validated. So are several emerging authentication approaches that would otherwise be trivially spoofable.

Plain DNS answers carry no authentication at all
Cache poisoning can redirect an entire domain to attacker infrastructure
Required for DANE and other DNS-based authentication
Increasingly expected in government and enterprise requirements
Protects the layer everything else depends on

How This DNSSEC Checker Works

The tool examines the signing records and attempts to validate the chain of trust.

Validates the domain input against format and SSRF safety checks
Queries for DNSKEY records to determine whether the zone is signed
Retrieves the DS record from the parent zone
Verifies that the DS record matches the published signing key
Reports whether the chain of trust validates end to end

How to Use the DNSSEC Checker

Enter the domain you want to check
Run the check to examine the signing records
Confirm whether the zone is signed at all
Check whether a DS record exists at the parent
Confirm the chain validates, since signing without a DS record achieves nothing

Understanding Your DNSSEC Results

Several records must be present and consistent for validation to succeed:

Field / Value	Meaning
`DNSKEY`	The public keys used to sign the zone. Their presence means the zone is signed, though signing alone does not establish trust without a DS record.
`DS record`	Published at the parent zone, fingerprinting your signing key. This is the link that connects your zone to the chain of trust, and it is set through your registrar.
`RRSIG`	The signatures over each record set. They carry expiry times and must be refreshed periodically, which managed DNS providers handle automatically.
`Chain validates`	The full path from the root zone through the TLD to your domain verifies successfully. This is the only state that provides actual protection.
`Signed but no DS`	The zone has signatures but the parent publishes no DS record, so resolvers have no reason to trust the keys. Common after a partial setup, and it provides no protection.
`Validation failure`	A break in the chain — usually a DS record that no longer matches the signing key after a rotation. Validating resolvers will refuse to resolve the domain at all.
`Not signed`	No DNSSEC at all. DNS answers for the domain are unauthenticated and can be forged.

Common Problems & How to Fix Them

Signing without a DS record provides no protection, because resolvers have no authenticated way to learn your keys.

Obtain the DS record values from your DNS provider and submit them through your registrar, which publishes them at the parent zone. This step is separate from enabling signing and is the one most commonly missed.

The chain is broken and validating resolvers are refusing to answer — which is DNSSEC working as designed, refusing an answer it cannot verify rather than returning a possibly forged one.

The usual cause is a DS record that does not match the current signing key. Remove the DS record at the registrar to disable validation and restore resolution, then correct the mismatch before re-enabling.

The signing key changed but the DS record at the parent still fingerprints the old one.

Key rollovers must be staged: publish the new key alongside the old, update the DS record, wait for propagation, then retire the old key. Managed DNS providers automate this. Doing it manually without overlap causes exactly this failure.

RRSIG records carry expiry times, and expired signatures cause validation failure just as a mismatch does.

Managed providers re-sign automatically. If you operate your own authoritative servers, confirm the re-signing process is running and monitored — a failed cron job here takes the domain offline for validating resolvers.

Signing keys do not transfer between providers, so the DS record at the parent no longer matches anything the new provider publishes.

Plan the migration: remove the DS record first, wait for the old TTL to expire so validation stops, migrate the zone, enable signing at the new provider, then publish the new DS record. Skipping the first step takes the domain offline.

Best Practices

Use a managed DNS provider that handles signing and key rollover automatically
Verify the chain validates after enabling, not just that signing is on
Remove the DS record before migrating DNS providers
Monitor DNSSEC validation continuously, since a break takes the domain offline
Stage key rollovers with an overlap period
Prefer NSEC3 over NSEC to limit zone enumeration
Test with a validating resolver rather than one that ignores DNSSEC

Security Recommendations

Remember DNSSEC provides authentication and integrity but not confidentiality — queries remain visible, which is what DNS over TLS and HTTPS address
Monitor validation status continuously, since a break causes a complete outage for validating resolvers rather than a degraded service
Use NSEC3 where available, as NSEC permits walking the zone to enumerate every record
Combine DNSSEC with registrar and registry locks, since it does not prevent an attacker who controls your registrar account
Enable DANE for mail servers once DNSSEC validates, which is one of its main practical benefits
Treat an unexpected DS record change as a possible hijack attempt

Frequently Asked Questions

A set of extensions that add cryptographic signatures to DNS records, letting resolvers verify that an answer genuinely came from the authoritative source and was not altered. It prevents cache poisoning and forged DNS responses.

No. It provides authentication and integrity, not confidentiality. Queries and answers remain visible to anyone on the network path. Encrypting them is what DNS over TLS and DNS over HTTPS do, and the two are complementary.

Almost certainly a missing DS record at the parent zone. Signing alone gives resolvers no authenticated way to learn your keys. The DS record is published through your registrar and is a separate step from enabling signing.

Yes. A broken chain causes validating resolvers to refuse to answer at all, which is a complete outage rather than a degraded service. This is deliberate — refusing is safer than returning a possibly forged answer.

Remove the DS record at your registrar first and wait for the old TTL to expire so validation stops. Then migrate the zone, enable signing at the new provider, and publish the new DS record. Migrating without removing the DS record first takes the domain offline.

Both prove that a name does not exist. NSEC does so in a way that allows walking the zone to enumerate every record. NSEC3 uses hashing to prevent that, and is preferable where zone contents should not be enumerable.

For anything where a forged DNS answer would matter, yes — and a managed provider makes the operational burden minimal. Running it yourself requires monitoring signature expiry and key rollovers, since failures here cause outages rather than warnings.