Search Again:

Re: Failed SOA

From: Mia''s Virtual Post Office
Date: Tuesday, November 6, 2001
Time: 9:48:37 am

Men & Mice Support said:

>At 12:37 PM -0700 11/5/01, Warren Michelsen wrote:
>>At 12:59 PM -0600 11/5/01, Mia's Virtual Post Office wrote:
>> > >
>> >>
>> >If I simply select Restart on the secondary, the problem does go away..
>> >Simpler than removing the zone and reloading it manually...
>>
>>This would seem to say "bug".
>
>Agreed. There is some sort of problem here, though we're not exactly
>sure what it is. We'd like some help in diagnosing this. Therefore,
>those of you experiencing this problem, I have a question for you.
>
>When the SOA check fails, the slave server should retry some time
>later, where the interval is shorter than normal refresh interval. At
>this point, do some of these failed zones get successfully checked?

No, at least not that I can tell.. I could have overlooked one as we have
a lot of zones, but from what I see in the logs the answer is currently
no.

Nov 6 09:39:11 Starting check for domain "mia.net."
Nov 6 09:39:46 Failed to lookup SOA info for domain "mia.net."

Nov 6 10:04:59 Starting check for domain "mia.net."
Nov 6 10:05:34 Failed to lookup SOA info for domain "mia.net."

Nov 6 10:21:35 Starting check for domain "mia.net."
Nov 6 10:22:10 Failed to lookup SOA info for domain "mia.net."

And it is not just "mia.net"... It is completely random. Now if restart
the server, mia.net, and the other zones that this happens to will find
the SOA without issue.. Again, for a time.

Another thing I note... When a zone is disabled on the primary, the
secondary will not be able to look up the SOA. I assume this is normal
since the zone is disabled? Is it possible that the primary is reloading
the "mia.net" and other zones at the same time the secondary is doing the
lookup? Just a thought. Seems way to coinsidental.
>
>You should be able to tell by checking the log; look for messages
>from about two hours after the server was last restarted. Two hours
>is the default retry interval in QuickDNS.
>
>If the answer is "yes", then I have a work-around for you to try.
>Currently, the retry interval is an even divisor into the refresh
>interval, and the ratio is fairly low - 4:1. Try setting the retry
>interval (for all your zones) to something lower, something that is
>not an even divisor of the refresh interval. A good value might be
>610 seconds. (28800 / 610 = 47.21311) This way, the failed zones will
>be retried far more often, and even if you somehow have so many zones
>failing that they don't all get successfully checked in 8 hours, the
>later retries won't overlap with the next refresh check of the ones
>that succeed the first time.
>____________________________________________________________________
So what is the work around if the answer is no?

jer (jer@mia.net)

Bella Mia, Inc.
High Speed Wireless - www.dslone.com
Web Hosting and Colocation - www.hostdrive.com
Nation Wide Dialup 4 years and running - www.mia.net



NetZero = What this company will "NET" --- "ZERO"





Messages In This Thread:



Return to Digital Point Solutions' Home Page