Exchange, SBS and Reverse DNS - Best Practices??

Discussion in 'Windows Small Business Server' started by Bryan L, Feb 3, 2008.

  1. Bryan L

    Bryan L Guest

    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
    "" and "" 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
    "" and "" 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 "" 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 L, Feb 3, 2008
    1. Advertisements

  2. Bryan L

    Alan Guest

    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: 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!



    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:

    Alan, Feb 3, 2008
    1. Advertisements

  3. Bryan L

    Claus Guest

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

    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.
    Claus, Feb 3, 2008
  4. Bryan L

    Gregg Hill Guest


    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

    Who provides your SBS server's Internet connection? They are the ones who
    should have a PTR record pointing "" 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 "" 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

    Go to and run a report on your domain.

    Gregg Hill
    Gregg Hill, Feb 4, 2008
  5. Bryan L

    Joe Guest

    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 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.
    Joe, Feb 4, 2008
  6. Bryan L

    Bryan L Guest

    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 L, Feb 5, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.