| Test Name | Result | Details |
|---|
| Direct Parent Domain Present | PASS | com. 12574 IN NS a.gtld-servers.net.
com. 12574 IN NS g.gtld-servers.net.
com. 12574 IN NS j.gtld-servers.net.
com. 12574 IN NS l.gtld-servers.net.
com. 12574 IN NS c.gtld-servers.net.
com. 12574 IN NS m.gtld-servers.net.
com. 12574 IN NS h.gtld-servers.net.
com. 12574 IN NS d.gtld-servers.net.
com. 12574 IN NS i.gtld-servers.net.
com. 12574 IN NS b.gtld-servers.net.
com. 12574 IN NS k.gtld-servers.net.
com. 12574 IN NS f.gtld-servers.net.
com. 12574 IN NS e.gtld-servers.net. Some domains (usually third or fourth level domains, such as example.co.us) do not have a direct parent zone ('co.us' in this example), which is legal but can cause confusion. |
| NS Records at Parent Nameservers | PASS | From a.gtld-servers.net.:
dictzone.com. 172800 IN NS igor.ns.cloudflare.com.
dictzone.com. 172800 IN NS beth.ns.cloudflare.com. When someone uses DNS to look up your domain, the first step (if it doesn't already know about your domain) is to go to the
parent servers. If you aren't listed there, you can't be found.
Reference RFC 1033. This could however, be a valid hostname and support email even if the test fails. |
| Glue at Parent Nameservers | PASS | igor.ns.cloudflare.com. 172800 IN A 173.245.59.119
beth.ns.cloudflare.com. 172800 IN A 173.245.58.103 The parent servers should have glue for your nameservers (RFC 1912 2.3). This means that they
are supplying the NS records (host.example.com) and the A records (192.0.2.53). If this is not
the case it 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. |
| Nameservers have A Records | PASS | All your DNS servers should either have A records at the zone parent
servers, or do not need them (if the DNS servers are on
other
TLDs). A records are required for your hostnames to ensure that other DNS servers
can reach your DNS servers. Note that there will be
problems if your DNS servers do not have these same A records. |
| Test Name | Result | Details |
|---|
| NS Records at Domain Nameservers | INFO | dictzone.com. 86400 IN NS igor.ns.cloudflare.com.
dictzone.com. 86400 IN NS beth.ns.cloudflare.com. |
| Public AXFR Transfers Denied | PASS | AXFR transfers allow all of the DNS records for your domain to be downloaded. Some
believe that this presents a security risk to your domain. Your DNS server
software should
allow you
configure it so that these are only available to slave DNS servers. |
| Consistent Glue | PASS | This checks for discrepancies between the glue provided by the parent servers and that provided by your authoritative DNS
servers. |
| Not Open Nameservers | PASS | An open DNS server is one that anyone in the world can query it for domains it is not
authoritative for (it is possible that the DNS
server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your
DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is
not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the
bad guys could use your DNS server as part of an attack, by forging their IP address. |
| NS A Records Present at Nameservers | PASS | Your nameservers should include corresponding A records when asked for your
NS records. This ensures that your DNS servers know
the A records corresponding to all your NS records. |
| Nameservers Report Identical NS Records | PASS | The NS records at all your nameservers should be identical. If you recently changed your NS records they may temporarily be
out of sync. |
| Nameservers Respond | PASS | All of your nameservers listed at the parent nameservers should respond. |
| Valid Nameserver Hostnames | PASS | Your NS records should not contain IP addresses or partial domain names. |
| Number of Nameservers | WARN | You have 2 nameservers. You must have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers), and preferably no more than 7. |
| Nameserver Authority | PASS | All the nameservers listed at the parent servers must answer authoritatively for your domain. |
| No Stealth Nameservers | PASS | All of your nameservers (as reported by your nameservers) should also be listed at the parent servers. You need to make sure
that these stealth nameservers are working; if they are not responding, you may have serious problems! This is listed as an ERROR
because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records
point to your own domain, for example). |
| No Missing Nameservers | PASS | All of the nameservers listed at the parent nameservers should also be listed as NS records at your nameservers. |
| No CNAMEs for Domain | PASS | RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. |
| No NSs with CNAMEs | PASS | RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. |
| Nameservers on Separate Subnets | PASS | 173.245.59.119
173.245.58.103 IPs are cached. You should have nameservers on different Class C (technically, /24) IP
ranges. You must have nameservers at geographically and
topologically dispersed locations. RFC2182 3.1 goes into more detail about secondary nameserver location. |
| NS IPs Public | PASS | IPs are cached. All of your NS records need to use public IPs. If there were any private
IPs, they would not be reachable, causing DNS
delays. |
| TCP Allowed | PASS | Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS
connections, it can cause hard-to-diagnose problems. |
| Nameservers Versions | INFO | igor.ns.cloudflare.com. UNKNOWN
beth.ns.cloudflare.com. UNKNOWN You should check to make sure that you are running software versions that do not
have any known security issues. This test currently only detects versions for BIND nameservers. |
| No Stealth NS Record Leakage | | This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records
listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the
stealth NS records in response to other queries. |
| Test Name | Result | Details |
|---|
| SOA Record | INFO | From beth.ns.cloudflare.com. (TTL: 86400)
Primary nameserver: beth.ns.cloudflare.com.
Hostmaster E-mail address: dns.cloudflare.com.
Serial #: 2020096807
Refresh: 10000
Retry: 2400
Expire: 604800
Default TTL: 3600 |
| Nameserver Agreement on SOA Number | PASS | igor.ns.cloudflare.com.: 2020096807
beth.ns.cloudflare.com.: 2020096807 All your nameservers should agree on your SOA serial number. That means that all your nameservers are using the
same data (unless you have different sets of data with the same serial number, which would be very bad)! If you recently updated your
zone file it may take some time for the changes to propogate to all of your servers. |
| SOA MNAME | PASS | Your SOA record states that your master (primary) name server is: beth.ns.cloudflare.com. This is legal, but you should be sure that you know what you are doing. |
| SOA RNAME | INFO | dns@cloudflare.com This is your DNS contact e-mail address, formatted as a normal e-mail address. |
| SOA Serial Number Format | PASS | The recommended format 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. |
| SOA Refresh Time | PASS | 10000 seconds RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily
increase Internet traffic. |
| SOA Retry Time | PASS | 2400 seconds This is normally 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. |
| SOA Expire Time | WARN | 604800 seconds About 1209600 to 2419200 seconds (2-4 weeks) is good. RFC1912 suggests 2-4 weeks. This is how long a
secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver. |
| SOA Minimum TTL | PASS | 3600 seconds About 3600 to 86400 seconds (1-24 hours) is good. RFC2308 suggests a value of 1-3 hours. This value used to
determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching. |
| Test Name | Result | Details |
|---|
| MX Record | WARN | You should have MX records for your domain so that if anyone needs to contact you for administrative reasons via e-mail they can. |
| Low Port Number | | Our local DNS server that uses a low port number can get your MX record. Some DNS servers are behind firewalls that block low
port numbers. This does not guarantee that your DNS server does not block low ports (this specific lookup must be cached), but is a good
indication that it does not. |
| Valid MX Hostnames | PASS | This checks for invalid characters in your MX hostnames. |
| Mail Exchanger A Records Exist | PASS | IPs are cached. All of your Mail Exchanger hostnames need to have A
records. Without A records, you will not be able to receive e-mail. Sometimes a
'dummy' record is added to prevent SPAM, e-mail should automatically retry delivery to
other available Mail Exchangers. |
| MX IPs Public | PASS | IPs are cached. All of your MX records should use public IPs. If there were any private
IPs, they would not be reachable, causing slight mail
delays, extra resource usage, and possibly bounced mail. |
| No MX Queries Return CNAMEs | PASS | Results are cached. If an MX record query returns a CNAME, extra processing is required,
and some mail servers may not be able to handle it. |
| No Mail Exchanger Hostnames are CNAMEs | PASS | CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3. |
| Mail Exchanger is Hostname | PASS | All of your MX records should be host names (as opposed to IP addresses, which are not allowed in MX records). |
| Multiple MX Records | WARN | You should have multiple MX records. This means that if one is down or unreachable, the other(s) will be able to accept mail for
you. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you. In the past,
mailservers would usually re-try E-mail for up to 48 hours. But many now only re-try for a couple of hours. If your primary mailserver
is very reliable (or can be fixed quickly if it goes down), having just one mailserver may be acceptable. |
| No Duplicate MX Records | PASS | You should not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can
cause a lot of confusion, and waste resources. |
| PTR records for Mail Exchanger IPs | PASS | RFC1912 2.1 says you should have a reverse DNS (PTR) 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. Note that this information is cached, so if you changed it
recently, it will not be reflected here. |
| SPF Record | INFO | TXT: "NO RECORD"
SPF: "NO RECORD" SPF records will help prevent spammers from abusing
your domain. Without 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). RFC 7208 section 3.1 states that you MUST have only a TXT record type, SPF is no longer valid as it was described in RFC 4408. If you are not
using this domain for e-mail, you can simply add the following TXT
record:"v=spf1 -all" |
| DMARC Record | INFO | TXT: "NO RECORD" DMARC records will help prevent spammers from abusing
your domain. A DMARC record allows you to instruct mail servers to quarantine or reject emails based on your
SPF and DKIM configuration. You should have both SPF and DKIM configured before you setup this record. |
NOTE: This doesn't actually verify any signatures in DNS. It just makes sure that a real
DNS resolver has everything it needs to validate the signatures for your domain. This does not verify the entire
trust chain!
| Test Name | Result | Details |
|---|
| Parent DS or DLV | FAIL | No DLV record at dlv.isc.org.
No DS record at parent a.gtld-servers.net. (DLV cached) RFC 4035 states that a DS record should be present at the parent of a child zone. A non-DLV
enabled name server will not be able to resolve if no parent DS record exists. Many parent zones do not
allow for a DS record yet, so you may not be able to fix this. ISC provides a mechanism to sign up for
DLV. It is still possible for a resolving server to manually trust the key for your domain, but you shouldn't rely on
this. |
| Signed DS | PASS | RFC 4035 states that all DS RRsets in a zone MUST be signed. |
| No DS at Domain Nameservers | PASS | RFC 4035 states that DS RRsets MUST NOT appear at a zone's apex. |
| Domain DNSKEY Record Exists | FAIL | DNSKEY must exist to verify signatures (RFC 4035). This indicates the public keys used to sign your domain. |
| DS/DLV Signature Valid | PASS | Your parent server needs to have the correct hash of your public key. Without this information being correct,
anyone that uses the parent as a trust root will not be able to access your domain. Because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur. |
| Domain NSEC Record Exists | WARN | RFC 4035 states that you MUST have an NSEC record present. This allows for signing of negative responses, such as when
a host does not exist. NSEC is more interoperable than NSEC3. Not using NSEC means some
resolving name servers might not be able to access resources on your domain. |
| Domain NSEC3PARAM Record Exists | FAIL | NSEC3PARAM record present. This allows for signing of negative
responses, such as when a host does not exist. You must have either a NSEC or NSEC3PARAM
record. |
| Domain NSEC3 Record Matches SOA minimum TTL | PASS | RFC 5155 states that the NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field. |
| Unsigned Parent NS Records | PASS | According to RFC 4035, NS records must NOT be signed at the parent nameservers by the child domain. |
| Signed NS Records | WARN | dictzone.com. 86400 IN NS igor.ns.cloudflare.com.
dictzone.com. 86400 IN NS beth.ns.cloudflare.com. According to RFC 4035, NS records must be signed at the domain nameservers. This is required for further
testing. |
| NS and DS Matching TTL | PASS | According to RFC 4035, the TTL for NS records at the parent should match the DS TTL. |
| Domain Record Valid Dates | PASS | Signed NS records expire after a certain amount of time, usually 30 days. If this time has passed the records are no longer
valid. Usually all you need to do is sign your zone file again if this fails. |
