TINYDNS-SIGN

NAME
SYNOPSIS
DESCRIPTION
EXIT STATUS
SEE ALSO
LIMITATIONS
CAVEATS
AUTHOR

NAME

tinydns−sign − Signs records in tinydns−data(8) files

SYNOPSIS

    tinydns−sign −g bits flags algorithm domain keyfile
    tinydns−sign [−t ttl] [keyfile ...] <infile >outfile

DESCRIPTION

The first form is used to generate a public/private RSA key pair with a modulus of length bits. If keyfile exists, tinydns-sign will try to read a private key from the file and print DS and DNSKEY pseudo-records for the corresponding public key on stdout. If keyfile does not exist, tinydns-sign will generate a new key pair and write the key plus the corresponding pseudo-records to keyfile.

In the second form, tinydns-sign reads key pairs from each given keyfile. It then reads a tinydns−data(8) file from STDIN and writes the same file to STDOUT , with the following modifications:

	•		It will delete all generic records with RRTYPE DS (43), RRSIG (46), DNSKEY (48), NSEC3 (50), NSEC3PARAM (51) and private types 65281 and 65282.
	•		It will turn each . record into a Z record and a & record.
	•		It will adjust the serial number of all Z records to the current time, unless the serial number begins with two zeroes. Note that an SOA must have a fixed serial for generating a matching RRSIG record.
	•		It will create new DS , DNSKEY and NSEC3PARAM records from each corresponding pseudo record (see below) present in the file.
	•		It will create NSEC3 records for all names in all zones that have at least one DNSKEY and NSEC3PARAM in the file.
	•		It will create a generic record with type 65281 for each name (including empty non-terminals) containing the owner of its matching NSEC3 RR .
	•		It will create generic records with type 65282 for each hex digit (i. e. 0−9a−f) below the zone apex containing all NSEC3 hashes starting with that digit.
	•		It will create RRSIG records for all RR-sets in all zones that have at least one DNSKEY in the file. If both DNSKEYS with and without the SEP flag set are present, then those with the SEP flag will be used only for RRSIGs on DNSKEY RRs and those without the SEP flag will be used for the remaining RR-sets. Otherwise, RRSIGs will be created using all DNSKEYs.

RRSIGs will be valid beginning one hour in the past and ending at (now + ttl) seconds. ttl defaults to 432000 (5 days).

Pseudo-Records
Pseudo-records are records defined in a syntax that’s only understood by tinydns-sign. To tinydns−data(8) they look like comments, i. e. they are ignored.

tinydns-sign will create one or more generic records for each pseudo-record. All generic records with an RR-type for which a pseudo-record can be defined are deleted from the input. (Otherwise, removing a pseudo-record would not result in removal of the corresponding generic record.)

In contrast to standard tinydns-data behaviour, trailing colons in pseudo-records are not optional.

Currently, pseudo-records are defined for the following RR-types:

•

#Kname:flags:proto:algorithm:key:ttl:timestamp:lo

This generates a DNSKEY record for name. flags. proto and algorithm are decimal numbers. At the time of writing, proto must be 3. tinydns-sign only supports algorithms 7 ( RSA−SHA1 ), 8 ( RSA−SHA256 ) and 10 ( RSA−SHA512 ). key is base−64 encoded key material, depending on the selected algorithm. ttl, timestamp and lo are as usual.

It is an error to have a DNSKEY pseudo-record in the input without a corresponding keyfile containing the matching private key.

•

#Dname:tag:algorithm:digest:fingerprint:ttl:timestamp:lo

This generates a DS record for name. tag is the key tag, algorithm specifies the algorithm of the referenced key and digest is the digest type (all in decimal). fingerprint is the hex-encoded actual digest value (omitting leading/trailing zeroes is not permitted!). ttl, timestamp and lo are as usual.

•

#Pname:algorithm:flags:iter:len:salt:ttl:timestamp:lo

This generates an NSEC3PARAM record for name with the given algorithm, flags, iteration count, salt length and salt. If salt is empty, a new random salt with the given salt length (4 bytes if len is empty) will be generated. If salt is non-empty, it must be a string of hex digits with even length. The salt length is derived from the given salt value, i. e. len is ignored in that case. ttl, timestamp and lo are as usual.

tinydns-sign currently only supports algorithm 1 ( SHA−1 ). At the time of writing, flags is defined to be 0, and the iteration count is limited depending on the key length (see RFC−5155 ).

EXIT STATUS

tinydns-sign will exit with status 0 if it thinks all went well. Warning messages will not trigger a nonzero exit status.

tinydns-sign will exit with nonzero status if an error occurred. In this case, the output is most likely incomplete and should not be used to replace an input file.

LIMITATIONS

	•		Location code handling is incomplete in that location codes must be present for all RRs in a zone, or for none at all.
	•		Timestamps are currently mostly ignored, i. e. signatures will happily outlive the RR-sets which they sign.
	•		It is currently not possible to protect the private keys with a passphrase.
	•		It is not possible to have a signed zone and a signed child zone in the same data file.
	•		NSEC3 RRs with Opt-Out child zones are not supported.
	•		The pseudo-RRs with type 65282 contain a list of hash values. The list cannot grow bigger than 65kBytes (about 3270 hashes). This is not a problem for a typical domain, but it would be a problem if tinydns were to serve the .de zone, for example. Also, the list is searched sequentially, which can cause a performance impact long before this limit is reached.

CAVEATS

	•		The system clock should be reasonably close to UTC (i. e. within a few minutes).
	•		Stock tinydns/axfrdns will happily work with signed data.cdb files, but they will not produce correct DNSSEC responses!
	•		If a zone contains both keys with and without the SEP flag, you must make sure that both key sets cover the same set of algorithms. This is due to a requirement in RFC−4035 section 2.2.