In message <200506282137.RAA27224@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr
ites:
>> [nonfunctional rDNS]  This in turn causes problems with using ftp --
>> the ftp server on ftp.netbsd.org tries to look up the name; it takes
>> sufficiently long to fail that (as best I can tell) my client times
>> out: ftp.c seems to have a fixed 60-second timer before it gives up
>> on the connection.
>
>> I'm not certain how best to fix this.
>
>I see two pieces to the problem here, in that there are two things that
>could use fixing, and fixing either would make the symptom go away: the
>rDNS trouble and the client-side timeouts.
>
>Of course, I think both should get fixed.
>
>I see no reason to have any application-level client-side timeout.
>There's a timeout implicit in the connect(), so there's no need for an
>application-level timeout there, and I would let the human level handle
>any timeout after connect() succeeds.  (For automated use, one could
>argue keepalives should be turned on, to prevent clients from hanging
>forever if the server crashes.  I'm not sure whether I think that
>should default on or off, though.)
>

This timeout is in the client, when reading the 220 response.  If I do 
a 'telnet -6 ftp.netbsd.org ftp', it takes about two minutes to receive 
the response.  There's a hard-coded 60-second timeout on the read 
client.

As for the rDNS problem -- I'd love to fix that; in common with most of 
us, I have exactly zero ability to do so directly.  (Nor is changing 
jobs, just to get a better rDNS, an option...)  I have sent in a 
support request, but I imagine it won't be a top priority for our 
support staff (and rightly so).  The issue is that our default client 
doesn't play nicely with our major ftp server under certain 
not-uncommon situations.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb