This is the reference guide for BIND 10 version +
This is the reference guide for BIND 10 version 20111129.
Copyright © 2010-2011 Internet Systems Consortium, Inc.
Abstract
BIND 10 is a Domain Name System (DNS) suite managed by Internet Systems Consortium (ISC). It includes DNS libraries and modular components for controlling authoritative and @@ -8,7 +8,7 @@ The most up-to-date version of this document (in PDF, HTML, and plain text formats), along with other documents for BIND 10, can be found at http://bind10.isc.org/docs. -
Table of Contents
Table of Contents
+
Table of Contents
Table of Contents
BIND is the popular implementation of a DNS server, developer interfaces, and DNS tools. BIND 10 is a rewrite of BIND 9. BIND 10 is written in C++ and Python @@ -20,7 +20,7 @@ BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server and a caching recursive name server which also provides forwarding. -
BIND 10 builds have been tested on Debian GNU/Linux 5, Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, and CentOS Linux 5.3. @@ -30,7 +30,7 @@ It is planned for BIND 10 to build, install and run on Windows and standard Unix-type platforms. -
BIND 10 requires Python 3.1. Later versions may work, but Python 3.1 is the minimum version which will work.
@@ -140,7 +140,7 @@ and, of course, DNS. These include detailed developer documentation and code examples. -
Table of Contents
Table of Contents
In addition to the run-time requirements, building BIND 10 from source code requires various development include headers.
@@ -204,14 +204,14 @@ the Git 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. -
+
Downloading a release tar file is the recommended method to obtain the source code.
The BIND 10 releases are available as tar file downloads from ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be available. -
Downloading this "bleeding edge" code is recommended only for developers or advanced users. Using development code in a production environment is not recommended. @@ -245,7 +245,7 @@ autoheader, automake, and related commands. -
BIND 10 uses the GNU Build System to discover build environment details. To generate the makefiles using the defaults, simply run: @@ -276,16 +276,16 @@
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/ —
@@ -385,7 +385,7 @@
during startup or shutdown. Unless specified, the component is started
in usual way. This is the list of components that need to be started
in a special way, with the value of special used for them:
- Table 3.1.
| Component | Special | Description |
|---|---|---|
| b10-auth | auth | Authoritative server |
| b10-resolver | resolver | The resolver |
| b10-cmdctl | cmdctl | The command control (remote control interface) |
| setuid | setuid | Virtual component, see below |
+
Table 3.1.
| Component | Special | Description |
|---|---|---|
| b10-auth | auth | Authoritative server |
| b10-resolver | resolver | The resolver |
| b10-cmdctl | cmdctl | The command control (remote control interface) |
| setuid | setuid | Virtual component, see below |
The kind specifies how a failure of the component should be handled. If it is set to “dispensable” @@ -610,12 +610,12 @@ shutdown the details and relays (over a b10-msgq command channel) the configuration on to the specified module.
-
Table of Contents
+
Table of Contents
The b10-auth is the authoritative DNS server. It supports EDNS0 and DNSSEC. It supports IPv6. Normally it is started by the bind10 master process. -
+
b10-auth is configured via the b10-cfgmgr configuration manager. The module name is “Auth”. @@ -635,7 +635,7 @@ This may be a temporary setting until then.
-
+
For the development prototype release, b10-auth
supports a SQLite3 data source backend and in-memory data source
backend.
@@ -649,7 +649,7 @@ This may be a temporary setting until then.
The default is /usr/local/var/.)
This data file location may be changed by defining the
“database_file” configuration.
-
RFC 1035 style DNS master zone files may imported into a BIND 10 data source by using the b10-loadzone utility. @@ -678,7 +678,7 @@ This may be a temporary setting until then. If you reload a zone already existing in the database, all records from that prior zone disappear and a whole new set appears. -
Table of Contents
+
Table of Contents
Incoming zones are transferred using the b10-xfrin process which is started by bind10. When received, the zone is stored in the corresponding BIND 10 @@ -696,7 +696,7 @@ This may be a temporary setting until then. In the current development release of BIND 10, incoming zone transfers are only available for SQLite3-based data sources, that is, they don't work for an in-memory data source. -
In practice, you need to specify a list of secondary zones to
enable incoming zone transfers for these zones (you can still
trigger a zone transfer manually, without a prior configuration
@@ -712,7 +712,7 @@ This may be a temporary setting until then.
> config commit
(We assume there has been no zone configuration before). -
As noted above, b10-xfrin uses AXFR for
zone transfers by default. To enable IXFR for zone transfers
for a particular zone, set the use_ixfr
@@ -764,7 +764,7 @@ This may be a temporary setting until then.
(i.e. no SOA record for it), b10-zonemgr
will automatically tell b10-xfrin
to transfer the zone in.
-
To manually trigger a zone transfer to retrieve a remote zone, you may use the bindctl utility. For example, at the bindctl prompt run: @@ -821,7 +821,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
use the system wide TSIG configuration. The way to specify zone specific configuration (ACLs, etc) is likely to be changed, too. -
Table of Contents
The b10-resolver process is started by bind10. @@ -860,7 +860,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
(Replace the “2”
as needed; run “config show
- Resolver/listen_on” if needed.)
+ Resolver/listen_on” if needed.)
By default, the b10-resolver daemon only accepts
DNS queries from the localhost (127.0.0.1 and ::1).
The Resolver/query_acl configuration may
@@ -893,7 +893,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
(Replace the “2”
as needed; run “config show
Resolver/query_acl” if needed.)
This prototype access control configuration - syntax may be changed.
Table of Contents
Dynamic Host Configuration Protocol for IPv4 (DHCP or +
Dynamic Host Configuration Protocol for IPv4 (DHCP or DHCPv4) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are protocols that allow one node (server) to provision configuration parameters to many hosts and devices (clients). To @@ -922,7 +922,8 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
clients. Even though principles of both DHCPv4 and DHCPv6 are somewhat similar, these are two radically different protocols. BIND10 offers server implementations for both DHCPv4 - and DHCPv6.
+ and DHCPv6. This chapter is about DHCP for IPv4. For description of + DHCPv6 server, see Chapter 13, DHCPv6 Server.
As of December 2011, both DHCPv4 and DHCPv6 components are skeleton servers. That means that while they are capable of performing DHCP configuration, they are not fully functional @@ -930,7 +931,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
databases. This means that they will assign the same, fixed, hardcoded addresses to any client that will ask. See the section called “DHCPv4 Server Limitations” and the section called “DHCPv6 Server Limitations” for detailed description. -
BIND10 provides DHCPv4 server component since December 2011. It is currently described as skeleton server and can be described as an early prototype that is not yet fully functional. It is mature enough to conduct first tests in lab @@ -962,7 +963,7 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
As DHCPv4 server opens privileged ports, it requires root access. Make sure you run this daemon as root. -
DHCPv4 server does not have lease database implemented yet or any support for configuration, so every time the same set of configuration options (including the same fixed address) @@ -972,46 +973,131 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
configuration is to tweak its source code. To do so, please edit src/bin/dhcp4/dhcp4_srv.cc file and modify following parameters:
-const std::string HARDCODED_LEASE = "10.3.2.222"; // assigned lease +const std::string HARDCODED_LEASE = "192.0.2.222"; // assigned lease const std::string HARDCODED_NETMASK = "255.255.255.0"; const uint32_t HARDCODED_LEASE_TIME = 60; // in seconds -const std::string HARDCODED_GATEWAY = "10.3.2.2"; -const std::string HARDCODED_DNS_SERVER = "8.8.8.8"; -const std::string HARDCODED_DOMAIN_NAME = "isc.example.org"; -const std::string HARDCODED_SERVER_ID = "10.3.1.1";
+const std::string HARDCODED_GATEWAY = "192.0.2.1"; +const std::string HARDCODED_DNS_SERVER = "192.0.2.2"; +const std::string HARDCODED_DOMAIN_NAME = "isc.example.com"; +const std::string HARDCODED_SERVER_ID = "192.0.2.1";
Lease database and configuration support is planned for 2012.
This are the current limitations of DHCPv4 server software. Most of them are reflection of the early stage of development. -
Table of Contents
Table of Contents
libdhcp++ is a common library written in C++ that is + only. See the section called “Interface detection” for details.
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is + specified in RFC3315. BIND10 provides DHCPv6 server implementation + that is described in this chapter. For DHCPv4 server + implementation, see Chapter 12, DHCPv4 Server. +
+ As of December 2011, both DHCPv4 and DHCPv6 components are + skeleton servers. That means that while they are capable of + performing DHCP configuration, they are not fully functional + yet. In particular, both do not have functional lease + databases. This means that they will assign the same, fixed, + hardcoded addresses to any client that will ask. See the section called “DHCPv4 Server Limitations” and the section called “DHCPv6 Server Limitations” for + detailed description. +
+ BIND10 provides DHCPv6 server component since September + 2011. It is currently described as skeleton server and can be + described as an early prototype that is not yet fully + functional. It is mature enough to conduct first tests in lab + environment, but it has significant limitations. See the section called “DHCPv6 Server Limitations” for details. +
+ DHCPv6 server is implemented as b10-dhcp6 + daemon. As it is configurable yet, it is fully autonomous, + i.e. it does not interact with b10-cfgmgr. + To start DHCPv6 server, simply input: + +
+#cd src/bin/dhcp6+#./b10-dhcp6+
+ + Depending on your installation, b10-dhcp6 + binary may reside in src/bin/dhcp6 in your source code + directory, in /usr/local/bin/b10-dhcp6 or other directory + you specified during compilation. + + Afre start, server will detect available network interfaces + and will attempt to open UDP sockets on all interfaces that + are up, running, are not loopback and have IPv4 address + assigned. + + Server will then listen to incoming traffic. Currently + supported client messages are SOLICIT and REQUEST. Server + will respond to them with ADVERTISE and REPLY, respectively. + + As DHCPv6 server opens privileged ports, it requires root + access. Make sure you run this daemon as root. +
+ DHCPv4 server does not have lease database implemented yet + or any support for configuration, so every time the same set + of configuration options (including the same fixed address) + will be assigned every time. +
+ At this stage of development, the only way to alter server + configuration is to tweak its source code. To do so, please edit + src/bin/dhcp6/dhcp6_srv.cc file and modify following parameters: +
+const std::string HARDCODED_LEASE = "2001:db8:1::1234:abcd"; +const uint32_t HARDCODED_T1 = 1500; // in seconds +const uint32_t HARDCODED_T2 = 2600; // in seconds +const uint32_t HARDCODED_PREFERRED_LIFETIME = 3600; // in seconds +const uint32_t HARDCODED_VALID_LIFETIME = 7200; // in seconds +const std::string HARDCODED_DNS_SERVER = "2001:db8:1::1";
+ + Lease database and configuration support is planned for 2012. +
+
+
Table of Contents
libdhcp++ is a common library written in C++ that is handles many DHCP-related tasks, like DHCPv4 and DHCPv6 packets parsing, manipulation and assembly, option parsing, manipulation and assembly, network interface detection and socket operations. @@ -1038,7 +1124,7 @@ eth0 fe80::21e:8cff:fe9b:7349 # For DHCPv4, please use following format: #eth0 192.0.2.5
-
The b10-stats process is started by bind10. It periodically collects statistics data from various modules @@ -1072,7 +1158,7 @@ eth0 fe80::21e:8cff:fe9b:7349 } }
-
The logging system in BIND 10 is configured through the Logging module. All BIND 10 modules will look at the @@ -1081,7 +1167,7 @@ eth0 fe80::21e:8cff:fe9b:7349 -
+
Within BIND 10, a message is logged through a component
called a "logger". Different parts of BIND 10 log messages
@@ -1102,7 +1188,7 @@ eth0 fe80::21e:8cff:fe9b:7349
(what to log), and the output_options
(where to log).
-
+
Each logger in the system has a name, the name being that of the component using it to log messages. For instance, if you want to configure logging for the resolver module, @@ -1175,7 +1261,7 @@ eth0 fe80::21e:8cff:fe9b:7349 “Auth.cache” logger will appear in the output with a logger name of “b10-auth.cache”). -
This specifies the category of messages logged. Each message is logged with an associated severity which @@ -1191,7 +1277,7 @@ eth0 fe80::21e:8cff:fe9b:7349 -
Each logger can have zero or more
output_options. These specify where log
@@ -1201,7 +1287,7 @@ eth0 fe80::21e:8cff:fe9b:7349
The other options for a logger are:
-
When a logger's severity is set to DEBUG, this value specifies what debug messages should be printed. It ranges @@ -1210,7 +1296,7 @@ eth0 fe80::21e:8cff:fe9b:7349 If severity for the logger is not DEBUG, this value is ignored. -
The main settings for an output option are the
destination and a value called
output, the meaning of which depends on
the destination that is set.
-
+
Depending on what is set as the output destination, this
value is interpreted as follows:
@@ -1257,12 +1343,12 @@ eth0 fe80::21e:8cff:fe9b:7349
The other options for output_options are:
-
+
Flush buffers after each log message. Doing this will reduce performance but will ensure that if the program terminates abnormally, all messages up to the point of termination are output. -
Only relevant when destination is file, this is maximum file size of output files in bytes. When the maximum size is reached, the file is renamed and a new file opened. @@ -1271,11 +1357,11 @@ eth0 fe80::21e:8cff:fe9b:7349 etc.)
If this is 0, no maximum file size is used. -
Each message written by BIND 10 to the configured logging
destinations comprises a number of components that identify
the origin of the message and, if the message indicates
diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml
index c4f02680b9..4fb781d56e 100644
--- a/doc/guide/bind10-guide.xml
+++ b/doc/guide/bind10-guide.xml
@@ -1817,7 +1817,8 @@ then change those defaults with config set Resolver/forward_addresses[0]/address
clients. Even though principles of both DHCPv4 and DHCPv6 are
somewhat similar, these are two radically different
protocols. BIND10 offers server implementations for both DHCPv4
- and DHCPv6.
+ and DHCPv6. This chapter is about DHCP for IPv4. For description of
+ DHCPv6 server, see