======================
FAIL: All nameserver respond
63.238.107.157 didn't respond...
I'm seeing problems that may likely be due to connectivity. I can get information from your nameservers within about 100 ms but some nameservers I check (ones I maintain) show over 4,000 ms, which is too long. ns1.earthlink.net found it in 177 ms, which is certainly fast enough.
Your glue is okay, and you're okay from my home and from my nameservers, so I think it's a connectivity problem.
However you may ask the question "how can it be a connectivity problem when the nameservers for both the domains are on the same network? That I can't answer except to point out you don't have reverse DNS, and absence of reverse DNS can cause connectivity delays.
WARN: Nameservers on separate class C's
Connecitity problems are the specific reason why nameservers should be on separate class Cs. Since you have multiple nameservers there's no real reason why you shouldn't have them at least on separate systems. But in your case (bad connectivity?) I'd recommend using someone else for secondary service on a different network if at all possible. (Note my possible conflict of interest; we believe in secondary DNS and we sell secondary DNS; be sure to get someone else's opinion
.
WARN: SOA Serial Number
I like to use the recommended format, but most hosting server administration systems don't. I thought John had made a change somewhere to allow it. John? (Note that it's certainly not critical.)
WARN: SOA REFRESH value
I recommend 20 minutes. However current versions of named, by default, use DNS notify. Contrary to RIPEs recommendation, if you use DNS notify you probably don't care at all what this setting is.
WARN: SOA EXPIRE value
While I use 172800 seconds, that's probably too low; I think I'll reset this on my servers to at least two weeks (1209600 seconds).
WARN: Multiple MX records
This warning isn't really about DNS; it's about email. While most of us don't have backup mailservers, it's nice to have them. But it's not really a DNS issue. In my opinion they shouldn't test this here; the inclusion of this test is the main reason I don't send end-users to dnsreport.com. When we start using backup mail servers (sometime this fall) we'll eliminate that problem
.
FAIL: Reverse DNS entries for MX records
This one really is critical since lots of domains just drop email from domains that don't properly reverse. If your email comes from mail.example.com and your mx points to example.com, then it's enough to have reverse records for mail.example.com, but for most of us, yes, we need reverse DNS entries for MX records. While no RFC requires reverse entries for anything on the Internet, common practice says yes, and you'll risk a lot of undeliverable mail from your box if you don't have reverse DNS for your MX records. Of course you may not be able to do reverse DNS; your provider may have to do it for you; you can only do reverse DNS if it's been delegated to you.
As I pointed out above, lack of reverse DNS can cause connectivity problems.
WARN: Mail server host name in greeting
I believe there's a way to fix this; there's something in most mailservers that can be set to they'll announce themselves with the name of the virtual server being used, instead of the main hostname of the system. But I've just done a bit of checking; this is an extremely common warning; it appears to be quite common when virtual domains are hosted on one box with one hostname.
WARN: Acceptance of domain literals
While this isn't really a DNS error either, it should be allowed, simply because it's required in the RFCs. However, as the warning says, it's unlikely anything will break if it's not. Plesk doesn't do this. Sun Cobalt RaQs do. John? Can you fix this?
Jeff
