How do I enable DNSSEC for my domain?

DNSSEC (DNS Security Extensions) cryptographically signs your DNS records so resolvers can detect a forged or cache-poisoned response and return SERVFAIL instead of sending users to an attacker's server. Enabling it is a two-sided operation — one change at your DNS host, one at your registrar — and the order matters. Get them out of sync and your domain can go dark for everyone using a validating resolver.

What DNSSEC actually does

Plain DNS is unauthenticated UDP: anyone who can influence the path between a client and a resolver can inject a fake answer (the 2008 Kaminsky cache-poisoning attack made this practical at scale). DNSSEC adds a chain of signatures traceable to the ICANN-signed root zone. It is authentication, not encryption — queries still travel in plaintext, so pair it with DoT/DoH if you also want query privacy.

The DS record is the link

The chain of trust flows root → TLD → your domain. Your zone is signed locally with a Key Signing Key (KSK) and Zone Signing Key (ZSK), but the parent TLD must publish a DS record — a hash of your KSK — for resolvers to trust the signatures. Enabling DNSSEC = generating the keys at your DNS host and getting that DS into the TLD via your registrar.

Step by step

1. Enable signing at your DNS host. Cloudflare, Route 53, Google Cloud DNS, NS1 and Azure DNS all support one-click signing with automated key rotation. Enabling it generates the KSK/ZSK and starts signing your zone.
2. Copy the DS record. Your DNS host displays a DS record with four fields: key tag, algorithm, digest type, and the digest (hash). Prefer ECDSA P-256 (algorithm 13) — compact signatures, universal resolver support. Avoid RSA/SHA-1 (deprecated).
3. Paste the DS at your registrar. Log into the registrar where you bought the domain (not the DNS host, unless they're the same company) and enter the DS record in its DNSSEC section. The registrar publishes it into the TLD zone.
4. Wait for propagation. The TLD's TTL governs this — usually up to 48 hours.
5. Verify. Run dig +dnssec example.com A and dig DS example.com @a.gtld-servers.net. A healthy answer has the AD (Authenticated Data) flag set in the header (flags: qr rd ra ad).

The two failure modes to avoid

• DS at the registrar doesn't match the KSK at the DNS host. One wrong key tag breaks resolution globally. If you migrate DNS hosts, remove the DS first, wait for it to age out, then re-enable on the new host.
• Signed zone but no DS published. Validators treat this as merely "insecure" rather than protected — you get zero benefit.

TLD gotcha you must check first

Not every TLD accepts DS records. Notably, the .ai ccTLD does not support DNSSEC at the registry — you cannot build a chain of trust for a .ai domain regardless of your DNS host. Confirm your TLD is DNSSEC-enabled (IANA's list) before starting. There is no DNSSEC "generator" — keys are created by your DNS host, not by a form. Full background in the DNSSEC guide; to verify the chain of trust (DS at parent, DNSKEY at child, RRSIG coverage, algorithm strength, signature expiry), run a free scan on the IntoDNS.ai homepage scanner.