]> Administrator Reference for BIND 10 2010Internet Systems Consortium, Inc. BIND is the popular implementation of a DNS server, developer interfaces, and DNS tools. BIND 10 is a rewrite, using C++ and Python, to provide modular components for serving and maintaining DNS. BIND 10, at this time, does not provide an recursive DNS server. It does provide a EDNS0- and DNSSEC-capable authoritative DNS server. BIND 10 provides separate executables for different tasks. The standard components include: msgq — message bus b10-auth — authoritative DNS server b10-cfgmgr — configuration manager b10-cmdctl b10-xfrin The user tools include: bindctl — interactive administration interface bind10 — master process for BIND 10 The tools and modules are covered in full detail in this users guide. In addition, manual pages are also provided in the default installation. BIND 10 also provides libraries and programmer interfaces for C++ and Python for the message bus, configuration backend, and, of course, DNS. These include detailed developer documentation and code examples. This chapter just covers the standard steps for installing and deploying BIND 10 as an authoritative nameserver using its defaults. For full customizations and details, see the respective chapters. BIND 10 is open source software written in C++ and Python. It is freely available in source code form from ISC via the Subversion code revision control system or as a downloadable tar file. It may also be available in pre-compiled ready-to-use packages from operating system vendors. The BIND 10 release and development snapshots are available as tarball downloads. The latest development code, including temporary experiments and un-reviewed code, is available via the BIND 10 code revision control system. This is powered by Subversion and all the BIND 10 development is public. The leading development is done in the trunk and the first year prototype containing reviewed code is in branches/Y1. The code can be checked out from svn://bind10.isc.org/svn/bind10; for example to check out the trunk: $ svn co svn://bind10.isc.org/svn/bind10/trunk When checking out the code from the code version control system, it doesn't include the generated configure script, Makefile.in files, nor the related configure files. They can be created by running autoreconf with the --install switch. This will run autoconf, aclocal, libtoolize, autoheader, automake, and related commands — and provide needed build files. This requires autoconf version 2.59 or newer and automake version 1.11 or better (for working Python 3.1 tests). Some operating systems do not provide these in their default installation nor standard packages collections. You may need to install them separately. BIND 10 requires Python 3.1, SQLite 3.3.9 or newer, and the Python _sqlite3.so module. Some operating systems do not provide these in their default installation nor standard packages collections. You may need to install them separately. Building BIND 10 also requires a C++ compiler and standard development headers. BIND 10 builds have been tested with GCC g++ 3.4.3, 4.1.2, 4.2.1, 4.3.2, and 4.4.1. BIND 10 builds have been tested on Debian GNU/Linux 5, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7, and CentOS Linux 5.3. It has been tested on Sparc, i386, and amd64 hardware platforms. It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms. BIND 10 uses the GNU Build System to discover build environment details. To generate the makefiles using the defaults, simply run: $ ./configure Run ./configure with the --help switch to view the different options. The commonly-used option is --prefix to define the installation location (the default is /usr/local/). Then to build the executables from the C++ code, run: $ make To install the BIND 10 executables, support files, and documentation, run: $ make install The install step may require superuser privileges. The following is the layout of the complete BIND 10 installation: bin/ — general tools and diagnostic clients. lib/ — libraries and python modules. libexec/bind10/ — executables that a user wouldn't normally run directly. Nor would they be used independently. These are the BIND 10 modules which are daemons started by the bind10 tool. sbin/ — commands used by the system administrator. share/bind10/ — configuration specifications. share/man/ — manual pages (online documentation). var/bind10/ — configuration and data source databases. BIND 10 provides the bind10 command which starts up the required daemons to provide the message communication bus, configurations, and the DNS server(s). Also known as BoB or the Boss of BIND, bind10 will also restart processes that exit. After starting the msgq communications channel, bind10 connects to it, runs the configuration manager, and reads its own configuration. Then it starts the other modules. The msgq and b10-cfgmgr services make up the core. The msgq daemon provides the communication channel between every part of the system. And b10-cfgmgr is always needed by every module, if only to send information about themselves somewhere, but more importantly to ask about their own settings, and about other modules. b10-cmdctl is the gateway between administrators and the whole system; when it starts it firsts asks b10-cfgmgr about what modules are running and what their configuration is (over the msgq channel), then it will start listening on HTTPS for clients (i.e. bindctl). /usr/local/share/bind10/cmdctl-keyfile.pem contains the Private key, such as a RSA PRIVATE KEY. /usr/local/share/bind10/cmdctl-certfile.pem contains the Certificate. This could be a self-signed certificate or purchased from a certification authority. The configuration manager, b10-cfgmgr handles all BIND 10 system configuration. It provides persistent storage for configuration, and notifies running modules of configuration changes. The administrator doesn't use it directly, but uses a tool like bindctl (or other GUI or web interface) to communicate with the configuration manager. To start the BIND 10 service, run bind10. Run it with the --verbose switch to get additional debugging or diagnostic output.