OT: Bind 9.9.0B1 Inline-Signing Question
Spain, Dr. Jeffry A.
spainj at countryday.net
Fri Nov 18 23:57:51 UTC 2011
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.
Jeffry A. Spain
Cincinnati Country Day School
From: bind-users-bounces+spainj=countryday.net at lists.isc.org [mailto:bind-users-bounces+spainj=countryday.net at lists.isc.org] On Behalf Of Evan Hunt
Sent: Friday, November 11, 2011 12:48 PM
To: Adam Tkac
Cc: bind-users at 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 -- each at isc.org
Internet Systems Consortium, Inc.
More information about the bind-users