PHPmailer appears to be ignoring DNS

[jtata]

Greetings. I'm a long time Nagios user and have recently begun deploying XI for a new employer. While settng up notifications I ran into some issues configuring email and it appears that the issue is realted to DNS. Here is what is happening:

When I configure my SMTP settings if I use the FQDN of my SMTP server and attempt to send a test email I receive "SMTP Error: Could not connect to SMTP host." If I replace the hostname with the IP address the email is delivered correctly, so obviously the issue is related to name resolution.

Digging in further I've confirmed my Nagios server can resolve DNS without problems. NSLOOKUP returns the correct IP, I can ping the SMTP server by name, even DNS checks from Nagios itself return correct values. The only thing that isn't working is the SMTP function from PHPmail.

Just for kicks I added a host file entry for my SMTP server...sure enough the test email arrives without incident. So it seems like PHPmail is only using my host file despite having nsswitch configured to use DNS? Has anyone encountered this and is there a way I can change it to actually resolve names using DNS?

Any advice would be apprciated since we are using a hosted email provider and the IP of the SMTP server could change in the future. Thanks.

[mmestnik]

Perhaps this is an MX record issue?

This is not a known problem, try using "getent hosts <DNS name>" to test nsswitch.

[jtata]

Checked mx records, nslookup returns the correct addresses, though I don't see what the MX has to do with it since I'm not even getting as far as submitting to the SMTP server.

Getent returns the correct IP for my SMTP:

• getent hosts secure.emailsrvr.com
  72.4.117.9 secure.emailsrvr.com

• nslookup secure.emailsrvr.com
  Server: 208.67.222.222
  Address: 208.67.222.222#53
  
  Non-authoritative answer:
  Name: secure.emailsrvr.com
  Address: 72.4.117.9

Host line of nsswitch reads:

• hosts: dns [NOTFOUND=return] files

However even with it set this way I still can send email when I have the IP for secure.emailsrvr.com in the /etc/hosts and get the same error when I don't. It really looks like PHPMailer is ignoring my nsswitch settings for some reason and going straight to hosts. Does PHP have its own conf file for names resolution or something?

[mmestnik]

Where did you get that nss line? This is the one I'm using:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

Removing the mdns stuff and the default/base nss file should be:
hosts: files dns

http://www.gnu.org/s/libc/manual/html_n ... figuration
So in your example a DNS lookup that returned UNAVAIL or TRYAGAIN would behave as you describe.

As for MX records lookup VS a generic lookup VS an explicit A lookup. It's difficult to test the results of these, I see what you are saying that MX records SHOULD be used to resolve the destination of an email address, however they can also be used to find the mail server for this host.
When testing DNS lookups it's important to try all combinations applicable and in some cases even more.

For this I use dig, like so

Code: Select all

record=smtp.fusemail.net
dig +trace $record
dig $record
dig A $record
dig MX $record

[jtata]

I edited the nsswitch file during my troubleshooting. Returned it to the defualt hosts files dns but the problem still persists.

Your suggestion to use dig has uncovered something interesting. In my query output I get the following:

First query returns this:

Code: Select all

;; Received 241 bytes from 192.12.94.30#53(e.gtld-servers.net) in 119 ms

secure.emailsrvr.com.   28800   IN      A       72.4.117.9

However each query returns the following:

Code: Select all

;; QUESTION SECTION:
;secure.emailsrvr.com.          IN      A

;; ANSWER SECTION:
secure.emailsrvr.com.   27414   IN      A       72.4.117.23

So dig + trace is giving me one IP, while dig and dig A are giving me a different one...maybe just a stale record and not relevant or maybe this what's screwing everything up?

[mmestnik]

The really nice thing about dig is it exposes an impotent element to DNS *troubleshooting. The TTL the server returns, this gives a little glimpse into the status of the **DNS server, this output indicates that the record was changed from 72.4.117.23 to 72.4.117.9 less then 30min ago(from when you did your test).

If that's not the case then I'd imagine some one forgot to trip the serial number.

[jtata]

I am going kick this to our email host and see what they say regarding the DNS change. Thanks very much for your help!