Hello Evan, As you probably saw from the other posts on the subject, the hint of taking and telling named to reload just the specific zone, and not just a general reload of all zones did indeed correct the problem.
As you mentioned, even a hard restart of the named process would not cause a resign of the zone, and not that I did it the last time around, but for sure removing the journal files and .signed zone file would cause named to update from the unsigned file and then the signed data would be correct. So I guess that asks the question, what is different between doing an 'rndc reload' vs doing an 'rndc reload <zone>', as performing the latter will correct the problem it seems with the .signed zones. I know for a fact the serial was updated over here, as I knew not changing that would cause it to think nothing changed, or that was my belief. You really would think that doing a full reload on all zones, would have the same exact effect as reloading only one, but apparently not. --- Howard Leadmon > -----Original Message----- > From: Evan Hunt [mailto:e...@isc.org] > Sent: Monday, January 30, 2012 6:21 PM > To: Howard Leadmon > Cc: 'Alan Clegg'; bind-users@lists.isc.org > Subject: Re: bind 9.9 & inline-signing issue.. > > > As stated in a prior message, just the signed zone is not being updated, > > when I make an update to the unsigned zone file. The earlier posting > > suggesting that I do a "rndc reload <zone>" does indeed cause the signed > > zones to update, but you must specify the zone, just doing a "rndc reload" > > to reload everything results in no update being performed on the signed > > zone, and even a hard restart of the named process doesn't cause an > update. > > I haven't been able to reproduce this bug in exactly the way you described > it, but I found something that sounds similar enough that it's likely to be > related: named can, under some circumstances, lose sync between the > signed and unsigned zone databases if you forget to update the SOA serial > number when you change the zone file. Normally that doesn't happen, but > once it does, the server can't recover without help. > > I'll send you a patch later that prevents this particular scenario from > reoccurring. It may turn out that there are other ways to get the server > into this broken state, though. I believe these steps will cause the > server to recover: > > - sync and remove the journal files: > $ rndc sync -clean leadmon.org in external > $ rndc sync -clean leadmon.org in internal > - increase the SOA serial number in the unsigned zone files > - restart the server > > When you restart, it will detect that the serial numbers in the unsigned > zone files have changed, but it won't find any journal files to replay, so > it will force the signed and unsigned databases to sync up to one another > directly; it should remain sane after that. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
