DNS Strategies and Best Practices, and a SLES10 Request
We've just set up our first Zimbra server on a NAT'd SuSE 10 box, so we've been spending some time searching the forums for posts regarding DNS.
I thought it might be helpful to post our experiences regarding DNS with Zimbra and DNS in general, given that we have set up a number of Postfix boxes for our own and our clients' use over the years. Feedback and differing views are welcomed!
First, our preferred Linux is SuSE, not Red Hat. Not that either is better or worse than the other, but we now have a lot of experience with SuSE (both the OpenSuSEs and SLES9/10) so we'd like not to spend cycles learning the unique "gotchas" of Red Hat.
With regard to DNS, the docs and the forum posts seem to presume a config where the Zimbra server gets a public IP address and runs bind and iptables. Our preferred config is to give our servers private IP addresses, with NAT performed by an enterprise-grade hardware firewall and with bind not installed.
We like this config for the following reasons:
1. We like offloading the firewall work to a dedicated device, which also does RBL checks, A/V, A/Spam, A/Phishing and IPS, and which results in a much lower load on the mail server and (we'd like to believe) better security for the mail server.
2. We like offloading DNS lookups (and we know Postfix does a lot of them for anti-UCE work) to the redundant DNS servers provided by our colo host. Their DNS servers rarely get rebooted or have bind restarted, so we benefit from the cached DNS lookups on those servers and the reduced workload on our servers.
3. We like the elimination of configuring zone files on bind, when our own domain host (Interland) and our client's domain hosts typically provide very slick GUI-based DNS managers to administer the DNS servers which are authoritative for those domains. Even if our colo host didn't provide fast DNS servers, we'd prefer to run bind as a locally caching dns server only, without any zone files.
4. Since we've seen some of our friend's dns servers get hacked, we are happy to avoid managing dns services if we can at all avoid doing so.
5. Since so much routine work is offloaded to other boxes, the number of accounts which can be serviced on a single Zimbra host is increased significantly.
As a result of the above preferred setup, we had to tweak our Zimbra config and firewall as follows:
1. We added entries to /etc/hosts for both the public and private IP addresses of the Zimbra server.
2. We had to open a port in the firewall for lmtp communications between the public and private IP addresses of the Zimbra server.
3. We had to change the default domain selected by the install script from the fqdn of the Zimbra host to the domain of the Zimbra host.
4. We had to use postconf to add 'proxy_interfaces = <public ip>' to postfix's main.cf file where <public ip> is the public ip address of the Zimbra host (NAT'd by the firewall) since postfix needs to know it's public IP. (The postfix documentation at postfix.org has the details on why this is so.)
So, all of the above is doable, but seemingly not standard and not documented in any one place (at least that we could find). In any event, we've been testing our new Zimbra host this weekend with some half dozen domains and a few thousand emails, and while we haven't tackled importing calendars, contacts, existing mail messages, etc., yet, we've read enough forum posts to feel we'll be OK there.
Presently, we are using the OSS version of Zimbra. But we know a number of our clients will want the features of the Professional editition, so we expect to be a paying customer within the next two months. But...
Since we like to build mail servers to last five years or so, may we ask if Zimbra has a timetable for releasing a version that will run on SLES10? (We tried already; we got it mostly working but weren't comfortable doing what we had to do to get it working.)
And if someone has different views than we do on configuring dns, would love to hear the whys and wherefores.
With best regards to all,
Postfix Proxy_Interfaces Directive and Anti-Spam Strategy
From the Postfix documentation:
Originally Posted by scalper
proxy_interfaces (default: empty)
The network interface addresses that this mail system receives mail on by way of a proxy or network address translation unit.
This feature is available in Postfix 2.0 and later.
You must specify your "outside" proxy/NAT addresses when your system is a backup MX host for other domains, otherwise mail delivery loops will happen when the primary MX host is down.
proxy_interfaces = 184.108.40.206
So, technically you don't need to use this directive on a primary MX, but I seem to recall that if you have a NAT'd Postfix box without this directive, then bounce messages will show the private IP of the server: "This is the Postfix program at mymailserver.mydomain.com (192.168.168.168). I'm sorry I wasn't able to deliver..."
We run a SonicWall PRO 2040 in front of our mail servers. It does RBL checking, anti-virus, anti-spam, etc. and catches most of the garbage before it can hit our mail servers. Better than 90% of the email entering our mail servers is actually legitimate email! It costs about US$2,800, but pays for itself because you don't need to have as powerful mail servers as you would otherwise (and one should have a hardware firewall as well anyway...)
Originally Posted by scalper