I'd like to ask for clarification on the operational issue stated below. Suppose there are no current changes to an inline-signed master zone, i.e. myzone.db.signed timestamp is later than myzone.db timestamp. In this circumstance, is it safe to stop and restart the bind service or reboot the system?
What about the situation where changes made by nsupdate have been recorded in the journal files but have not yet been written to the zone files? In other words, myzone.db.jnl timestamp is later than myzone.db timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.signed timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.jnl timestamp. Thanks. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School -----Original Message----- From: bind-users-bounces+spainj=countryday....@lists.isc.org [mailto:bind-users-bounces+spainj=countryday....@lists.isc.org] On Behalf Of Evan Hunt Sent: Friday, November 11, 2011 12:48 PM To: Adam Tkac Cc: bind-users@lists.isc.org Subject: Re: OT: Bind 9.9.0B1 Inline-Signing Question I should mention that there is a known operational issue in the current version of inline-signing that you should be cautious about. If you're using inline-signing with a master zone, and you make changes to the zone file, you should *not* kill and restart your server to load the new file. Instead, use "rndc reload" or "kill -HUP <pid>" to force named to reload the zone while it's running. That way, named will be able to compare the former version against the new one, and generate the proper set of diffs to apply to the signed zone. If you kill and restart your server to load changes to your zone, then the signed version of the zone will fall out of sync with the raw version, and some of your data will not be accessible to queries. There's no way to recover from this condition except to delete the signed zone and start over, which generates big transfers to slaves and is generally undesirable. We'll have a fix for this in a future release. It's not a problem when using inline-signing on slave zones; slaves load their data via zone transfer, not from files, so this issue doesn't affect them at all. -- 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
