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

[Srinivas Hebbar]

Hello,

Thank you. My system doens't have RTC. Hence it used to start at 1970.
After initialising the time to start from 2010Jan1, everything works fine.

But, I expected the record to expire immediately if the timestamp on the
given record is more than 2 years.

Thanks,
Hebbar.

On Fri, Jan 6, 2012 at 10:58 PM, Sam Trenholme <maradns at gmail.com> wrote:

> 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.
>