proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
marka at isc.org
Tue May 10 06:15:33 UTC 2011
In message <1305006478.3040.1450174377 at webmail.messagingengine.com>, "" writes:
> On Tue, 10 May 2011 15:32 +1000, "Mark Andrews" <marka at isc.org> wrote:
> > "date -u" on the nameserver. It is "Tue 10 May 2011 05:32:13 UTC"
> > as I send this.
> date -u
> Mon May 9 22:34:59 UTC 2011
> hrm? not good :-/
> switch time server daemon to a known signed domain (clock.isc.org)
> service ntp restart
> 9 May 15:36:50 sntp: Started sntp
> 2011-05-09 15:36:55.874669 (+0800) +25198.977371 +/- 0.004883 secs
> Time synchronized with clock.isc.org
> Starting network time protocol daemon
> date -u
> Tue May 10 05:37:43 UTC 2011
> looks like problems with name resolution of time servers @ ntp startup?
> i'll dig further. in any case ... with this corrected,
> looks good, right?
> was this simply a wrong-time artifact? or is there something else up?
Simply the wrong time. The DNSKEY records for COM were signed far enough
in the past to be valid as far as your nameserver was concerned. The
SOA record for COM was being signed in the future as far as your nameserver
was concerned. The expiry and inception dates for the records below.
RRSIG DNSKEY ... 20110514182533 20110507182033 ...
RRSIG SOA ... 20110517055901 20110510044901 ...
May 9 22:34:59 UTC 2011 -> 20110509223459 and it needs to be between the
two values in the RRSIG record for the RRSIG to be considered valid.
DNSSEC only needs wristwatch time accuracy however it is easy to
get the time wrong if the server is configured in the wrong timezone.
The error was equal to the local time offset from UTC which indicates
it was running in UTC but set with the local time.
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