DNS Report for pupman.com

Generated by http://www.dnsreport.com/ at 00:27:11 GMT on 20 Sep 2003.
Category Status Test Name Information
Parent PASS Missing Parent check OK. Your parent zone exists, which is good. Some domains (usually third or fourth level domains, such as example.co.us) do not have a parent zone ('co.us' in this example), which is legal but can cause confusion.
INFO NS records at parent servers Your NS records at the parent servers are:
york.jymis.com. [] [TTL=172800]
dick.jymis.com. [] [TTL=172800]
ns2.rmpg.org. [ (NO GLUE)]
[These were obtained from h.gtld-servers.net]
PASS Parent nameservers have your nameservers listed OK. 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. But you are listed there, with 3 entries.
WARN Glue at parent nameservers WARNING. The parent servers (h.gtld-servers.net.) 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 (, which can cause slightly slower connections, and may cause some incompatibilities with some programs (if the programs are not fully RFC-compliant). This behavior is allowed by 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.co.uk" 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.
NS INFO NS records at your nameservers Your NS records at your nameservers are:
ns2.rmpg.org. [TTL=3600]
ns3.rmpg.org. [TTL=3600]
WARN All nameservers report identical NS records WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).
PASS All nameservers respond OK. All of your nameservers listed at the parent nameservers responded.
PASS Nameserver name validity OK. All of the NS records that your nameservers report seem valid (no IPs or partial domain names).
PASS Number of nameservers OK. You have 3 nameservers. You must have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers), and preferably no more than 7.
PASS Lame nameservers OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
WARN Missing (stealth) nameservers WARNING: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly.
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:
PASS No CNAMEs for domain OK. There are no CNAMEs for pupman.com. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Note that I only checked pupman.com, I did not check the NS records, which should not have CNAMEs either.
PASS No NSs with CNAMEs OK. There are no CNAMEs for your NS records. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
WARN Nameservers on separate class C's WARNING: All of your nameservers (listed at the parent nameservers) are in the same Class C address space, which means that they are probably at the same physical location. 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. [If the parent servers have no glue for your domain, this could be a false positive.]
INFO Nameservers versions Your nameservers have the following versions: 9.1.0 9.2.1 9.1.0
SOA INFO SOA record Your SOA record [TTL=900] is:
Primary nameserver: dick.jymis.com.
Hostmaster E-mail address: cdmcj.dick.jymis.com.
Serial #: 2003082900
Refresh: 10800
Retry: 3600
Expire: 604800
Default TTL: 86400
FAIL NS agreement on SOA Serial # ERROR: Your nameservers disagree as to which version of your DNS is the latest! 2003082801 versus 2003082900! 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 2003082900 is the correct serial #.
PASS SOA MNAME Check OK. Your SOA (Start of Authority) record states that your master (primary) name server is: dick.jymis.com.. That server is listed at the parent servers, which is correct.

PASS SOA RNAME Check OK. Your SOA (Start of Authority) record states that your DNS contact E-mail address is: cdmcj@dick.jymis.com. (techie note: we have changed the initial '.' to an '@' for display purposes).
PASS SOA Serial Number OK. Your SOA serial number is: 2003082900. This appears to be in the recommended format of YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.
WARN 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.
PASS SOA RETRY value OK. Your SOA RETRY interval is : 3600 seconds. This seems normal (about 120-7200 seconds is good). 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.
PASS SOA EXPIRE value OK. Your SOA EXPIRE time: 604800 seconds. This seems normal (about 1209600 to 2419200 seconds (2-4 weeks) is good). RFC1912 recommends 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.
PASS SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: 86400 seconds. This seems normal (about 60 to 86400 seconds or 1-24 hours is good). RFC1912 2.2 recommends 1-5 days (86400 to 432000) unless you are about to change DNS entries. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
MX INFO MX Record Your 3 MX records are:
5  pupman.com. [TTL=3600]  IP= [TTL=3600]
10  mail.jymis.com. [TTL=3600]  IP= [CNAME]
20 york.jymis.com. [TTL=3600] IP= (No Glue) [TTL=810]
WARN MX records are not CNAMEs WARNING: When I looked up your MX record, your DNS server returned a CNAME. This is an unusual situation, and I can't handle it -- the following MX tests may not work properly. The problem is:
WARN MX A lookups have no CNAMEs WARNING: One or more of your MX records did not return an A record; most likely, they have a CNAME. CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3. The problem MX records are:
PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records).
PASS Multiple MX records OK. You have multiple MX records. This means that if one is down or unreachable, the other(s) will be able to accept mail for you.
FAIL Reverse DNS entries for MX records ERROR: 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: [No reverse DNS entry (rcode: 3 ancount: 1)]
Mail FAIL Connect to mail servers ERROR: I could not connect to one or more of your mailservers:
pupman.com: Timed out [Last data sent: QUIT ]
york.jymis.com: Timed out [Last data sent: QUIT ]
WARN Mail server host name in greeting WARNING: One or more of your mailservers claims 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 is a technical violation of RFC821 4.3.
mail.jymis.com claims to be host dick.jymis.com.
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@pupman.com (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1).
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@pupman.com.
PASS Acceptance of domain literals OK: All of your mailservers accept mail in the domain literal format (user@[]).
PASS Open relay test OK: All of your mailservers appear to be closed to relaying.
mail.jymis.com OK: 550 5.7.1 ... Relaying denied
WWW INFO WWW Record Your www.pupman.com A record is:
www.pupman.com.  A [TTL=3600]
PASS CNAME Lookup OK. Some domains have a CNAME record for their WWW server that requires an extra DNS lookup, which slightly delays the initial access to the website and use extra bandwidth. There are no CNAMEs for www.pupman.com, which is good.