Re: How to disable the "implicit mx record" in Exchange
- From: Evan McNally <EvanMcNally@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 3 Mar 2007 19:45:08 -0800
Just a followup that I have responded here:
http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?query=evan&dg=microsoft.public.exchange.admin&cat=en-us-technet-exch2000&lang=en&cr=US&pt=A644703B-6C4F-491F-8154-EE3096DCF463&catlist=328BAFD2-1A81-4558-B1DE-B6EB49F31B7E&dglist=&ptlist=&exp=&sloc=en-us
"Ace Fekay [MVP]" wrote:
In news:F509A047-A343-4433-A4F7-B5C1A669C958@xxxxxxxxxxxxx,.
Evan McNally <EvanMcNally@xxxxxxxxxxxxxxxxxxxxxxxxx> stated, which I
commented on below:
I am having a problem with exchange sending to hosts in recipient
domains where these hosts are not actually mail servers. After a lot
of review of the SMTP logs, I realized that sometimes Exchange is
sending to the correct MX record host, and sometimes it is sending to
the host with the A record for the actual domain. When I say the
record for the domain, I mean an A record that refences the bare
domain name rather than an individual host in the domain.
So when Exchange gets a DNS timeout looking up an MX record, it falls
back to sending to the domain A record. This causes an immediate
failure with no further retry in cases where the MX and A records go
to diferent IP addresses and the A record host accepts mail but not
for the particular recipients we are sending to--we get the "cannot
relay for that user" type error.
This link explains how this behavior is by design according to the
RFC:
http://exchangepedia.com/blog/2006/11/rfc-2821-and-implicit-mx-rule-can-you.html
I feel that this problem is a combination of saturated bandwidth
causing DNS request packets to be dropped and poor performance with
our ISP's DNS and perhaps slow response from the recipient domain's
DNS servers during recursive lookup. BUT, it is not feasable to fix
those problems quickly.
Does anyone know if it is possible to tell Exchange to do one of the
following:
1. Retry the MX lookup more times. I have already increased the DNS
timout value in the forwarder section of our internal DNS server, but
it does not help when the DNS packet is simply lost.
2. Disable the fall back to using the domain A record. If it would
just retry the MX lookup after a while, we would be fine.
I beilieve I can also "fix" this by entering Exchange routing rules
with an explicit recipient host for the problem domains, but that's
kind a crummy way to cover up the problem.
Thanks for any advice!
Evan
You know, I don't post into this group, but this subject caught my eye and I
had to read the post. Why did it catch my eye? An MX record is a type of DNS
record, and any record must be explicity entered. It either exists or it
doesn't. And you don't disable an MX record, whether the infrastructure uses
their own Exchange or other type of mail server under their own domain name,
or an ISP or someone else hosting it for them. A record is a record. If you
don't want the record, delete it.
This whole thing could be simply a bad Forwarder issue, as was pointed out
by Oliver. Try 4.2.2.2 as a forwarder. That is always a winner.
This can also be an EDNS0 issue with an older firewall or a firewall that
needs to be updated. Up until recently, DNS UDP traffic max packet size is
512 bytes. If the response packet is larger than 512 bytes, such as with
domains that have numerous records, the traffic then switches up to TCp to
allow the larger traffic. However if Windows 2003 DNS is left to default,
which supports EDNS0 =, which means it will support a UDP packet size to
1280 bytes, then it will fail with a router that cannot support it. EDNS0 is
a new industry standard and a great feature to increase resolution
efficiency. Windows 2003 is one of the early adopters. Many other are
following. if they haven't already.
828263 - DNS query responses do not travel through a firewall in Windows
Server 2003:
http://support.microsoft.com/?id=828263
828731 - An External DNS Query May Cause an Error Message in Windows Server
2003:
http://support.microsoft.com/?id=828731
The other folks offer allot of great information and suggestions as well. If
I were you, I would consider all suggestions and test them to see which one
will do the trick.
--
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Directory Services
Microsoft Certified Trainer
Innovative IT Concepts, Inc (IITCI)
Willow Grove, PA
Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."
- References:
- Re: How to disable the "implicit mx record" in Exchange
- From: Ace Fekay [MVP]
- Re: How to disable the "implicit mx record" in Exchange
- Prev by Date: Re: Problems with OWA permissions
- Next by Date: Re: Installing the Exchange Calendar Update tool
- Previous by thread: Re: How to disable the "implicit mx record" in Exchange
- Next by thread: RE: How to disable the "implicit mx record" in Exchange
- Index(es):
Relevant Pages
|
