
 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
