timeout value for no response from primary name server

[Kevin Darcy]

It's hard to venture an answer to this question when you haven't indicated
what platform your clients are running. I just tried tests on Solaris 7 and
Win 95 and the fallback was fairly reasonable; about 10-15 seconds for
both, when there is nothing at the first-listed address, and about 5
seconds or less if the first-listed address is active but with nothing
listening to UDP port 53. What platform are you running, that would take 80
seconds to fall back?


- Kevin

Mark Conroy wrote:

> Question for the group,
>
> I need to apply some y2k patches to a solaris system(solaris 2.6) on a
> primary name server.  I would like to perform this during the day, which
> means shutting down the system into single user mode. I have a secondary
> name server that resolves if the primary is not there.   I am running
> bind 8.1.2.
>
> I performed a test on a test name server, and noticed that when I reboot
> the system, and  perform an nslookup on a machine that is using the test
> name server to resolve, it takes about 80 seconds for the request to
> timeout and go to the backup server.  In production, I cannot afford
> everyone to be waiting over 80 seconds to get resolved.  I noticed that
> with nslookup, I can tweek a couple of the parameters(timeout/retry) to
> lower that.  They are set at a default timeout of 5 seconds, and a retry
> of 4 times.  With each retry, it doubles the timeout value, so at the
> end of 4 retries, it has waited almost 80 seconds. However, thousands of
> people that are using dns are not using nslookup, they are just trying
> to telnet or ftp.
>
> On page 107 of DNS & BIND(version3), it says that if there are more then
> one name server configured, it queries the first name server in the
> list, with a timeout of 5 seconds, and if it timesout, it will fall back
> to the next name server, waiting 5 seconds.  I am not seeing this
> behavior.  It waits up to 80 seconds if I am using nslookup or telnet to
> a machine.
>
> Any thoughts would be appreciated.
>
> Thanks
>
> Mark Conroy
>
> ***********************************************************
> * This transmission may contain information that is       *
> * privileged, confidential and exempt from disclosure     *
> * under applicable law.  If you are not the intended      *
> * recipient, you are hereby notified that any disclosure, *
> * copying, distribution, or use of the information        *
> * contained herein (including any reliance thereon)       *
> * is STRICTLY PROHIBITED.                                 *
> *                                                         *
> * If you received this transmission in error, please      *
> * contact the sender and delete the material from any     *
> * computer immediately.  Thank you.                       *
> ***********************************************************