Re: Exchange, SBS and Reverse DNS - Best Practices??
- From: Joe <joe@xxxxxxxxxxxxxx>
- Date: Mon, 04 Feb 2008 20:48:33 +0000
Bryan L wrote:
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:
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?'.
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?
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.
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?
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.
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.
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.
.
- References:
- Exchange, SBS and Reverse DNS - Best Practices??
- From: Bryan L
- Exchange, SBS and Reverse DNS - Best Practices??
- Prev by Date: Re: SQL 2000 on SBS 2003 Premium?
- Next by Date: Re: Small Business Server R2 and Symantec Endpoint Protection 11.0
- Previous by thread: Re: Exchange, SBS and Reverse DNS - Best Practices??
- Next by thread: remove user's outlook from exchange
- Index(es):
Relevant Pages
|
