bind 9.9 & inline-signing issue..

[Howard Leadmon]

   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:each at isc.org]
> Sent: Monday, January 30, 2012 6:21 PM
> To: Howard Leadmon
> Cc: 'Alan Clegg'; bind-users at 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 -- each at isc.org
> Internet Systems Consortium, Inc.