Inline-signing feature request: Directly set the signed zone's serial number

Terry Burton tez at
Tue Oct 7 23:39:01 UTC 2014

On 7 Oct 2014 22:35, "Alan Clegg" <alan at> wrote:
> On 10/7/2014 2:03 PM, Terry Burton wrote:
>> On 7 Oct 2014 18:42, "Alan Clegg" <alan at
>> <mailto:alan at>> wrote:
>>  >
>>  > On 10/7/2014 9:49 AM, Terry Burton wrote:
>>  > > This is especially useful in bootstrapping scenarios where the zone
>>  > > data is held under strict revision control or generated by some
>>  > > provisioning system that "owns" the serial number.
>>  >
>>  > By setting the number backwards, you are breaking all of your slave
>> servers and causing no-end of problems getting all of THEM corrected.
>> You've misunderstood. I'm not attempting to decrease the serial number.
>> With inline signing you have a hidden serial number in the unsigned zone
>> and an exposed serial number in the signed versions which your slaves
>> track. After redeployment (following DR, emergency relocation, elastic
>> capacity expansion, etc.) I want to be able to bump the exposed serial
>> number (once) back to an appropriate value without having to modify the
>> unsigned zones.
> Ok, I'm aware of the difference between unsigned and signed zones in an
in-line signing configuration and am more and more curious about your
terminology of "appropriate value" for the signed zones.

Currently advertised serial +1.

> If the data hasn't changed, the serial is appropriate.  If the data has
changed, the signed data serial number is going to be incremented the next
time you transfer (bump in the wire) or reload (on box) the data.

BIND on a reinitialised signing master doesn't know about the external
serial number until you tell it either by updating the unsigned zone data
(fine when you control this) or update the signing state by some other
method, as I propose.

> As Doug said, edit the data and when you reload it's going to "do the
right thing" but you should never get into this predicament to begin with
from my limited understanding of DNS.

Separate the data provider and DNS infrastructure provider and this
predicament ensues.

> Now, the problem with his added step is that the next time you edit the
file that you have in your version control system, the serial number is now
going to match (if you treat it as "just a number") the one that you edited
OUTSIDE OF THE PROCEDURE and you won't get correct zone transfers.
> I'd recommend adding one step to the DR/whatever procedure:  "bump serial
number in version control in to complete process".

That sounds ideal however in this case it's not possible to redefine access
to the VCS in this fashion due to the integrity constraints of the current
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list