DNSSEC-IMPORTKEY(1)

πŸ’… dnssec-importkey β€” the BIND 9 glow-up manual (part of the BIND 9 fam, bestie)

okay so picture this: you've got a DNSKEY record living somewhere outside your nice tidy BIND setup, and you want it managed like the rest of your keys. That's the whole gig here. Welcome to dnssec-importkey ✨


✨ NAME ✨

dnssec-importkey β€” imports DNSKEY records from external systems so they can actually be managed, no cap 🫢


πŸ¦‹ SYNOPSIS πŸ¦‹

dnssec-importkey [-K directory] [-L ttl] [-P date/offset] [-P sync
date/offset] [-D date/offset] [-D sync date/offset] [-h] [-v level] [-V]
{keyfile}

dnssec-importkey {-f filename} [-K directory] [-L ttl] [-P date/offset]
[-P sync date/offset] [-D date/offset] [-D sync date/offset] [-h] [-v
level] [-V] [dnsname]

πŸ’– DESCRIPTION πŸ’–

So like, dnssec-importkey reads a public DNSKEY record and generates a pair of .key/.private files for you. Iconic behaviour, honestly.

Where can that DNSKEY record come from? Two vibes:

  • It can be read from an existing .key file β€” in which case a corresponding .private file gets generated for it πŸŽ€
  • Or it can be read from any other file, or from standard input β€” in which case both the .key and .private files get generated πŸ’…
lowkey important: the newly created .private file does not contain private key data, and it cannot be used for signing. Like, at all. πŸ™ˆ

But bestie, here's the slay part β€” having a .private file makes it possible to set publication (-P) and deletion (-D) times for the key. Which means the public key can be added to and removed from the DNSKEY RRset on schedule, even if the true private key is stored offline. Main character energy for a file with no secrets in it, ngl πŸ”₯

🌸 When you're using dnssec-policy, do not use dnssec-importkey to import key files that cannot be used for signing. Instead, simply publish the imported DNSKEY record in the zone, and make sure the files are outside the configured key-directory. Periodt.

🌈 OPTIONS 🌈

  • -f filename β€” this one flips you into zone file mode πŸ¦‹. Instead of a public keyfile name, the argument is the DNS domain name of a zone master file, which can be read from filename. And if the domain name is the same as filename, then it may be omitted (we love a shortcut). If filename is set to -, then the zone data is read from the standard input. Very stdin-core of it ✨
  • -K directory β€” sets the directory where the key files are gonna reside. Home sweet home 🏠
  • -L ttl β€” sets the default TTL to use for this key when it's converted into a DNSKEY RR. This is the TTL used when the key is imported into a zone, unless there was already a DNSKEY RRset in place, in which case the existing TTL takes precedence (existing TTL said "I was here first", respectfully). Setting the default TTL to 0 or none removes it from the key πŸŽ€
  • -h β€” emits a usage message and exits. A little "here's how this works" moment πŸ’–
  • -v level β€” sets the debugging level. Crank it up when you wanna see everything πŸ”
  • -V β€” prints version information. Gotta know what you're working with πŸ’…

⏰ TIMING OPTIONS ⏰

okay so dates, bestie. they're flexible, but you gotta know the formats πŸ‘‘:

Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS (which is the format used inside key files), or 'Day Mon DD HH:MM:SS YYYY' (as printed by dnssec-settime -p), or UNIX epoch time (as printed by dnssec-settime -up), or the literal now.

The argument can be followed by + or - and an offset from the given time. The literal now can be omitted before an offset. The offset can be followed by one of the suffixes y, mo, w, d, h, or mi, so that it's computed in:

  • years (defined as 365 24-hour days, ignoring leap years) β€” y
  • months (defined as 30 24-hour days) β€” mo
  • weeks β€” w
  • days β€” d
  • hours β€” h
  • minutes β€” mi

Without a suffix, the offset is computed in seconds. Math but make it cute 🧚

πŸ’€ To explicitly prevent a date from being set, use none, never, or unset.

All these formats are case-insensitive. slay πŸ’…

  • -P date/offset β€” sets the date on which a key is to be published to the zone. After that date, the key is included in the zone but is not used to sign it.
    • sync date/offset β€” sets the date on which CDS and CDNSKEY records that match this key are to be published to the zone 🌟
  • -D date/offset β€” sets the date on which the key is to be deleted. After that date, the key is no longer included in the zone. (However, it may remain in the key repository β€” it's not gone gone, just off the guest list πŸ™ˆ)
    • sync date/offset β€” sets the date on which the CDS and CDNSKEY records that match this key are to be deleted.

πŸ“ FILES πŸ“

A keyfile can be designed by the key identification Knnnn.+aaa+iiiii or the full file name Knnnn.+aaa+iiiii.key, as generated by dnssec-keygen.


🌸 SEE ALSO 🌸

(the RFC is sitting right there in the group chat, iykyk πŸ¦‹)


πŸ‘‘ Author πŸ‘‘

Internet Systems Consortium β€” the ones who brought you this entire situation πŸ’œ


2026, Internet Systems Consortium


and that's the whole page, bestie!! 🫢 this was version 9.20.30, dated 2026-10-12, brought to you with love by BIND 9 ✨ go import some keys, you absolute icon πŸ’…β­

πŸ“¦ where this page comes from