Your zone can be signed, with DNSKEY and RRSIG records published, and still get no benefit from DNSSEC. If the parent zone (the TLD or registry above your domain) has no DS record for you, validating resolvers have no anchor to start from. They treat your zone as unsigned and accept whatever answer arrives. This article covers what the scanner finds, why the gap matters, and how to close it.
What the finding means
DNSSEC, defined in RFC 4033 and RFC 4035, builds a chain of trust from the root downward. The root signs the TLD's keys. The TLD publishes a DS (Delegation Signer) record for each child zone that opts in, and that record holds a digest of the child's key-signing DNSKEY. A resolver follows the chain like this:
- It trusts the root key as a configured trust anchor.
- It fetches the DS record for your domain from the parent. The parent signs this record.
- It fetches your DNSKEY set and checks that one key matches the DS digest.
- It uses that key to verify the RRSIG signatures over your answers.
If step 2 returns nothing, the chain breaks at the top. Under RFC 4035 section 5, a zone with no DS at the parent is an "insecure delegation". The resolver cannot distinguish "this zone is deliberately unsigned" from "an attacker stripped the signatures", so it falls back to ordinary unauthenticated DNS.
This finding fires when the parent zone publishes no DS record for your domain.
Why it is rated high
A missing DS record disables the whole mechanism, even when everything else is configured correctly. Signing the zone does nothing for the validator until the parent vouches for the key.
An attacker who can influence DNS answers can exploit the gap. Typical positions are an on-path network, a compromised resolver cache, or a poisoned response. With no DS record, the attacker can forge or alter answers and the resolver has nothing to check them against. The records most at risk are:
- MX and mail-related TXT records. Redirecting these lets an attacker intercept mail or defeat SPF and DKIM lookups.
- CAA records. A forged "no CAA" answer can let a rogue certificate authority issue a certificate for your domain.
- TLSA records. DANE only works when DNSSEC authenticates the TLSA answer. Without a valid chain, it is advisory.
- MTA-STS discovery. The policy TXT record is fetched over DNS, so a forged answer can downgrade or hide the policy.
- A and AAAA records. Forged addresses send users and API clients to attacker infrastructure.
DNSSEC does not encrypt anything, and it does not stop attacks that bypass DNS. It is, however, the only mechanism that makes DNS answers verifiable end to end, and skipping it weakens the controls built on top of DNS. An auditor reviewing your email authentication or certificate issuance will ask how the DNS data underneath them is protected. "Not at all" is a weak answer, and frameworks that reference DNS integrity will flag it.
How the scanner detects and rates it
The scanner queries the parent zone's authoritative servers for DS records at your domain's delegation point. It runs this separately from the DNSKEY lookup against your own nameservers, so it can tell the failure cases apart.
- Pass: the parent returns at least one DS record for the domain.
- Fail, high severity: the parent returns an empty answer, or NODATA, for DS at your name.
- Evidence: the report records the parent zone queried, the response code, and the DS records returned. If your zone publishes DNSKEY records but the parent has no DS, the evidence says so. That tells you the signing work is done and only the delegation step is missing.
The scanner gives no partial credit. A DS record that exists but matches no DNSKEY is a different failure, because the chain is broken rather than absent. The neighboring chain-validity checks report it. This finding only asks whether the parent publishes a DS record at all.
How to fix it
You can only add a DS record through whoever controls the delegation: your registrar, or the registry if you are a registrar yourself. You cannot publish it in your own zone.
1. Make sure the zone is signed
Confirm that your DNS provider signs the zone and publishes a DNSKEY record:
dig +short DNSKEY example.com @ns1.example-dns.net
If this returns nothing, enable DNSSEC at your DNS provider first. Most managed providers have a single toggle. If you run your own authoritative servers, enable signing in your software. For BIND with automatic key management:
zone "example.com" {
type primary;
file "example.com.zone";
dnssec-policy default;
inline-signing yes;
};
2. Get the DS record data
Your provider normally shows the DS values in its dashboard. You can also derive them from the key-signing key:
dig +short DNSKEY example.com | dnssec-dsfromkey -2 -f - example.com
A typical result looks like this:
example.com. IN DS 12345 13 2 49FD46E6C4B45C55D4AC...
The four fields are key tag, algorithm number, digest type, and digest. Prefer digest type 2 (SHA-256), and avoid digest type 1 (SHA-1) unless the registry requires it.
3. Submit it at the registrar
Open the registrar's DNSSEC or DS record settings for the domain and enter the key tag, algorithm, digest type, and digest exactly as shown. Some registrars ask for the full DNSKEY instead and compute the digest themselves. If your DNS provider and registrar are the same company, there is often a one-click option.
Some registries support CDS and CDNSKEY records, which let the child zone signal the parent to publish or update DS automatically. If your registry scans for these, the provider may handle the whole step for you.
4. Wait for propagation
Registries usually publish DS changes within minutes to a few hours. Cached negative answers can persist for the TTL of the parent's SOA minimum.
Avoiding an outage
If you publish a DS record for a zone that is not correctly signed, validating resolvers return SERVFAIL for your domain, and it goes dark for a large share of users. Before you submit, check that the DNSKEY is live on every nameserver and that RRSIGs are present and unexpired. If you are moving DNS providers, do not publish the DS record until the new provider serves the same signed zone. When you remove DNSSEC, delete the DS record before you turn off signing.
Confirming the fix on re-scan
First check the parent directly:
dig +short DS example.com
dig +dnssec example.com A
The first command should print your DS record. In the second, a validating resolver such as 1.1.1.1 should return the ad (authenticated data) flag in the response header. You can also run delv example.com, which reports "fully validated" when the chain is intact.
Then re-run the scan in SetEnforce. The finding clears once the parent returns a DS record, and the evidence shows the DS data the scanner saw. If it still fails, the registry change may not have propagated yet, so wait and re-scan.
Key takeaways
- A signed zone without a DS record at the parent is still treated as unsigned, so resolvers will not verify its answers.
- The finding is rated high because it silently removes the protection that TLSA, CAA, and MTA-STS discovery depend on.
- You fix it at the registrar, not in your own zone file. Publish the key tag, algorithm, digest type, and digest from your current key-signing key.
- Confirm that the zone is correctly signed before you publish the DS record. A mismatched DS record causes an outage, not just a warning.
- Verify with
dig DS, thendelv, then a fresh scan.