[ExchangeList] Re: How to Clear Up Queues (and solve some of my problems!)

John,

 

Here is the DNS report for your domain thompsonig.com.  Hopefully this will 
help.

 

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:

ns1.acomhosting.com. [69.25.72.105] [TTL=172800] [US]
ns2.acomhosting.com. [69.25.72.106] [TTL=172800] [US]
[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.

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:

ns1.acomhosting.com. [69.25.72.105] [TTL=86400]
ns2.acomhosting.com. [69.25.72.106] [TTL=86400]

FAIL

Open DNS servers

ERROR: One or more of your nameservers reports that it is an open DNS server. 
This usually means 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. Problem 
record(s) are:

Server 69.25.72.105 reports that it will do recursive lookups. [test 
<http://www.dnsstuff.com/tools/lookup.ch?domain=www.DNSstuff.com&server=69.25.72.105>
 ] Server 69.25.72.106 reports that it will do recursive lookups. [test 
<http://www.dnsstuff.com/tools/lookup.ch?domain=www.DNSstuff.com&server=69.25.72.106>
 ] See this page <http://member.dnsstuff.com/info/opendns.php>  for info on 
closing 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 2 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 2 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 thompsonig.com. RFC1912 
<http://www.DNSstuff.com/pages/rfc1912.htm>  2.4 and RFC2181 
<http://www.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://www.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.

WARN

Nameservers on separate class C's

WARNING: All of your nameservers (listed at the parent nameservers) are in the 
same Class C (technically, /24) 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 <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.

WARN

Single Point of Failure

WARNING: Although you have at least 2 NS records, they may both point to the 
same server (one of our two tests shows them being the same, the other does 
not), which would result in a single point of failure. You are required to have 
at least 2 nameservers per RFC 1035 <http://www.DNSstuff.com/pages/rfc1035.htm> 
 section 2.2. 

INFO

Nameservers versions

[For security reasons, this test is limited to members]

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=86400] is:

Primary nameserver: ns1.acomhosting.com.
Hostmaster E-mail address: service.acomhosting.com.
Serial #: 2005011497
Refresh: 10800
Retry: 3600
Expire: 604800
Default TTL: 86400

PASS

NS agreement on SOA serial #

OK. All your nameservers agree that your SOA serial number is 2005011497. 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: ns1.acomhosting.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: service@xxxxxxxxxxxxxxxx (techie note: we have changed the initial 
'.' to an '@' for display purposes). 

PASS

SOA Serial Number

OK. Your SOA serial number is: 2005011497. 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 14 Jan 2005 (and was revision #97). This 
number must be incremented every time you make a DNS change.

PASS

SOA REFRESH value

OK. Your SOA REFRESH interval is : 10800 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 : 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 
<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: 86400 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:

5 exchangesrvr.thompsonig.com. [TTL=86400] IP=67.108.89.73 [TTL=86400] [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://www.dnsstuff.com/tools/rfc.ch?detail=1034>  3.6.2, RFC1912 
<http://www.dnsstuff.com/tools/rfc.ch?detail=1912>  2.4, and RFC2181 
<http://www.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:

73.89.108.67.in-addr.arpa static-67-108-89-73.wig.tcwireless.us. 
<http://www.DNSstuff.com/tools/ptr.ch?ip=67.108.89.73>  [TTL=38400] 

 

Mail

PASS

Connect to mail servers

OK: I was able to connect to all of your mailservers.

PASS

Mail server host name in greeting

OK: All of your mailservers have their host name in the greeting:

exchangesrvr.thompsonig.com:<br />    220 exchangesrvr.thompsonig.com Microsoft 
ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Sat, 20 Oct 2007 08:53:17 
-0400 <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 postmaster@xxxxxxxxxxxxxx (as 
required by RFC822 <http://www.DNSstuff.com/pages/rfc822.htm>  6.3, RFC1123 
<http://www.dnsstuff.com/tools/rfc.ch?detail=1123>  5.2.7, and RFC2821 
<http://www.dnsstuff.com/tools/rfc.ch?detail=2821>  4.5.1).

PASS

Acceptance of abuse address

OK: All of your mailservers accept mail to abuse@xxxxxxxxxxxxxxx

INFO

Acceptance of domain literals

WARNING: 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 
<http://www.DNSstuff.com/pages/rfc1123.htm>  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 
(mailservers at many common large domains have this problem).

exchangesrvr.thompsonig.com's postmaster@[67.108.89.73] response:<br /> >>> 
RCPT TO:<postmaster@[67.108.89.73]><br /> <<< 550 5.7.1 Unable to relay for 
postmaster@[67.108.89.73] <br /> 

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> .

exchangesrvr.thompsonig.com OK: 550 5.7.1 Unable to relay for 
Not.abuse.see.www.DNSreport.com.from.IP.206.192.63.161@xxxxxxxxxxxxx <br />

PASS

SPF record

You have an SPF record <http://www.openspf.org> . This is very good, as it will 
help prevent spammers from abusing your domain. Your SPF record (I don't check 
to see if it is well designed!) is:
"v=spf1 ip4:67.108.89.73 ~all" [TTL=86400] 

 

WWW

INFO

WWW Record

Your www.thompsonig.com A record is:

www.thompsonig.com. A 69.25.72.149 [TTL=86400] [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.thompsonig.com, which is good.

INFO

Domain A Lookup

Your thompsonig.com A record is:

thompsonig.com. A 69.25.72.149 [TTL=86400]

 



Legend:

*       Rows with a FAIL indicate a problem that in most cases really should be 
fixed. 
*       Rows with a WARN indicate a possible minor problem, which often is not 
worth pursuing. 
*       Note that all information is accessed in real-time (except where 
noted), so this is the freshest information about your domain. 
*       Note that automated usage is not tolerated; please only view the DNS 
report directly with your web browser.

 

 

From: exchangelist-bounce@xxxxxxxxxxxxx 
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Gabriel E. Rincon
Sent: Saturday, October 20, 2007 7:43 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: How to Clear Up Queues (and solve some of my 
problems!)

 

John,

 

The likely problem with yahoo & hotmail& gmail Is that it will use reverse 
lookup to ensure that the email is coming from a legit domain address.

 

For example, if you go to dnsstuff.com and put in your domain name to check 
that all your dns records are correct, you will likely notice that the reverse 
entry for the mail.mydomain.com is probably not there, or providing erroneous 
info.

 

If you are authoiritative for your domain (you control all of your DNS 
records), you need to make sure that the reverse zone (in my case 
63.192.206-in-addr-arpa zone file) has an entry for the mx record.

 

It could also be that your ISP (if you are not your ISP) will have to enter a 
record in their reverse zone file to recoird your MX record properly.

 

Hope this helps

 

Gabe Rincón

Computer Technologies 

225-293-2844

 

From: exchangelist-bounce@xxxxxxxxxxxxx 
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of John L. Gitzen II
Sent: Saturday, October 20, 2007 4:53 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: How to Clear Up Queues (and solve some of my 
problems!)

 

Simon, 

 

Thank you for the quick response.  I started the process to set up SMTP 
connectors, but my process kept failing because of authorization.  As it turns 
out I had two different problems with my DNS setup.  Please note that DNS 
primary runs on the DC which I did not set up.  It was configured to not allow 
Recursion, so my Exchange Server could never get external server address to 
connect the SMTP connectors with.  Once that was corrected my email started 
flowing.  

 

The problem I was having with setting up the SMTP connectors was also likely a 
DNS issue.  I had started to install DNS on my Exchange Server setting it up as 
a Secondary zone with replication from the primary DNS, but once I got into the 
wizard I got scared and cancelled the installation.  This left DNS defined to 
my server but not replicating.  It had no entries, including pointers to my own 
DC where my active directory also resides, so the wizard to define the SMTP 
connector failed every time because the AD check failed to even find the AD 
server.

 

Almost all of my email is now flowing in and out just great - except to my 
yahoo.com email address.  Since I use this address a lot to test and I initiate 
a lot of email from it, I would like to get this corrected, so I am considering 
the SMTP Connector route for this one domain.  I posted an inquiry on 
yahoo.com's Contact Us link but I don't expect any amazing solutions from them.

 

Has anyone ever had this problem and how did you approach the vendor?  I think 
my site or my personal email address may be on yahoo.com's grey list, but I 
have no way to prove it.  I know that the Troubleshooting Assistant shows the 
email leaving my site and going to mta300.mail.mud.yahoo.com, but that is as 
far as I can tell it gets.  Also be advised that earlier yesterday I was able 
send and receive from my yahoo.com email address

 

Thanks

John 
Technology Applied  

-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx 
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Simon Butler
Sent: Wednesday, October 17, 2007 5:21 AM
To: 'exchangelist@xxxxxxxxxxxxx'
Subject: [ExchangeList] Re: How to Clear Up Queues (and solve some of my 
problems!)

 

Quick way to deal with those messages while you wait for the DNS to clear is to 
setup an SMTP connector to route email via your ISPs SMTP server. 

http://www.amset.info/exchange/smtp-connector.asp 

 

Also don't forget that the retry times for Exchange increase over time, so the 
longer it goes the more time between retries. However setup an SMTP Connector 
and the messages will be gone. 

 

Finally - it isn't really the MX record that is causing the problem - but PTR 
(aka reverse DNS) records. You need to speak to your ISP about those. Ideally 
you should have the server announcing itself as the same name as on the reverse 
DNS. Your current reverse DNS record looks like a dynamic allocation, so 
messages will get rejected. 

 

Simon. 

 

 

--
Simon Butler
MVP: Exchange, MCSE
Amset IT Solutions Ltd.

e: simon@xxxxxxxxxxx
w: www.amset.co.uk
w: www.amset.info

Need cheap certificates for Exchange, compatible with Windows Mobile 5.0?
Go to http://www.certificatesforexchange.com/ for certificates for just $20 a 
year. 

 

 

 

________________________________

From: exchangelist-bounce@xxxxxxxxxxxxx 
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of John L. Gitzen II
Sent: 17 October 2007 07:57
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] How to Clear Up Queues (and solve some of my problems!)

Hello Exchange Experts!

 

I have over 100 queues with SMTP Connector Entries for outgoing mail that is 
not making it to their intended recipients.  I have had some problems with my 
DNS records and understanding how DNS works with my external webhosting company 
and also my Internet Provider.  I hope I have those correctly set now, but with 
the lag in DNS records being refreshed and then Email servers recognizing the 
changes I am frustrated to say the least waiting to see if my email problems 
will clear up.

 

At this point I can not send out email from a user on my Exchange server to any 
of the addresses I can query on - yahoo.com, gmail.com, Comcast.net or 
charter.net.  They all sit waiting on the remote server to respond.  

 

So two questions - 

 

1.      How do I clear up these SMTP connector entries?  Being an old school 
mainframer, I am used to getting error messages, being able to look them up to 
find the root cause and having tools I can run to tell what is going on.  If 
they are available for Exchange they are pretty well hidden.  The closest I can 
find is the Troubleshooting Assistant, but in my case it is not giving me back 
anything I can use.  On my last pass it told me that it had a fatal error 
accessing active directory. 

a.      The two corrections listed were to try connecting to exchange server 
analyzer without specifying a domain controller.  I don't see where the tool 
ever asks for a domain controller.  Under advanced login options I could 
specify a domain, but I don't use the advanced login, the id I am logged on 
with is as high up in our Active Directory as you can get.  I specify an 
Exchange Server name and a Global Catalog Server Name.  It won't run without 
these. 

b.      The other possible solution says to specify a domain controller that is 
running and is available to you.  I only have 1 domain controller, it is 
running, and it is available to me.  I checked Active Directory on it and it is 
working.  I have accessed the Exchange portions of the Active Directory Users 
on the same server, which is my exchange server that I am running my test on.  
I have tried to reboot both servers -  AAARGGH - Nothing changed, the same 
results.   

c.      Regardless of this lame solution, I have reason to believe my outgoing 
email is not making it to their intended SMTP connectors because the DNS MX 
record at the site hosting my domain was pointing to mail.thompsonig.com 
instead of exchangesrvr.thompsonig.com.  The email going out was coming from 
exchangesrvr.thompsonig.com, but when the servers to a DNS lookup on 
thompsonig.com, it was finding mail.thompsonig.com.  
exchangesrvr.thompsonig.com would match the *.thompsonig.com A record that 
pointed to the web hosting IP address and not the ip address for my Exchange 
Server.  So now that this is fixed - how do I get my outgoing email moving 
again and this stuff cleaned up  

 

2.      Second, is there a way I can test DNS and Email changes without having 
to wait 24 to 48 hours?  This is an eternity when you have the whole company 
breathing down your back. 

 

My domain is thompsonig.com.  my ip address for my email server should be 
67.108.89.73.  my Exchange server FQDN is exchangesrvr.thompsonig.com.

 

Any and all advice is appreciated.  Sorry for the long winded email, it is late.

John 
Technology Applied 

The more I learn the more I realize I don't know!

Other related posts: