|
|
@@ -2,19 +2,19 @@
|
|
|
|
|
|
Administrator Reference for BIND 10
|
|
|
|
|
|
- This is the reference guide for BIND 10 version 20120405.
|
|
|
+ This is the reference guide for BIND 10 version 20120712.
|
|
|
|
|
|
Copyright (c) 2010-2012 Internet Systems Consortium, Inc.
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
BIND 10 is a framework that features Domain Name System (DNS) suite and
|
|
|
- Dynamic Host Configuration Protocol (DHCP) servers managed by Internet
|
|
|
- Systems Consortium (ISC). It includes DNS libraries, modular components
|
|
|
- for controlling authoritative and recursive DNS servers, and experimental
|
|
|
- DHCPv4 and DHCPv6 servers.
|
|
|
+ Dynamic Host Configuration Protocol (DHCP) servers with development
|
|
|
+ managed by Internet Systems Consortium (ISC). It includes DNS libraries,
|
|
|
+ modular components for controlling authoritative and recursive DNS
|
|
|
+ servers, and experimental DHCPv4 and DHCPv6 servers.
|
|
|
|
|
|
- This is the reference guide for BIND 10 version 20120405. The most
|
|
|
+ This is the reference guide for BIND 10 version 20120712. 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.
|
|
|
@@ -31,7 +31,7 @@ Administrator Reference for BIND 10
|
|
|
|
|
|
1.1. Supported Platforms
|
|
|
|
|
|
- 1.2. Required Software
|
|
|
+ 1.2. Required Software at Run-time
|
|
|
|
|
|
1.3. Starting and Stopping the Server
|
|
|
|
|
|
@@ -39,29 +39,31 @@ Administrator Reference for BIND 10
|
|
|
|
|
|
2. Installation
|
|
|
|
|
|
- 2.1. Building Requirements
|
|
|
+ 2.1. Packages
|
|
|
+
|
|
|
+ 2.2. Install Hierarchy
|
|
|
|
|
|
- 2.2. Quick start
|
|
|
+ 2.3. Building Requirements
|
|
|
|
|
|
- 2.3. Installation from source
|
|
|
+ 2.4. Quick start
|
|
|
|
|
|
- 2.3.1. Download Tar File
|
|
|
+ 2.5. Installation from source
|
|
|
|
|
|
- 2.3.2. Retrieve from Git
|
|
|
+ 2.5.1. Download Tar File
|
|
|
|
|
|
- 2.3.3. Configure before the build
|
|
|
+ 2.5.2. Retrieve from Git
|
|
|
|
|
|
- 2.3.4. Build
|
|
|
+ 2.5.3. Configure before the build
|
|
|
|
|
|
- 2.3.5. Install
|
|
|
+ 2.5.4. Build
|
|
|
|
|
|
- 2.3.6. Install Hierarchy
|
|
|
+ 2.5.5. Install
|
|
|
|
|
|
3. Starting BIND10 with bind10
|
|
|
|
|
|
3.1. Starting BIND 10
|
|
|
|
|
|
- 3.2. Configuration of started processes
|
|
|
+ 3.2. Configuration to start processes
|
|
|
|
|
|
4. Command channel
|
|
|
|
|
|
@@ -81,7 +83,7 @@ Administrator Reference for BIND 10
|
|
|
|
|
|
8.2.1. In-memory Data Source
|
|
|
|
|
|
- 8.2.2. In-memory Data Source With SQLite3
|
|
|
+ 8.2.2. In-memory Data Source with SQLite3
|
|
|
Backend
|
|
|
|
|
|
8.2.3. Reloading an In-memory Data Source
|
|
|
@@ -160,7 +162,7 @@ Administrator Reference for BIND 10
|
|
|
|
|
|
List of Tables
|
|
|
|
|
|
- 3.1.
|
|
|
+ 3.1. Special startup components
|
|
|
|
|
|
Preface
|
|
|
|
|
|
@@ -179,33 +181,41 @@ Chapter 1. Introduction
|
|
|
|
|
|
1.1. Supported Platforms
|
|
|
|
|
|
- 1.2. Required Software
|
|
|
+ 1.2. Required Software at Run-time
|
|
|
|
|
|
1.3. Starting and Stopping the Server
|
|
|
|
|
|
1.4. Managing BIND 10
|
|
|
|
|
|
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 and provides a modular environment for serving and maintaining
|
|
|
- DNS. BIND 10 provides a EDNS0- and DNSSEC-capable authoritative DNS server
|
|
|
- and a caching recursive name server which also provides forwarding.
|
|
|
+ and DNS tools. BIND 10 is a rewrite of BIND 9 and ISC DHCP. BIND 10 is
|
|
|
+ written in C++ and Python and provides a modular environment for serving,
|
|
|
+ maintaining, and developing DNS and DHCP. BIND 10 provides a EDNS0- and
|
|
|
+ DNSSEC-capable authoritative DNS server and a caching recursive name
|
|
|
+ server which also provides forwarding. It also provides experimental
|
|
|
+ DHCPv4 and DHCPv6 servers.
|
|
|
|
|
|
- This guide covers the experimental prototype of BIND 10 version 20120405.
|
|
|
+ This guide covers the experimental prototype of BIND 10 version 20120712.
|
|
|
|
|
|
1.1. Supported Platforms
|
|
|
|
|
|
BIND 10 builds have been tested on (in no particular order) Debian
|
|
|
- GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5, Solaris 10 and 11,
|
|
|
+ GNU/Linux 6 and unstable, Ubuntu 9.10, NetBSD 5, Solaris 10 and 11,
|
|
|
FreeBSD 7 and 8, CentOS Linux 5.3, MacOS 10.6 and 10.7, and OpenBSD 5.1.
|
|
|
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.
|
|
|
|
|
|
-1.2. Required Software
|
|
|
+1.2. Required Software at Run-time
|
|
|
+
|
|
|
+ Running BIND 10 uses various extra software which may not be provided in
|
|
|
+ some operating systems' default installations nor standard packages
|
|
|
+ collections. You may need to install this required software separately.
|
|
|
+ (For the build requirements, also see Section 2.3, "Building
|
|
|
+ Requirements".)
|
|
|
|
|
|
- BIND 10 requires at least Python 3.1 (http://www.python.org/). It has also
|
|
|
- been tested with Python 3.2.
|
|
|
+ BIND 10 requires at least Python 3.1 (http://www.python.org/). It also
|
|
|
+ works with Python 3.2.
|
|
|
|
|
|
BIND 10 uses the Botan crypto library for C++
|
|
|
(http://botan.randombit.net/). It requires at least Botan version 1.8.
|
|
|
@@ -219,16 +229,9 @@ Chapter 1. Introduction
|
|
|
|
|
|
The b10-ddns, b10-xfrin, b10-xfrout, and b10-zonemgr components require
|
|
|
the libpython3 library and the Python _sqlite3.so module (which is
|
|
|
- included with Python). The b10-stats-httpd component uses the Python
|
|
|
- pyexpat.so module. The Python modules need to be built for the
|
|
|
+ included with Python). Python modules need to be built for the
|
|
|
corresponding Python 3.
|
|
|
|
|
|
- Note
|
|
|
-
|
|
|
- Some operating systems do not provide these dependencies in their default
|
|
|
- installation nor standard packages collections. You may need to install
|
|
|
- them separately.
|
|
|
-
|
|
|
1.3. Starting and Stopping the Server
|
|
|
|
|
|
BIND 10 is modular. Part of this modularity is accomplished using multiple
|
|
|
@@ -254,7 +257,8 @@ Chapter 1. Introduction
|
|
|
o b10-msgq -- Message bus daemon. This process coordinates communication
|
|
|
between all of the other BIND 10 processes.
|
|
|
o b10-resolver -- Recursive name server. This process handles incoming
|
|
|
- queries.
|
|
|
+ DNS queries and provides answers from its cache or by recursively
|
|
|
+ doing remote lookups.
|
|
|
o b10-sockcreator -- Socket creator daemon. This process creates sockets
|
|
|
used by network-listening BIND 10 processes.
|
|
|
o b10-stats -- Statistics collection daemon. This process collects and
|
|
|
@@ -266,23 +270,25 @@ Chapter 1. Introduction
|
|
|
server.
|
|
|
o b10-xfrout -- Outgoing zone transfer service. This process is used to
|
|
|
handle transfer requests to send a local zone to a remote secondary
|
|
|
- server, when acting as a master server.
|
|
|
- o b10-zonemgr -- Secondary manager. This process keeps track of timers
|
|
|
- and other necessary information for BIND 10 to act as a slave server.
|
|
|
+ server.
|
|
|
+ o b10-zonemgr -- Secondary zone manager. This process keeps track of
|
|
|
+ timers and other necessary information for BIND 10 to act as a slave
|
|
|
+ server.
|
|
|
|
|
|
- These are ran automatically by bind10 and do not need to be run manually.
|
|
|
+ These are ran by bind10 and do not need to be manually started
|
|
|
+ independently.
|
|
|
|
|
|
1.4. Managing BIND 10
|
|
|
|
|
|
Once BIND 10 is running, a few commands are used to interact directly with
|
|
|
the system:
|
|
|
|
|
|
- o bindctl -- interactive administration interface. This is a low-level
|
|
|
+ o bindctl -- Interactive administration interface. This is a low-level
|
|
|
command-line tool which allows a developer or an experienced
|
|
|
administrator to control BIND 10.
|
|
|
- o b10-loadzone -- zone file loader. This tool will load standard
|
|
|
+ o b10-loadzone -- Zone file loader. This tool will load standard
|
|
|
masterfile-format zone files into BIND 10.
|
|
|
- o b10-cmdctl-usermgr -- user access control. This tool allows an
|
|
|
+ o b10-cmdctl-usermgr -- User access control. This tool allows an
|
|
|
administrator to authorize additional users to manage BIND 10.
|
|
|
|
|
|
The tools and modules are covered in full detail in this guide. In
|
|
|
@@ -296,28 +302,59 @@ Chapter 2. Installation
|
|
|
|
|
|
Table of Contents
|
|
|
|
|
|
- 2.1. Building Requirements
|
|
|
+ 2.1. Packages
|
|
|
+
|
|
|
+ 2.2. Install Hierarchy
|
|
|
+
|
|
|
+ 2.3. Building Requirements
|
|
|
|
|
|
- 2.2. Quick start
|
|
|
+ 2.4. Quick start
|
|
|
|
|
|
- 2.3. Installation from source
|
|
|
+ 2.5. Installation from source
|
|
|
|
|
|
- 2.3.1. Download Tar File
|
|
|
+ 2.5.1. Download Tar File
|
|
|
|
|
|
- 2.3.2. Retrieve from Git
|
|
|
+ 2.5.2. Retrieve from Git
|
|
|
|
|
|
- 2.3.3. Configure before the build
|
|
|
+ 2.5.3. Configure before the build
|
|
|
|
|
|
- 2.3.4. Build
|
|
|
+ 2.5.4. Build
|
|
|
|
|
|
- 2.3.5. Install
|
|
|
+ 2.5.5. Install
|
|
|
|
|
|
- 2.3.6. Install Hierarchy
|
|
|
+2.1. Packages
|
|
|
|
|
|
-2.1. Building Requirements
|
|
|
+ Some operating systems or softare package vendors may provide
|
|
|
+ ready-to-use, pre-built software packages for the BIND 10 suite.
|
|
|
+ Installing a pre-built package means you do not need to install build-only
|
|
|
+ prerequisites and do not need to make the software.
|
|
|
|
|
|
- In addition to the run-time requirements, building BIND 10 from source
|
|
|
- code requires various development include headers.
|
|
|
+ FreeBSD ports, NetBSD pkgsrc, and Debian testing package collections
|
|
|
+ provide all the prerequisite packages.
|
|
|
+
|
|
|
+2.2. Install Hierarchy
|
|
|
+
|
|
|
+ The following is the standard, common layout of the complete BIND 10
|
|
|
+ installation:
|
|
|
+
|
|
|
+ o bin/ -- general tools and diagnostic clients.
|
|
|
+ o etc/bind10-devel/ -- configuration files.
|
|
|
+ o lib/ -- libraries and python modules.
|
|
|
+ o libexec/bind10-devel/ -- executables that a user wouldn't normally run
|
|
|
+ directly and are not run independently. These are the BIND 10 modules
|
|
|
+ which are daemons started by the bind10 tool.
|
|
|
+ o sbin/ -- commands used by the system administrator.
|
|
|
+ o share/bind10-devel/ -- configuration specifications.
|
|
|
+ o share/doc/bind10-devel/ -- this guide and other supplementary
|
|
|
+ documentation.
|
|
|
+ o share/man/ -- manual pages (online documentation).
|
|
|
+ o var/bind10-devel/ -- data source and configuration databases.
|
|
|
+
|
|
|
+2.3. Building Requirements
|
|
|
+
|
|
|
+ In addition to the run-time requirements (listed in Section 1.2, "Required
|
|
|
+ Software at Run-time"), building BIND 10 from source code requires various
|
|
|
+ development include headers and program development tools.
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -337,10 +374,11 @@ Chapter 2. Installation
|
|
|
g++ 3.4.3, 4.1.2, 4.1.3, 4.2.1, 4.3.2, and 4.4.1; Clang++ 2.8; and Sun C++
|
|
|
5.10.
|
|
|
|
|
|
- Visit the wiki at http://bind10.isc.org/wiki/SystemSpecificNotes for
|
|
|
- system-specific installation tips.
|
|
|
+ Visit the user-contributed wiki at
|
|
|
+ http://bind10.isc.org/wiki/SystemSpecificNotes for system-specific
|
|
|
+ installation tips.
|
|
|
|
|
|
-2.2. Quick start
|
|
|
+2.4. Quick start
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -385,14 +423,14 @@ Chapter 2. Installation
|
|
|
|
|
|
10. Test the new zone.
|
|
|
|
|
|
-2.3. Installation from source
|
|
|
+2.5. Installation from source
|
|
|
|
|
|
BIND 10 is open source software written in C++ and Python. It is freely
|
|
|
- available in source code form from ISC via 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.
|
|
|
+ available in source code form from ISC as a downloadable tar file or via
|
|
|
+ BIND 10's Git code revision control service. (It may also be available in
|
|
|
+ pre-compiled ready-to-use packages from operating system vendors.)
|
|
|
|
|
|
- 2.3.1. Download Tar File
|
|
|
+ 2.5.1. Download Tar File
|
|
|
|
|
|
Downloading a release tar file is the recommended method to obtain the
|
|
|
source code.
|
|
|
@@ -401,7 +439,7 @@ Chapter 2. Installation
|
|
|
ftp://ftp.isc.org/isc/bind10/. Periodic development snapshots may also be
|
|
|
available.
|
|
|
|
|
|
- 2.3.2. Retrieve from Git
|
|
|
+ 2.5.2. Retrieve from Git
|
|
|
|
|
|
Downloading this "bleeding edge" code is recommended only for developers
|
|
|
or advanced users. Using development code in a production environment is
|
|
|
@@ -409,14 +447,14 @@ Chapter 2. Installation
|
|
|
|
|
|
Note
|
|
|
|
|
|
- When using source code retrieved via Git additional software will be
|
|
|
+ When using source code retrieved via Git, additional software will be
|
|
|
required: automake (v1.11 or newer), libtoolize, and autoconf (2.59 or
|
|
|
newer). These may need to be installed.
|
|
|
|
|
|
- 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 Git and all the BIND 10 development is public.
|
|
|
- The leading development is done in the "master".
|
|
|
+ The latest development code (and temporary experiments and un-reviewed
|
|
|
+ code) is available via the BIND 10 code revision control system. This is
|
|
|
+ powered by Git and all the BIND 10 development is public. The leading
|
|
|
+ development is done in the "master" branch.
|
|
|
|
|
|
The code can be checked out from git://git.bind10.isc.org/bind10; for
|
|
|
example:
|
|
|
@@ -424,19 +462,19 @@ Chapter 2. Installation
|
|
|
$ git clone git://git.bind10.isc.org/bind10
|
|
|
|
|
|
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
|
|
|
+ doesn't include the generated configure script, Makefile.in files, nor
|
|
|
+ their related build files. They can be created by running autoreconf with
|
|
|
the --install switch. This will run autoconf, aclocal, libtoolize,
|
|
|
autoheader, automake, and related commands.
|
|
|
|
|
|
- 2.3.3. Configure before the build
|
|
|
+ 2.5.3. Configure before the build
|
|
|
|
|
|
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
|
|
|
+ Run ./configure with the --help switch to view the different options. Some
|
|
|
commonly-used options are:
|
|
|
|
|
|
--prefix
|
|
|
@@ -464,14 +502,14 @@ Chapter 2. Installation
|
|
|
|
|
|
If the configure fails, it may be due to missing or old dependencies.
|
|
|
|
|
|
- 2.3.4. Build
|
|
|
+ 2.5.4. Build
|
|
|
|
|
|
After the configure step is complete, to build the executables from the
|
|
|
C++ code and prepare the Python scripts, run:
|
|
|
|
|
|
$ make
|
|
|
|
|
|
- 2.3.5. Install
|
|
|
+ 2.5.5. Install
|
|
|
|
|
|
To install the BIND 10 executables, support files, and documentation, run:
|
|
|
|
|
|
@@ -481,28 +519,13 @@ Chapter 2. Installation
|
|
|
|
|
|
The install step may require superuser privileges.
|
|
|
|
|
|
- 2.3.6. Install Hierarchy
|
|
|
-
|
|
|
- The following is the layout of the complete BIND 10 installation:
|
|
|
-
|
|
|
- o bin/ -- general tools and diagnostic clients.
|
|
|
- o etc/bind10-devel/ -- configuration files.
|
|
|
- o lib/ -- libraries and python modules.
|
|
|
- o libexec/bind10-devel/ -- executables that a user wouldn't normally run
|
|
|
- directly and are not run independently. These are the BIND 10 modules
|
|
|
- which are daemons started by the bind10 tool.
|
|
|
- o sbin/ -- commands used by the system administrator.
|
|
|
- o share/bind10-devel/ -- configuration specifications.
|
|
|
- o share/man/ -- manual pages (online documentation).
|
|
|
- o var/bind10-devel/ -- data source and configuration databases.
|
|
|
-
|
|
|
Chapter 3. Starting BIND10 with bind10
|
|
|
|
|
|
Table of Contents
|
|
|
|
|
|
3.1. Starting BIND 10
|
|
|
|
|
|
- 3.2. Configuration of started processes
|
|
|
+ 3.2. Configuration to start processes
|
|
|
|
|
|
BIND 10 provides the bind10 command which starts up the required
|
|
|
processes. bind10 will also restart some processes that exit unexpectedly.
|
|
|
@@ -517,7 +540,8 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
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
|
|
|
- b10-sockcreator will allocate sockets for the rest of the system.
|
|
|
+ b10-sockcreator daemon helps allocate Internet addresses and ports as
|
|
|
+ needed for BIND 10 network services.
|
|
|
|
|
|
In its default configuration, the bind10 master process will also start up
|
|
|
b10-cmdctl for administration tools to communicate with the system, and
|
|
|
@@ -534,17 +558,15 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
names for the Python-based daemons will be renamed to better identify them
|
|
|
instead of just "python". This is not needed on some operating systems.
|
|
|
|
|
|
-3.2. Configuration of started processes
|
|
|
-
|
|
|
- The processes to be started can be configured, with the exception of the
|
|
|
- b10-sockcreator, b10-msgq and b10-cfgmgr.
|
|
|
+3.2. Configuration to start processes
|
|
|
|
|
|
- The configuration is in the Boss/components section. Each element
|
|
|
- represents one component, which is an abstraction of a process (currently
|
|
|
- there's also one component which doesn't represent a process).
|
|
|
+ The processes to be used can be configured for bind10 to start, with the
|
|
|
+ exception of the required b10-sockcreator, b10-msgq and b10-cfgmgr
|
|
|
+ components. The configuration is in the Boss/components section. Each
|
|
|
+ element represents one component, which is an abstraction of a process.
|
|
|
|
|
|
- To add a process to the set, let's say the resolver (which not started by
|
|
|
- default), you would do this:
|
|
|
+ To add a process to the set, let's say the resolver (which is not started
|
|
|
+ by default), you would do this:
|
|
|
|
|
|
> config add Boss/components b10-resolver
|
|
|
> config set Boss/components/b10-resolver/special resolver
|
|
|
@@ -552,32 +574,31 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
> config set Boss/components/b10-resolver/priority 10
|
|
|
> config commit
|
|
|
|
|
|
- Now, what it means. We add an entry called b10-resolver. It is both a name
|
|
|
- used to reference this component in the configuration and the name of the
|
|
|
- process to start. Then we set some parameters on how to start it.
|
|
|
+ Now, what it means. We add an entry called "b10-resolver". It is both a
|
|
|
+ name used to reference this component in the configuration and the name of
|
|
|
+ the process to start. Then we set some parameters on how to start it.
|
|
|
|
|
|
- The special one is for components that need some kind of special care
|
|
|
+ The special setting is for components that need some kind of special care
|
|
|
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
|
|
|
+ a 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.
|
|
|
+ Table 3.1. Special startup components
|
|
|
|
|
|
- +------------------------------------------------------------------------+
|
|
|
- | Component | Special | Description |
|
|
|
- |--------------+----------+----------------------------------------------|
|
|
|
- | b10-auth | auth | Authoritative server |
|
|
|
- |--------------+----------+----------------------------------------------|
|
|
|
- | b10-resolver | resolver | The resolver |
|
|
|
- |--------------+----------+----------------------------------------------|
|
|
|
- | b10-cmdctl | cmdctl | The command control (remote control |
|
|
|
- | | | interface) |
|
|
|
- +------------------------------------------------------------------------+
|
|
|
+ +----------------------------------------------------------------------+
|
|
|
+ | Component | Special | Description |
|
|
|
+ |--------------+----------+--------------------------------------------|
|
|
|
+ | b10-auth | auth | Authoritative DNS server |
|
|
|
+ |--------------+----------+--------------------------------------------|
|
|
|
+ | b10-resolver | resolver | DNS resolver |
|
|
|
+ |--------------+----------+--------------------------------------------|
|
|
|
+ | b10-cmdctl | cmdctl | Command control (remote control interface) |
|
|
|
+ +----------------------------------------------------------------------+
|
|
|
|
|
|
The kind specifies how a failure of the component should be handled. If it
|
|
|
is set to "dispensable" (the default unless you set something else), it
|
|
|
will get started again if it fails. If it is set to "needed" and it fails
|
|
|
- at startup, the whole bind10 shuts down and exits with error exit code.
|
|
|
+ at startup, the whole bind10 shuts down and exits with an error exit code.
|
|
|
But if it fails some time later, it is just started again. If you set it
|
|
|
to "core", you indicate that the system is not usable without the
|
|
|
component and if such component fails, the system shuts down no matter
|
|
|
@@ -587,27 +608,20 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
fail).
|
|
|
|
|
|
The priority defines order in which the components should start. The ones
|
|
|
- with higher number are started sooner than the ones with lower ones. If
|
|
|
+ with higher numbers are started sooner than the ones with lower ones. If
|
|
|
you don't set it, 0 (zero) is used as the priority. Usually, leaving it at
|
|
|
the default is enough.
|
|
|
|
|
|
There are other parameters we didn't use in our example. One of them is
|
|
|
- "address". It is the address used by the component on the b10-msgq message
|
|
|
+ address. It is the address used by the component on the b10-msgq message
|
|
|
bus. The special components already know their address, but the usual ones
|
|
|
don't. The address is by convention the thing after b10-, with the first
|
|
|
letter capitalized (eg. b10-stats would have "Stats" as its address).
|
|
|
|
|
|
The last one is process. It is the name of the process to be started. It
|
|
|
defaults to the name of the component if not set, but you can use this to
|
|
|
- override it.
|
|
|
-
|
|
|
- Note
|
|
|
-
|
|
|
- This system allows you to start the same component multiple times (by
|
|
|
- including it in the configuration with different names, but the same
|
|
|
- process setting). However, the rest of the system doesn't expect such a
|
|
|
- situation, so it would probably not do what you want. Such support is yet
|
|
|
- to be implemented.
|
|
|
+ override it. (The special components also already know their executable
|
|
|
+ name.)
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -621,7 +635,7 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
In short, you should think twice before disabling something here.
|
|
|
|
|
|
It is possible to start some components multiple times (currently b10-auth
|
|
|
- and b10-resolzer). You might want to do that to gain more performance
|
|
|
+ and b10-resolver). You might want to do that to gain more performance
|
|
|
(each one uses only single core). Just put multiple entries under
|
|
|
different names, like this, with the same config:
|
|
|
|
|
|
@@ -634,7 +648,9 @@ Chapter 3. Starting BIND10 with bind10
|
|
|
example, each resolver will have its own cache, each authoritative server
|
|
|
will keep its own copy of in-memory data and there could be problems with
|
|
|
locking the sqlite database, if used. The configuration might be changed
|
|
|
- to something more convenient in future.
|
|
|
+ to something more convenient in future. Other components don't expect such
|
|
|
+ a situation, so it would probably not do what you want. Such support is
|
|
|
+ yet to be implemented.
|
|
|
|
|
|
Chapter 4. Command channel
|
|
|
|
|
|
@@ -647,8 +663,9 @@ Chapter 4. Command channel
|
|
|
10 system.
|
|
|
|
|
|
Administrators do not communicate directly with the b10-msgq daemon. By
|
|
|
- default, BIND 10 uses port 9912 for the b10-msgq service. It listens on
|
|
|
- 127.0.0.1.
|
|
|
+ default, BIND 10 uses a UNIX domain socket file named
|
|
|
+ /usr/local/var/bind10-devel/msg_socket for this interprocess
|
|
|
+ communication.
|
|
|
|
|
|
Chapter 5. Configuration manager
|
|
|
|
|
|
@@ -672,13 +689,11 @@ Chapter 5. Configuration manager
|
|
|
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.
|
|
|
+ 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-devel/b10-config.db. (The full path is what was
|
|
|
+ /usr/local/var/bind10-devel/b10-config.db. (The directory 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
|
|
|
@@ -742,10 +757,13 @@ Chapter 6. Remote control daemon
|
|
|
|
|
|
6.1. Configuration specification for b10-cmdctl
|
|
|
|
|
|
- The configuration items for b10-cmdctl are: key_file cert_file
|
|
|
- accounts_file
|
|
|
-
|
|
|
- The control commands are: print_settings shutdown
|
|
|
+ The configuration items for b10-cmdctl are: accounts_file which defines
|
|
|
+ the path to the user accounts database (the default is
|
|
|
+ /usr/local/etc/bind10-devel/cmdctl-accounts.csv); cert_file which defines
|
|
|
+ the path to the PEM certificate file (the default is
|
|
|
+ /usr/local/etc/bind10-devel/cmdctl-certfile.pem); and key_file which
|
|
|
+ defines the path to the PEM private key file (the default is
|
|
|
+ /usr/local/etc/bind10-devel/cmdctl-keyfile.pem).
|
|
|
|
|
|
Chapter 7. Control and configure user interface
|
|
|
|
|
|
@@ -777,7 +795,7 @@ Chapter 8. Authoritative Server
|
|
|
|
|
|
8.2.1. In-memory Data Source
|
|
|
|
|
|
- 8.2.2. In-memory Data Source With SQLite3 Backend
|
|
|
+ 8.2.2. In-memory Data Source with SQLite3 Backend
|
|
|
|
|
|
8.2.3. Reloading an In-memory Data Source
|
|
|
|
|
|
@@ -785,9 +803,9 @@ Chapter 8. Authoritative Server
|
|
|
|
|
|
8.3. Loading Master Zones Files
|
|
|
|
|
|
- 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.
|
|
|
+ The b10-auth is the authoritative DNS server. It supports EDNS0, DNSSEC,
|
|
|
+ IPv6, and SQLite3 and in-memory zone data backends. Normally it is started
|
|
|
+ by the bind10 master process.
|
|
|
|
|
|
8.1. Server Configurations
|
|
|
|
|
|
@@ -796,15 +814,16 @@ Chapter 8. Authoritative Server
|
|
|
|
|
|
database_file
|
|
|
This is an optional string to define the path to find the SQLite3
|
|
|
- database file. Note: Later the DNS server will use various data
|
|
|
- source backends. This may be a temporary setting until then.
|
|
|
+ database file. Note: This may be a temporary setting because the
|
|
|
+ DNS server can use various data source backends.
|
|
|
|
|
|
datasources
|
|
|
datasources configures data sources. The list items include: type
|
|
|
to define the required data source type (such as "memory"); class
|
|
|
to optionally select the class (it defaults to "IN"); and zones to
|
|
|
- define the file path name, the filetype (e.g., sqlite3), and the
|
|
|
- origin (default domain). By default, this is empty.
|
|
|
+ define the file path name, the filetype ("sqlite3" to load from a
|
|
|
+ SQLite3 database file or "text" to load from a master text file),
|
|
|
+ and the origin (default domain). By default, this is empty.
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -894,10 +913,10 @@ Chapter 8. Authoritative Server
|
|
|
> config set Auth/datasources[0]/zones[0]/file "example.com.zone"
|
|
|
> config commit
|
|
|
|
|
|
- The authoritative server will begin serving it immediately after it is
|
|
|
- loaded.
|
|
|
+ The authoritative server will begin serving it immediately after the zone
|
|
|
+ data is loaded from the master text file.
|
|
|
|
|
|
- 8.2.2. In-memory Data Source With SQLite3 Backend
|
|
|
+ 8.2.2. In-memory Data Source with SQLite3 Backend
|
|
|
|
|
|
The following commands to bindctl provide an example of configuring an
|
|
|
in-memory data source containing the "example.org" zone with a SQLite3
|
|
|
@@ -911,8 +930,8 @@ Chapter 8. Authoritative Server
|
|
|
> config set Auth/datasources[1]/zones[0]/filetype "sqlite3"
|
|
|
> config commit
|
|
|
|
|
|
- The authoritative server will begin serving it immediately after it is
|
|
|
- loaded.
|
|
|
+ The authoritative server will begin serving it immediately after the zone
|
|
|
+ data is loaded from the database file.
|
|
|
|
|
|
8.2.3. Reloading an In-memory Data Source
|
|
|
|
|
|
@@ -987,7 +1006,7 @@ Chapter 9. Incoming Zone Transfers
|
|
|
started by bind10. When received, the zone is stored in the corresponding
|
|
|
BIND 10 data source, and its records can be served by b10-auth. In
|
|
|
combination with b10-zonemgr (for automated SOA checks), this allows the
|
|
|
- BIND 10 server to provide "secondary" service.
|
|
|
+ BIND 10 server to provide secondary service.
|
|
|
|
|
|
The b10-xfrin process supports both AXFR and IXFR. Due to some
|
|
|
implementation limitations of the current development release, however, it
|
|
|
@@ -1052,7 +1071,6 @@ Chapter 9. Incoming Zone Transfers
|
|
|
|
|
|
> config add Zonemgr/secondary_zones
|
|
|
> config set Zonemgr/secondary_zones[0]/name "example.com"
|
|
|
- > config set Zonemgr/secondary_zones[0]/class "IN"
|
|
|
> config commit
|
|
|
|
|
|
If the zone does not exist in the data source already (i.e. no SOA record
|
|
|
@@ -1076,15 +1094,15 @@ Chapter 9. Incoming Zone Transfers
|
|
|
|
|
|
The administrator doesn't have to do anything for b10-auth to serve the
|
|
|
new version of the zone, except for the configuration such as the one
|
|
|
- described in Section 8.2.2, "In-memory Data Source With SQLite3 Backend".
|
|
|
+ described in Section 8.2.2, "In-memory Data Source with SQLite3 Backend".
|
|
|
|
|
|
Chapter 10. Outbound Zone Transfers
|
|
|
|
|
|
The b10-xfrout process is started by bind10. When the b10-auth
|
|
|
authoritative DNS server receives an AXFR or IXFR request, b10-auth
|
|
|
internally forwards the request to b10-xfrout, which handles the rest of
|
|
|
- request processing. This is used to provide primary DNS service to share
|
|
|
- zones to secondary name servers. The b10-xfrout is also used to send
|
|
|
+ this request processing. This is used to provide primary DNS service to
|
|
|
+ share zones to secondary name servers. The b10-xfrout is also used to send
|
|
|
NOTIFY messages to secondary servers.
|
|
|
|
|
|
A global or per zone transfer_acl configuration can be used to control
|
|
|
@@ -1119,8 +1137,8 @@ Chapter 10. Outbound Zone Transfers
|
|
|
> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]
|
|
|
> config commit
|
|
|
|
|
|
- Both Xfrout and Auth will use the system wide keyring to check TSIGs in
|
|
|
- the incoming messages and to sign responses.
|
|
|
+ Both b10-xfrout and b10-auth will use the system wide keyring to check
|
|
|
+ TSIGs in the incoming messages and to sign responses.
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -1143,15 +1161,15 @@ Chapter 11. Dynamic DNS Update
|
|
|
|
|
|
When the b10-auth authoritative DNS server receives an UPDATE request, it
|
|
|
internally forwards the request to b10-ddns, which handles the rest of
|
|
|
- request processing. When the processing is completed b10-ddns will send a
|
|
|
- response to the client with the RCODE set to the value as specified in RFC
|
|
|
- 2136 (NOERROR for successful update, REFUSED if rejected due to ACL check,
|
|
|
- etc). If the zone has been changed as a result, it will internally notify
|
|
|
- b10-xfrout so that other secondary servers will be notified via the DNS
|
|
|
- notify protocol. In addition, if b10-auth serves the updated zone from its
|
|
|
- in-memory cache (as described in Section 8.2.2, "In-memory Data Source
|
|
|
- With SQLite3 Backend"), b10-ddns will also notify b10-auth so that
|
|
|
- b10-auth will re-cache the updated zone content.
|
|
|
+ this request processing. When the processing is completed, b10-ddns will
|
|
|
+ send a response to the client as specified in RFC 2136 (NOERROR for
|
|
|
+ successful update, REFUSED if rejected due to ACL check, etc). If the zone
|
|
|
+ has been changed as a result, it will internally notify b10-xfrout so that
|
|
|
+ other secondary servers will be notified via the DNS NOTIFY protocol. In
|
|
|
+ addition, if b10-auth serves the updated zone from its in-memory cache (as
|
|
|
+ described in Section 8.2.2, "In-memory Data Source with SQLite3 Backend"),
|
|
|
+ b10-ddns will also notify b10-auth so that b10-auth will re-cache the
|
|
|
+ updated zone content.
|
|
|
|
|
|
The b10-ddns component supports requests over both UDP and TCP, and both
|
|
|
IPv6 and IPv4; for TCP requests, however, it terminates the TCP connection
|
|
|
@@ -1164,13 +1182,13 @@ Chapter 11. Dynamic DNS Update
|
|
|
|
|
|
As of this writing b10-ddns does not support update forwarding for
|
|
|
secondary zones. If it receives an update request for a secondary zone, it
|
|
|
- will immediately return a response with an RCODE of NOTIMP.
|
|
|
+ will immediately return a "not implemented" response.
|
|
|
|
|
|
Note
|
|
|
|
|
|
- For feature completeness update forwarding should be eventually supported.
|
|
|
- But right now it's considered a lower priority task and there is no
|
|
|
- specific plan of implementing this feature.
|
|
|
+ For feature completeness, update forwarding should be eventually
|
|
|
+ supported. But currently it's considered a lower priority task and there
|
|
|
+ is no specific plan of implementing this feature.
|
|
|
|
|
|
11.1. Enabling Dynamic Update
|
|
|
|
|
|
@@ -1186,10 +1204,10 @@ Chapter 11. Dynamic DNS Update
|
|
|
Second, for the obvious reason dynamic update requires that the underlying
|
|
|
data source storing the zone data be writable. In the current
|
|
|
implementation this means the zone must be stored in an SQLite3-based data
|
|
|
- source. Also, right now, the b10-ddns component configures itself with the
|
|
|
- data source referring to the "database_file" configuration parameter of
|
|
|
- b10-auth. So this information must be configured correctly before starting
|
|
|
- b10-ddns.
|
|
|
+ source. Also, in this development version, the b10-ddns component
|
|
|
+ configures itself with the data source referring to the database_file
|
|
|
+ configuration parameter of b10-auth. So this information must be
|
|
|
+ configured correctly before starting b10-ddns.
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -1214,22 +1232,22 @@ Chapter 11. Dynamic DNS Update
|
|
|
|
|
|
Note
|
|
|
|
|
|
- In theory "kind" could be omitted because "dispensable" is its default.
|
|
|
- But there's some peculiar behavior (which should be a bug and should be
|
|
|
- fixed eventually; see Trac ticket #2064) with bindctl and you'll still
|
|
|
- need to specify that explicitly. Likewise, "address" may look unnecessary
|
|
|
- because b10-ddns would start and work without specifying it. But for it to
|
|
|
+ In theory kind could be omitted because "dispensable" is its default. But
|
|
|
+ there's some peculiar behavior (which should be a bug and should be fixed
|
|
|
+ eventually; see Trac ticket #2064) with bindctl and you'll still need to
|
|
|
+ specify that explicitly. Likewise, address may look unnecessary because
|
|
|
+ b10-ddns would start and work without specifying it. But for it to
|
|
|
shutdown gracefully this parameter should also be specified.
|
|
|
|
|
|
11.2. Access Control
|
|
|
|
|
|
- By default b10-ddns rejects any update requests from any clients by
|
|
|
- returning a response with an RCODE of REFUSED. To allow updates to take
|
|
|
- effect, an access control rule (called update ACL) with a policy allowing
|
|
|
- updates must explicitly be configured. Update ACL must be configured per
|
|
|
- zone basis in the "zones" configuration parameter of b10-ddns. This is a
|
|
|
- list of per-zone configurations regarding DDNS. Each list element consists
|
|
|
- of the following parameters:
|
|
|
+ By default, b10-ddns rejects any update requests from any clients by
|
|
|
+ returning a REFUSED response. To allow updates to take effect, an access
|
|
|
+ control rule (called update ACL) with a policy allowing updates must
|
|
|
+ explicitly be configured. Update ACL must be configured per zone basis in
|
|
|
+ the zones configuration parameter of b10-ddns. This is a list of per-zone
|
|
|
+ configurations regarding DDNS. Each list element consists of the following
|
|
|
+ parameters:
|
|
|
|
|
|
origin
|
|
|
The zone's origin name
|
|
|
@@ -1246,14 +1264,12 @@ Chapter 11. Dynamic DNS Update
|
|
|
|
|
|
In general, an update ACL rule that allows an update request should be
|
|
|
configured with a TSIG key. This is an example update ACL that allows
|
|
|
- updates to the zone named "example.org" of RR class "IN" from clients that
|
|
|
- send requests signed with a TSIG whose key name is "key.example.org" (and
|
|
|
- refuses all others):
|
|
|
+ updates to the zone named "example.org" (of default RR class "IN") from
|
|
|
+ clients that send requests signed with a TSIG whose key name is
|
|
|
+ "key.example.org" (and refuses all others):
|
|
|
|
|
|
> config add DDNS/zones
|
|
|
> config set DDNS/zones[0]/origin example.org
|
|
|
- > config set DDNS/zones[0]/class IN
|
|
|
- (Note: "class" can be omitted)
|
|
|
> config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}
|
|
|
> config commit
|
|
|
|
|
|
@@ -1274,10 +1290,10 @@ Chapter 11. Dynamic DNS Update
|
|
|
> config commit
|
|
|
|
|
|
(Note the "add" in the first line. Before this sequence, we have had only
|
|
|
- entry in zones[0]/update_acl. The "add" command with a value (rule) adds a
|
|
|
+ entry in zones[0]/update_acl. The add command with a value (rule) adds a
|
|
|
new entry and sets it to the given rule. Due to a limitation of the
|
|
|
current implementation, it doesn't work if you first try to just add a new
|
|
|
- entry and then set it to a given rule).
|
|
|
+ entry and then set it to a given rule.)
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -1315,9 +1331,9 @@ Chapter 11. Dynamic DNS Update
|
|
|
|
|
|
11.3. Miscellaneous Operational Issues
|
|
|
|
|
|
- Unlike BIND 9, BIND 10 currently does not support automatic resigning of
|
|
|
+ Unlike BIND 9, BIND 10 currently does not support automatic re-signing of
|
|
|
DNSSEC-signed zone when it's updated via DDNS. It could be possible to
|
|
|
- resign the updated zone afterwards or make sure the update request also
|
|
|
+ re-sign the updated zone afterwards or make sure the update request also
|
|
|
updates related DNSSEC records, but that will be pretty error-prone
|
|
|
operation. In general, it's not advisable to allow DDNS for a signed zone
|
|
|
at this moment.
|
|
|
@@ -1331,8 +1347,8 @@ Chapter 11. Dynamic DNS Update
|
|
|
updating secondary zones via DDNS requests, b10-ddns refers to the
|
|
|
"secondary_zones" configuration of b10-zonemgr. Zones listed in
|
|
|
"secondary_zones" will never be updated via DDNS regardless of the update
|
|
|
- ACL configuration; b10-ddns will return a response with an RCODE of
|
|
|
- NOTAUTH as specified in RFC 2136. If you have a "conceptual" secondary
|
|
|
+ ACL configuration; b10-ddns will return a NOTAUTH (server not
|
|
|
+ authoritative for the zone) response. If you have a "conceptual" secondary
|
|
|
zone whose content is a copy of some external source but is not updated
|
|
|
via the standard zone transfers and therefore not listed in
|
|
|
"secondary_zones", be careful not to allow DDNS for the zone; it would be
|
|
|
@@ -1477,23 +1493,30 @@ Chapter 13. DHCPv4 Server
|
|
|
environment, but it has significant limitations. See Section 13.4, "DHCPv4
|
|
|
Server Limitations" for details.
|
|
|
|
|
|
- The DHCPv4 server is implemented as b10-dhcp4 daemon. As it is not
|
|
|
- configurable yet, it is fully autonomous, that is it does not interact
|
|
|
- with b10-cfgmgr. To start DHCPv4 server, simply input:
|
|
|
-
|
|
|
- #cd src/bin/dhcp4
|
|
|
- #./b10-dhcp4
|
|
|
-
|
|
|
- Depending on your installation, b10-dhcp4 binary may reside in
|
|
|
- src/bin/dhcp4 in your source code directory, in /usr/local/bin/b10-dhcp4
|
|
|
- or other directory you specified during compilation. At start, the 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. The server will then listen to incoming traffic.
|
|
|
- Currently supported client messages are DISCOVER and REQUEST. The server
|
|
|
- will respond to them with OFFER and ACK, respectively. Since the DHCPv4
|
|
|
- server opens privileged ports, it requires root access. Make sure you run
|
|
|
- this daemon as root.
|
|
|
+ b10-dhcp4 is a BIND10 component and is being run under BIND10 framework.
|
|
|
+ To add a DHCPv4 process to the set of running BIND10 services, you can use
|
|
|
+ following commands in bindctl:
|
|
|
+
|
|
|
+ > config add Boss/components b10-dhcp4
|
|
|
+ > config set Boss/components/b10-dhcp4/kind dispensable
|
|
|
+ > config commit
|
|
|
+
|
|
|
+ To shutdown running b10-dhcp4, please use the following command:
|
|
|
+
|
|
|
+ > Dhcp4 shutdown
|
|
|
+
|
|
|
+ or
|
|
|
+
|
|
|
+ > config remove Boss/components b10-dhcp4
|
|
|
+ > config commit
|
|
|
+
|
|
|
+ At start, the 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. The server will then listen
|
|
|
+ to incoming traffic. Currently supported client messages are DISCOVER and
|
|
|
+ REQUEST. The server will respond to them with OFFER and ACK, respectively.
|
|
|
+ Since the DHCPv4 server opens privileged ports, it requires root access.
|
|
|
+ Make sure you run this daemon as root.
|
|
|
|
|
|
Note
|
|
|
|
|
|
@@ -1550,12 +1573,7 @@ Chapter 13. DHCPv4 Server
|
|
|
configuration is to directly modify source code. See see Section 13.2,
|
|
|
"DHCPv4 Server Configuration" for details.
|
|
|
o Upon start, the server will open sockets on all interfaces that are
|
|
|
- not loopback, are up and running and have IPv4 address. Support for
|
|
|
- multiple interfaces is not coded in reception routines yet, so if you
|
|
|
- are running this code on a machine that has many interfaces and
|
|
|
- b10-dhcp4 happens to listen on wrong interface, the easiest way to
|
|
|
- work around this problem is to turn down other interfaces. This
|
|
|
- limitation will be fixed shortly.
|
|
|
+ not loopback, are up and running and have IPv4 address.
|
|
|
o PRL (Parameter Request List, a list of options requested by a client)
|
|
|
is currently ignored and server assigns DNS SERVER and DOMAIN NAME
|
|
|
options.
|
|
|
@@ -1728,21 +1746,10 @@ Chapter 15. libdhcp++ library
|
|
|
routines. Interface detection is currently only supported on Linux
|
|
|
systems.
|
|
|
|
|
|
- For non-Linux systems, there is currently stub implementation provided. As
|
|
|
- DHCP servers need to know available addresses, there is a simple mechanism
|
|
|
- implemented to provide that information. User is expected to create
|
|
|
- interfaces.txt file. Format of this file is simple. It contains list of
|
|
|
- interfaces along with available address on each interface. This mechanism
|
|
|
- is temporary and is going to be removed as soon as interface detection
|
|
|
- becomes available on non-Linux systems. Here is an example of the
|
|
|
- interfaces.txt file:
|
|
|
-
|
|
|
- # For DHCPv6, please specify link-local address (starts with fe80::)
|
|
|
- # If in doubt, check output of 'ifconfig -a' command.
|
|
|
- eth0 fe80::21e:8cff:fe9b:7349
|
|
|
-
|
|
|
- # For DHCPv4, please use following format:
|
|
|
- #eth0 192.0.2.5
|
|
|
+ For non-Linux systems, there is currently stub implementation provided.
|
|
|
+ Interface manager detects loopback interfaces only as their name (lo or
|
|
|
+ lo0) can be easily predicted. Please contact BIND10 development team if
|
|
|
+ you are interested in running DHCP components on systems other than Linux.
|
|
|
|
|
|
15.2. DHCPv4/DHCPv6 packet handling
|
|
|
|
Jeremy C. Reed