did I break BIND , Postfix or both?

14 posts / 0 new
Last post
#1 Fri, 12/03/2010 - 22:31

did I break BIND , Postfix or both?

As of right now..
DNS resolution is flaky.. Some times i get an answer, sometimes I see a SERVERFAIL reply i can not receive e-mail. (they bounce back..) I am however to use the page, and send e-mail to an external server

I have a VPS, running CentOS 5.4 I left the default hostname that was given to it from the provider

I was given 3 ip addresses when i bought the VPS I picked one of my domains.. and set the glue records and created a host for each of the addresses

I then took those 3 fqdn and used them for all of my other domains at the registrar

For some of my domains i take the mx record within virtualmin and change it to point to the GMail servers. Others i leave alone and let my server host the e-mail

For the longest time i thought that the problem was simply with my dns server not responding(slow?) to queries on the mx record, Now i believe there is a configuration error on my part.

I have recently tried to send (web)mail on the server itself to another account on a different domain, Both to an account where the mx record points to google and where the e-mail is on the same server.... I can send e-mail to another domain completely, but i can not send e-mail to any domain that is on that server, regardless of where the mx record points.

Gmail will bounce an e-mail back with the following reply Connection was dropped by remote host (SENT_RCPT)

I cant get the DNS resolution to fail right now.. but sometimes i simply see a SERVERFAIL message...

.... Not sure if this is the same problem, or just one really screwed up installation, with many issues... I simply don't know where to go right now.

99% of the install is default from virtualmin..

what did i miss?

Fri, 12/03/2010 - 23:16

I ran a dns check on the domains in question through introDNS

no failure.. couple warnings as follows

SOA MNAME entry WARNING: SOA MNAME (*The original host-name as generated by my host*) is not listed as a primary nameserver at your parent nameserver!

Im not sure about this.. why would it matter...

SOA Serial Your SOA serial number is: 1280284406. This can be ok if you know what you are doing.

this is confusing to me.. is it because its high.. or is there another problem?

Fri, 12/03/2010 - 23:18

Well, it's hard to say, it could be a few things :-)

One place you might start is to browse to intodns.com, and input one of your domains there. It would run a DNS report, and tell you if it sees anything awry.


Fri, 12/03/2010 - 23:25

Well, the problem isn't the SOA number.

If it's not failing now, and intodns isn't seeing a problem, it may be some sort of network issue that's just not acting up at the moment.

What I might suggest is running the intodns report during a time when things aren't working.


Sat, 12/04/2010 - 04:17

Effects where name resolution sometimes works and sometimes not are often caused by "flaky" domain entries at the NIC... Like one NS entry pointing to the correct (your) host and a secondary one is not (as in pointing to a completely incorrect server, or a server that does not really host your zone).

To evaluate this further, I'd need to know the concrete domain names in question, and what they are supposed to point to, so that I can do some checks.

Sat, 12/04/2010 - 16:27

dns1.spydercomputing.com dns2.spydercomputing.com dns3.spydercomputing.com

all assigned to different ip addresses on the server at the registrar for spydercomputing.com

idoshows.ca is the dns in question that has the mx records pointing to Google. but e-mail bounces back sometimes randomly.. so even if my postfix config is screwed.. e-mail should work if my dns is working(Right??).. or could postfix still get in the way of that e-mail too?

I changed the SOA from the vendor assigned hostname to dns1.spydercomputing.com .. intoDNS seems to like it better. It tells me everything else is okay.

I realize i really should get a second dns server to replicate, instead of having everything point to the same box. I just want to get this working first.

Sat, 12/04/2010 - 17:36

Yeah, the DNS -- and in particular, MX records -- look good at each of your nameservers.

What exactly is the error you're getting when your email bounces back? Knowing the specific error might help figure this out.


Sat, 12/04/2010 - 18:09

From my friend's server

-> RCPT TO:<scott@spydercomputing.com>
* Remote host closed connection unexpectedly.

from gmail

Message will be retried for 2 more day(s)

Technical details of temporary failure:
Connection was dropped by remote host (SENT_RCPT)
Sat, 12/04/2010 - 18:54

I just did some checks too.

DNS resolution looks good, all the responsible nameservers point to as MX for "spydercomputing.com".

I then did a "manual" email delivery test via telnet to port 25. It happenes like the reports say: After the RCPT TO command, your Postfix simply drops the connection.

You should check /var/log/mail.log for errors. The reason is quite surely noted there. :)

I also did not get what you were trying to say with this "idoshows.ca" and it "pointing to Google"? How does that relate to the "spydercomputing" issue?

Sat, 12/04/2010 - 18:56
Dec  4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: connect from blu0-omc3-s27.blu0.hotmail.com[]
Dec  4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: fatal: missing service information
Dec  4 17:50:27 ip-173-201-26-143 postfix/master[10031]: warning: process /usr/libexec/postfix/smtpd pid 18292 exit status 1
Dec  4 17:50:27 ip-173-201-26-143 postfix/master[10031]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling

I point the mx records for idoshows to gmail.. but the e-mails still bounce back.. unlikely that gmail is down .. i assume its my dns..

spydercomputing e-mail is hosted on this same virtualmin server.. so i have 2 diferent domains, both with similar issues, but with 2 different e-mail solutions... led me to believe its a DNS issue..

Sat, 12/04/2010 - 19:09

How exactly do mails to idoshows bounce back? What's the error message? Its MX records look good and point to Google, your Postfix issue should not be the reason there.

Dec 4 17:50:26 ip-173-201-26-143 postfix/smtpd[18292]: fatal: missing service information

This looks like the culprit there. My first guess it that it might have to do with Greylisting, which is implemented as a policy daemon - getting called through Postfix' smtpd_recipient_restrictions by connecting to it on Maybe the port number is missing there.

Do you have Greylisting active? Does it work when you turn it off? Before you do that, does your /etc/postfix/main.cf contain a line like this?

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:

Sat, 12/04/2010 - 19:28

i don't have an example of a bounced e-mail send to Gmail. it always works for me because my Gmail accounts are linked and just go to the correct box without leaving google.. I have not been "lucky" enough to bounce one when i try on my own.. i just know it happens from talking to people in person.. I'll try to dig up a copy from somebody else.

Maybe its just my server not responding when they query the mx record... shrugs

[root@ip-173-201-26-143 log]#  grep smtpd_recipient_restrictions  /etc/postfix/main.cf
# through Postfix.  See the smtpd_recipient_restrictions parameter
# relay mail to.  See the smtpd_recipient_restrictions description in
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:

... from the web interface

Greylist is a technique to reduce spam by initially rejecting email the first time another mail server tries to contact your server. Real mail servers will re-try after a short delay, but those operated by spammers typically will not. Thus legitimate email still gets delivered, but spam does not.

Greylisting is not currently fully enabled on your system. Click this button to have Virtualmin configure
Sat, 12/04/2010 - 19:34

Yes, obviously the port number in your smtpd_recipient_restriction directive is missing. You can add it, according to the line I sent you, or turn greylisting off and on again. That should re-create the correct line too.

(And I must note here that I'm somewhat proud of myself that I had the right idea there right away. ;) )

And yes, if your nameserver does not respond when someone tries to send a mail to that Google-based domain, that would sure be a reason for failure, even if Google itself is up.

Sat, 12/04/2010 - 19:41

Thanks a lot for your time..

I really had no intention to use greylisting.. I remember playing with settings a while ago.. but i made sure it was off when i was done...

I just turned it on, then turned it off...

it cleaned up the line..

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

I was just able to send an e-mail to an account hosted on the server from gmail....

my mail log looks normal from what i can tell..

Thanks again.. as for the DNS.. ... Maybe i'll work on replicating the dns to a second server for some redundancy

Topic locked