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

Mark Andrews marka at isc.org
Thu Apr 29 01:15:37 UTC 2010


In message <Pine.GSO.4.55.1004281743100.11178 at loogie.intranet.csupomona.edu>, "
Paul B. Henson" writes:
> 
> 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 201
> 00501000000 -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
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

The .private timestamps are in UTC and that is what is used for key
management.  The .key values are just comments.  You should be able
to work out my current offset from UTC.

% grep Created Klllll.+005+59421.*
Klllll.+005+59421.key:; Created: Thu Apr 29 11:10:24 2010
Klllll.+005+59421.private:Created: 20100429011024
% 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list