moving DNSSEC to a hidden master [SOLVED]

David Newman dnewman at
Mon Oct 14 19:57:16 UTC 2013

Hash: SHA1

On 10/14/13 12:39 PM, Alan Clegg wrote:

>> In this case, I started with a serial of 2013092700, incremented
>> it to 2013092701, and reloaded. 'dig soa' would still return
>> 2013092700.
>> Problem is, bind logged the current serial number as 2013092705. 
>> Guessing here, but it looks as though my change wouldn't be seen
>> by dig or any other external tool because internally, Bind was
>> already on a larger serial number.
>> As soon as I advanced the serial to something ahead of the one in
>> the logs, everything worked again.
> So, you were able to see the <zone> and <zone (signed)> entries in
> the log file?

I see only the signed entry, e.g.:

14-Oct-2013 12:36:30.584 zone (signed):
sending notifies (serial 2013092706)

I do not have something for just the <zone>.

>> This is probably another thing for dynamic zone fans to snicker
>> at us static zone users about. But as long as the static zone
>> file's serial number is greater than or equal to the internal
>> serial number (modulo a counter wrap), this appears to work OK.
> You shouldn't need to keep track of the "signed" vs. "unsigned"
> serial numbers.  Inline signing is supposed to be completely (and I
> mean 100%) transparent to the process that you had in place prior
> to signing.
> Now that you have (what I'll call)
> "synchronized-but-out-of-sync-due-to-inline-signing" serial numbers
> (the signed one should be a bit higher than the unsigned one but
> you'll only see that from the log messages; dig should ALWAYS
> produce the higher number), can you try incrementing the serial on
> your static/unsigned zone by one, reloading the zone and seeing
> what the logging produces?  It _should_ increment the signed
> version (otherwise your slaves will never update), when you reload
> the zone (as the SOA is resigned).   [wow, that's a horrible
> paragraph, but I think it makes sense]

Yes. When I increment by one and reload, I see the signed entry
increment in the logs. I see the same serial from dig queries to slave
servers (this is a hidden master).

> Also note that the inline-signed zone (in memory and dumped out to
> zone.signed file) will continue to increment serial numbers even
> without you making changes to the static/unsigned zone because of
> internal re-signing caused by signature expiration.

That's interesting. If I understand correctly, you're saying I should
focus on the zone serial number, same as I always have with static
zones, and pay no attention to the internal signed serial numbers.


>> Thanks again for the pointers. Much appreciated.
> No problem, AlanC
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


More information about the bind-users mailing list