I am running an apache webserver on a Redhat 7.2 box. It also has WuFTP installed. This computer is connected to a switch which is connected to a router with 3 interfaces (external, optional and trusted).
Now on my trusted network I have private 10.10.x.x addresses that are assigned via a DHCP server. I also have statically assigned public IP addresses on this same network. NAT is taken care of by a Cisco 3640 router on the external interface.
When a user with a private address on the trusted network attempts to go to the webserver which is on the optional network it takes 15 - 30 seconds for the pages to completely load, however when attempted from a public IP address it works just fine.
I assumed that it was a problem with my router with 3 interfaces. I installed in its place a redhat 7.2 box with 3 nics and setup routing that way. The problem still persists and I am at a loss as to what could be wrong. NAT shouldn't have anything to do with the problem because it isn't changed to a public address until it needs to leave my facility via the 3640 router. Does NE1 have ANY ideas as to what could be causing this problem?

try adding the ips of the problem computers on your lan to /etc/hosts

hooray my 200th post!!!

Thas my first thought so I tried that. It didn't work either.

Where did you add it to /etc/hosts? On the router or the apache webserver. It's the webserver that is trying to resolve the names. How does the apache server resolve it's names? /etc/nsswitch.conf should tell you where it looks first. Should be files and then dns. Files would mean it looks in the local /etc/hosts.
You can also stop apache from doing a reverse lookup on an ip number, because it slows it down more then necessary. If you still want resolved hostnames in the logfiles then you should use the tool logresolve that comes with apache, and run that as a cron job to resolve the names in your log files.

You hit the nail right on the head. It was a second DNS server that was decommisioned a month ago that was causing the problems.

I've got a similar problem, except its with Sendmail. Outgoing mail, using whatever: pine, elm, Mutt, takes about 20-30 seconds to process out, but not all the time. Could this be an issue with my (hardly reliable) DNS servers?

Cheers,

Finegan

It is possible, usually a delay on connect but then fast transfers has to do with the fact that it's timing out on a dns query somewhere. The best way to fix it is to find out how your dns names get resolved. First by looking in /etc/nsswitch.conf and check each step it takes for the hostnames entry. Local names which you use in your network should not be resolved by an external dns because you'll definetly get a timeout. If you still think everything is configured right then you could try logging udp packets at port 53. Try and see which dns server it's trying to get it's answers from. If you want to go even further you could try scanning through the contents of the packets to find out which hostnames it's trying to resolve.
You also mentioned that it only sometimes takes a long time. DNS queries are done through udp. On a very busy network udp packets tend to get dropped every so often. So if the udp packet with the dns request gets dropped you'll just receive a timeout.
Hope that helps to find your problem.