cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8936
Views
5
Helpful
12
Replies

Issue sending e-mails to certain domain

doug.dockter
Level 1
Level 1

I'm having an issue sending e-mails to domain capitaliii.com from my Ironport.  I see the following message in the Ironport log.

"DNS Temporary Failure capitaliii.com MX - unable to reach nameserver on any valid IP"

When I issue a nslookup on the MX record from the Ironport, I get the below message.

Temporary query error:  "unable to reach nameserver on any valid IP" looking up A record for "capitaliii.com" to nameserver
ns3.digipark.com


I can however do a successful a successful nslookup from my workstation.  See the results below.  Any ideas?  I've done
a flushdns on the Ironport to no avail.

Non-authoritative answer:

capitaliii.com  MX preference = 10, mail exchanger = mail1.digipark.com

mail1.digipark.com      internet address = 64.111.26.141
12 Replies 12

Jeronimo Orona
Level 1
Level 1

Hello Doug,

This may just be an issue with the DNS servers that your IronPort is configured to query. Are you using root(default setting) DNS servers or are have you configured your appliance to query internal servers?

Regards,

-Jerry Orona

My IronPort is set to the default - use root DNS servers.

Hello Doug,

check if your firewall in front of the IronPort appliance allows TCP for DNS on port 53.  The query results I get are close to the 512 byte limit, where DNS switches from UDP to TCP:

cisco$  dig mx capitaliii.com +trace

; <<>> DiG 9.6-ESV-R4-P3 <<>> mx capitaliii.com +trace

;; global options: +cmd

.                       274955  IN      NS      f.root-servers.net.

.                       274955  IN      NS      g.root-servers.net.

.                       274955  IN      NS      h.root-servers.net.

.                       274955  IN      NS      i.root-servers.net.

.                       274955  IN      NS      j.root-servers.net.

.                       274955  IN      NS      k.root-servers.net.

.                       274955  IN      NS      l.root-servers.net.

.                       274955  IN      NS      m.root-servers.net.

.                       274955  IN      NS      a.root-servers.net.

.                       274955  IN      NS      b.root-servers.net.

.                       274955  IN      NS      c.root-servers.net.

.                       274955  IN      NS      d.root-servers.net.

.                       274955  IN      NS      e.root-servers.net.

;; Received 260 bytes from xxx.xxx.xxx.xxx in 189 ms

com.                    172800  IN      NS      a.gtld-servers.net.

com.                    172800  IN      NS      b.gtld-servers.net.

com.                    172800  IN      NS      c.gtld-servers.net.

com.                    172800  IN      NS      d.gtld-servers.net.

com.                    172800  IN      NS      e.gtld-servers.net.

com.                    172800  IN      NS      f.gtld-servers.net.

com.                    172800  IN      NS      g.gtld-servers.net.

com.                    172800  IN      NS      h.gtld-servers.net.

com.                    172800  IN      NS      i.gtld-servers.net.

com.                    172800  IN      NS      j.gtld-servers.net.

com.                    172800  IN      NS      k.gtld-servers.net.

com.                    172800  IN      NS      l.gtld-servers.net.

com.                    172800  IN      NS      m.gtld-servers.net.

;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 23 ms

capitaliii.com.         172800  IN      NS      ns4.digipark.com.

capitaliii.com.         172800  IN      NS      ns3.digipark.com.

;; Received 109 bytes from 192.55.83.30#53(m.gtld-servers.net) in 50 ms

capitaliii.com.         86400   IN      MX      10 mail1.digipark.com.

capitaliii.com.         86400   IN      NS      ns3.digipark.com.

capitaliii.com.         86400   IN      NS      ns4.digipark.com.

;; Received 147 bytes from 64.111.26.135#53(ns4.digipark.com) in 148 ms

Hope that helps,

Andreas

I’ve made the below change on my ASA, but that doesn’t seem to have helped.

policy-map global_policy

class inspection_default

inspect dns maximum-length 4096

I had a similiar problem, it was an issue on our border routers.  Someone had put in a bogon list, but not kept it updated, so the router was dropping the traffic...

Do you have connectivity to 64.111.26.141???

I can ping and tracert to it.  It ges through 13 hops to get there.

hi doug,

your issue was already solved? what did you do?

Yes it has finally been resolved.  I had to change my Ironport DNS  setting to NOT use the Internet's root DNS servers.  If I use my  internal DNS servers or Google's DNS server, it works.

ryantheissaird
Level 1
Level 1

So I'm on the other end - seems anyone with an Ironport has intermittent MX query failures to our domain Hitchcock.org.

We've had a few critical partners set up SMTP routes to our mail servers, or as noted here have the Ironport query their internal DNS server instead of following the Internet root server referrals. But not everyone is willing or able to change their configuration.

Has anyone figured out what the root cause is here? Nslookups from these domains succeed, only the Ironport seems to fail to get a reply from our DNS server. Network captures show the MX query going out but no response ever coming back. Many of the A record queries fail also but they seem to get responses more often. PTR queries always seem to get replies.

Sounds like there is some strange Name Server issue for this Domain.

When I run your domain against MXToolbox DNS Check, it said it could not find an authoritative Name Server. It found a name server but it did not seem to be authoritative. I would check your Domain Register to make sure it has the correct Name Server Selected. Work with your Domain register and check your name server configuration. It is likely it is not just an Ironport Cisco ESA issue.

Here is the output I get for hitchcock.org from MXToolbox DNS Check. Notice all the entries say Non-Auth.

MXTB-PWS3v2 7129ms
  0  a2.org.afilias-nst.info  199.249.112.1  NON-AUTH  78 ms  Received 2 Referrals , rcode=NO_ERROR    NS dns2.hitchcock.org,NS alfred.hitchcock.org,  

  1  alfred.hitchcock.org  130.189.240.100  NON-AUTH  78 ms  Timeout after 3 sec, rcode=NO_ERROR      

  1  dns2.hitchcock.org  130.189.241.68  NON-AUTH  78 ms  Timeout after 3 sec, rcode=NO_ERROR      

There was no non-authoritative reply.  MxToolbox displays "NON-AUTH" even though really the query timed out.

RESOLVED. In our case, it turned out our ISP had implemented some kind of DNS grey listing policy, in which DNS packets between [client IP, server IP] pairs were blocked unless there was a preceding attempt in the last 60 seconds. (see http://en.wikipedia.org/wiki/Greylisting )

IronPorts have unusually long DNS retry intervals, and very rarely made the retry window. The timeline of a failed query to our domain looks like this:

t=0s: IronPort tries primary DNS server, receives no response. Greylisting retry window opens for [client, primary].

t=15s: IronPort tries secondary DNS server, receives no response. Greylisting retry window opens for [client, secondary].

t=60s: Greylisting retry window to primary DNS server expires.

t=75s: Ironport retries primary DNS server and receives no response. Greylisting retry window to secondary DNS server expires.

t=90s: Ironport retries secondary DNS server and receives no response.

Note that nslookup and dig typically retry after 2 seconds. I believe by default, dig won't even show you the timeouts. So this behavior was hidden from our troubleshooting efforts until a thorough Cisco engineer figured this out. I was then able to duplicate the timeouts from several locations, and determined our ISP's name server was also affected. Traceroute from those locations showed that there were no upstream networks in common that might be blocking the queries, so the fault had to be with our ISP.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: