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

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 <[email protected]> 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 <[email protected]>
> 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.
>