[MaraDNS list] TTL is not aging after a big jump in system time.

[Sam Trenholme]

This is not a bug, it's a feature.

Deadwood is year-2038 compliant, even on systems with a 32-bit time_t.
 In order to pull this off, Deadwood assumes that systems showing a
timestamp before May 6 2007 (chosen because it was 6 months before the
first Deadwood release [1]) have had their clock "wrap around" and
that it's really far in the future, not far in the past.

This allows Deadwood to have accurate timestamps on systems with a
32-bit time_t until 2143.  The side effect is that Deadwood assumes
that systems with a timestamp of 0 are not in 1970, but instead are in
the year 2106.  This results in all records stored in the cache on
systems with an incorrect timestamp not expiring until 2106.

If you're building Deadwood on a system which sometimes has an
incorrect timestamp, there are some ways to work around this:

* Set up the system to not start up Deadwood unless the system clock
is set to May 2007 or later.

* Change the value of DW_MINTIME in DwSys.h to a lower or negative
value.  Note that, if this is set, for example, to -1 instead of its
current value (1178488417: May of 2007), Deadwood will start to have
inaccurate timestamps on systems with 32-bit time_t in 2106, not 2143.
 Please upgrade your system to a 64-bit one before 2106.

  Please also note that dwh_put_int64() in DwHash.c (the code that
writes the cache to disk) will not correctly store timestamps earlier
than March 20, 1979 (they will simply be marked as being on that day).
 Such records in the cache *should* immediately expire on systems once
the timestamp is correctly set, but this has not been tested at all.
I'll let Seinivas Hebbar perform the SQA for this corner case.  :)

I'll update Deadwood docs to include this information.

- Sam

[1] http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html

On Fri, Jan 6, 2012 at 5:01 AM, Srinivas Hebbar <sshebbar at gmail.com> wrote:
> Hello,
>
> TTL get stuck at anywhere between 1 to 60 (The original A record TTL is 60)
> and until I restart the Deadwood, the record will stay in that state.
>
> This can be consistently reproduced by the following method.
>
> 1) Set the system time way back. (My box resets it to Jan 1, 1970).
> 2) dig test.testing.tindip.com
>
> 3) Now set the system time to current date. (Jan 6, 2012).
> 4) dig test.testing.tindip.com The TTL is stuck at some number and
>    the record never expires.
>
> I don't think this is an short TTL issue. Basically, Deadwood is
> getting confused when a large step in system time. I haven't tested the
> date going backwards yet.
>
> Only the records which was queried prior to date change is affected.
> All new name lookups are working fine after the date change.
>
> Thank you,
> Srinivasa Hebbar.