Funny, the exact same thing just happened to one of my servers today.
Nearly same symptoms, nearly same setup.  I'm running wu-ftpd (small ftp
site, internal only use), RH7.2, and updated the kernel today, but
before I even rebooted into the new kernel (2.4.9-31), all windows-based
ftp logins were all timing out.  I opened up an external route, and was
able to login externally just fine.

My /etc/resolv.conf uses internal M$ DNS servers, (not maintained by
me), that I know specifically do not have reverse dns setup.  In fact,
they never have, and the current admin thinks it's stupid to use reverse
dns.  But, forward dns works (all windows clients have registered
hostnames, and they are the ones ftping in).

I know what you're thinking, but what I'd like to know, is why it is
that for 4 or so months, internal ftp access was INSTANT, as was ssh.
But, starting today (I was assuming it was the kernel upgrade), ssh and
ftp are dog slow.  The only way I was able to ftp from windows clients,
was to add an entry to the hosts file.  Note: nothing has changed on the
M$ side affecting dns.

I did a little digging, and found this option for wu-ftpd in the man
page:
dns resolveroptions -recurse

I put that in my /etc/ftpaccess, and windows clients were able to ftp,
though after 10 seconds or so (not near as instant as before).  This
definitely has to do with reverse dns.  I rearranged my nsswitch.conf,
to no affect.  Rebooted into the new kernel, but everything was still
the same.  What gets me is that ssh is still slow. This is a desc I
found of why wu-ftpd used reverse dns:

http://www.landfield.com/wu-ftpd/mail-archive/wuftpd-doc/2001/Sep/0000.h
tml

I was just about to setup an internal dns server and populate the zone
files with host1, host2...  entries, but with over 14 class c networks
all  on an internal network, this doesn't seem viable.  What really gets
me is that there IS dns zone files, with the correct info (I can do a
`host windozebox` and get an immediate return from M$ dns server, but
the reverse of course does not work).  I considered copying those zone
files, and running my own reverse dns, but is it really worth it?

Anyone else have any suggestions?

I seriously doubt a hack, as I run netfilter on this box, only allowing
ftp, ssh, and web, though all internally only, not to mention tripwire,
pix, ids, and various other things keeping baddies away.

relevant configs:

/etc/resolv.conf
search our.domain
nameserver ip.of.m$.ds
nameserver ip.of.m$.dns2

/etc/nsswitch.conf
hosts: files dns [NOTFOUND=return]

/etc/hosts
127.0.0.1 localhost
my.int.box.ip  servername


Thanks in advance,
Vinny

On Thu, 2002-02-28 at 11:17, Paul Hamm wrote:
> Sounds like you have a resolver issue.  Check your DNS specificaly the

> reverse lookup.  Or you may have been hacked ;-)
> 
> -----Original Message-----
> From: gabriel [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 28, 2002 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: spontaneous lag (x3)
> 
> 
> the oddest thing has been happening to the machines here in my office 
> for the past few months. most of the time, telnetd/sshd/ftpd all seem 
> to be working fine, but on three separate days in the last two months,

> an odd lag has manifested itself during the login.  ie. it takes 
> nearly a full minute to telnet into a local rh6.2 machine. and about 
> the same time to ftp between either machines.  apache however, which 
snip



_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to