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