Re: nntp problems with hibernating and waking up in a new network

[Steinar Bang <sb@dod.no>]

>>>>> Bjørn Mork <bmork@dod.no>:

> The main problem when doing this is that emacs (or libc?) will cache
> DNS resolvers for you, and these probably won't work in your new
> network environment.  Therefore there is no nntp traffic, only
> unanswered DNS queries.

I thought it might be something like this, but I had hoped it was in
the lisp code in the nntp backend, since nnimap worked.

However...

> Can't explain why the nnimap sessions work.  Maybe they are using
> some external process to set up the connection, e.g a ssh tunnel?

That is indeed the case.  That is, not an SSH tunnel, but as NNIMAPS
using the "openssl" executable.

> Never found a good solution to the cached DNS resolver problem.
> Note that is isn't confined to emacs.  The same problem applies to
> most applications running forever without mechanisms for reloading
> /etc/resolv.conf, like most browsers.

Actually, my browsers survive.  I used to have a problem with a
similar situation in Opera, when I went on VPN using PPTP, and back
(this changed the /etc/resolv.conf file but the browser didn't keep
track). 

But with recent versions of Opera, this problem has gone away.

> Personally I resorted to running BIND locally on the laptop...

That won't work for me, because this would confuse the PPTP client, I
think.  Or perhaps I could just list all DNS clients at work and at
home, and let BIND sort them out?

But if so, what happens when I go online in a different network where
I'm passed a name server with the DHCP lease?

I'm thinking of a simple workaround, which would be to use an
intermediate connection like nntp-open-via-rlogin-and-telnet or
something.  But instead of connecting to a remote machine, just use
the current machine.

The idea here is to "misuse" the indirection to fork off a new process
that would actually read /etc/resolv.conf.

We'll see.