Zimbra servers make a lot of DNS requests, so having a locally available caching DNS server system for Zimbra to use is important. In helping customers with very active Zimbra servers, we have found that deploying BIND9 gets the job done when dnsmasq, Zimbra’s Unbound or even local Active Directory servers with the DNS role can’t keep up. This post will show you how to do this easily.
Which BIND9 To Use?
BIND9’s authors and maintainers, the Internet Systems Consortium, recommend installing BIND9 downloaded from them directly versus using the version of BIND9 shipped with your Linux distro. Their experience has been that many Linux distros do not update their BIND9 packages as quickly as is desired (if at all), so by downloading from the authors directly, you are ensured of getting the latest stable packages.
As of this writing, 9.18.13 is the latest version, released about one week ago. Ubuntu Server 22.04 has 9.18.12 as the latest version, which was released about a month ago. Ubuntu 20.04 has 9.16.1; Ubuntu 18.04 has 9.11.3, and; Ubuntu 16.04 with ESM has 9.10.3.
Given the foregoing, we recommend not installing BIND9 on your Zimbra servers, but instead to install multiple separate, BIND9-only servers on the latest stable operating system. In that scenario, ideally, you should use the BIND9 packages downloaded from ISC. But if you are prepared to rotate out your BIND9 servers and use the latest available supported distro (and confirm that their BIND9 packages are as up to date as Ubuntu 22.04 seems to be doing presently), then the ease of use of using your distro’s BIND9 packages may not be too big of a compromise–especially if the BIND9 servers to be used by Zimbra are isolated from the rest of your network. The other benefit of using ISC’s BIND9 packages is that you can purchase Support from ISC directly if you have an issue.
Architectural Decisions and Recommendations
We do our own Zimbra hosting on Amazon Web Services, and in line with AWS’s Well Architected Framework, we recommend deploying one Ubuntu 22.04 BIND9 server in each Availability Zone. In the example below, we will build three identical Ubuntu 22.04 BIND9 servers in each of three different Availability Zones, each on different subnets.
BIND9 has a very small footprint. Its cache size is memory dependent to avoid swapping, and it uses not a lot of CPU, so we typically start with a t3.micro instance (2 CPU cores and 1GB of RAM) and a single 32GB root disk. For safety’s sake, we add a 2GB swap file. These instances all-in cost a little under US$10/month each.
If your Zimbra system delivers more than 500K emails/day, you may want to consider an instance size for your BIND9 servers with more RAM.
For simplicity’s sake, we will presume that you will use Ubuntu 22.04 servers with BIND9 installed from the Ubuntu repos. If you use a Red Hat-based distro, or ISC’s builds, please note the location of some files may be different, and some installations use chroot as well. (We have not tested this.) Your choice!
BIND9 will need one or more forwarders. (Forwarders are DNS servers that can perform DNS lookups on our BIND9 servers’ behalf, when the answer to a Zimbra server’s query is not already in the BIND9 server’s cache.) If your Zimbra server is already using Zimbra’s Unbound, you can use the IP address(es) in the attribute zimbraDNSMasterIP as the forwarder(s). If you are using Active Directory servers for DNS lookups currently, you can use your AD servers’ IP addresses as forwarders for BIND9. We use AWS’s Route 53 managed DNS service for hosting our zone files, so will use that service’s IP in the setup example below.
Whatever you use for a forwarder, the forwarder must resolve the Zimbra server’s forward and reverse lookups with the actual IP addresses of the Zimbra servers. In other words, if your Zimbra servers are NAT’d, the forwarder you use must resolve the Zimbra servers at their private IP addresses. Using caching DNS servers will reduce the load on your forwarder(s), but the forwarder(s) still need to be performant. If you are hosting your own forwarders (e.g. Active Directory servers), please ensure that the forwarders the AD servers use are also performant. Typically, ISP-provided DNS servers are insufficient for this role in busy environments.
If you have been using dnsmasq and do not have a DNS server that will resolve the Zimbra servers at their private IP addresses, then you will need to add forward and reverse Zone Files to the BIND9 servers. Configuring Zone Files and Replication in BIND9 is well documented and can be added on to the configurations below. But, configuring BIND9 with Zone Files is beyond the scope of this post, which is about configuring BIND9 only as a caching DNS server for Zimbra.
Zimbra Configuration – Prebuild
The three BIND9 servers we will deploy will be named bind1.mydomain.com, bind2.mydomain.com and bind3.mydomain.com. Once these servers have been provisioned (no BIND9 configured yet) and you know their IP addresses, we should let Zimbra know about them. At the end of /etc/hosts on all of your Zimbra servers, add:
172.31.0.202 bind1.mydomain.com bind1 172.31.16.64 bind2.mydomain.com bind2 172.31.32.125 bind3.mydomain.com bind3
BIND9 Servers’ Buildout – Initial Preparation Work
First step is to deploy the 2 GB swapfile on your newly provisioned servers. Ubuntu on AWS is provisioned without any swap. As root you can run:
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile && swapon --show && echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab
With swap configured, we now need to configure the operating system to avoid using swap unless absolutely necessary (same as with Zimbra). As root, run:
nano /etc/sysctl.conf
At the end of the file, add the following two lines:
# Reduce Swappiness vm.swappiness = 1
Next step is to edit /etc/hosts on all three BIND9 servers to match /etc/hosts on your Zimbra servers (including the entries for the BIND9 servers themselves that you added in the previous section). In other words, at this point, /etc/hosts on your Zimbra servers and on the BIND9 servers should all be identical.
Edit /etc/hostname on each of the BIND9 servers to remove the existing entry and to replace it with the FQDN of each of the BIND9 servers (e.g. like “bind1.mydomain.com”).
Update the operating system and reboot. As root, run:
apt clean all && apt-get update && apt-get dist-upgrade -y reboot now
After the reboot is complete, install BIND9 and all of the companion packages. On Ubuntu Server 22.04, we did as root:
apt-get install bind9 bind9utils bind9-doc
BIND9 is now installed, but unconfigured. Let’s do that next.
BIND9 Servers’ Buildout – BIND9 Configuration Work
We have two BIND9 configuration files to edit: /etc/bind/named.conf.options and /etc/bind/named.conf.
For /etc/bind/named.conf.options, we need to add an access control list to limit which hosts can query BIND9. We need to specify the forwarder(s), and we need to make some other adjustments to make BIND9 work correctly.
For /etc/bind/named.conf, I like to turn up logging. In this way, if there are any issues (e.g. timeouts, lame server responses, however the forwarders are responding etc.), we’ll have that data captured in the log files. If you are using centralized syslogging, be sure to update the rsyslog configs on the BIND9 servers to ship these logs to your centralized syslog server.
So here’s what /etc/bind/named.conf.options looks like:
acl goodclients {
// Consider tighter restrictions, e.g. instead of using subnets,
// list only the /32 IPs of your Zimbra servers. The networks
// below refer to each of the three AWS Availability Zones used.
172.31.0.0/19;
172.31.16.0/19;
172.31.32.0/19;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
//
// Here we use the dedicated IP address for the AWS Route 53
// DNS service.
forwarders {
172.31.0.2;
};
recursion yes;
allow-recursion { goodclients; };
allow-transfer { none; };
allow-query { goodclients; };
auth-nxdomain no; # conform to RFC1035
empty-zones-enable no;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation no;
listen-on-v6 { any; };
};
And here’s what /etc/bind/named.conf looks like:
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
logging {
channel bind.log {
file "/var/lib/bind/bind.log" versions 10 size 20m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { bind.log; };
category default { bind.log; };
category config { bind.log; };
};
After completing the above changes, let’s lint the configuration. As root run:
named-checkconf
If you get nothing back, that means all of your syntax is OK. It doesn’t necessarily mean you have a working configuration, but at this point you should restart BIND9 to find out for sure. As root:
service bind9 restart && service bind9 status
If BIND9 restarts OK, terrific! If not, you can look through /var/log/syslog for errors and address them.
BIND9 QA Testing
We still need to test that BIND9 resolves critical lookups correctly. By “critical” I mean that BIND9 performs successful forward and reverse lookups for all of your Zimbra servers, and is also able to resolve external hosts. To perform these tests, pick one of your Zimbra servers to use to test, let’s presume it’s proxy1.mydomain.com. On each and every BIND9 server, you can run:
dig @localhost proxy1.mydomain.com +short
You should get back just the private IP address of that Zimbra proxy server. Let’s presume the IP that comes back is 172.31.0.45. Using that IP address, let’s next QA reverse lookups:
dig @localhost -x 172.31.0.45 +short
You should get back the FQDN “proxy1.mydomain.com”. It’s a good idea to repeat the above two tests for all of your Zimbra server’s FQDNs, and, again, on all of the BIND9 servers.
Lastly, let’s confirm external lookups are OK, since we need these for Zimbra’s MTA to function:
dig @localhost www.yahoo.com +short
To eliminate the possibility of any networking/firewall issues between Zimbra and the BIND9 servers, I would suggest rerunning the above tests from each of your Zimbra servers, but instead of using “@localhost” in the dig command, use instead “@172.31.0.202” etc. to reference the IP of each of the three BIND9 DNS servers and confirm that every Zimbra server can perform lookups on every BIND9 server.
On the presumption that all of your BIND9 servers pass the above QA tests, we are now ready to configure Zimbra to use the three new BIND9 servers you have just built.
Configure Zimbra To Use BIND9
This step is pretty straightforward (usually). All we need to do is comment out in /etc/resolv.conf the existing nameserver entries pointing to the existing DNS servers we have been using, and add entries for our new BIND9 servers. If our new BIND9 servers have the IP addresses 172.31.0.202, 172.31.16.64 and 172.31.32.125, and our existing DNS server has the IP address 172.31.5.49, then we want to edit /etc/resolv.conf to look like this:
# Remove existing DNS server: # nameserver 172.31.5.49 # Add new BIND9 caching DNS servers: nameserver 172.31.0.202 nameserver 172.31.16.64 nameserver 172.31.32.125 search mycompany.com
As soon as you make the above changes on each of your Zimbra servers, Zimbra will start using the new BIND9 DNS servers.
If you need help with setting all this up, or with any other Zimbra issues, just reach out using the form below:
Hope that helps,
L. Mark Stone
Mission Critical Email LLC
29 March 2023
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.