DNSSEC

DNS turns a domain name into the addresses your browser and mail server connect to, but plain DNS has no way to prove an answer is genuine. DNSSEC (DNS Security Extensions) adds digital signatures to DNS records so that a resolver can check that an answer really came from the domain's DNS host and was not altered on the way. This guide explains how DNSSEC works, what it takes to switch it on safely, and how to check and troubleshoot it.

1. What DNSSEC is, and what it is not

DNSSEC is a set of standards that adds cryptographic signatures to DNS data. When a validating resolver (for example your ISP's resolver, or a public one such as Google Public DNS, Cloudflare or Quad9) looks up a signed domain, it checks each signature. If a signature is missing or wrong, the resolver refuses the answer instead of passing a forged address to the visitor.

It helps to be clear about the limits:

• DNSSEC proves authenticity, not secrecy. DNS answers are still readable by anyone on the path. Encryption of DNS queries is a separate topic (DNS over HTTPS or TLS).
• DNSSEC does not replace SSL/TLS. Your website still needs an HTTPS certificate. DNSSEC stops a visitor being sent to the wrong server; TLS protects the connection once they get there.
• DNSSEC does not stop a hijack at the registrar. If someone takes over your registrar account and changes nameservers, DNSSEC cannot help. Protect that account with a strong password and two-factor authentication.

2. Why it matters

DNSSEC is most valuable for domains that handle logins, payments or email that others rely on. For a small brochure site the benefit is smaller, and the main cost is operational care, covered in section 7.

3. How the chain of trust works

DNSSEC works as a chain from the root of the DNS down to your domain. Each level vouches for the key of the level below it.

If any link is missing, the domain is treated as unsigned (no protection, but it still works). If a link is present but wrong, the domain fails validation and stops resolving for everyone who uses a validating resolver.

4. The DNSSEC record types

Zone-signing and key-signing keys

Most setups use two keys. The zone-signing key (ZSK) signs your everyday records. The key-signing key (KSK) signs only the DNSKEY set, and it is the key the DS record at the parent points to. Splitting them means the ZSK can be changed without touching the registry. Some modern setups use one combined signing key (CSK) instead, which is fine too.

Algorithms in 2026

Choose ECDSA P-256 with SHA-256 (algorithm 13) for new setups. It gives small signatures and is what most large zones, including .in and .com, now use. RSA with SHA-256 (algorithm 8) is still valid. Avoid anything based on SHA-1 (algorithms 5 and 7), and use digest type 2 (SHA-256) for DS records, not digest type 1.

5. Setting up DNSSEC for a domain

How you switch it on depends almost entirely on who hosts your DNS.

If a managed DNS provider hosts your DNS

Many DNS providers, for example Cloudflare, sign zones for you with one switch. The provider then shows you the DS record details: a key tag, an algorithm number, a digest type and a digest (a long hexadecimal string). That DS record then has to be published at the registry through your registrar. The provider also handles key rollovers, which is the hard part.

If you run your own DNS server

On your own server or VPS, current versions of BIND and Knot DNS can sign a zone and roll its keys automatically. In BIND 9.18 and later, you attach a policy to the zone instead of generating keys by hand:

zone "example.com" {
    type primary;
    file "example.com.zone";
    dnssec-policy default;
    inline-signing yes;
};

The built-in default policy uses ECDSA P-256 and manages the keys for you. Older guides that run dnssec-keygen and dnssec-signzone by hand still work, but they leave you responsible for re-signing the zone before signatures expire, which is a common cause of outages. Once the zone is signed, read the DS record from your server (for example with dnssec-dsfromkey) and have it published at the registry.

Publishing the DS record

The DS record is the step that makes DNSSEC live, and it goes to the registry through the registrar that holds your domain. For domains registered with Domain India, the client area does not currently have a self-service DS record page. Open a support ticket with the domain name and the name of your DNS provider, and support will tell you what is possible for that domain before anything is changed.

6. Checking DNSSEC

You can check any domain from a terminal. dig is available on macOS and Linux, and in WSL on Windows.

# Is the extension signed? Any answer means yes.
dig DS in. +short

# Is a DS record published for your domain?
dig DS yourdomain.in +short

# Does your zone publish keys?
dig DNSKEY yourdomain.in +short

# Ask a validating resolver and look for the "ad" flag in the header
dig @1.1.1.1 +dnssec yourdomain.in A

# Full validation trace from the root (BIND's delv tool)
delv yourdomain.in A +vtrace

In the dig output, flags: qr rd ra ad means the resolver validated the answer. If the domain is signed but a validating resolver returns SERVFAIL while dig +cd (checking disabled) returns an answer, DNSSEC validation is failing.

Online tools draw the whole chain for you, which is the fastest way to find a broken link:

• DNSViz (dnsviz.net) shows every level from the root to your records and highlights errors.
• Verisign DNSSEC Analyzer (dnssec-analyzer.verisignlabs.com) lists each check with a pass or fail.
• Internet.nl tests DNSSEC together with other standards such as IPv6 and HTTPS.

7. Running DNSSEC without breaking your domain

Most DNSSEC outages come from routine changes, not attacks.

On key rollovers: current guidance no longer calls for rotating keys every few months. Automated tools roll the zone-signing key on their own schedule; a KSK rollover needs a DS change at the registry and should be planned, not rushed. For NSEC3, current best practice (RFC 9276) is zero extra iterations and no salt, which is what BIND's default policy does.

Common failures and what they mean

8. Which extensions support DNSSEC

Almost all extensions in common use are signed, including .in and its second-level extensions such as .co.in, .com, .net and .org. You can confirm any extension with dig DS in. +short (replacing in). For a checked list of popular extensions, read the list of extensions that support DNSSEC.

9. DNSSEC and Domain India

Domain India is a NIXI-accredited .IN registrar, and the extensions we sell most, such as .in, .co.in and .com, are signed at the registry. Whether DNSSEC can be enabled for a particular domain depends on where its DNS is hosted and on the extension, so we don't promise it for every domain. If you want DNSSEC on a domain registered with us, open a ticket with the domain name and your DNS provider before you change anything.

If you only need your domain to work with your hosting, you don't need DNSSEC for that. Point the domain at your hosting nameservers as described in how do I change my nameservers.

Ready to secure your domain? Check your extension and domain with the commands above, see the list of extensions that support DNSSEC, and for a domain registered with us, open a ticket before you publish a DS record. Looking for a new name? Search for a domain.