Exchange 2010 Error 451 4.4.0 Error DNS Query Failed

We’ve seen this happen at two environments recently. Both with Small Business Server 2011 running Exchange 2010 SP1 Rollup 3-v3 and 4. Our service provides monitoring of the Exchange server; however, we don’t have an eye on the queues. So, no alarms go off when a message is delayed.

When logging on to the Exchange Server and looking at the Outbound queues, we noticed mail for only a particular domain being held with the 451 4.4.0 Error DNS Query Failed error. Other symptoms:

1.  The nslookup command run on the Exchange server could resolve the domain, proving the internal DNS server was normal.
2.  After gaining the MX record from who.is, the nslookup command resolved the mail server’s IPv4 address, proving the receiver’s mail server was resolvable.
3.  A telnet session to the MX record successfully contacted the suspected domain’s mail server on port 25.
4.  Internal email delivery was functioning.
5.  All other external mail delivery was functioning.

Now we’re down to Exchange itself, since everything DNS related on the server is working correctly. This is the current fix we use:

Change the Network properties of the Edge Transport Server. In this case, it’s the same one.

Step 1: Configure and External DNS server

  1. Click Server Configuration
  2. Right click the server and choose properties
  3. Click The External DNS Lookup tab
    1. Choose Use these DNS servers
    2. Add the DNS Server IPv4 address
    3. Click Apply

Configure an External DNS address

Step 2: Configure the Hub Transport to use the External DNS for external domains.

  1. Click on the Hub Transport of Organization Configuration
  2. Choose Send Connectors
  3. Right click the connector and choose properties
  4. Click the Network Tab
  5. Check the Use External DNS Lookup… box

Configure Exchange to use an External DNS

  1. Restart the Transport Service

The queue should empty immediately.

We’re not sure why this is happening. We theorize it has to do with conflicting or corrupt DNS data being sent back on either the IPv4 or IPv6 stack to the internal DNS server. With this fix, we’re just telling Exchange to bypass the internal DNS for an external one for outbound mail that isn’t delivered to its domain.

Other fixes that may help:

1. Flush the DNS caches on the internal DNS servers and the Exchange server.
2. Add a Forwarder to the internal DNS server. I’m not a big fan of this one as the Root Forwarders should be sufficient. It did work at one site, though.

About these ads


Categories: IT Pros, Microsoft

Tags: , ,

34 replies

  1. Were the MX records for the unresolvable domains appearing in your local DNS cache?

    • I did not verify the cache. However, nslookups were successful from the Exchange server’s command prompt. MX records responded to pings and SMTP send commands were successful from the server.

  2. Try a query for the AAAA record the MX lookup returns. We just ran into an issue similar to this, and I suspect it’s the same issue you are seeing.

    Scenario: Several Exchange 2010 sites could not deliver mail to our MX hosts, they were reporting delays (which would eventually bounce) due to DNS failures.

    Upon investigation I found, like you, that the query for the MX server was successful. Per RFC, the host provided by the MX record MUST be resolvable by either an A or AAAA record. Ours only had an A record. Exchange 2010 seems to default to lookup an AAAA record first. Watching the DNS traffic on our site, I saw the sites that were having issues delivering were not doing an A record query they were doing a query for an AAAA record.

    We did not have an IPv6 AAAA record configured for our mx hosts. Our DNS server was returning a SERVFAIL for the query. According to RFC a sending server that receives a failed DNS query MUST defer the mail. Unfortunately, it’s my opinion that both parties are playing by the RFC technically.

    What we did to correct this issue (remember I am the receiving domain side) was tell our DNS servers to return a NOERROR for the AAAA query instead of a failure. This immediately resolved the issues.

    I suspect that you could tell your Exchange 2010 environment to not use IPv6 DNS resolution and that would also fix the error.

    To verify this is the issue you are seeing, attempt a query for the AAAA record of the mx host received. If you get a SERVFAIL, that’s probably the issue you are seeing.

    $ nslookup
    > set type=AAAA
    > smtp.domain.org
    ;; Got SERVFAIL reply from 1.2.3.4, trying next server
    Server: 1.2.3.4
    Address: 1.2.3.4#53

    ** server can’t find smtp.domain.org: NXDOMAIN

  3. Try a query for the AAAA record the MX lookup returns. We just ran into
    an issue similar to this, and I suspect it’s the same issue you are
    seeing.

    Scenario: Several Exchange 2010 sites could not deliver mail to our MX
    hosts, they were reporting delays (which would eventually bounce) due to
    DNS failures.

    Upon investigation I found, like you, that the query for the MX server was
    successful. Per RFC, the host provided by the MX record MUST be
    resolvable by either an A or AAAA record. Ours only had an A record.
    Exchange 2010 seems to default to lookup an AAAA record first. Watching
    the DNS traffic on our site, I saw the sites that were having issues
    delivering were not doing an A record query they were doing a query for an
    AAAA record.

    We did not have an IPv6 AAAA record configured for our mx hosts. Our DNS
    server was returning a SERVFAIL for the query. According to RFC a sending
    server that receives a failed DNS query MUST defer the mail.
    Unfortunately, it’s my opinion that both parties are playing by the RFC
    technically.

    What we did to correct this issue (remember I am the receiving domain
    side) was tell our DNS servers to return a NOERROR for the AAAA query
    instead of a failure. This immediately resolved the issues.

    I suspect that you could tell your Exchange 2010 environment to not use
    IPv6 DNS resolution and that would also fix the error.

    To verify this is the issue you are seeing, attempt a query for the AAAA
    record of the mx host received. If you get a SERVFAIL, that’s probably
    the issue you are seeing.

    $ nslookup
    set type=AAAA
    smtp.domain.org
    ;; Got SERVFAIL reply from 1.2.3.4, trying next server
    Server: 1.2.3.4
    Address: 1.2.3.4#53

    ** server can’t find smtp.domain.org: NXDOMAIN

  4. Excellent and logical work around – thanks!

  5. I had the same issue and this resolved it.. Thanks!

  6. Thanks, I solved the problem.

  7. Same here – thanks for the workaround

  8. how do I…
    was tell our DNS servers to return a NOERROR for the AAAA query
    instead of a failure.??

  9. Worked for me! I just did step 2 and the mail queues emptied. I spend 3 days solid working on this with no joy.
    Thanks

  10. This was a huge help! After wasting time on other research, Step 2 was the fix. Well written and easy to follow. thanks!!

  11. I had this error when my Exchange server had no space on the C drive. clearing space fixed it

  12. Thanks a lot! I spent a lot of time searching for an answer and this worked like a charm! Thanks!

  13. Thanks mate, you made my day. After investigating vor several hours why one (!) maildomain wasn´t resolveable, althought it should be, your fix did the tick.

    Greetings

  14. thanks you so muck for this article , very nice

  15. Hi,
    Thanks for this blog,
    Have you any idea about the cause of problem?

  16. thanks resolved half-of my problem

  17. thank you, you saved my Christmas Eve.

  18. I’m very pleased to find this web site. I want to to thank you for ones time for this particularly fantastic read!! I definitely savored every part of it and i also have you bookmarked to check out new information in your web site.

  19. forwarder works, no such complicated setting needed on mine exchange, root hints no good, must do forwarder!

  20. It’s very trouble-free to find out any topic on net as compared to textbooks, as I found this article at this web site.

  21. Thanks a lot…cleared most of my queue but I having this error still with a longer message for one of my domains that mails are usually sent to.

    The mail queue viewer has under last error:

    “451 4.4.0 Primary target IP address responded with: “421 4.2.1 Unable to connect.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate host, or delivery failed to all alternate host”

  22. Hi! Someone in my Facebook group shared this website with us so I came to look it over.
    I’m definitely enjoying the information. I’m bookmarking and
    will be tweeting this to my followers! Exceptional blog
    and fantastic style and design.

  23. This solved this problem for me, the hardest part was to find the error code. Took me almost a day untill I found this solution. THANK YOU!

  24. You actually make it appear so easy with your
    presentation but I find this matter to be actually something
    that I feel I would by no means understand. It seems too complex and very wide for me.
    I’m taking a look ahead for your subsequent publish, I’ll try to get the
    hang of it!

  25. Having read this I thought it was very enlightening. I appreciate you taking the time and effort to put this informative article together.
    I once again find myself spending a significant amount of time both reading and commenting.

    But so what, it was still worthwhile!

  26. I don’t even know how I ended up here, but I thought this post
    was good. I don’t know who you are but certainly you’re going to
    a famous blogger if you aren’t already ;) Cheers!

  27. What’s up everybody, here every person is sharing such know-how,
    therefore it’s nice to read this web site, and I used to go to see this web site daily.

  28. Great, that really saved me a lot of time! we now use the Google DNS 8.8.8.8

Trackbacks

  1. Problema Exchange 2010, errore DNS Query Failed (451 4.4.0) | Cloud Zone

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

MyVirtuaLife.Net

Every cloud has a silver lining.

Live Virtually

or die in IT

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video

Just another WordPress.com site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments

Virtu-Al.Net

Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow-Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

Follow

Get every new post delivered to your Inbox.

Join 25 other followers

%d bloggers like this: