Enabling DNSSEC: the DS Record, the Right Order and Common Errors

Plain DNS answers carry no signature, so an attacker could in theory plant a forged answer in a resolver cache and send users to the wrong server. DNSSEC fixes this with cryptographic signatures that resolvers verify along a chain starting at the parent zone. It is strong protection that does not forgive mistakes: a wrong DS record or an expired signature makes the domain unreachable for everyone behind a validating resolver.

The chain of trust

The root zone vouches for a top-level zone such as .uz, which vouches for your domain. Your zone publishes DNSKEY records and RRSIG signatures; the parent holds a DS record, a hash of your key, submitted through the registrar. So DNSSEC is configured in two places: at your DNS host and where the domain is registered. A KSK signs the DNSKEY set and its hash goes into DS, a ZSK signs everything else, and many modern setups use a single combined CSK.

Before you start

Your DNS service must be able to sign the zone, either with a single switch in a managed service or with BIND, Knot or PowerDNS on your own server. The TLD and registrar must accept DS records; if your domain is with sayt.uz, check the option in the cabinet or with support. Algorithm 13, ECDSAP256SHA256, is the usual recommendation today.

The right order: sign first, then DS

Sign the zone and publish DNSKEY, wait at least the DNSKEY TTL, and only then add DS at the parent. If DS appears before the zone is signed, validating resolvers return SERVFAIL. In BIND 9.18 and later, a policy automates keys and re-signing:

zone "example.uz" {
    type primary;
    file "/var/lib/bind/db.example.uz";
    dnssec-policy default;
    inline-signing yes;
};

rndc reconfig
rndc dnssec -status example.uz
dnssec-dsfromkey -2 /var/lib/bind/Kexample.uz.+013+12345.key

The output looks like example.uz. IN DS 12345 13 2 3F1A...C9D2: key tag, algorithm, digest type (2 means SHA-256) and digest, the four values a registrar asks for. Once DS is live at the parent, tell BIND with rndc dnssec -checkds published example.uz so key rollovers proceed correctly.

Verifying

dig @8.8.8.8 example.uz A +dnssec
dig example.uz DS +short
delv @1.1.1.1 example.uz A

The ad flag means validation succeeded. If a normal query returns SERVFAIL but dig @8.8.8.8 example.uz A +cd (checking disabled) answers, the problem is DNSSEC. Tools such as DNSViz show which link in the chain is broken.

Common errors

The most dangerous one happens when changing DNS hosts. A private school in Bukhara moved its site and changed nameservers but left the old DS in place. The new provider signed with a different key, so parents using validating resolvers could not open the site while others saw nothing wrong, which made the fault hard to find. The safe order is: remove DS, wait out its TTL, change NS, then enable DNSSEC again at the new host.

Other classics are expired RRSIG signatures when the signer stops or a zone was signed once by hand, a DS built from the ZSK or with the wrong algorithm number, a missing new DS after a key rollover, and a wrong server clock that makes fresh signatures look invalid.

Monitoring signatures

Because expired signatures break a domain silently, add DNSSEC to your monitoring. dig example.uz SOA +dnssec +multi prints the RRSIG record with its inception and expiration timestamps; a simple daily check that alerts when expiration is less than a week away catches a stalled signer long before users notice. Also confirm the DNS server clock is synced with NTP.

Turning DNSSEC off safely

Reverse the order: remove DS at the registrar, wait a day or two for the parent TTL and resolver caches, and only then stop signing. Keeping the zone signed in the meantime does no harm and keeps the site working for resolvers that still cache the old DS.