Hi!
We ran a DNS Report on our domain and received the following warnings:
Is there a way to correct these?
NS TTL discrepancy Warning: Your NS records at your authoritative DNS servers have TTLs that do not match what the parent servers report:
ns.ourresellernameserver. [TTL 172800 at parent; 86400 at IP Address]ns2.ourresellernamerserver.net. [TTL 172800 at parent; 86400 at IP Address]
In some cases, this can cause some serious problems. For example, if the parent servers have a 172800 second TTL (48 hours), and your authoritative DNS servers report a TTL of 3600 seconds (1 hour), you are saying that the parent DNS servers do not have the correct information. But, after 1 hour your DNS records may time out. At that point a DNS resolver will need to get fresh NS records. This can cause a serious problem in some cases.
SOA REFRESH value WARNING: Your SOA REFRESH interval is : 10800 seconds. This seems a bit high. You should consider decreasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours; 12 hours seems very high to us), although some registrars may limit you to 10000 seconds or higher, and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommend 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.
Multiple MX records WARNING: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you.
Reverse DNS entries for MX records ERROR: The IP of one or more of your mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout" below, it may mean that your DNS servers did not respond fast enough). RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site. The problem MX records are:
11.248.36.66.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0)]
Mail server host name in greeting WARNING: One or more of your mailservers may be claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won't cause any harm, but may be a technical violation of RFC821 4.3 (and RFC2821 4.3.1).
mail.ourresellernameserver.net claims to be host mail.m****here.biz.
Acceptance of abuse address WARNING: One or more of your mailservers does not accept mail to [email protected]. Mailservers are expected by RFC2142 to accept mail to abuse.
mail.ourresellernameserver.net's abuse response:
>>> RCPT TO:<[email protected]>
<<< 556 sorry, bounce messages should have a single envelope recipient (#5.7.1)
Acceptance of domain literals WARN: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted.
mail.ourresellernameserver.net's postmaster@[66.36.248.11] response:
>>> RCPT TO:<postmaster@[66.36.248.11]>
<<< 553 sorry, that domain isn't allowed to be relayed thru this MTA (#5.7.1)
We ran a DNS Report on our domain and received the following warnings:
Is there a way to correct these?
NS TTL discrepancy Warning: Your NS records at your authoritative DNS servers have TTLs that do not match what the parent servers report:
ns.ourresellernameserver. [TTL 172800 at parent; 86400 at IP Address]ns2.ourresellernamerserver.net. [TTL 172800 at parent; 86400 at IP Address]
In some cases, this can cause some serious problems. For example, if the parent servers have a 172800 second TTL (48 hours), and your authoritative DNS servers report a TTL of 3600 seconds (1 hour), you are saying that the parent DNS servers do not have the correct information. But, after 1 hour your DNS records may time out. At that point a DNS resolver will need to get fresh NS records. This can cause a serious problem in some cases.
SOA REFRESH value WARNING: Your SOA REFRESH interval is : 10800 seconds. This seems a bit high. You should consider decreasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours; 12 hours seems very high to us), although some registrars may limit you to 10000 seconds or higher, and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommend 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.
Multiple MX records WARNING: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you.
Reverse DNS entries for MX records ERROR: The IP of one or more of your mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout" below, it may mean that your DNS servers did not respond fast enough). RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site. The problem MX records are:
11.248.36.66.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0)]
Mail server host name in greeting WARNING: One or more of your mailservers may be claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won't cause any harm, but may be a technical violation of RFC821 4.3 (and RFC2821 4.3.1).
mail.ourresellernameserver.net claims to be host mail.m****here.biz.
Acceptance of abuse address WARNING: One or more of your mailservers does not accept mail to [email protected]. Mailservers are expected by RFC2142 to accept mail to abuse.
mail.ourresellernameserver.net's abuse response:
>>> RCPT TO:<[email protected]>
<<< 556 sorry, bounce messages should have a single envelope recipient (#5.7.1)
Acceptance of domain literals WARN: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted.
mail.ourresellernameserver.net's postmaster@[66.36.248.11] response:
>>> RCPT TO:<postmaster@[66.36.248.11]>
<<< 553 sorry, that domain isn't allowed to be relayed thru this MTA (#5.7.1)