Erre con erre cigarro
Erre con erre barril
Rápido ruedan los carros
En el ferrocarril

Support MaraDNS or listen to my music

Y2038 statement

MaraDNS is fully Y2038 compliant on systems with a 64-bit time_t. Here in the 2020s, even 32-bit Linux distributions, such as Alpine Linux, have a 64-bit time_t.

Deadwood, in addition, for its Windows 32-bit binary, uses Windows filetime to generate internal timestamps; filetime stamps will not run over until the year 30827 or so.

coLunacyDNS, likewise, uses Windows filetime for timestamps with its Win32 binary.

On *NIX systems with a 32-bit time_t, some features which depend on OS-level time and date libraries are disabled. MaraDNS has support for showing a human readable timestamp with the timestamp_type parameter; this parameter is disabled on systems with a 32-bit time_t since the underlying libraries MaraDNS uses will probably fail at the Y2038 cutoff. Likewise, MaraDNS has support for generating a human-readable SOA serial number with the synth_soa_serial parameter, but this feature is disabled if time_t is 32-bit. In both cases, the feature in question is, by default, disabled in MaraDNS, so only users who have explicitly enabled these features will see any change in behavior.

MaraDNS has the ability to generate a synthetic SOA serial number if a zone file does not have a SOA record. The SOA serial is based on the timestamp for the zone file. If time_t is 32-bit, MaraDNS assumes that the stat call will return a negative timestamp after the Y2038 cutoff, and will adjust timestamps from before 2001 (the year MaraDNS was first developed) to be after the Y2038 cutoff. If there are systems out there where a stat call for a file’s modification time fail after the Y2038 cutoff, one can avoid Y2038 issues by having a SOA record with a serial number in zone files. The Windows port of MaraDNS, as of 3.5.0028, uses Windows Y2038 compliant system calls instead of POSIX calls to get zone file timestamps.

Both Deadwood and coLunacyDNS make some effort to generate accurate timestamps on *NIX systems with a 32-bit time_t until later than 2106; this code assumes that 32-bit systems will have the time stamp “wrap around” after 2038 but still have the 32-bit time be updated.