Post by CameronI've done that...about 6 days ago. I set it up to point to
mail.bstastjohns.com and of course changed the A record for
mail.bstastjohns.com to the current IP. Do I need to set up TXT
records or add a PTR or is that more than I need?
Here is what is showing
www.DNSreport.com <http://www.DNSreport.com> at 15:04:27 GMT
on 15 Jan 2008.
Category Status Test Name Information
Parent *PASS* Missing Direct Parent check OK. Your direct parent zone
exists, which is good. 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.
*INFO* NS records at parent servers Your NS records at the parent
servers are:
|dns010.d.register.com. [216.21.236.10] [TTL=172800] [US]
dns029.c.register.com. [216.21.235.29] [TTL=172800] [US]
dns062.b.register.com. [216.21.232.62] [TTL=172800] [US]
dns213.a.register.com. [216.21.231.213] [TTL=172800] [US]
|[These were obtained from c.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.
*PASS* Glue at parent nameservers OK. The parent servers have glue for
your nameservers. That means they send out the IP address of your
nameservers, as well as their host names.
*PASS* DNS servers have A records OK. All your DNS servers 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.
NS *INFO* NS records at your nameservers Your NS records at your
nameservers are:
|dns213.a.register.com.
dns062.b.register.com.
dns029.c.register.com.
dns010.d.register.com.
|
*PASS* Open DNS servers OK. Your DNS servers do not announce that they
are open DNS servers. Although there is a slight chance that they really
are open DNS servers, this is very unlikely. Open DNS servers increase
the chances that of cache poisoning, can degrade performance of your
DNS, and can cause your DNS servers to be used in an attack (so it is
good that your DNS servers do not appear to be open DNS servers).
*PASS* Mismatched glue OK. The DNS report did not detect any
discrepancies between the glue provided by the parent servers and that
provided by your authoritative DNS servers.
*PASS* No NS A records at nameservers OK. Your nameservers do 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.
*PASS* All nameservers report identical NS records OK. The NS records
at all your nameservers are identical.
*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 4 nameservers. You must have
at least 2 nameservers (RFC2182
<http://www.DNSstuff.com/pages/rfc2182.htm> 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.
*PASS* Missing (stealth) nameservers OK. All 4 of your nameservers (as
reported by your nameservers) are also listed at the parent servers.
*PASS* Missing nameservers 2 OK. All of the nameservers listed at the
parent nameservers are also listed as NS records at your nameservers.
*PASS* No CNAMEs for domain OK. There are no CNAMEs for
bstastjohns.com. RFC1912 <http://www.DNSstuff.com/pages/rfc1912.htm> 2.4
and RFC2181 <http://private.dnsstuff.com/tools/rfc.ch?detail=2181> 10.3
state that there should be no CNAMEs if an NS (or any other) record is
present.
*PASS* No NSs with CNAMEs OK. There are no CNAMEs for your NS records.
RFC1912 <http://www.DNSstuff.com/pages/rfc1912.htm> 2.4 and RFC2181
<http://private.dnsstuff.com/tools/rfc.ch?detail=2181> 10.3 state that
there should be no CNAMEs if an NS (or any other) record is present.
*PASS* Nameservers on separate class C's OK. You have nameservers on
different Class C (technically, /24) IP ranges. You must have
nameservers at geographically and topologically dispersed locations.
RFC2182 <http://www.DNSstuff.com/pages/rfc2182.htm> 3.1 goes into more
detail about secondary nameserver location.
*PASS* All NS IPs public OK. All of your NS records appear to use
public IPs. If there were any private IPs, they would not be reachable,
causing DNS delays.
*PASS* TCP Allowed OK. All your DNS servers allow TCP connections.
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.
*INFO* Nameservers versions Your nameservers have the following versions:
216.21.236.10: "Register.com Basic DNS - New York, NY 0x0d"
216.21.235.29: "Register.com Basic DNS - Phoenix, AZ 0x0a"
216.21.232.62: "Register.com Basic DNS - Phoenix, AZ 0x0a"
216.21.231.213: "Register.com Basic DNS - New York, NY 0x0c"
*PASS* Stealth NS record leakage Your DNS servers do not leak any
stealth NS records (if any) in non-NS requests.
SOA *INFO* SOA record Your SOA record [TTL=14400] is:
|Primary nameserver: dns213.a.register.com.
Hostmaster E-mail address: root.register.com.
Serial #: 2007041017
Refresh: 28800
Retry: 7200
Expire: 604800
Default TTL: 14400
|
*PASS* NS agreement on SOA Serial # OK. All your nameservers agree
that your SOA serial number is 2007041017. 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)! Note that
the DNSreport only checks the NS records listed at the parent servers
(not any stealth servers).
*PASS* SOA MNAME Check OK. Your SOA (Start of Authority) record states
that your *master* (primary) name server is: *dns213.a.register.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: ****@register.com.* (techie
note: we have changed the initial '.' to an '@' for display purposes).
*PASS* SOA Serial Number OK. Your SOA serial number is: *2007041017*.
This appears to be in the recommended format of YYYYMMDDnn, where 'nn'
is the revision. So this indicates that your DNS was last updated on 10
Apr 2007 (and was revision #17). This number *must* be incremented every
time you make a DNS change.
*PASS* SOA REFRESH value OK. Your SOA REFRESH interval is : *28800
seconds*. This seems normal (about 3600-7200 seconds is good if not
using DNS NOTIFY; RFC1912 <http://www.DNSstuff.com/pages/rfc1912.htm>
2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12
hours)). This value determines how often secondary/slave nameservers
check with the master for updates.
*PASS* SOA RETRY value OK. Your SOA RETRY interval is : *7200
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 <http://www.DNSstuff.com/pages/rfc1912.htm> 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.
*PASS* SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: *14400
seconds*. This seems normal (about 3,600 to 86400 seconds or 1-24 hours
is good). RFC2308 <http://www.DNSstuff.com/pages/rfc2308.htm> 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.
MX *INFO* MX Record Your 1 MX record is:
|0 mail.bstastjohns.com. [TTL=14400] IP=71.86.114.51 [TTL=14400] [US]
|
*PASS* Low port test OK. 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.
*PASS* Invalid characters OK. All of your MX records appear to use
valid hostnames, without any invalid characters.
*PASS* All MX IPs public OK. All of your MX records appear to 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.
*PASS* MX records are not CNAMEs OK. Looking up your MX record did not
just return a CNAME. If an MX record query returns a CNAME, extra
processing is required, and some mail servers may not be able to handle it.
*PASS* MX A lookups have no CNAMEs OK. There appear to be no CNAMEs
returned for A records lookups from your MX records (CNAMEs are
prohibited in MX records, according to RFC974
<http://www.DNSstuff.com/pages/rfc974.htm>, RFC1034
<http://private.dnsstuff.com/tools/rfc.ch?detail=1034> 3.6.2, RFC1912
<http://private.dnsstuff.com/tools/rfc.ch?detail=1912> 2.4, and RFC2181
<http://private.dnsstuff.com/tools/rfc.ch?detail=2181> 10.3).
*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).
*INFO* Multiple MX records NOTE: 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. 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.
*PASS* Differing MX-A records OK. I did not detect differing IPs for
your MX records (this would happen if your DNS servers return different
IPs than the DNS servers that are authoritative for the hostname in your
MX records).
*PASS* Duplicate MX records OK. You do 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.
*PASS* Reverse DNS entries for MX records OK. The IPs of all of your
mail server(s) have reverse DNS (PTR) entries. RFC1912
<http://www.DNSstuff.com/pages/rfc1912.htm> 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. Note that this information is /cached/, so if
you changed it recently, it will not be reflected here (see the
www.DNSstuff.com Reverse DNS Tool <http://www.dnsstuff.com> for the
current data). The reverse DNS entries are:
| 51.114.86.71.in-addr.arpa 71-86-114-51.dhcp.ftwo.tx.charter.com.
<http://www.DNSstuff.com/tools/ptr.ch?ip=71.86.114.51> [TTL=86400]
|
Mail *PASS* Connect to mail servers OK: I was able to connect to all
of your mailservers.
*WARN* Mail server host name in greeting WARNING: One or more of your
mailservers is 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). If your mailserver sends out E-mail using this
domain in its EHLO or HELO, your E-mail might get blocked by anti-spam
software. This is also a technical violation of RFC821
<http://www.DNSstuff.com/pages/rfc821.htm> 4.3 (and RFC2821
<http://private.dnsstuff.com/tools/rfc.ch?detail=2821> 4.3.1). Note that
the hostname given in the SMTP greeting should have an A record pointing
back to the same server. Note that this one test may use a cached DNS
record.
|mail.bstastjohns.com claims to be host mail.dot11net.com [but that host
is at 69.56.171.162 (may be cached), not 71.86.114.51]. <br />|
*PASS* Acceptance of NULL <> sender OK: All of your mailservers accept
mail from "<>". You are required (RFC1123
<http://www.DNSstuff.com/pages/rfc1123.htm> 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 ***@bstastjohns.com (as required by RFC822
<http://www.DNSstuff.com/pages/rfc822.htm> 6.3, RFC1123
<http://private.dnsstuff.com/tools/rfc.ch?detail=1123> 5.2.7, and
RFC2821 <http://private.dnsstuff.com/tools/rfc.ch?detail=2821> 4.5.1).
*WARN* Acceptance of abuse address WARNING: One or more of your
mailservers does not accept mail to ***@bstastjohns.com. Mailservers
are expected by RFC2142 <http://www.DNSstuff.com/pages/rfc2142.htm> to
accept mail to abuse.
|mail.bstastjohns.com's abuse response:<br /> >>> RCPT
TO:<***@bstastjohns.com><br /> <<< 511 sorry, no mailbox here by that
name (#5.1.1 - chkuser) <br /> |
*PASS* Acceptance of domain literals OK: All of your mailservers
accept mail in the domain literal format (user@[71.86.114.51]).
*PASS* Open relay test OK: All of your mailservers appear to be closed
to relaying. This is /not/ a thorough check, you can get a thorough one
here <http://www.abuse.net/relay.html>.
|mail.bstastjohns.com OK: 553 sorry, that domain isn't in my list of
allowed rcpthosts (#5.5.3 - chkuser) <br />|
*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
<http://www.openspf.org> 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).
WWW
*INFO* WWW Record Your www.bstastjohns.com A record is:
|www.bstastjohns.com. A 69.56.205.29 [TTL=14400] [US]
|
*PASS* All WWW IPs public OK. All of your WWW IPs appear to be public
IPs. If there were any private IPs, they would not be reachable, causing
problems reaching your web site.
*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.bstastjohns.com, which is good.
*FAIL* *Domain A Lookup* ERROR: I couldn't find any A records for
bstastjohns.com. But I did find a referral to www.bstastjohns.com. (and
maybe others). If you want a website at bstastjohns.com (as well as
www.bstastjohns.com), you will need an A record for bstastjohns.com. If
you do not want a website at bstastjohns.com, you can ignore this error.