DNSSEC Checker

Every signed zone publishes its public keys as DNSKEY records and signs each set of records with an RRSIG. A resolver can verify the RRSIG on an answer for example.com with the zone's DNSKEY, but anyone can publish a key. The chain of trust is what proves the key itself is genuine.

The parent zone, .com, publishes a DS record for example.com containing a hash of the example.com key signing key. That DS record is signed with the .com key, and the root zone publishes a DS for .com signed with the root key. The root key is the one thing every validating resolver is configured to trust in advance. Validation therefore runs top down: the root vouches for .com, .com vouches for example.com, and example.com vouches for its own records. A missing or wrong link anywhere in that chain, and the answer cannot be validated.

Our checker queries the DNSKEY set of the domain and the DS set at its parent directly, recomputes the DS digest from the published key and confirms the two match, and verifies the RRSIG over the DNSKEY set with the key it names. For the chain above the domain it reads the AD bit from a validating resolver rather than walking the root and TLD zones itself, and it says so in the result.

Most signed zones use two keys. The key signing key (KSK) signs only the DNSKEY record set, and it is the key that the parent's DS record hashes. The zone signing key (ZSK) signs everything else: the A records, MX records, TXT records and so on. In a DNSKEY record the flags field tells them apart. A KSK has flags 257, meaning the zone key bit and the secure entry point (SEP) bit are both set. A ZSK has flags 256, with only the zone key bit.

The split exists so that keys can be rotated at different speeds. Changing the ZSK is entirely internal to the zone and can happen monthly with no outside involvement. Changing the KSK means publishing a new DS at the registrar and waiting for the old one to expire from caches, so it is done rarely and carefully.

The DS record has its own digest type, separate from the key algorithm. Digest type 2 (SHA-256) is the standard choice and digest type 1 (SHA-1) is deprecated. Our checker names both the algorithm and the digest type for every record it finds.

At the registrar. The DS record lives in the parent zone, and only the registry that runs the parent can write it, which it does on instruction from your registrar. Your DNS provider generates the KSK and shows you the DS values (key tag, algorithm, digest type and digest), and you enter those values in the DNSSEC section of your registrar's control panel. Some registrars that are also DNS providers, such as Cloudflare Registrar with Cloudflare DNS, publish it automatically.

Until the DS is published, a zone with DNSKEY records is signed but not validatable. Resolvers treat it exactly like an unsigned zone. Our checker reports this state separately from unsigned, because the fix is one form at the registrar rather than a change to the zone.

• DS mismatch after a key rollover or provider change. The DS at the parent hashes a key that no longer exists in the zone. This is the failure that takes domains offline when they move DNS providers without updating the registrar, and validating resolvers answer SERVFAIL for every name in the zone.
• Expired RRSIG. Signatures carry an expiration time, typically two to four weeks after signing. If the signing process stops, the signatures expire and the zone goes bogus even though nothing in it changed. Our checker shows the expiry of the signature over the DNSKEY set.
• Unsigned delegation. A subdomain delegated to other nameservers with NS records but no DS record. The subdomain is insecure, which is valid, but any DNSSEC it publishes is ignored.
• Stale DS after DNSSEC is switched off. A provider disables signing but the registrar still holds a DS. Validators expect signatures, find none, and fail.

nslookup can fetch the DNSKEY and DS records but never sets the DO bit, so it shows no RRSIG and cannot tell you whether the chain validates. The PowerShell cmdlet Resolve-DnsName with the -DnssecOk switch sets the DO bit and returns the RRSIG records alongside the answer. Point it at a validating resolver such as 1.1.1.1 to see whether the AD flag comes back.

nslookup -type=DNSKEY cloudflare.com
nslookup -type=DS cloudflare.com
Resolve-DnsName cloudflare.com -Type DNSKEY -DnssecOk
Resolve-DnsName cloudflare.com -Type A -Server 1.1.1.1 -DnssecOk

macOS ships dig, so no install is needed. Ask for the DNSKEY records with the +dnssec flag to see the RRSIG alongside them, and ask the parent for the DS. The key id in the dig output is the key tag and should match the first field of the DS record, and in the example both are 2371.

$ dig +dnssec +multi DNSKEY cloudflare.com
cloudflare.com. 3600 IN DNSKEY 257 3 13 (
    mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ== ) ; KSK; alg = ECDSAP256SHA256 ; key id = 2371
cloudflare.com. 3600 IN RRSIG DNSKEY 13 2 3600 ( ... )

$ dig DS cloudflare.com +short
2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D63826F2B9

dig and delv come from the dnsutils package on Debian and Ubuntu and from bind-utils on Fedora and RHEL. To find out whether a validating resolver accepts the chain, query one with dig and look for the ad flag in the header. A bogus zone answers SERVFAIL instead, and adding +cd (checking disabled) to the same query makes the answer come back, which confirms DNSSEC is the reason. delv validates the chain itself from the root trust anchor and prints either fully validated or the reason it failed.

$ dig @1.1.1.1 A cloudflare.com | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

$ dig @1.1.1.1 A broken-dnssec.example.com +cd

$ delv @1.1.1.1 A cloudflare.com
; fully validated
cloudflare.com.    300    IN    A    104.16.132.229