No valid trust anchors for '.' - solved
Lyle Giese
lyle at lcrcomputer.net
Sun Jun 10 15:16:08 UTC 2012
I stumbled across an issue with an error message that was misleading and
from what I could Google, undocumented. I am posting this to document
this issue for others that may stumble across this issue in the future.
Background:
I am building a new server to replace an old system and add some
functionality for system backups. The system hosts one of our DNS
servers. I downloaded 9.8.3-P1 and installed it and copied over
named.conf, rndc.conf and a couple of other key files. But since this
server is a slave for all zones, I did not copy any zone files. And
yes, I am running two views.
Upon first run of named, I noticed the clock error and realized I had
not started up NTP yet and found the system clock on the new system a
day in the future. I corrected that and restarted the system(init 6).
Then I got a new error message from named that was quite puzzleing:
No valid trust anchors for '.'!
Googling for this did not lead to anything that proved useful and the
error persisted. I am comparing notes between the old system that I
took the named.conf from and this new system. I am failing to find
anything useful.
Until I noticed the serial number for the managed-keys-zone. It did not
match the serial number that the old server showed. How does one
correct this? I stopped named on the new server, deleted the two .mkeys
files and their related .jnl files and restarted named. Presto, problem
fixed. I got the right serial number now and no more error messages
about 'No valid trust anchors'.
It looks like the .mkeys files are dynamic zones and failed to update
properly when the time was foobared and failed to self-correct when
restarted with the correct date, until I deleted the .mkeys and related
.jnl files.
Maybe named needs a warning that the date/time stamp on the zone files
is in the future?
There may have been more related error messages, but when starting
named, a lot of messages are logged and it's easy to overlook/miss some
key error messages during the first start of named. And after I
discovered the date/time issue, I did not go back to the logs and look
at the first boot error messages and focused on the last restart of
named set of messages.
Lyle Giese
LCR Computer Services, Inc.
Related error messages:
Jun 9 22:29:21 ns1a named[6252]: zone 78.0.10.in-addr.arpa/IN/chase:
refresh: failure trying master 184.175.161.68#53 (source 0.0.0.0#0):
clocks are unsynchronized
Jun 8 22:33:31 ns1a named[6444]: using built-in DLV key for view external
Jun 8 22:33:31 ns1a named[6444]: set up managed keys zone for view
external, file
'3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys'
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: No
valid trust anchors for '.'!
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: 0
key(s) revoked, 1 still pending
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: All
queries to '.' will fail
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: No
valid trust anchors for 'dlv.isc.org'!
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: 0
key(s) revoked, 1 still pending
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external: All
queries to 'dlv.isc.org' will fail
Jun 8 22:33:32 ns1a named[6444]: managed-keys-zone ./IN/external:
loaded serial 3
Jun 8 22:33:32 ns1a named[6444]: running
More information about the bind-users
mailing list