Delay connecting to dual homed host

[John Murphy]

Mike Bristow <mike at urgle.com> wrote:

>On Thu, 2004-06-10 at 16:12, John Murphy wrote:
>> Whenever my FreeBSD-5.2.1 gateway looses its connection to
>> the ISP it takes much longer to establish an ssh session to
>> it from the LAN side.
>>=20
>> I can live with the delay (not sure I can live with the ISP)
>> but I wonder what's happening.
>
>It's probably DNS.
>
>Run "tcpdump port 53" while the modem is off, and things will probably
>be clearer.

Thanks for the clues Mike.  I tried running tcpdump on the external
interface first and then the internal one.  Neither showed any port
53 activity.  I ran top which showed an sshd process in state kqread
which initially used 89.9% WCPU and dropped slowly to 0%.

>sshd uses tcpwrappers, so it'll do a reverse lookup on the IP of the
>client and then a forward lookup of the result (to make sure it
>matches).
>
>> Also sendmail fails to accept and queue email from clients
>> and browsers can't convert addresses even though Bind is
>> running as a caching only name server.
>
>Does it have the relevant info cached?  =20

Yes.  I connected to google then switched off the modem and tried
to connect again immediately and got a 'connecting to' message,
so at least the caching is working.  Only for a few minutes though.
Trying again a little later gave "Can't resolve host google...",
which I guess is to be expected.

>Does /etc/resolv.conf point at that nameserver?

Yes "nameserver 127.0.0.1" is the first line.

>Note that if it's RFC1918 space (ie, 10/8 etc) then your caching bind
>will cache a negative answer for (by default, I think) 10 minutes, so 10
>minutes after the link dies the cache is irrelvant - bind will try and
>query blackhole-{1,2}.iana.org for the data and after a long time
>timeout.

I have boa running on the gateway (on the internal NATted NIC), serving
the FreeBSD documentation mostly, and no delays occur with the modem off.
(I guess there would be no resolving necessary in this case though.)

--=20
TIA for any further suggestions,
John.