"Jens B. Jorgensen" <[EMAIL PROTECTED]> writes:
>I believe it makes a lot more sense to find out *what* names are being looked
>up and *why* and solve the real problem rather than shoehorn in some kludge.
I knew there was something I was forgetting to mention!
>As I said, logically you only need to look up "external" names when you're
>connected to the net. Otherwise you won't need to. It sounds like you need
>to set up your own zone for carpanet. If you haven't done this then this is
>most likely why you're seeing the problem.
*nod* that's what I was suspecting. If you don't have _any_ internal
name service [serving your local names and going to the root for names
it doesn't know], then as long as you don't type names that your server
doesn't know when your not connected you won't see a delay.
If you _don't_ have an internal server, and your just using /etc/hosts
to serve your internal names, and your resolvers point to external
nameservers, the query will go to the external name server, and then
resolve from /etc/hosts if the external doesn't answer... that's where
the time delay comes in. [I know in one of the VMS products I'm responsible
for we allow for control of the ordering of the local lookups vs. the
remote lookups, but that's something I've not gotten around to writing
up and recommending to ISC, and I havn't had time to analyse the BIND 8
resolver to see if the funky changes in there allow for changing the
resolving order].
-Jeff
*********************************************************************
| Jeff Schreiber | System administrators are, of course, |
| aka - "Spectre" | incorruptible. You can offer me any |
| [EMAIL PROTECTED] | amount of money. And you can believe |
| | me, because I'm always right, and I |
| | never lie. |
| | (Paul Sand - [EMAIL PROTECTED]) |
*********************************************************************
--
Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
