Exchange, SBS and Reverse DNS - Best Practices??

This may be slightly OT, so please direct me elsewhere if you know of a more
appropriate place to post. And thanks in advance for reading a long post.

I'm an IT professional who's come to appreciate SBS 2003 in my own
workplace, so I recommended it for a family member's business. They like
their new SBS network, which we planned and implemented about a year ago.
They are now hosting their own email, but for a while they had troubles
sending email to certain domains (AOL and a number of others).

As I worked the problem, it appeared that the trouble was related to their
DNS setup. Their email server's DNS records would pass normal reverse
lookup checking, but a reverse lookup of their second-level domain name
would resolve to another IP address; in fact, the IP address of their
website. It appeared that some organizations were taking a more aggressive
stance against spam and were using those "conflicting" lookup results as
evidence that their server wasn't who it said it was, and were consequently
blocking their email.

In discussing the issue with their website admin -- who also happened to be
controlling their DNS -- he either disagreed with my assessment, or didn't
understand me, and was reluctant to make any changes to their DNS. We
finally agreed that he would turn over hosting of their DNS to me. The DNS
hosting transfer took place several months ago and went smoothly. (The SBS
is not hosting their public DNS - it's now placed with a large, reputable
hosting company.) Of course I configured "www" to resolve to the same IP as
always, but I configured their DNS so that reverse lookups of
"mail.domain.com" and "domain.com" resolved to the same IP. Since that time
I've heard no complaints about outgoing emails being blocked or returned.

However, there is a now a problem with the shopping cart feature of their
website. In looking at the notes provided by their website admin, I think
the problem is that in their shopping cart configuration, the URLs
"www.domain.com" and "domain.com" were probably used interchangeably. It
worked before the DNS move because at that time, both lookups resolved to
the IP of the website -- now only "www" resolves to the website, while the
second-level domain name resolves to the IP of the SBS.

They way I see it, there are two solutions: have the website admin configure
all URLs within the website shopping cart setup to use the correct FQDN of
the website -- OR -- reconfigure the DNS on their second-level domain name
to again resolve to the website's IP. But before I stick to my guns with
the website admin, I want to be sure I'm not in the wrong. So my questions
are these:

1) I understood that using reverse DNS to combat spam was limited to
checking IP > DNSHostName, then DNSHostName > IP. Is it true and/or
accepted that admins may also check DNSDomainName > IP for another match?
2) What do best practices say about setting "domain.com" to resolve to the
same IP as the MX record? Do they say anything about how to configure the
second-level domain name resolution?
3) Have I made any horrendous mistakes here? I feel I acted responsibly in
a step-by-step, thorough manner, but if I've gone awry somewhere please
don't hesitate to point it out.

Incidentally, the website admin believes that I actually moved the website
hosting in addition to the DNS, which I did not -- the IP of the website has
not changed. He showed me the results of a tracert that are supposed to
"prove" this, but the tracert was not performed on "www", but on the domain
name itself -- which of course resolved to the WAN IP of the SBS, which he
does not recognize.

Thanks again for reading a long post, and thanks in advance for any replies.

Bryan

 

Hi Bryan,

This is my 'take' on it - not necessarily what the RFCs say or what
most people do.

1) The website admin should definately re-write any URLs that do not
specify the server, and only contain the domain name.

2) You should configure a proper SPF record in the DNS records as I
am guessing that might help in resolving your issues with third party
mail servers that are doing reverse DNS lookups.

3) Where should your DNS record point the domain IP address to? The
right answer, as far as I am concerned is 'nowhere' since it is not a
computer. HOWEVER, given that so many people *expect* to be able to
type: domainname.com into their web browser and connect to a machine
that is serving http requests, the best (commercial) answer is
probably to point it at the website.


Of course, if (2) does not solve the problem with email, then you
really have a sticky problem. In that case....

4) Consider hosting the website on the same IP address?? Not a pretty
option I grant you!


I wonder if you can find out *specifically and definitively* why AOL
was bouncing the emails? That might inform your decision making?


HTH, and Good Luck in a difficult situation!

--

Alan.

The views expressed are my own, and not those of my employer or anyone
else associated with me.

My current valid email address is:



This is valid as is. It is not munged, or altered at all.

It will be valid for AT LEAST one month from the date of this post.

If you are trying to contact me after that time,
it MAY still be valid, but may also have been
deactivated due to spam. If so, and you want
to contact me by email, try searching for a
more recent post by me to find my current
email address.

The following is a (probably!) totally unique
and meaningless string of characters that you
can use to find posts by me in a search engine:

ewygchvboocno43vb674b6nq46tvb

 

I would insist that the web developer fixes his/her issues. It's plain bad
coding.

It is a very very bad idea to host a public website on the SBS. Lots of
security risks. Now, with certain setups you could still achieve having
website and mail going to the same public IP without hosting it on the SBS.

Place a second box into the DMZ on your router and then forward incoming
traffic on port 80 to that box. SBS doesn't need (and shouldn't get) port 80
traffic. If you need SSL traffic directed to your website, you are out of
luck or you will loose part of the SBS functionality.

 

Bryan,

When you stated, "but I configured their DNS so that reverse lookups..." did
you mean that you have a reverse DNS lookup set up somewhere in your own DNS
hosting? Typically, the only one with the authority or ability to set up a
reverse DNS record (or PTR record) is the ISP on which your SBS server
resides.

Who provides your SBS server's Internet connection? They are the ones who
should have a PTR record pointing "mail.domain.com" to your SBS server's WAN
IP (or to your firewall's WAN IP when forwarding).

The only PTR record you should have is for the "mail.domain.com" name and
its IP address. Your mail server greeting should also have the FQDN and not
just the domain in its answer. You can telnet to it on port 25 to see the
greeting.

Go to www.dnsstuff.com and run a report on your domain.

Gregg Hill

 

I'd agree with the others: both. It is customary for the domain itself,
which as has correctly been pointed out is not a hostname, to
nonetheless point to the IP address of the domain's main web server
which will normally be named or aliased 'www'. Certainly any program
code should refer, not to a mixture of entities, not even to a specific
website, but to a single URL variable which can as necessary be
configured to any hostname. Hardcoding URLs is insanity. 'What were they
thinking of?'.

Whatever you want. Most mail servers have a small programming language,
and are therefore infinitely flexible.

Most look for a complementary pair of IP->PTR->hostname->DNS->IP as a
minimum. Some look for a PTR-MX record match, though an ISP or large
organisation may well use separate IP addresses for mail sending and
receiving, which messes that one up. Some require a match of MX record
with HELO string, which makes more sense, but only just. Many require a
HELO string to be a valid hostname accessible in public DNS even if it
doesn't match the MX. I've seen no less an organisation than British
Telecom send mail with a .local HELO string.

I know for a fact that AOL does not require either PTR-MX or PTR-HELO
matching, since my PTR record is a hostname that has no place at all in
my mail system. But that hostname does resolve to the IP address, so AOL
may well require a complementary PTR-hostname pair. My accountant rather
unprofessionally uses an aol.com email address, so I'll know soon enough
if their policy changes.

As I and others have said, I think the domain and the www, if it exists,
should be the same. Many DNS servers will return the domain IP address
if no www entry exists, or automatically generate such a www entry when
validating the zone. Many people just type the domain name for websites,
and the browser will automatically add 'http://' but it can't (at least
it shouldn't) add the 'www'. Many web servers are not called 'www'.
Typically in the SBS world, the MX is mail.domain, which points to the
SBS public IP address, almost invariably different from that of www as
it should be.

A lot of this is custom, and changing quickly as we try to deal with
spam. There are no real laws on the Internet, just Requests For
Comments. My mail server looks for the complementary PTR-DNS pair and
for the HELO to be a valid public DNS name, but nothing else along those
lines. There are legitimate reasons why various other things might not
match, but none at all for someone setting up a mail server to fail to
ensure a valid PTR and corresponding hostname, or to know how to
configure their HELO (something the CEICW should deal with in SBS).

Looking at my logs, the senders who fail those tests are all
non-commercial users (therefore viruses or bots) and are sending to
deliberately invalid recipients or using dictionary tactics. And anyone
who sets their HELO to be my IP address (more common than you might
think) is just plain taking the p. I don't need them in my inbox.

 

To clarify, I am not hosting a public website nor their DNS on the SBS.
Their public website and DNS hosting are both hosted elsewere. Sorry if my
post wasn't clear on those points.

Bryan