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
- Click Server Configuration
- Right click the server and choose properties
- Click The External DNS Lookup tab
- Choose Use these DNS servers
- Add the DNS Server IPv4 address
- Click Apply
Configure an External DNS address
Step 2: Configure the Hub Transport to use the External DNS for external domains.
- Click on the Hub Transport of Organization Configuration
- Choose Send Connectors
- Right click the connector and choose properties
- Click the Network Tab
- Check the Use External DNS Lookup… box
Configure Exchange to use an External DNS
- 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.
Advertisement
Like this:
Be the first to like this post.
Home Network Hardware
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.
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
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
Excellent and logical work around – thanks!
I had the same issue and this resolved it.. Thanks!
Brilliant!
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