/home/set/tech/maradns/maradns-0.9.31/doc/en/misc/year_2038_statement.html

MaraDNS and the year 2038

MaraDNS, like many *NIX applications, uses standard UNIX time for variables which need to keep track of the time. In the year 2002, with a RedHat 7.2 system on an Intel x86 (Pentium III) processor, UNIX time is stored as a 32-bit signed integer, which means the date will roll over early in the morning of January 19, 2038 (GMT time zone).

MaraDNS will start to exhibit problems before this time on systems which uses 32-bit signed integers to store time values. Problems will start to show up in January of 2036, and become increasingly more frequent until 2038. The problem is that MaraDNS uses timestamps to determine when to remove entries in the cache; if a given resource record has an expire time which is after January 19, 2038, the record will be set to expire in they year 1901 (or thereabouts). As a consequence, the record in question will immediately expire.

Since all answers MaraDNS' recursive/caching nameserver hands out come from the cache, any record which expires after January 19, 2038 (on systems which use 32-bit signed time_t) will be inaccessible.

MaraDNS allows a given resource record to expire as long as two years in the future. This is why problems will start to appear in early 2036.

The solution is to recompile and deploy MaraDNS on a system where time_t is either a 32-bit unsigned integer (in which case the roll-over date is 2099) or a 64-bit signed integer (at which point, MaraDNS will work fine until the year 292,277,026,596).

- Sam