]> 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. This guide covers the experimental prototype version of BIND 10. BIND 10 provides separate executables for different tasks. The standard components include: msgq — message bus daemon b10-auth — authoritative DNS server b10-cfgmgr — configuration manager b10-cmdctl REST-ful communication service b10-xfrin Incoming zone transfer service bind10 — master process for BIND 10 The user tools include: bindctl — interactive administration interface b10-loadzone — tool to load standard master zone files 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 quickly covers the standard steps for installing and deploying BIND 10 as an authoritative nameserver using its defaults. For troubleshooting, full customizations and further details, see the respective chapters in the BIND 10 user guide. Install required dependencies: Python 3.1, SQLite3 library, and Boost development headers. Download the BIND 10 source tarball. Extract the tar file: $ gzcat bind10-VERSION.tar.gz | tar -xvf - Go into the source and run configure: $ cd bind10-VERSION $ ./configure Build it: $ make Install it (to default /usr/local): $ make install Start the server: $ /usr/local/sbin/bind10 The Y1 prototype of the b10-auth server listens on 0.0.0.0 (all interfaces) port 5300. (This is not the standard domain service port.) Test it; for example: $ dig @127.0.0.1 -p 5300 -c CH -t TXT authors.bind Load desired zone file(s), for example: $ b10-loadzone your.zone.example.org Test the new zone. 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 development snapshots and releases 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 You don't need to retrieve the source code from subversion unless you are testing latest code which is not provided in the source tarball. Most users will just use the source tar file. 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. Building from the source tarball requires the Boost build-time headers. At least Boost version 1.34 is required. If the Boost System Library is detected at configure time, BIND 10 will be built using an alternative method for networking I/O using Boost ASIO support. This provides asynchrony support; with ASIO the Authoritative DNS server can handle other queries while the processing of a TCP transaction stalls. This dependency is not required unless you need this feature as TCP transport support is provided using alternative code. For the Y1 prototype release, the only supported data source backend is SQLite3. The authoritative server requires SQLite 3.3.9 or newer, and the XFRin module requires the Python _sqlite3.so module. Some operating systems do not provide these dependencies 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 options are: --with-boostlib Define the path to find the Boost system library. --without-boostlib or --with-boostlib=no Disable the Boost ASIO support. --with-pythonpath Define the path to Python 3.1 if it is not in the standard execution path. --with-boost-include Define the path to find the Boost headers. --prefix Define the the installation location (the default is /usr/local/). For example, the following configures it to build with BOOST ASIO support, find the Boost headers, find the Python interpreter, and sets the installation location: $ ./configure --with-boostlib=/usr/pkg/lib \ --with-boost-include=/usr/pkg/include \ --with-pythonpath=/usr/pkg/bin/python3.1 \ --prefix=/opt/bind10 If the configure fails, it may be due to missing or old dependencies. After the configure step is complete, to build the executables from the C++ code and prepare the Python scripts, 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. etc/bind10/ — configuration files. 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/ — data source and configuration 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. The b10-cfgmgr daemon 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. The bind10 master process will also startup b10-cmdctl for admins to communicate with the system, b10-auth for Authoritative DNS service, and b10-xfrin for inbound DNS zone transfers. (These are covered in upcoming chapters.) To start the BIND 10 service, simply run bind10. Run it with the --verbose switch to get additional debugging or diagnostic output. The BIND 10 components use the msgq message routing daemon to intercommunicate. This is called the Command Channel. The members of the channel subscribe to listen to certain messages and are programmed to handle received messages. Example messages include shutdown, get configurations, and set configurations. This Command Channel is not used for DNS message passing. Administrators do not communicate directly with the msgq daemon. The only configuration is to choose the port number it listens on. By default, BIND 10 uses port 9912 for the msgq service. It listens on 127.0.0.1. 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 b10-auth and b10-xfrin daemons and other components receive their configurations from the configuration manager over the msgq command channel. The administrator doesn't connect to it directly, but uses a user interface to communicate with the configuration manager via b10-cmdctl's REST-ful interface. b10-cmdctl is covered in . The Y1 prototype release only provides the bindctl as a user interface to b10-cmdctl. Upcoming releases will provide another interactive command-line interface and a web-based interface. The b10-cfgmgr daemon can send all specifications and all current settings to the bindctl client (via b10-cmdctl). b10-cfgmgr relays configurations received from b10-cmdctl to the appropriate modules. The stored configuration file is at /usr/local/var/bind10/b10-config.db. (The full path is what was defined at build configure time for --localstatedir. The default is /usr/local/var/.) The format is loosely based on JSON and is directly parseable python, but this may change in a future version. This configuration data file is not manually edited by the administrator. The configuration manager does not have any command line arguments. Normally it is not started manually, but is automatically started using the bind10 master process (as covered in ). b10-cmdctl is the gateway between administrators and the BIND 10 system. It is a HTTPS server that uses standard HTTP Digest Authentication for username and password validation. It provides a REST-ful interface for accessing and controlling BIND 10. When b10-cmdctl 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 — the user interface — such as bindctl. b10-cmdctl directly sends commands (received from the user interface) to the specified component. Configuration changes are actually commands to b10-cfgmgr so are sent there. The HTTPS server requires a private key, such as a RSA PRIVATE KEY. The default location is at /usr/local/etc/bind10/cmdctl-keyfile.pem. (A sample key is at /usr/local/share/bind10/cmdctl-keyfile.pem.) It also uses a certificate located at /usr/local/etc/bind10/cmdctl-certfile.pem. (A sample certificate is at /usr/local/share/bind10/cmdctl-certfile.pem.) This may be a self-signed certificate or purchased from a certification authority. The HTTPS server doesn't support a certificate request from a client (at this time). The b10-cmdctl daemon does not provide a public service. If any client wants to control BIND 10, then a certificate needs to be first recieved from the BIND 10 administrator. The BIND 10 installation provides a sample PEM bundle that matches the sample key and certificate. The b10-cmdctl daemon also requires the user account file located at /usr/local/etc/bind10/cmdctl-accounts.csv. This comma-delimited file lists the accounts with a user name, hashed password, and salt. (A sample file is at /usr/local/share/bind10/cmdctl-accounts.csv. It contains the user named root with the password bind10.) The administrator may create a user account with the b10-cmdctl-usermgr tool. By default the HTTPS server listens on the localhost port 8080. The port can be set by using the --port command line option. The address to listen on can be set using the --address command line argument. Each HTTPS connection is stateless and timesout in 1200 seconds by default. This can be redefined by using the --idle-timeout command line argument. The configuration items for b10-cmdctl are: key_file cert_file accounts_file The control commands are: print_settings shutdown print_message For the Y1 prototype release, bindctl is the only user interface. It is expected that upcoming releases will provide another interactive command-line interface and a web-based interface for controlling and configuring BIND 10. The bindctl tool provides an interactive prompt for configuring, controlling, and querying the BIND 10 components. It communicates directly with a RESTful interface over HTTPS provided by b10-cmdctl. It doesn't communicate to any other components directly. Configuration changes are actually commands to b10-cfgmgr. So when bindctl sends a configuration, it is sent to b10-cmdctl (over a HTTPS connection); then b10-cmdctl sends the command (over a msgq command channel) to b10-cfgmgr which then stores the details and relays (over a msgq command channel) the configuration on to the specified module.