iis smtp nntp: Hi,

I had a strange problem with IIS SMTP attempting to send mail to the
'A' record of a domain rather than the MX.
SMTP protocol (rfc 2821) states that "If no MX records are found, but
an A RR is found, the A RR is treated as if it was associated with an
implicit MX RR, with a preference of 0, pointing to that host."
So I can see that IIS thought that there was no MX record which is why
it attempted to use the A.

The problem is that this happened many 10's of thousands of times over
a few days. I know the DNS servers were good as I work for the ISP who
manages them. They deal with millions of requests everyday and had no
issues from any other customers. And when I looked up MX records using
'nslookup' on the command line of the IIS server the records would
return o.k.

What's strange is that the problem went away when I changed the default
DNS server on the machine to something else ( a lower spec server
further away ). Which would suggest the original DNS servers where bad,
but I know they're not.

I now need to explain what happened.
Does IIS SMTP have a timeout on DNS requests after which it decides
that record doesn't exist? If so could someone point me to a doc that
states the timeout is X seconds so I have something I can quote.

Has anyone seen this before and have any insight as to why it happened?

Thanks,
Dave

[quoted text, click to view]

This is the second time in a couple of weeks that I have heard such
symptoms mentioned, and not before. Yet, as I responded to the other
poster, I have doubts about the ubiquity of this situation, because
it would be so catastrophic to countless installations. It seems more
likely to be some combination of IIS SMTP version, perhaps atypical
internal configuration (like multihoming), perhaps firewall/router
hardware, and DNS vendor/version. Could you expand on the specs in
these areas? Also, the infamous "What Changed?" has to be answered.
If you're talking about the same load on the MTAs and the same
response time on the DNS servers from week to week, it'd be pretty
strange for you to suddenly see 10,000+ errors. Are the lines clean
between the sites? Packet loss?

I also mentioned that I'd be very interested to see a packet trace
establishing that IIS SMTP received, but disregarded, an MX RR, or
that IIS SMTP did not request the MX RR, but only the A record. That
would be no laughing matter. I know of a major MTA that shall remain
nameless, one specific version of which was known to use A records
even if MXs existed; yet that product is known to be pretty janky
overall. IIS SMTP is quite respected as an MTA, so we need to get to
the bottom of this.

--Sandy

Hi,
Thanks for the reply.
In hindsight installing ethereal on this server whilst the problem was
happening would have given a lot more information as to whether the MX
records were discarded or simply not requested.
What I did first was to change the DNS servers and the problem went
away. This server is managed by my company but is part of a
customer's infrastructure and I had to get it working ASAP.
I have since installed ethereal and I can see that IIS is always
requesting MX records so I can only assume that whilst the problem was
happening it was also requesting them.
The IIS server is Windows 2003 IIS 6.
The server is multihomed and the NIC facing the internet is the primary
in the advanced network config.
The DNS servers are both bind on linux. (Both being the one that had
the problem and the one that fixed it)
There is a firewall between IIS and the internet, this is checkpoint
and allows TCP and UDP out on port 53 so I don't think there was a
problem here.

I believe the SMTP server was sending out more mail than normal. The
company tell me it's their busiest time of year. When I was watching
the SMTP stats in perfmon it was sending around 5 mails per second.

The lines between the IIS server and DNS servers were fine, as I
mentioned I work an ISP and all servers involved and connections
between them are ours. We have 100's of similar servers and only this
one has ever the problem.

Unfortunately I don't think I'll get an answer without ethereal or some
form of packet sniffing stats from when the problem was actually
happening.
I'm just now tasked with explaining to the customer why it happened and
I'm at a bit of loss right now. The consensus at the moment is to blame
IIS but I'm really not convinced.

Thanks,
Dave