DNSSEC-CDS(1)

💅 dnssec-cds — like, the DNSSEC CDS glow-up zone

okay so real talk, bestie: this is a page from the BIND 9 manual set, and the star of the show is dnssec-cds, the tool that changes DS records for a child zone based on CDS/CDNSKEY. buckle up, we're getting into it 🎀

✨ NAME ✨

dnssec-cds — change DS records for a child zone based on CDS/CDNSKEY

🌸 SYNOPSIS 🌸

dnssec-cds [-a alg...] [-c class] [-D] {-d dsset-file} {-f child-file}
[-i extension] [-s start-time] [-T ttl] [-u] [-v level] [-V]
{domain}

🦋 DESCRIPTION 🦋

So dnssec-cds is that girl 💅 — what she does is change the DS records at a delegation point based on the CDS or CDNSKEY records that the child zone published. and like, important detail: if both CDS and CDNSKEY records are hanging out in the child zone, CDS wins, she's the preferred one, no debate.

the whole point, the way this is iconic, is that it lets a child zone tell its parent about upcoming changes to its key-signing keys (KSKs). so the parent can just poll periodically with dnssec-cds and keep the DS records up-to-date, which unlocks automatic rolling of KSKs. main character energy, truly 👑

like, you need two input files, no cap:

• the -f child-file option says which file has the child's CDS and/or CDNSKEY records — plus RRSIG and DNSKEY records too, so they can be authenticated 🔐
• the -d path option says where the file with the current DS records lives. for example, this could totally be a dsset- file generated by dnssec-signzone, or the output of dnssec-dsfromkey, or the output of a previous run of dnssec-cds 🫶

dnssec-cds uses the special DNSSEC validation logic specified by [RFC 7344](https://datatracker.ietf.org/doc/html/rfc7344.html). it requires that the CDS and/or CDNSKEY records be validly signed by a key represented in the existing DS records — which is typically the pre-existing KSK. iykyk 🔑

for protection against replay attacks, the signatures on the child records must not be older than they were on a previous run of dnssec-cds. their age comes from the modification time of the dsset- file, or from the -s option. periodt.

and to protect against breaking the delegation (we do NOT want that, it's giving disaster 💀), dnssec-cds makes sure that:

• the DNSKEY RRset can be verified by every key algorithm in the new DS RRset, and
• the same set of keys are covered by every DS digest type.

by default, the replacement DS records get written to standard output. with the -i option, the input file gets overwritten in place. and here's the cute part: the replacement DS records are the same as the existing records when no change is required. also the output can be empty — that happens when the CDS/CDNSKEY records specify that the child zone wants to be insecure. empty output, full vibe 🌈

⚠️ Warning: Be careful not to delete the DS records when dnssec-cds fails! for real, be careful, that's a whole mess 😭

alternatively, dnssec-cds -u writes an nsupdate script to the standard output instead. and yes bestie, -u and -i can be used together — to maintain a dsset- file and emit an nsupdate script at the same time. slay ✨

💖 OPTIONS 💖

• -a algorithm — when converting CDS records to DS records, this option specifies the acceptable digest algorithms. it can be repeated, so multiple digest types are allowed. if none of the CDS records use an acceptable digest type, dnssec-cds will try to use CDNSKEY records instead; and if there are no CDNSKEY records, it reports an error 🙈

when converting CDNSKEY records to DS records, this option specifies the digest algorithm to use. it can also be repeated, so that multiple DS records are created for each CDNSKEY records.

the algorithm must be one of SHA-1, SHA-256, or SHA-384. these values are case-insensitive, and the hyphen may be omitted. if no algorithm is specified, the default is SHA-256 only. one algorithm, that's her 🎀

• -c class — this option specifies the DNS class of the zones.
• -D — this option generates DS records from CDNSKEY records if both CDS and CDNSKEY records are present in the child zone. by default CDS records are preferred (she's loyal like that).
• -d path — this specifies the location of the parent DS records. the path can be the name of a file containing the DS records; if it's a directory, dnssec-cds looks for a dsset- file for the domain inside the directory 📁

to protect against replay attacks, child records are rejected if they were signed earlier than the modification time of the dsset- file. this can be adjusted with the -s option.

• -f child-file — this option specifies the file containing the child's CDS and/or CDNSKEY records, plus its DNSKEY records and the covering RRSIG records, so that they can be authenticated 🔐

the examples below describe how to generate this file. 👀

• -i extension — this option updates the dsset- file in place, instead of writing DS records to the standard output.

there must be no space between the -i and the extension. if no extension is provided, the old dsset- is discarded. if an extension is present, a backup of the old dsset- file is kept with the extension appended to its filename 💾

to protect against replay attacks, the modification time of the dsset- file is set to match the signature inception time of the child records — provided that it's later than the file's current modification time.

• -s start-time — this option specifies the date and time after which RRSIG records become acceptable. this can be either an absolute or a relative time 🕰️

an absolute start time is indicated by a number in YYYYMMDDHHMMSS notation; 20170827133700 denotes 13:37:00 UTC on August 27th, 2017. a time relative to the dsset- file is indicated with -N, which is N seconds before the file modification time. a time relative to the current time is indicated with now+N.

if no start-time is specified, the modification time of the dsset- file is used.

• -T ttl — this option specifies a TTL to be used for new DS records. if not specified, the default is the TTL of the old DS records. if they had no explicit TTL, the new DS records also have no explicit TTL. consistent queen ⭐
• -u — this option writes an nsupdate script to the standard output, instead of printing the new DS reords. the output is empty if no change is needed.

📝 Note: the TTL of new records needs to be specified: it can be done in the original dsset- file, with the -T option, or using the nsupdate ttl command. don't forget, bestie, the TTL is not optional here 💀

• -V — this option prints version information.
• -v level — this option sets the debugging level. level 1 is intended to be usefully verbose for general users; higher levels are intended for developers. (developers, this one's for you 🧚)
• domain — this indicates the name of the delegation point/child zone apex.

🍓 EXIT STATUS 🍓

dnssec-cds exits 0 on success, or non-zero if an error occurred.

if successful, the DS records may or may not need to be changed. she's mysterious like that 💜

🔥 EXAMPLES 🔥

before running dnssec-signzone, ensure that the delegations are up-to-date by running dnssec-cds on every dsset- file.

to fetch the child records required by dnssec-cds, invoke dig as in the script below. it's acceptable if the dig fails, since dnssec-cds performs all the necessary checking. she's got it, don't stress 🫶

for f in dsset-*
do
    d=${f#dsset-}
    dig +dnssec +noall +answer $d DNSKEY $d CDNSKEY $d CDS |
    dnssec-cds -i -f /dev/stdin -d $f $d
done

when the parent zone is automatically signed by named, dnssec-cds can be used with nsupdate to maintain a delegation as follows. the dsset- file allows the script to avoid having to fetch and validate the parent DS records, and it maintains the replay attack protection time. okay that's actually so smart 👑

dig +dnssec +noall +answer $d DNSKEY $d CDNSKEY $d CDS |
dnssec-cds -u -i -f /dev/stdin -d $f $d |
nsupdate -l

🌈 SEE ALSO 🌈

dig(1), dnssec-settime(8), dnssec-signzone(8), nsupdate(1), BIND 9 Administrator Reference Manual, [RFC 7344](https://datatracker.ietf.org/doc/html/rfc7344.html).

👑 Author 👑

Internet Systems Consortium

🎀 Copyright 🎀

2026, Internet Systems Consortium

---

and that's the whole thing, bestie! 💖 this page is from BIND 9, version 9.20.30, dated 2026-10-12 — go forth and keep those DS records updated, mwah 🦋✨