Thank everyone who respond. Sorry for the later summary.
Some answer following:
------------------------------
from Imre:
es, once.
My dns server is secondary for ericsson.se and in-addr.arpa,
primaries for these zones went down, there were no zone transfers
for a week. Then in.named said that secondary zone
ericsson.se/in-addr.arpa has expired so I had to do something.
I hacked the zone backup files to look like fresh, ie. I changed
the SOA serialno, the date and thus the file date also changed,
from 19990902 to 19990910.
(I don't know which of this three is significant for in.named)
Then I kill -HUP-ed in.named, who said:
secondary zone in-addr.arpa/ericsson.se time warp
and went to work, no more expired messages (for a week).
The bottom line is, if you change the system date you should change the
zone backup files as well.
Imre
---------------------------------------
from Martin:
Not seen the error message before, but I'd guess the SOA record in the DNS
alleges that the DNS info. is from some time in the future?
Martin.
----------------------------------------
from Alan Miller:
I had the same problem after I had turned the clock forward on
my Sun/E450 to run Y2K tests and later turned it back to 1999.
In doing my tests I made sure to perform all my tests on
copies of my system and data disks BUT what I hadn't thought of was
the fact that the system (when placed in the Y2000) still might
exchange data (named/nis) with other systems, which in turn would
affect my system once the original disks were installed and returned
to 1999.
The solution for me was to remove all the zone files for the domains
where I act as a secondary and restarted my named.
cd /var/named
rm -f `cat named.boot |grep ^secondary | awk '{print $4}' `
ps -ef |grep named | head -1 | awk '{print $2}'
+--------------------------------------------------------------------+
| Alan Miller BinTec Commmunications AG |
| System/Network Administrator S¨¹dwestpark 94 |
| Voice: +49 911 96 73 14 55 D-90449, N¨¹rnberg |
| Fax: +49 911 96 73 14 99 Germany |
| mailto:alan@bintec.de http://www.BinTec.de |
+--------------------------------------------------------------------+
Just shooting in the dark here, but...
1) BIND isn't actually Y2K compliant, has decided it's 1900, and freaks
out when named-xfer gives it a file retreived from a host that thinks
it's 1999 (which would take a hell of a time warp). Doubt this, since
plenty of people have their clocks set to the wrong (and earlier) year.
2) BIND's secondary zone files are stamped something in 1999, you've
suddenly switched the date to 2025 or so, and BIND is freaking out
because you shouldn't be trying to use zone files that old.
Number 2 feels more likely to me, but I'll be interested to see if
anyone has a definite response.
~ g r @cs.swarthmore.edu
-------------------------------------------------
Thanks all.
the result is I remove the secondary zone data file , and kill -HUP
in.named. fix
this problem.
but I still don't understand why this will happen.
likun
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:26 CDT