Bind on NON Y2K Compliant System

[Bob Halley]

Mark Olbert <mark at arcabama.com> writes:

> I'm running bind (v8+) on a linux system which I believe is not Y2K
> compliant (meaning that the hardware is not Y2K compliant). I say this
> because whenever I try to set the hardware clock to a date in January,
> 2000, the date shows up (upon reboot) as being in January, 2094.
> 
> I am also running into a problem where nslookup will hang (frequently,
> but not always), because the dns cache is being continually emptied
> (e.g. I presume that's what thousands of 'cache cleared of 0 RRs'
> messages in my /var/log/message file mean).

This sounds like a repeating timer problem that was fixed in BIND 8.1.2.

 306.	[bug]		Timewarping into the future would cause repeating
			timers to generate an event for every interval between
			the previous time and the new time.  Repeating timers
			are now rescheduled based on the last event time, not
			their due time.  Idle timers now use the last event
			time to compute the idle interval instead of the due
			time.

Caching cleaning is done by a repeating timer (once an hour by
default), so if the system's notion of the current time suddenly
jumped far into the future, versions of BIND 8 earlier than 8.1.2
would run the cache cleaning code for every hour between the previous
time and the current time.

Upgrading to a more recent version of BIND should fix the excessive
cache cleaning problem.  Fixing your system clock is also important,
since 'named', like many daemons, wants a reasonably stable clock.  If
the current absolute time is 'T', then 10 minutes later 'named' would
like the system's notion of the current absolute time to be 
'T + 10 minutes'.  If the system clock is frequently making large
jumps backwards and forwards, you might see strange results, e.g. RRs
that live a very long time or failures in periodic zone maintenance.

/Bob