dnssec-keygen & dnssec-signzone "smart signing" vs time zones

Paul B. Henson henson at acm.org
Thu Apr 29 00:57:08 UTC 2010


I've been testing dnssec-keygen and the "smart signing" mode of
dnssec-signzone and have run into some timezone confusion; I'm not sure if
it's expected behavior or a bug. I searched around a bit and didn't find
anything relevant, apologies in advance if I missed a FAQ.

If I create a new key leaving the various time metadata options with the
default of "now":

$ date
Wed Apr 28 17:20:00 PDT 2010
$ dnssec-keygen -a RSASHA256 -3 -b 1024 -n ZONE -r /dev/urandom test.domain

$ cat Ktest.domain.+008+57078.key
; This is a zone-signing key, keyid 57078, for test.domain.
; Created: Wed Apr 28 17:20:54 2010
; Publish: Wed Apr 28 17:20:54 2010
; Activate: Wed Apr 28 17:20:54 2010

The metadata times match my current time.

OTOH, if I explicitly specify times for the metadata:

$ date
Wed Apr 28 17:23:15 PDT 2010

$ dnssec-keygen -a RSASHA256 -3 -b 1024 -n ZONE -r /dev/urandom -P now -A 20100501000000 -D 20100601000000 test.domain

$ cat Ktest.domain.+008+53670.key
; This is a zone-signing key, keyid 53670, for test.domain.
; Created: Wed Apr 28 17:23:16 2010
; Publish: Wed Apr 28 17:23:16 2010
; Activate: Fri Apr 30 17:00:00 2010
; Delete: Mon May 31 17:00:00 2010

The times are off by 7 hours; rather than 05/01/2010 00:00:00 and
06/01/2010 00:00:00, they're 04/30/2010 17:00:00 and 05/31/2010 17:00:00.

Probably not coincidentally, my timezone is currently UTC-7.

It seems like when an explicit time is specified, it's considered UTC, and
converted to the local time zone before being stored?

The only documentation I found about the time format was "Dates can be
expressed in the format YYYYMMDD or YYYYMMDDHHMMSS", there was no mention
of timezones.

This is rather confusing. I would understand if time metadata was always
stored as UTC, which would allow key files to be migrated to servers at
various locations whichout changing the relative meaning of the times.
However, storing times based on the local time zone yet parsing times as
UTC doesn't appear very useful. You get both the problem of the time
metadata being relative and dnssec-signzone doing different things
depending on where it's run, and the headache of not being able to specify
times based on your local timezone 8-/.

Am I missing something?

Thanks for any insight...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768



More information about the bind-users mailing list