On 09 August 2007, Ken Price kprice@nowyouknow.net wrote: <snip>
I'll give my two cents and retire for the evening. I've tried multiple times from 3 different locations (Atlanta & Seattle) to connect to MAIL.MEDVOICE.COM on port 25 ... which I'm assuming is your problem server. I get inconsistent results. Half the time I get a near immediate (<2 seconds) 220 prompt. The rest of the time I get > 10 seconds or timeouts.
I tried his SMTP this morning and it was either OK or timeout.
- Who does your DNS? Looks like Qwest is authoritative for your
domain, do you use their recursive DNS servers too? If yes, this could be a problem. If you don't already, RUN YOUR OWN RECURSIVE DNS for your server!! Bandwidth and DNS are the likely culprits.
Possibly someone who knows a *lot* more about DNS management than I do can look at his DNS management? I have the ttl (IN) for "A" and "PTR" at 3600s for my web site. Faster, if one changes IP address. He has those ttl at 100000s.
Possibly he could use the IP address more, in DNS management?
I've had the SMTP service die, over the past 68 months, approximately 10-15 times, on a RH server (shared hosting). Never daily. Services and processes sometimes die mysteriously, but probably not on a daily basis.
In the WHOIS record:
Name Server: AUTHNS3.STTL.QWEST.NET Name Server: AUTHNS1.MPLS.QWEST.NET Name Server: AUTHNS2.DNVR.QWEST.NET
Possibly those should be in different order? (I have mine, NS1, NS2, NS3, NS4 from top to bottom)
Jason,
This has nothing to do with AUTHORITATIVE dns. I'm speculating this is a problem with your choice of RECURSIVE (caching) name servers. Realize, however, that without being on the box and looking at your configuration, all I can do is speculate.
Mail .medvoice.com actually resolves to the mail server insidethrough port forwarding.
Very typical.
It's not really named that just everything going to the mail ports ends up there.
Understood. Again, very typical.
Would DNS still be an issue for sending internal mail.
Maybe, maybe not. It depends on your internal network setup and where your server and workstations sit respective to each other. What's in your server's /etc/resolv.conf file? On your windows workstation, from the command prompt: ipconfig /all ... what "DNS Servers" are listed here?
I ran top during one of these unresponsive email spats and noticed that there are no smtp processes listed.
That just means there's no Postfix process in the busiest 20 or so processes. Use the command "ps -aux" for a more complete process view. That also means it's very unlikely your server is overloaded or reaching process limits.
When someone initially connects to your mail server, typically the first thing your mail server does is a reverse IP lookup on the person connecting. Then, depending on your setup, it could also query a number of RBL sources (Real Time Black Hole Lists) to see if the sender is a known spammer. The more stuff that is done on that initial connection, the more DNS lookups your server has to make and the longer it takes to return the "OK" 220 prompt. That's why I'm speculating this is a DNS issue. If my hunch is correct, your /etc/resolv.conf will point to your ISP's recursive (caching) name servers. Rarely do they perform well since they're shared amongst hundreds/thousands/millions of users. For performance reasons, you're better off running at least one caching name server of your own inside your network - even on the server in question. While this is only speculation on your problem, these methods also lean towards "Best Practices" and are simple to implement.
-Ken
Ken,
You are correct, resolve.conf does list my isp's dns 250.171.3.65 which is qwest. The internal windows workstations also point o the isp's dns server. Can I setup a cashing dns server on the mail server itself??
PS: I just wanted to say thanks to everyone who has helped me so far.
-jr
Ken Price wrote:
Jason,
This has nothing to do with AUTHORITATIVE dns. I'm speculating this is a problem with your choice of RECURSIVE (caching) name servers. Realize, however, that without being on the box and looking at your configuration, all I can do is speculate.
Mail .medvoice.com actually resolves to the mail server insidethrough port forwarding.
Very typical.
It's not really named that just everything going to the mail ports ends up there.
Understood. Again, very typical.
Would DNS still be an issue for sending internal mail.
Maybe, maybe not. It depends on your internal network setup and where your server and workstations sit respective to each other. What's in your server's /etc/resolv.conf file? On your windows workstation, from the command prompt: ipconfig /all ... what "DNS Servers" are listed here?
I ran top during one of these unresponsive email spats and noticed that there are no smtp processes listed.
That just means there's no Postfix process in the busiest 20 or so processes. Use the command "ps -aux" for a more complete process view. That also means it's very unlikely your server is overloaded or reaching process limits.
When someone initially connects to your mail server, typically the first thing your mail server does is a reverse IP lookup on the person connecting. Then, depending on your setup, it could also query a number of RBL sources (Real Time Black Hole Lists) to see if the sender is a known spammer. The more stuff that is done on that initial connection, the more DNS lookups your server has to make and the longer it takes to return the "OK" 220 prompt. That's why I'm speculating this is a DNS issue. If my hunch is correct, your /etc/resolv.conf will point to your ISP's recursive (caching) name servers. Rarely do they perform well since they're shared amongst hundreds/thousands/millions of users. For performance reasons, you're better off running at least one caching name server of your own inside your network - even on the server in question. While this is only speculation on your problem, these methods also lean towards "Best Practices" and are simple to implement.
-Ken
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
You are correct, resolve.conf does list my isp's dns 250.171.3.65 which is qwest. The internal windows workstations also point o the isp's dns server. Can I setup a cashing dns server on the mail server itself??
Absolutely. Assuming that none is running already:
#> netstat -l | grep -e "domain" -e "54"
Should return no results. Now, there are many opinions out there regarding what caching name server to use. I think the easiest here would be BIND. A little bulky, but easily maintained and installed via YUM. Assuming nothing funky with your install, the following should work fine. (you probably have one or many of these installed already)
#> yum install bind bind-utils bind-devel bind-libs caching-nameserver #> /etc/init.d/named start
#> netstat -l | grep -e "domain" -e "54"
Should now show something like: ~]# netstat -l | grep -e "domain" -e "54" tcp 0 0 localhost:domain *:* LISTEN udp 0 0 localhost:domain *:* LISTEN
Now double check that it works: #> dig @127.0.0.1 yahoo.com
If you get a result with Yahoo's IP address info, go ahead and make your server use your new caching name server.
Edit /etc/resolv.conf and add "nameserver 127.0.0.1" to the **TOP** of the list. Leave your ISP's DNS server there just for good measure - you should always have more than one caching DNS server for redundancy. It should now look something like:
#/etc/resolv.conf nameserver 127.0.0.1 nameserver 250.171.3.65 search yourdomainname.com
Feel free to restart your mail server processes if you like, but most should start seeing your new name server right away.
PS: I just wanted to say thanks to everyone who has helped me so far.
No problem. I just hope it helps. I'm running Qmail right now in an ISP setup and had nasty issue about six months ago. Got hit with a double whammy. A bad DNS cache, and a RBL provider timing out and providing poor performance. Gave me similar symptoms.
-Ken
Ken,
Thanks. I followed you instrustions and it installed fine.
I started up bind and can now dig @127.0.0.1 whatever.com and get a response.
The only problem is when I use netstat -l | grep -e "domain" -e "54" i get "warning, got duplicate tcp line. a netstat -l gets me the folowing.
[root@tms1 ~]# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:20000 *:* LISTEN tcp 0 0 *:768 *:* LISTEN tcp 0 0 *:nfs *:* LISTEN tcp 0 0 *:32769 *:* LISTEN tcp 0 0 *:32770 *:* LISTEN tcp 0 0 *:5801 *:* LISTEN tcp 0 0 *:747 *:* LISTEN tcp 0 0 *:pop3 *:* LISTEN tcp 0 0 *:imap *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:10000 *:* LISTEN tcp 0 0 *:http *:* LISTEN tcp 0 0 *:6001 *:* LISTEN tcp 0 0 tms1.teltrax.com:domain *:* LISTEN tcp 0 0 localhost.localdomai:domain *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 localhost.localdomain:smtp *:* LISTEN tcp 0 0 tms1.teltrax.com:smtp *:* LISTEN
Is this ok?
-jason
-
Jason Ross -
Ken Price -
Lanny Marcus