How to configure DNSSEC

DNS was never designed with authentication in mind, which is why attackers can still forge responses, redirect users to malicious infrastructure, and poison resolver caches decades after the protocol's debut. If you're responsible for a domain that anchors customer trust, a software update channel, or an API your build pipeline depends on, you cannot treat DNS as a solved problem. This guide walks through how to configure DNSSEC end-to-end: generating keys, signing your zone, publishing a DS record with your registrar, and verifying the chain of trust actually resolves. By the end, you'll have a working DNSSEC setup guide you can repeat across every zone you manage, and a clear sense of how it fits into broader DNS security best practices aimed at helping you prevent DNS spoofing before it reaches your users.

Step 1: Understand What DNSSEC Actually Protects Before You Configure DNSSEC

Before you touch a config file, it helps to be precise about the threat model. DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that a response genuinely came from the zone's authoritative source and wasn't altered in transit. It does not encrypt DNS traffic — that's a separate concern handled by DoH or DoT — and it does not stop denial-of-service attacks. What it does stop is cache poisoning and spoofing attacks, where an attacker injects forged records into a resolver's cache to redirect traffic for a domain to servers they control. For a supply chain security team, this matters because package registries, artifact repositories, and CI/CD webhooks all resolve hostnames before they trust them. If DNS can be spoofed, TLS certificate validation and code-signing checks downstream can be undermined too. Signing your zone closes that gap.

Step 2: Check Whether Your Registrar and DNS Provider Support It

Not every registrar accepts DS records, and not every DNS host can sign zones automatically. Before you configure DNSSEC, confirm both ends of the chain support it:

• Ask your DNS hosting provider (Cloudflare, Route 53, Google Cloud DNS, NS1, etc.) whether they offer managed DNSSEC signing.
• Check your domain registrar's control panel for a "DNSSEC" or "DS records" section — this is where you'll publish the key that links your zone to the parent zone.

Most managed providers now handle key generation and rotation for you, which is the path we'll assume for most of this guide, with a manual BIND example included for teams running their own authoritative servers.

Step 3: Enable DNSSEC on a Managed DNS Provider

If you're using a managed provider, enabling DNSSEC is usually a single toggle plus a copy-paste step to your registrar. Using Cloudflare as an example:

1. In the Cloudflare dashboard, go to DNS > Settings and click Enable DNSSEC.
2. Cloudflare generates a DS record and displays it, something like:

Key Tag: 2371
Algorithm: 13 (ECDSAP256SHA256)
Digest Type: 2 (SHA-256)
Digest: 1F5C0A3B8E9D2C4A7F6B1E3D9C8A7B6F5E4D3C2B1A9F8E7D6C5B4A3F2E1D0C9B

3. Log in to your registrar and locate the DS record or "DNSSEC records" field for your domain.
4. Enter the Key Tag, Algorithm, Digest Type, and Digest exactly as shown, then save.

Propagation to the parent zone (the TLD's nameservers) can take anywhere from a few minutes to 24 hours depending on the registrar and TLD.

Step 4: Sign the Zone Manually With BIND (Self-Hosted Authoritative Servers)

If you run your own authoritative nameserver, you'll generate keys and sign the zone yourself. This example uses BIND's dnssec-keygen and dnssec-signzone tools.

Generate a Zone Signing Key (ZSK) and Key Signing Key (KSK):

# Zone Signing Key
dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com

# Key Signing Key (with the SEP/KSK flag)
dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE example.com

Add the resulting $INCLUDE lines for both public keys to your zone file, then sign it:

dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \
  -N INCREMENT -o example.com -t db.example.com

This produces db.example.com.signed, which you point BIND to load instead of the original zone file. Update named.conf to reference the signed zone, then reload:

rndc reload example.com

Finally, extract the DS record for your registrar from the generated dsset-example.com. file.

Step 5: Publish the DS Record and Confirm the Chain of Trust

Whether you used a managed provider or BIND, the critical step is the same: the DS record must be published in the parent zone via your registrar. Until that happens, your signed zone is invisible to validating resolvers — they'll simply treat it as unsigned. Log into your registrar, paste in the DS record values, and save. Then wait for propagation before moving to verification.

Step 6: Verify DNSSEC Is Actually Working

Don't trust the dashboard checkmark — verify independently.

Check that DNSKEY and RRSIG records are published:

dig example.com DNSKEY +short
dig example.com A +dnssec

You should see RRSIG records alongside the A record answer. Next, confirm the resolver validates the chain of trust:

dig +dnssec +multiline example.com A @8.8.8.8

Look for the ad (Authenticated Data) flag in the response header — its presence means a validating resolver confirmed your signatures against the DS record in the parent zone. You can also use online tools like Verisign's DNSSEC Analyzer or delv (part of the BIND toolkit) for a more detailed trust-chain walk:

delv example.com A

A fully validated response from delv ends with ; fully validated, which is the strongest confirmation you'll get from the command line.

Troubleshooting Common DNSSEC Issues

• SERVFAIL after enabling DNSSEC: Almost always means the DS record at the registrar doesn't match the current DNSKEY. This happens after key rotation if the old DS wasn't updated, or if a digest/algorithm value was copied incorrectly. Re-copy the DS record directly from your DNS provider's dashboard.
• No ad flag despite a valid setup: The resolver you're querying may not perform DNSSEC validation at all. Test against 8.8.8.8 or 1.1.1.1, both of which validate by default.
• Zone works internally but fails for external users: Check TTL and propagation timing — parent zone updates can lag well behind your authoritative zone's changes.
• Signed zone breaks after a record change: Manual BIND setups require re-signing after every zone edit. Automate this with a cron job calling dnssec-signzone, or move to a provider with automatic re-signing to avoid stale signatures.
• Key rollover causes a brief outage: Follow the pre-publish or double-signature rollover method rather than swapping keys directly, so resolvers with cached DNSKEY records don't suddenly fail validation.

How Safeguard Helps

Configuring DNSSEC correctly is necessary but not sufficient — it's one control in a much larger chain of trust that software supply chains depend on. Safeguard continuously monitors the DNS posture of the domains your build systems, package registries, and deployment pipelines rely on, flagging unsigned zones, expiring DS records, and misconfigurations before they become exploitable gaps. Because DNS spoofing is often a precursor to more damaging attacks — typosquatted dependency downloads, forged webhook endpoints, or redirected artifact repositories — Safeguard correlates DNS security findings with your software bill of materials and CI/CD integrations, so a weak DNSSEC setup on a vendor's domain shows up as a supply chain risk, not just a networking footnote. Combined with the DNS security best practices outlined above, that visibility helps you close one of the oldest, most overlooked gaps in software supply chain security before an attacker finds it first.