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

[Paul Kosinski]

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?