[Opendnssec-user] two small requests for ods-ksmutil

[Paul Wouters]

Hi,

Two small feature requests...

See this example:

Keys:
Zone:                           Keytype:      State:    Date of next transition (to):  Size:   Algorithm:  CKA_ID:          Repository:                       Keytag:
zone.com                              KSK           ready     waiting for ds-seen (active)   2048    8           e077c489dc9abbd87b571156af787384  AEP                               39151
zone.com                              ZSK           retire    2012-03-17 00:04:57 (dead)     1024    8           7f3df2ab75d79f94cba1c0fb6b7c47ad  AEP                               54634
zone.com                              ZSK           retire    2012-03-18 00:05:02 (dead)     1024    8           464069efe5688ba0f8b9ff9f29a2b28b  AEP                               65431
zone.com                              ZSK           retire    2012-03-19 00:05:08 (dead)     1024    8           93fd2dfbbf244d8913deba5cb0702f88  AEP                               22246
zone.com                              ZSK           active    2012-03-12 11:05:08 (retire)   1024    8           c842110e1409d9f6289c5ff5fe793b61  AEP                               4450
zone.com                              ZSK           publish   2012-03-12 10:05:10 (ready)    1024    8           382ffeea9db6a814d0a573717232a707  AEP                               37491

1) Leading zeroes

When trying to sign with both bind and opendnssec, some conversions need
to happen. We need to grab the current KSK and ZSK from where, so we can
run dnssec-keyfromlabel. Since we are dealing with filenames generated
based on keytag and algorithm, there is this annoying issue with leading
zeros for both the key tag and the algorithm. Could opendnssec print
leading in this screen?

This can be worked around with, eg in python using something like:

keytag = keytag.zfill(5)
keyalgo = keyalgo.zfill(3)

2) keep consistent field count

Currently the "waiting for ds-seen" is causing a simple field count to
get shifted based on the date of next transition. It would be nice if
this could somehow be done in a way that keeps the fields consistent.

Leaving out the Keys: line which seems oddly out of place would also be
good, but is harmless by checking if the first word on a line matches
the zone name.

Or perhaps a "machine parsable output" flag could be added that gives us
some nice comma separated output?

Cheers,

Paul