大家帮忙看看DNS Report 的几个严重问题

koskok

1.

WARN

Glue at parent nameservers

WARNING. The parent servers (I checked with c.dns.cn.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

2.

WARN

All nameservers report identical NS records

WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).

3.

FAIL

Missing nameservers 2

ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.zjdomain.com.

4.

WARN

Nameservers on separate class C's

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

5.

WARN

Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

6.

FAIL

NS agreement on SOA Serial #

ERROR: Your nameservers disagree as to which version of your DNS is the latest (1164699766 versus 1164702878). This is OK if you have just made a change recently, and your secondary DNS servers haven't yet received the new information from the master. I will continue the report, assuming that 1164702878 is the correct serial #. The serial numbers reported by each DNS server are: 202.96.96.67: 1164699766 202.96.104.24: 1164702878

7.

WARN

SOA Serial Number

WARNING: Your SOA serial number is: 1164702878. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change. Your SOA serial appears to be the number of seconds since midnight 01 Jan 1970 when the last DNS change was made (tinydns format). That works out to be Tue Nov 28 03:34:38 2006 EST.

8.

WARN

SOA RETRY value

WARNING: Your SOA RETRY interval is : 14400 seconds. This seems a bit high. You should consider decreasing this value to about 120-7200 seconds. The retry value is the amount of time your secondary/slave nameservers will wait to contact the master nameserver again if the last attempt failed

9.

FAIL

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 if you recently changed your reverse DNS entry (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server). The problem MX records are: 203.78.191.60.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0) (check it)]

10.

WARN

SPF record

Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).

11.

FAIL

WWW Category

ERROR: I couldn't find any A records for www.CHIEFMATE.COM.CN. But I did find a referral to ns1.zjdomain.com. (and maybe others). If you want a website at www.CHIEFMATE.COM.CN, you will need an A record for www.CHIEFMATE.COM.CN. If you do not want a website at www.CHIEFMATE.COM.CN, you can ignore this error.

koskok

怎么解决?