Re: How to disable the "implicit mx record" in Exchange



On Mon, 26 Feb 2007 10:26:13 -0800, Evan McNally
<EvanMcNally@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

David,

I understand your general advice, but I am really looking for an answer on
how to modify the two numbered points in my original post.

To respond to your points:
-I suspect saturation at our site is a factor, but slow recursive lookups
(which would be a problem at the recipient domain) could also be an issue.
The error occurs with some domains a lot more than others. Better links will
not help with this.
-The MX record does resolve _most of the time_. This is not a resolution
problem, per se. It is only when the MX lookup fails on occation that we
have the error.

I do not want to sound unappreciative, but trust me when I say that I know
exactly what the error is. I just need to know how to modify the bahavior of
Exchange or Microsoft DNS to compensate for the error conditions.


Well trust me when I say what you are saying makes no sense :)

Per the RFC, the A record should only be used if the mx record is not
found in the DNS zone for the domain you are sending to.
IOW, if your are able to resolve the domain and it does not contain
a mx record, then the implicit rule comes into effect.
Its not a "most of the time" thing. The record either exists or not.

If exists, use it, if it doesnt, try the A record. If the mx record
exists and you can not connect to the mailserver defined, then
generate an error, but do not fail-over to an A record if a mx record
exists.
If the lookup fails, then it should be reported as an error and the
mail will queue or be returned to the sender at some point after
timing out. In order for the implicit mx record rule to kick in as you
say it does, then resolution has to work at some level, otherwise how
does it obtain the A record?

I also do not understand your other statement:

"and the A record host accepts mail but not for the particular
recipients weare sending to--we get the "cannot relay for that user"
type error."

Not too many orgs have a mx record for some users and a A record for
others to mail to, so I dont quite get that statement.

As to your specific question, I dont know if that behavior can be
changed. If anything, in the past, Exchange was bad a failing over to
an A record when the mx record did not exist in a recpients DNS zone.


You may want to open a case with PSS.





Thanks, Evan

"Andy David {MVP}" wrote:

On Mon, 26 Feb 2007 10:06:43 -0800, Evan McNally
<EvanMcNally@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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


If your link is saturated from looking up DNS records, its time to get
a new link.

If you are unable to lookup a mx record for a domain, then you should
not be able to look up their A record either.

I suspect you have something else going on that is causing problems.

.



Relevant Pages

  • Re: Exchange set up newbie
    ... The person responsible for setting the A and MX record is the Domain Host ... If you do not know who is hosting your Domain, ... Before you choose DNS be sure you can Telnet out on Port 25 from command ... >> First get Exchange installed. ...
    (microsoft.public.windows.server.sbs)
  • Re: How to disable the "implicit mx record" in Exchange
    ... where these hosts are not actually mail servers. ... MX record host, and sometimes it is sending to the host with the A record for ... So when Exchange gets a DNS timeout looking up an MX record, ... I feel that this problem is a combination of saturated bandwidth causing DNS ...
    (microsoft.public.exchange.admin)
  • Re: How to disable the "implicit mx record" in Exchange
    ... It is only when the MX lookup fails on occation that we ... Exchange or Microsoft DNS to compensate for the error conditions. ... MX record host, and sometimes it is sending to the host with the A record for ...
    (microsoft.public.exchange.admin)
  • Re: Exchange misbehaving:
    ... I called my host armed to the teeth following yours ... SBS and Exchange, even if i did configure everything correctly it ... Get rid of them and find another company to host your DNS. ... the nameservers for your domain with your registrar. ...
    (microsoft.public.windows.server.sbs)
  • Re: Exchange misbehaving:
    ... Well, I'm actually a chick, but I guess "guy" is a fairly generic unisex ... I called my host armed to the teeth following yours ... Exchange, even if i did configure everything correctly it sometimes ... Get rid of them and find another company to host your DNS. ...
    (microsoft.public.windows.server.sbs)