problem with DNS lookups on non-IPv4-only-mode?

[Dan Kaminsky]

Damien Miller wrote:

>On Wed, 9 Jun 2004, Dan Kaminsky wrote:
>
>  
>
>>It's totally an architectural problem, very much like that Cisco fault a 
>>while back where unresolved packets in unassigned protocols would 
>>eventually cause the entire system to fall over.  If one channel kills 
>>the rest, there's an architectural fault.
>>    
>>
>
>I think you have a very different definition of "architectural": I mean 
>that there is nothing in sshd's design that precludes implementation of 
>this. The actual changes are fairly straightforward.
>
>As always, someone interested just needs to do the work.
>
>-d
>  
>
What I meant by this being an architectural fault is that while sshd
invocations are entirely independent (one session dying does not kill
the entire server, IIS4/5 style), a particular sshd invocation
cooperatively shares resources across its list of channels. That means
that if any individual channel blocks, for any reason, all freeze.

If each channel was managed by an individual thread, the architectural
fault would be resolved. Note, I didn't say this was a good idea -- just
that it would make it impossible for any particular channel to affect
traffic outside of its own context, except through the rich library of
non-deterministic bugs threading is famous for :)

We can, and I'm sure eventually will include some sort of async DNS
support in sshd. That will solve this particular malady, wherein an
external server can by withholding a DNS response cease the flow of
execution within sshd. But the architectural fault is that sshd trusts
that certain functions will necessarily return in a reasonable amount of
time, and that's simply not necessarily the case.

I have found that forcing the remote server to have some server->client
communication on a regular basis can kick me out of certain loops.
Perhaps an alarm/signal combo might be helpful...?

--Dan