dnsreport help

Single Point of Failure - It's just saying that since both of your nameservers are actually the same literal machine, if that machine goes down you have no backup DNS - all of your DNS is done by a single machine.... not uncommon for a lot of Cpanel hosters.

Nameservers on Separate Class C's - Yeah you could use zonedit.com or a bunch of other ones (none bounce of my noggin at present though) as additional nameservers if you pay for the privilege. Nowadays this really should just be a 'single point of failure' thing as far as your concerned - If you are hosted at a Data Center with a bunch of bandwidth providers connected, the likelihood that one class C fed by that data center would have connectivity if the other class C didn't isn't nearly as high... and not as likely for those links to go down considering most have multiple providers and are running BGP.

Acceptance of Domain Literals - Means just what it describes. Per RFCs, one should be able to send email to a user (such as postmaster) @[ip.add.re.ss] - the main IP address of your machine. But as it describes, this isn't a must either since there are many large and small mail providers that do not allow this. Chances are that if somebody's mail system is so misconfigured that it cannot receive email at its hostname or some domain hosted on it, it probably isn't worth it for anybody to try to send mail to @[ipaddress] either.

Mail Server Hostname in Greeting - Your mail server, when it attempts to deliver mail, claims that it is spring.blahhawebhosts.com. However, spring.blahhawebhosts.com does not resolve to the IP address of that specific machine - it resolves to 67.xxx.26.xxx but your machine is 208.xx.169.xxx. Technically, DNSReport would expect to see that when it connects to blahhawebhosts.com mail server, the mail server would EHLO with blahhawebhosts.com and not spring.blahhawebhosts.com - But there may be legitimate reasons why you have blahhawebhosts.com on another server. Unless i knew more to make a better judgement, I wouldn't worry about this one. But you should make sure that if your main hostname (telnet localhost 25 and see what it announces itself as) to the main IP address on your ethernet adaptor for that machine and that the main IP address reverse resolves to the actual hostname of the machine. But of course, again without knowing full details, I wouldnt' advise you to just willynilly change hostnames or anything if your mail appears to be delivering fine and everything is functioning fine. I don't have all of the info needed.

- Mike

 

For the domain in question, edit the dns zone of that domain and put in the FQN of the servers host name for the MX.

So instead of
domain.com 14400 in MX 0 domain.com
use
domain.com 14400 in MX 0 host.domain.com

This will happen if your root domain is on a dedicated IP and not on the share IP.

 

As Jay explained in:

Edit the DNZ zonefile for host.com. Find the MX entry - and to the right of MX 0 change 'host.com' to 'servername.host.com'

In the end you should have something like:

host.com 14400 in MX 0 servername.host.com as your only MX

When you go to DNSReports and type in 'host.com', it does a lookup of the MX (which currently points to host.com). It then attempts to connect to 'host.com' on the shared IP. The machine responds by introducing itself as servername.host.com (because that's the main hostname of the machine and is mapped to the main IP on the adapter).

DNSreports checks and resolves host.com to the shared IP and then checks and resolves servername.host.com to another IP.

I don't think that changing the MX is going to resolve this part of the DNSReport finding:

blahhawebhosts.com claims to be host spring.blahhawebhosts.com [but that host is at 67.xxx.26.xx (may be cached), not 208.xx.169.xxx].

As long as host.com resolves to 208.xx.169.xxx and servername.host.com resolves to 67.xxx.26.xx, DNSReports is going to continue saying this. What DNSReports is 'hoping' to find is that the MX for host.com resolves to the same IP address as the hostname that the machine announces itself as in the SMTP greeting.

host.com - 208.xx.169.xxx
servername.host.com - 67.xxx.26.xx

Exim announces itself as servername.host.com during EHLO. servername.host.com is 67.xxx.26.xx.

The only way to get rid of this message in DNSReports is to have host.com resolve to the same IP address as servername.host.com. This means that host.com would need to be hosted on the main IP address of the server.

Mike

 

Either way, if you put in your full host name of the mail server, it will indeed resolve to the IP which handles the mail. This is what DNS report is looking for. I am not completely sure if the contrasting IP's are the same server or not but either way, you need to put in the fully qualified host name as your mail server.

If this is the box you have access to, then simply type in ssh,

hostname

to get the fully qualified name and you should also be able to ping the hostname as well.

One last comment, DNS Report may be cached so it may take up to a full day to see the error cleared.

Good luck.