Messaging Gateway

We have a customer to which all emails are getting stuck in the delivery queue.  The message we are seeing is:

Error: 454 4.4.4 [internal] no MX or A for domain

But, if we flush the dns cache, do a nslookup -type=mx against their domain then flush the delivery queue, the message will send properly.

I'm trying to figure out why these messages are being flagged as not having an MX or A record, and I wanted to look through the DNS server logs, but I cannot find them anywhere.  Is there a way I can query these logs?

It's very annoying because it's happening multiple times a day, and we cannot figure out whether it's a problem with SMG or with their DNS records on the Internet.

You mean inbound mails, from internet to customer mailsys, in terms of smg "inbound local mail delivery", right?

Or, to clarify, can you give us as sample of queued sender and recipient.

I would first take a look at MX-Lookup checkbox at inbound host config.

I guess I wasn't clear what the problem was.  The problem is with outbound delivery, not inbound.  

The emails are going from our Exchange servers to our SMG, and from there should be queued for delivery to the remote mail system.  At this point, our SMG is setup to lookup the MX record of the remote mail system (Outbound Non-Local Mail Delivery is set to "Use MX Lookup for non-local domain mail"), but for some reason, for a few particular domains, the MX record lookup does not seem to be working.  The message gets queued in the delivery queue with the error "Error: 454 4.4.4 [internal] no MX or A for domain", even though I can use nslookup -type=mx locally on our SMG to lookup the MX record.

Ok, that makes sense ... ;-)

Usually its the performance of the DNS-Servers you are asking. Take a look there, tcpdump etc should give you the answer.

I'm not sure if you can see DNS-Queries in SMG. If you have syslog enabled you can see the lookups.

What does "dns-control status" say?

I'm using the internal caching DNS server that is built in to SMG (Host DNS configuration is set to "Use Internet Root servers").

As for syslog, unfortunately, I'm not sending the logs anywhere.  That's why I was asking in my original question how I could acesss the DNS logs on the appliance itself.

Finally, dns-control status gives me the following output:

version: 9.5.2-P4 (Version response disabled)
number of zones: 12
debug level: 2
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
Command 'status' completed successfully.

You should see the DNS lookups in the host log at info level. Did you take a look at them?

Why are you using the roots? From my understanding the roots are not designed for regular usage - change to local ones, eg own or internet provider.

In case of an error situation whats the reponse of an nslookup - it should tell you something like temp unavailable, too many requests etc

I'm not seeing any DNS lookups in the host logs (or at least, not that I can see from the control center).  Is there a specific setting I need to enable to get this?

Where this gets odd, I can do a nslookup -type=mx and get the MX record for the emails that are sitting in the delivery queue.  That's why I'm confused.

You are running a very old version of the Messaging Gateway. If you upgrade to the current version, you will see more helpful error mesages. This error specifically was known to be too vague in that version and not helpful in pointing out the real issue.

I thought I was running the newest version of Messaging Gateway:  10.5.4-4.  Is there something newer available?

- Version: From my point of view 10.5.4 is the latest version, 10.6 is in the queue (first KB-articles show up public).

- nslookup: You mentioned you can do the nslookups for domains where mails are in your delivery queue, right? By using nslookup, which server is used to query? Usually when doing nslookup on smg you query localhost. By the time the mail gets sent the lookup takes places. If you try the lookup even ms later it might get trough, no shure method to detect these kind of errors.

- using root server: Have you just tried to change the dns to the servers from your isp, or just try googles 8.8.8.8, or setup your own?

- logs: To see the dns things in the log you possibly need a higher log level. Its an MTA-Log-Entry - so see admin-doc - we use info-level.

Hope it helps