Inline-signing / dnssec-policy: Signed SOA serial diverges from source serial causing monitoring warnings

[Ondřej Surý]

SOA SERIAL is unsigned 32-bit number.

Thus anything you wrote about the internal time representation just doesn’t apply, neither signed 32-bit nor 64-bit time_t has any effect on SOA serial integer type.

Ondřej
--
Ondřej Surý (He/Him)
ondrej at isc.org

ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply!

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 21. 7. 2026, at 20:47, Paul Kosinski <bind at iment.com> wrote:
> 
> Sorry, I forgot that in original Unix (and many successors, such as Linux) the time counter is a *signed* 32-bit number. So (according to "https://en.wikipedia.org/wiki/Year_2038_problem") the first problem appears at 03:14:07 UTC on 19 January 2038. Then, depending on the exact code behavior on overflow, the "time" goes negative, and becomes 20:45:52 UTC on 13 December 1901. It then counts forward from that, all the way up to 00:00:00 UTC on 1 January 1970. Maybe the 2106 date would apply if the 32-bit time counter were unsigned?
> 
> Since 2038 is only 12 years away, you probably will care. (I might not, since the first program I wrote was for the IBM 704 at Argonne National Lab.)
> 
> In any case, many recent systems use a 64-bit seconds counter (clock), so they will not overflow for quite (!) a while. Also, the decimal representation of such a UnixTime presumably does not have a limit on the number of digits. Thus BIND could emit decimal Unix timestamps indefinitely, even beyond what a 4-digit year allows.
> 
> ---------------------------
> 
>> On Tue, 21 Jul 2026 19:16:05 +0200
>> Ondřej Surý <ondrej at isc.org> wrote:
>> 
>> I don’t understand your question, but ai will try to answer it anyway.
>> 
>> Personally, I don’t really care what happens in year 2106 as I am going to be already dead anyway, but serial number follow the serial number arithmetics which means the number will just roll to 0 and everything will continue to work as 2^32-1 is less than 0.
>> 
>> Ondřej
>> 
>>>> On 21. 7. 2026, at 19:00, Paul Kosinski <bind at iment.com> wrote:
>>> 
>>> So BIND's UnixTime, being represented in decimal, allows values beyond 2^32-1 without any problem?