After upgrading to macOS Mojave and macOS Server 5.8, DNS and web services were no longer available. Since v. 5.7, Apple has discontinued macOS Server support for many services that have macOS or open source alternatives. I discovered a simple solution for recovering my websites (macOS Server v5.8: Where Are My Web Sites? or discussions.apple.com/thread/250537819), and I expected the DNS solution to be even simpler. After all, serving web sites seems to be a much more complex task compared to serving and referring domain names. No such luck.
Although macOS Server discontinued web site support, many macOS Mojave and macOS Server services require web services, as do many apps. Apache v2.4.34 is bundled and launched with macOS Mojave. DNS services are not bundled or launched with macOS Mojave or macOS Server v5.7+. In order to recover the local domain name table after upgrading macOS Server, a DNS service (open source or proprietary) must be installed and launched. This post will address the open source solution using BIND9.
The macOS Server Service Migration Guide v1.2 details the processes for configuring, building, testing, installing, and launching BIND9, with some big caveats. Rather then echoing the contents of the Service Migration Guide, I will focus on the caveats, each of which is an obstacle to success. The list of potential problems includes:
Since solving all of these problems is much easier on a dedicated server, this post will assume a dedicated server. I recommend activating the root user account and logging in as the root user to immediately establish administrator credentials which do not expire. Root users do not need the "sudo" command prefix in the macOS Terminal app. See SERVER PREPARATION for more information.
Most migration steps require using a UNIX shell (command line) interface such as the macOS Terminal app. The default Terminal display is too small to be effective. Use the Terminal app's "Preferences ..." option in the Application Menu to increase the window size (Window tab in the Profiles tab) to at least 100 columns and 50 rows.
App installation on Apple devices is strictly controlled and limited to the App Store and identified developers. All other downloads from the internet are automatically quarantined with a file system extended attribute named "com.apple.quarantine". macOS will not permit access to sensitive services by or with quarantined files, and each migration process entails a degree of complexity that would not tolerate a quarantined file. PROCESS COMPLEXITY is discussed below.
The Terminal app is the most effective means of fixing quarantined files and UNIX permissions (discussed below in its own section). After downloading the BIND9 archive from the ISC (Internet Systems Consortium) web site, check the extended attributes with the following command:
Clear all extended attributes from the "*.tar" or "*.tar.gz" file with the following command. You will be prompted for an administrator password:
Confirm removal of extended attributes with "ls -l@".
If quarantined files persist or you forget this step before expanding the archive, remove the extended attributes from the expanded folder with the following command, also requiring an administrator password:
UNIX-like and otherwise POSIX-compliant systems, including Linux-based systems and all macOS versions, have a simple system for managing individual file permissions. Permissions on UNIX-like systems are managed in three distinct scopes or classes. These scopes are known as user, group, and others. Read, write, and execute permissions are assigned to each of these scopes.
Files downloaded from the internet are usually assigned to the current user and group. However, files and folders expanded from a downloaded archive may be assigned to different users and/or groups. In a dedicated server, the downloaded archive should be assigned to the "root" user and the "wheel" group. The files and folders expanded from the archive should also be assigned to the "root" user and the "wheel" group.
Use the following Terminal command to change the user and group of the downloaded archive. An administrator password is required:
Use the following command to change the user and group of the expanded files and folders. An administrator password is required:
Since 2009, BIND9 has provided stable extended support versions (ESV) which are supported for 4 years. Otherwise, development and stable versions of BIND9 are supported for about one year. Since BIND v9.13, major development versions are odd, and major stable versions are even. BIND v9.11.9 is the latest extended support version (ESV) which is scheduled to be end-of-life (EOL) in December 2021. BIND v9.14.4 is the latest stable version. BIND v9.15.2 is the latest unstable development version.
The macOS Server Service Migration Guide v1.2 used BIND v9.9.9, which is no longer available.
As of BIND v9.14, cryptography support is mandatory. macOS Mojave no longer bundles or supports openSSL cryptography and recommends that developers use the macOS API. In order to use BIND v9.14 with macOS Mojave, a compatible version of openSSL or LibreSSL must be installed. The potential for security conflicts and failure dissuaded me from pursuing this course. BIND v.9.11 does not require cryptography and is compatible with the processes outlined in the macOS Server Service Migration Guide v1.2. This post describes the use of BIND v9.11.8.
Many migration processes require the use of "sudo" to establish administrator credentials, adding excessive keystrokes to the overall migration. All of these excessive keystrokes can be eliminated by performing the migration as the root user. Logging in as the root user immediately establishes permanent administrator credentials and eliminates the need for the "sudo" prefix. Maintaining the server with the root user account is consistent with the philosophy of a dedicated server. Use the macOS Directory Utility to activate and deactivate the root user account.
Since BIND9 is open source and supports many versions of UNIX (including macOS), it is distributed as source code written in C and Python. It must be configured, built, tested, installed, and launched. Well, this requires running compilers, interpreters, linkers, testers, installers, and launchers. The good news is that many of these services are bundled and installed with macOS. The bad news is that using them is complicated.
The Xcode app is Apple's integrated development environment (IDE) for all Apple operating systems. Xcode reduces the complexity of building, testing, and installing software from source code by automating many processes. It is a 6GB package, and it can be downloaded and installed from the macOS App Store. Once Xcode is installed, follow the macOS Server Service Migration Guide v1.2 instructions to install the Xcode command line tools.
Apple developers ($99/year) can download and install the Xcode command line tools without installing Xcode. Either way, the Service Migration Guide instructions require the Xcode command line tools.
Parts of BIND9 (e.g. testing) are written in Python and require Python and the Python "ply" module. macOS Mojave bundles and launches Python v2.7, but does not include the "ply" module. The "ply" module can be downloaded from https://pypi.python.org/pypi/ply as a compressed tar archive or a wheel (.whl) file. Wheel files can be installed with Python's "pip" module. Are you still with me?
The "pip" module is included in Python v2.7 bundled with macOS, but it may not be activated. Use the following Terminal command to check if the "pip" module is activated in macOS Mojave:
If necessary, use the following Terminal command to activate the Python "pip" module. Log in as the root user to eliminate "sudo -H":
If "pip" activation is successful, the above command should end with the following three lines:
Use the "pip --version" command to confirm activation:
Once the "pip" module is activated, install the "ply" module with the following Terminal command using quotes and the actual name (and location if not the present working directory) of the downloaded wheel file:
Success is indicated by the following lines:
I highly recommend configuring, building, testing, installing, and launching BIND9 as the root user to eliminate potential UNIX permission issues. Once the server is fully prepared to handle all the caveats described in this post, follow the instructions in the macOS Server Service Migration Guide v1.2 (remembering that "sudo" is not required as the root user).
Expect large volumes of Terminal output after the "configure" and "make" commands, which are likely to flag many warnings. If there are errors and/or fatal errors, the source code will not be configured for "make", and "make" will not run. After running "configure", check the "config.log" file with the Following Terminal command:
Before proceeding with "make", the last line should show an exit code of 0, as illustrated below:
After completing the instructions in the macOS Server Service Migration Guide v1.2, confirm that BIND9 was launched and functioning with the "nslookup" Terminal command, as illustrated below:
As noted below, my PLATFORM consists of two early 2009 Apple Xserve's. macOS Server allowed me to configure primary and secondary DNS servers, which was successfully reproduced after installing and launching BIND9.
However, BIND9 does not provide an effective interface for modifying DNS data. My ultimate solution involved creating an active directory domain on a Windows server, which includes a primary DNS server and GUI interface to the data. Both Xserve's are now secondary DNS servers using BIND9. All DNS data is managed on the Windows server.
The volume of Terminal output attests to the complexity of these processes. As complexity increases, so do the risks of failure. I have documented what worked on my platform (described below) for others in the same bind (pun intended). I cannot guarantee success, and I am unable to otherwise support your efforts. If you encounter problems, my best suggestion is to ensure that you followed my path to success. Use of openSSL, LibreSSL, and/or different versions of Python and BIND9 may require different paths to success, which are beyond the scope of this post.
Good luck. The macOS Server Service Migration Guide v1.2 was, by far, the closest match to my searches, but each step in the guide had to be researched individually as the Service Migration Guide was written for macOS High Sierra v10.13.
©2020 Arthur Rosel, Ltd. All rights reserved.