The system of domain name servers (DNS) is a global hierarchy of databases dedicated to the simple but essential task of looking up host names like
www.digitalocean.com and turning them into one or more IP addresses. Whenever an email is sent or a connection to a host is initiated by its name, the DNS system is used. There is a good introduction to the DNS system available from the DigitalOcean community.
Such an essential and fundamental component of Internet infrastructure gets a lot of use. It is not uncommon for a busy system to make hundreds of name lookups per second or more. If services running on your server perform much work at all behind the scenes then it is likely that security and performance will benefit from verifying and caching within your own systems the name lookups that your service performs to conduct its operations.
In this tutorial, you will learn how to set up a FreeBSD server to remember all DNS lookups in a system-wide cache. Information will automatically expire from this cache, honoring each looked-up domain’s individual policy for rechecking.
Note: As of July 1, 2022, DigitalOcean no longer supports the creation of new FreeBSD Droplets through the Control Panel or API. However, you can still spin up FreeBSD Droplets using a custom image. Learn how to import a custom image to DigitalOcean by following our product documentation.
In order to follow this tutorial, you will need:
FreeBSD 10.1 includes the verifying caching resolver Unbound (version 1.4.22) as part of the base system; FreeBSD 10.2 includes version 1.5.3. Both are considered secure and ready to be put into production use.
Once you are logged into your server via SSH, enabling FreeBSD’s included resolver is as simple as issuing the following command:
- sudo sysrc local_unbound_enable=YES
Your server is now configured to start Unbound at the next system reboot.
You can fire up the resolver immediately without performing a full system restart.
To start the resolver:
- sudo service local_unbound start
If Unbound starts successfully you should see output similar to the following:
Performing initial setup. Extracting forwarders from /etc/resolv.conf. /var/unbound/forward.conf created /var/unbound/lan-zones.conf created /var/unbound/unbound.conf created /etc/resolvconf.conf created original /etc/resolv.conf saved as /etc/resolv.conf.20150812.184225 Starting local_unbound.
You are now running the Unbound verifying caching name resolver but not all of your currently running software is guaranteed to notice and pick up the modification.
Actions like restoring a backup image or using a snapshot image as the basis for a new server would normally clobber the configuration we’ve done so far. This is due to a minor bug in the OpenStack driver for FreeBSD. Luckily this bug has been fixed in the upcoming release. We will individually apply this particular patch to the current release now in order to ensure Unbound’s proper operation with your cloud provider’s backup and snapshotting facilities.
Download the patch from the official repository for BSD-CloudInit, (the FreeBSD OpenStack driver):
- fetch https://github.com/pellaeon/bsd-cloudinit/commit/a7ee246c23.diff
Apply the patch to the proper file:
- sudo patch -N -F3 /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py < a7ee246c23.diff
You should see output that ends with the following, indicating the patch applied successfully:
. . . Patching file /usr/local/bsd-cloudinit/cloudbaseinit/osutils/freebsd.py using Plan A... Hunk #1 succeeded at 4 with fuzz 2 (offset 1 line). Hunk #2 succeeded at 83 with fuzz 3 (offset 4 lines). done
You no longer need the patch file and may remove it:
- rm a7ee246c23.diff
Your system is now configured to use Unbound through system backups and restorations, or after being cloned to an entirely new server.
The simplest way to ensure all of your software is using the new resolver is to restart the server entirely.
You can delay doing this until it least impacts the service your server provides. The running software will use either the old resolver or the new one, rather than malfunction; any software that is able to pick up the transition in the meantime will do so gracefully. and there should be no ill effects from both being potentially in use side by side temporarily.
When you are ready, restart your server:
- sudo shutdown -r now
That’s all there is to it!
In this tutorial you learned how to cache host name and domain name lookups on your system and why you might want to do so. You can learn more about FreeBSD’s caching resolver at the homepage for the Unbound project.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.