I just had this problem happen to me, and it was quite a beast. It happened after I had a power flicker at home. Enough of one to kill the machine. Upon reboot, bind didn't start. Not only that, neither dig nor nslookup worked; they gave the RUNTIME_CHECK(isc_time_now(&now) == 0) failed error. ntpdate did work, however, but it only set the system clock. It set that with the wrong year: 1940. I was also able to telnet to www.yahoo.com, but I think it might have picked up DNS resolution from an alternate nameserver. So, let's see if I can retrace the steps I took to make it work again.
OS=Fedora Core 2 Bind=9.2.3-13 I began with hwclock and it errored with "The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095)". I'm thinking, 'Great! That power surge fried my CMOS'. I tried a few settings on hwclock and finally this did something: hwclock --set --directisa --badyear --date="5/21/11 11:34:00" (Read over the parameters for hwclock to understand what I did. Note: hwclock isn't a Linux thing - its an DEC Alpha utility that has been ported over. Did you read the help message?) That didn't quite get things right, though because the year displayed was 1940. That would explain the first error message above. PC Clones didn't even exist in 1940 :D For some reason, hwclock --show still wasn't working. I added the -utc option: hwclock --set --directisa --utc --date="5/21/2008 11:34:00" and I got a new error message from dig: timer.c:284: isc_time_now() failed: unexpected error dig: isc_timer_create: unexpected error Progress? At this point, the hwclock was displaying with the proper year: 2008, and hwclock --show was working. The year from the date command was wrong. Setting that: date --set="May 21,2008 11:48:000" Running ntpdate: ntpdate 192.43.244.18 dig works - Yay! BIND starts - Yay! Don't forget to set the hwclock: hwclock --systohc and we're all done!
