-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>BIND 10 Guide</title><link rel="stylesheet"
type="text/css" href="./bind10-guide.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><meta name="description" content="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. This is the reference guide for BIND 10 version 20120405. 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 ."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="BIND 10 Guide"><div class="titlepage"><div><div><h1 class="title"><a name="idp25968"></a>BIND 10 Guide</h1></div><div><h2 class="subtitle">Administrator Reference for BIND 10</h2></div><div><p class="releaseinfo">This is the reference guide for BIND 10 version
- 20120
405.</p></div><div><p class="copyright">Copyright © 2010-2012 Internet Systems Consortium, Inc.</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>BIND 10 is a framework that features Domain Name System
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>BIND 10 Guide</title><link rel="stylesheet"
href="./bind10-guide.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><meta name="description" content="BIND 10 is a framework that features Domain Name System (DNS) suite and 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 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 ."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="BIND 10 Guide"><div class="titlepage"><div><div><h1 class="title"><a name="id1168229451102"></a>BIND 10 Guide</h1></div><div><h2 class="subtitle">Administrator Reference for BIND 10</h2></div><div><p class="releaseinfo">This is the reference guide for BIND 10 version
+ 20120
712.</p></div><div><p class="copyright">Copyright © 2010-2012 Internet Systems Consortium, Inc.</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>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
+ 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.
</p><p>
- This is the reference guide for BIND 10 version 20120405.
+ 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 <a class="ulink" href="http://bind10.isc.org/docs" target="_top">http://bind10.isc.org/docs</a>.
- </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id
p32752">Preface</a></span></dt><dd><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></dd><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#idp38240">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></dd><dt><span class="chapter"><a href="#installation">2. Installation</a></span></dt><dd><dl><dt><span class="section"><a href="#build-requirements">2.1. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.2. Quick start</a></span></dt><dt><span class="section"><a href="#install">2.3. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#idp128960">2.3.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp131696">2.3.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp140672">2.3.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp154016">2.3.4. Build</a></span></dt><dt><span class="section"><a href="#idp156000">2.3.5. Install</a></span></dt><dt><span class="section"><a href="#idp159168">2.3.6. Install Hierarchy</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#bind10">3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></a></span></dt><dd><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration of started processes</a></span></dt></dl></dd><dt><span class="chapter"><a href="#msgq">4. Command channel</a></span></dt><dt><span class="chapter"><a href="#cfgmgr">5. Configuration manager</a></span></dt><dt><span class="chapter"><a href="#cmdctl">6. Remote control daemon</a></span></dt><dd><dl><dt><span class="section"><a href="#cmdctl.spec">6.1. Configuration specification for b10-cmdctl</a></span></dt></dl></dd><dt><span class="chapter"><a href="#bindctl">7. Control and configure user interface</a></span></dt><dt><span class="chapter"><a href="#authserver">8. Authoritative Server</a></span></dt><dd><dl><dt><span class="section"><a href="#idp280304">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#idp323936">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#in-memory-datasource">8.2.1. In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-with-sqlite3-backend">8.2.2. In-memory Data Source With SQLite3 Backend</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-loading">8.2.3. Reloading an In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-disabling">8.2.4. Disabling In-memory Data Sources</a></span></dt></dl></dd><dt><span class="section"><a href="#idp357152">8.3. Loading Master Zones Files</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrin">9. Incoming Zone Transfers</a></span></dt><dd><dl><dt><span class="section"><a href="#idp375360">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp380704">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#idp397792">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#idp401488">9.5. Incoming Transfers with In-memory Datasource</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrout">10. Outbound Zone Transfers</a></span></dt><dt><span class="chapter"><a href="#ddns">11. Dynamic DNS Update</a></span></dt><dd><dl><dt><span class="section"><a href="#idp433840">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#idp448128">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#idp471872">11.3. Miscellaneous Operational Issues</a></span></dt></dl></dd><dt><span class="chapter"><a href="#resolverserver">12. Recursive Name Server</a></span></dt><dd><dl><dt><span class="section"><a href="#idp492912">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp509632">12.2. Forwarding</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp4">13. DHCPv4 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp4-usage">13.1. DHCPv4 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp4-config">13.2. DHCPv4 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp4-std">13.3. Supported standards</a></span></dt><dt><span class="section"><a href="#dhcp4-limit">13.4. DHCPv4 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp6">14. DHCPv6 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp6-usage">14.1. DHCPv6 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp6-config">14.2. DHCPv6 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp6-std">14.3. Supported DHCPv6 Standards</a></span></dt><dt><span class="section"><a href="#dhcp6-limit">14.4. DHCPv6 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#libdhcp">15. libdhcp++ library</a></span></dt><dd><dl><dt><span class="section"><a href="#iface-detect">15.1. Interface detection</a></span></dt><dt><span class="section"><a href="#packet-handling">15.2. DHCPv4/DHCPv6 packet handling</a></span></dt></dl></dd><dt><span class="chapter"><a href="#statistics">16. Statistics</a></span></dt><dt><span class="chapter"><a href="#logging">17. Logging</a></span></dt><dd><dl><dt><span class="section"><a href="#idp609968">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp611664">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp648032">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp673088">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp704416">17.2. Logging Message Format</a></span></dt></dl></dd></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>3.1. <a href="#idp193680"></a></dt></dl></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="idp32752"></a>Preface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></div><div class="section" title="1. Acknowledgements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="acknowledgements"></a>1. Acknowledgements</h2></div></div></div><p>ISC would like to acknowledge generous support for
+ </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id
1168229451188">Preface</a></span></dt><dd><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></dd><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229451275">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software at Run-time</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></dd><dt><span class="chapter"><a href="#installation">2. Installation</a></span></dt><dd><dl><dt><span class="section"><a href="#packages">2.1. Packages</a></span></dt><dt><span class="section"><a href="#install-hierarchy">2.2. Install Hierarchy</a></span></dt><dt><span class="section"><a href="#build-requirements">2.3. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.4. Quick start</a></span></dt><dt><span class="section"><a href="#install">2.5. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229436957">2.5.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#id1168229436977">2.5.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#id1168229437037">2.5.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#id1168229437136">2.5.4. Build</a></span></dt><dt><span class="section"><a href="#id1168229437150">2.5.5. Install</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#bind10">3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></a></span></dt><dd><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration to start processes</a></span></dt></dl></dd><dt><span class="chapter"><a href="#msgq">4. Command channel</a></span></dt><dt><span class="chapter"><a href="#cfgmgr">5. Configuration manager</a></span></dt><dt><span class="chapter"><a href="#cmdctl">6. Remote control daemon</a></span></dt><dd><dl><dt><span class="section"><a href="#cmdctl.spec">6.1. Configuration specification for b10-cmdctl</a></span></dt></dl></dd><dt><span class="chapter"><a href="#bindctl">7. Control and configure user interface</a></span></dt><dt><span class="chapter"><a href="#authserver">8. Authoritative Server</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229438312">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#id1168229438638">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#in-memory-datasource">8.2.1. In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-with-sqlite3-backend">8.2.2. In-memory Data Source with SQLite3 Backend</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-loading">8.2.3. Reloading an In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-disabling">8.2.4. Disabling In-memory Data Sources</a></span></dt></dl></dd><dt><span class="section"><a href="#id1168229438940">8.3. Loading Master Zones Files</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrin">9. Incoming Zone Transfers</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229439105">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#id1168229439142">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#id1168229439316">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#id1168229439342">9.5. Incoming Transfers with In-memory Datasource</a></span></dt></dl></dd><dt><span class="chapter"><a href="#xfrout">10. Outbound Zone Transfers</a></span></dt><dt><span class="chapter"><a href="#ddns">11. Dynamic DNS Update</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229439633">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#id1168229439733">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#id1168229439954">11.3. Miscellaneous Operational Issues</a></span></dt></dl></dd><dt><span class="chapter"><a href="#resolverserver">12. Recursive Name Server</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229440091">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#id1168229440276">12.2. Forwarding</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp4">13. DHCPv4 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp4-usage">13.1. DHCPv4 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp4-config">13.2. DHCPv4 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp4-std">13.3. Supported standards</a></span></dt><dt><span class="section"><a href="#dhcp4-limit">13.4. DHCPv4 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#dhcp6">14. DHCPv6 Server</a></span></dt><dd><dl><dt><span class="section"><a href="#dhcp6-usage">14.1. DHCPv6 Server Usage</a></span></dt><dt><span class="section"><a href="#dhcp6-config">14.2. DHCPv6 Server Configuration</a></span></dt><dt><span class="section"><a href="#dhcp6-std">14.3. Supported DHCPv6 Standards</a></span></dt><dt><span class="section"><a href="#dhcp6-limit">14.4. DHCPv6 Server Limitations</a></span></dt></dl></dd><dt><span class="chapter"><a href="#libdhcp">15. libdhcp++ library</a></span></dt><dd><dl><dt><span class="section"><a href="#iface-detect">15.1. Interface detection</a></span></dt><dt><span class="section"><a href="#packet-handling">15.2. DHCPv4/DHCPv6 packet handling</a></span></dt></dl></dd><dt><span class="chapter"><a href="#statistics">16. Statistics</a></span></dt><dt><span class="chapter"><a href="#logging">17. Logging</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229440926">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229440937">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#id1168229441248">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#id1168229441431">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#id1168229441640">17.2. Logging Message Format</a></span></dt></dl></dd></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>3.1. <a href="#id1168229437333">Special startup components</a></dt></dl></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="id1168229451188"></a>Preface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#acknowledgements">1. Acknowledgements</a></span></dt></dl></div><div class="section" title="1. Acknowledgements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="acknowledgements"></a>1. Acknowledgements</h2></div></div></div><p>ISC would like to acknowledge generous support for
BIND 10 development of DHCPv4 and DHCPv6 components provided
- by <a class="ulink" href="http://www.comcast.com/" target="_top">Comcast</a>.</p></div></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p38240">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></div><p>
+ by <a class="ulink" href="http://www.comcast.com/" target="_top">Comcast</a>.</p></div></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229451275">1.1. Supported Platforms</a></span></dt><dt><span class="section"><a href="#required-software">1.2. Required Software at Run-time</a></span></dt><dt><span class="section"><a href="#starting_stopping">1.3. Starting and Stopping the Server</a></span></dt><dt><span class="section"><a href="#managing_once_running">1.4. Managing BIND 10</a></span></dt></dl></div><p>
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 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.
</p><p>
This guide covers the experimental prototype of
- BIND 10 version 20120405.
- </p><div class="section" title="1.1. Supported Platforms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p38240"></a>1.1. Supported Platforms</h2></div></div></div><p>
+ BIND 10 version 20120712.
+ </p><div class="section" title="1.1. Supported Platforms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229451275"></a>1.1. Supported Platforms</h2></div></div></div><p>
BIND 10 builds have been tested on (in no particular order)
- Debian GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5,
+ Debian 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 is planned for BIND 10 to build, install and run on
Windows and standard Unix-type platforms.
- </p></div><div class="section" title="1.2. Required Software"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="required-software"></a>1.2. Required Software</h2></div></div></div><p>
+ </p></div><div class="section" title="1.2. Required Software at Run-time"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="required-software"></a>1.2. Required Software at Run-time</h2></div></div></div><p>
+ 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
+ <a class="xref" href="#build-requirements" title="2.3. Building Requirements">Section 2.3, “Building Requirements”</a>.)
+ </p><p>
BIND 10 requires at least Python 3.1
(<a class="ulink" href="http://www.python.org/" target="_top">http://www.python.org/</a>).
- It has also been tested with Python 3.2.
+ It also works with Python 3.2.
</p><p>
BIND 10 uses the Botan crypto library for C++
(<a class="ulink" href="http://botan.randombit.net/" target="_top">http://botan.randombit.net/</a>).
BIND 10 uses the log4cplus C++ logging library
(<a class="ulink" href="http://log4cplus.sourceforge.net/" target="_top">http://log4cplus.sourceforge.net/</a>).
It requires at least log4cplus version 1.0.3.
+
</p><p>
The authoritative DNS server uses SQLite3
(<a class="ulink" href="http://www.sqlite.org/" target="_top">http://www.sqlite.org/</a>).
<span class="command"><strong>b10-xfrout</strong></span>, and <span class="command"><strong>b10-zonemgr</strong></span>
components require the libpython3 library and the Python
_sqlite3.so module (which is included with Python).
- The <span class="command"><strong>b10-stats-httpd</strong></span> component uses the
- Python pyexpat.so module.
- The Python modules need to be built for the corresponding Python 3.
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- Some operating systems do not provide these dependencies
- in their default installation nor standard packages
- collections.
- You may need to install them separately.
- </p></div></div><div class="section" title="1.3. Starting and Stopping the Server"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="starting_stopping"></a>1.3. Starting and Stopping the Server</h2></div></div></div><p>
+ Python modules need to be built for the corresponding Python 3.
+ </p></div><div class="section" title="1.3. Starting and Stopping the Server"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="starting_stopping"></a>1.3. Starting and Stopping the Server</h2></div></div></div><p>
BIND 10 is modular. Part of this modularity is
accomplished using multiple cooperating processes which, together,
provide the server functionality. This is a change from
</li><li class="listitem">
<span class="command"><strong>b10-resolver</strong></span> —
Recursive name server.
- This process handles incoming queries.
-
+ This process handles incoming DNS queries and provides
+ answers from its cache or by recursively doing remote lookups.
</li><li class="listitem">
<span class="command"><strong>b10-sockcreator</strong></span> —
Socket creator daemon.
<span class="command"><strong>b10-xfrout</strong></span> —
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.
+ send a local zone to a remote secondary server.
</li><li class="listitem">
<span class="command"><strong>b10-zonemgr</strong></span> —
- Secondary manager.
+ Secondary zone manager.
This process keeps track of timers and other
necessary information for BIND 10 to act as a slave server.
</li></ul></div><p>
</p><p>
- These are ran automatically by <span class="command"><strong>bind10</strong></span>
- and do not need to be run manually.
+ These are ran by <span class="command"><strong>bind10</strong></span>
+ and do not need to be manually started independently.
</p></div><div class="section" title="1.4. Managing BIND 10"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="managing_once_running"></a>1.4. Managing BIND 10</h2></div></div></div><p>
Once BIND 10 is running, a few commands are used to interact
directly with the system:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
<span class="command"><strong>bindctl</strong></span> —
- interactive administration interface.
+ Interactive administration interface.
This is a low-level command-line tool which allows
a developer or an experienced administrator to control
BIND 10.
</li><li class="listitem">
<span class="command"><strong>b10-loadzone</strong></span> —
- zone file loader.
+ Zone file loader.
This tool will load standard masterfile-format zone files into
BIND 10.
</li><li class="listitem">
<span class="command"><strong>b10-cmdctl-usermgr</strong></span> —
- user access control.
+ User access control.
This tool allows an administrator to authorize additional users
to manage BIND 10.
</li></ul></div><p>
and, of course, DNS. These include detailed developer
documentation and code examples.
- </p></div><div class="chapter" title="Chapter 2. Installation"><div class="titlepage"><div><div><h2 class="title"><a name="installation"></a>Chapter 2. Installation</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#build-requirements">2.1. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.2. Quick start</a></span></dt><dt><span class="section"><a href="#install">2.3. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#idp128960">2.3.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp131696">2.3.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp140672">2.3.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp154016">2.3.4. Build</a></span></dt><dt><span class="section"><a href="#idp156000">2.3.5. Install</a></span></dt><dt><span class="section"><a href="#idp159168">2.3.6. Install Hierarchy</a></span></dt></dl></dd></dl></div><div class="section" title="2.1. Building Requirements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="build-requirements"></a>2.1. Building Requirements</h2></div></div></div><p>
- In addition to the run-time requirements, building BIND 10
- from source code requires various development include headers.
+
+ </p></div><div class="chapter" title="Chapter 2. Installation"><div class="titlepage"><div><div><h2 class="title"><a name="installation"></a>Chapter 2. Installation</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#packages">2.1. Packages</a></span></dt><dt><span class="section"><a href="#install-hierarchy">2.2. Install Hierarchy</a></span></dt><dt><span class="section"><a href="#build-requirements">2.3. Building Requirements</a></span></dt><dt><span class="section"><a href="#quickstart">2.4. Quick start</a></span></dt><dt><span class="section"><a href="#install">2.5. Installation from source</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229436957">2.5.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#id1168229436977">2.5.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#id1168229437037">2.5.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#id1168229437136">2.5.4. Build</a></span></dt><dt><span class="section"><a href="#id1168229437150">2.5.5. Install</a></span></dt></dl></dd></dl></div><div class="section" title="2.1. Packages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="packages"></a>2.1. Packages</h2></div></div></div><p>
+ 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
+ <span class="emphasis"><em>make</em></span> the software.
+ </p><p>
+ FreeBSD ports, NetBSD pkgsrc, and Debian
+ <span class="emphasis"><em>testing</em></span> package collections provide
+ all the prerequisite packages.
+ </p></div><div class="section" title="2.2. Install Hierarchy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="install-hierarchy"></a>2.2. Install Hierarchy</h2></div></div></div><p>
+ The following is the standard, common layout of the
+ complete BIND 10 installation:
+ </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+ <code class="filename">bin/</code> —
+ general tools and diagnostic clients.
+ </li><li class="listitem">
+ <code class="filename">etc/bind10-devel/</code> —
+ configuration files.
+ </li><li class="listitem">
+ <code class="filename">lib/</code> —
+ libraries and python modules.
+ </li><li class="listitem">
+ <code class="filename">libexec/bind10-devel/</code> —
+ 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 <span class="command"><strong>bind10</strong></span> tool.
+ </li><li class="listitem">
+ <code class="filename">sbin/</code> —
+ commands used by the system administrator.
+ </li><li class="listitem">
+ <code class="filename">share/bind10-devel/</code> —
+ configuration specifications.
+ </li><li class="listitem">
+ <code class="filename">share/doc/bind10-devel/</code> —
+ this guide and other supplementary documentation.
+ </li><li class="listitem">
+ <code class="filename">share/man/</code> —
+ manual pages (online documentation).
+ </li><li class="listitem">
+ <code class="filename">var/bind10-devel/</code> —
+ data source and configuration databases.
+ </li></ul></div><p>
+ </p></div><div class="section" title="2.3. Building Requirements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="build-requirements"></a>2.3. Building Requirements</h2></div></div></div><p>
+ In addition to the run-time requirements (listed in
+ <a class="xref" href="#required-software" title="1.2. Required Software at Run-time">Section 1.2, “Required Software at Run-time”</a>), building BIND 10
+ from source code requires various development include headers and
+ program development tools.
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
Some operating systems have split their distribution packages into
a run-time and a development package. You will need to install
BIND 10 builds have been tested with GCC 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.
</p><p>
- Visit the wiki at <a class="ulink" href="http://bind10.isc.org/wiki/SystemSpecificNotes" target="_top">http://bind10.isc.org/wiki/SystemSpecificNotes</a>
+ Visit the
user-contributed wiki at <a class="ulink" href="http://bind10.isc.org/wiki/SystemSpecificNotes" target="_top">http://bind10.isc.org/wiki/SystemSpecificNotes</a>
for system-specific installation tips.
- </p></div><div class="section" title="2.
2. Quick start"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="quickstart"></a>2.2. Quick start</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ </p></div><div class="section" title="2.
4. Quick start"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="quickstart"></a>2.4. Quick start</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
This quickly covers the standard steps for installing
and deploying BIND 10 as an authoritative name server using
its defaults. For troubleshooting, full customizations and further
</p><pre class="screen">$ <strong class="userinput"><code>b10-loadzone <em class="replaceable"><code>your.zone.example.org</code></em></code></strong></pre><p>
</p></li><li class="listitem">
Test the new zone.
- </li></ol></div></div><div class="section" title="2.
3. Installation from source"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="install"></a>2.3. Installation from source</h2></div></div></div><p>
+ </li></ol></div></div><div class="section" title="2.
5. Installation from source"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="install"></a>2.5. Installation from source</h2></div></div></div><p>
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.
- </p><div class="section" title="2.
3.1. Download Tar File"><div class="titlepage"><div><div><h3 class="title"><a name="idp128960"></a>2.3.1. Download Tar File</h3></div></div></div><p>
+ It is freely 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.)
+ </p><div class="section" title="2.
5.1. Download Tar File"><div class="titlepage"><div><div><h3 class="title"><a name="id1168229436957"></a>2.5.1. Download Tar File</h3></div></div></div><p>
Downloading a release tar file is the recommended method to
obtain the source code.
</p><p>
The BIND 10 releases are available as tar file downloads from
<a class="ulink" href="ftp://ftp.isc.org/isc/bind10/" target="_top">ftp://ftp.isc.org/isc/bind10/</a>.
Periodic development snapshots may also be available.
- </p></div><div class="section" title="2.
3.2. Retrieve from Git"><div class="titlepage"><div><div><h3 class="title"><a name="idp131696"></a>2.3.2. Retrieve from Git</h3></div></div></div><p>
+ </p></div><div class="section" title="2.
5.2. Retrieve from Git"><div class="titlepage"><div><div><h3 class="title"><a name="id1168229436977"></a>2.5.2. Retrieve from Git</h3></div></div></div><p>
Downloading this "bleeding edge" code is recommended only for
developers or advanced users. Using development code in a production
environment is not recommended.
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- When using source code retrieved via Git additional
+ 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.
</p></div><p>
- The latest development code, including temporary experiments
- and un-reviewed code, is available via the BIND 10 code revision
+ 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 <span class="quote">“<span class="quote">master</span>”</span>.
+ The leading development is done in the <span class="quote">“<span class="quote">master</span>”</span>
+ branch.
</p><p>
The code can be checked out from
<code class="filename">git://git.bind10.isc.org/bind10</code>;
</p><p>
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.
+ generated configure script, Makefile.in files, nor their
+ related build files.
They can be created by running <span class="command"><strong>autoreconf</strong></span>
with the <code class="option">--install</code> switch.
This will run <span class="command"><strong>autoconf</strong></span>,
<span class="command"><strong>autoheader</strong></span>,
<span class="command"><strong>automake</strong></span>,
and related commands.
- </p></div><div class="section" title="2.
3.3. Configure before the build"><div class="titlepage"><div><div><h3 class="title"><a name="idp140672"></a>2.3.3. Configure before the build</h3></div></div></div><p>
+ </p></div><div class="section" title="2.
5.3. Configure before the build"><div class="titlepage"><div><div><h3 class="title"><a name="id1168229437037"></a>2.5.3. Configure before the build</h3></div></div></div><p>
BIND 10 uses the GNU Build System to discover build environment
details.
To generate the makefiles using the defaults, simply run:
</p><pre class="screen">$ <strong class="userinput"><code>./configure</code></strong></pre><p>
</p><p>
Run <span class="command"><strong>./configure</strong></span> with the <code class="option">--help</code>
- switch to view the different options. The commonly-used options are:
+ switch to view the different options. Some commonly-used options are:
</p><div class="variablelist"><dl><dt><span class="term">--prefix</span></dt><dd>Define the installation location (the
default is <code class="filename">/usr/local/</code>).
</p><p>
If the configure fails, it may be due to missing or old
dependencies.
- </p></div><div class="section" title="2.
3.4. Build"><div class="titlepage"><div><div><h3 class="title"><a name="idp154016"></a>2.3.4. Build</h3></div></div></div><p>
+ </p></div><div class="section" title="2.
5.4. Build"><div class="titlepage"><div><div><h3 class="title"><a name="id1168229437136"></a>2.5.4. Build</h3></div></div></div><p>
After the configure step is complete, to build the executables
from the C++ code and prepare the Python scripts, run:
</p><pre class="screen">$ <strong class="userinput"><code>make</code></strong></pre><p>
- </p></div><div class="section" title="2.
3.5. Install"><div class="titlepage"><div><div><h3 class="title"><a name="idp156000"></a>2.3.5. Install</h3></div></div></div><p>
+ </p></div><div class="section" title="2.
5.5. Install"><div class="titlepage"><div><div><h3 class="title"><a name="id1168229437150"></a>2.5.5. Install</h3></div></div></div><p>
To install the BIND 10 executables, support files,
and documentation, run:
</p><pre class="screen">$ <strong class="userinput"><code>make install</code></strong></pre><p>
- </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The install step may require superuser privileges.</p></div></div><div class="section" title="2.3.6. Install Hierarchy"><div class="titlepage"><div><div><h3 class="title"><a name="idp159168"></a>2.3.6. Install Hierarchy</h3></div></div></div><p>
- The following is the layout of the complete BIND 10 installation:
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
- <code class="filename">bin/</code> —
- general tools and diagnostic clients.
- </li><li class="listitem">
- <code class="filename">etc/bind10-devel/</code> —
- configuration files.
- </li><li class="listitem">
- <code class="filename">lib/</code> —
- libraries and python modules.
- </li><li class="listitem">
- <code class="filename">libexec/bind10-devel/</code> —
- 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 <span class="command"><strong>bind10</strong></span> tool.
- </li><li class="listitem">
- <code class="filename">sbin/</code> —
- commands used by the system administrator.
- </li><li class="listitem">
- <code class="filename">share/bind10-devel/</code> —
- configuration specifications.
- </li><li class="listitem">
- <code class="filename">share/man/</code> —
- manual pages (online documentation).
- </li><li class="listitem">
- <code class="filename">var/bind10-devel/</code> —
- data source and configuration databases.
- </li></ul></div><p>
- </p></div></div></div><div class="chapter" title="Chapter 3. Starting BIND10 with bind10"><div class="titlepage"><div><div><h2 class="title"><a name="bind10"></a>Chapter 3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration of started processes</a></span></dt></dl></div><p>
+ </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The install step may require superuser privileges.</p></div></div></div></div><div class="chapter" title="Chapter 3. Starting BIND10 with bind10"><div class="titlepage"><div><div><h2 class="title"><a name="bind10"></a>Chapter 3. Starting BIND10 with <span class="command"><strong>bind10</strong></span></h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#start">3.1. Starting BIND 10</a></span></dt><dt><span class="section"><a href="#bind10.config">3.2. Configuration to start processes</a></span></dt></dl></div><p>
BIND 10 provides the <span class="command"><strong>bind10</strong></span> command which
starts up the required processes.
<span class="command"><strong>bind10</strong></span>
The <span class="command"><strong>b10-cfgmgr</strong></span> 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 <span class="command"><strong>b10-sockcreator</strong></span> will
- allocate sockets for the rest of the system.
+ about other modules. The <span class="command"><strong>b10-sockcreator</strong></span> daemon
+ helps allocate Internet addresses and ports as needed for BIND 10
+ network services.
</p><p>
In its default configuration, the <span class="command"><strong>bind10</strong></span>
master process will also start up
the process names for the Python-based daemons will be renamed
to better identify them instead of just <span class="quote">“<span class="quote">python</span>”</span>.
This is not needed on some operating systems.
- </p></div></div><div class="section" title="3.2. Configuration of started processes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="bind10.config"></a>3.2. Configuration of started processes</h2></div></div></div><p>
- The processes to be started can be configured, with the exception
- of the <span class="command"><strong>b10-sockcreator</strong></span>, <span class="command"><strong>b10-msgq</strong></span>
- and <span class="command"><strong>b10-cfgmgr</strong></span>.
+ </p></div></div><div class="section" title="3.2. Configuration to start processes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="bind10.config"></a>3.2. Configuration to start processes</h2></div></div></div><p>
+ The processes to be used can be configured for
+ <span class="command"><strong>bind10</strong></span> to start, with the exception
+ of the required <span class="command"><strong>b10-sockcreator</strong></span>,
+ <span class="command"><strong>b10-msgq</strong></span> and <span class="command"><strong>b10-cfgmgr</strong></span>
+ components.
+ The configuration is in the <code class="varname">Boss/components</code>
+ section. Each element represents one component, which is
+ an abstraction of a process.
</p><p>
- 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).
- </p><p>
- 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:
</p><pre class="screen">> <strong class="userinput"><code>config add Boss/components b10-resolver</code></strong>
> <strong class="userinput"><code>config set Boss/components/b10-resolver/special resolver</code></strong>
> <strong class="userinput"><code>config set Boss/components/b10-resolver/kind needed</code></strong>
> <strong class="userinput"><code>config set Boss/components/b10-resolver/priority 10</code></strong>
> <strong class="userinput"><code>config commit</code></strong></pre><p>
- 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
+ <span class="quote">“<span class="quote">b10-resolver</span>”</span>. 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.
</p><p>
- The special one 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 special way, with the value of special used for them:
- </p><div class="table"><a name="idp193680"></a><p class="title"><b>Table 3.1. </b></p><div class="table-contents"><table border="1"><colgroup><col align="left" class="component"><col align="left" class="special"><col align="left" class="description"></colgroup><thead><tr><th align="left">Component</th><th align="left">Special</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">b10-auth</td><td align="left">auth</td><td align="left">Authoritative server</td></tr><tr><td align="left">b10-resolver</td><td align="left">resolver</td><td align="left">The resolver</td></tr><tr><td align="left">b10-cmdctl</td><td align="left">cmdctl</td><td align="left">The command control (remote control interface)</td></tr></tbody></table></div></div><p><br class="table-break">
+ The <code class="varname">special</code> setting is for components
+ that need some kind of special care during startup or
+ shutdown. Unless specified, the component is started in 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:
+
+ </p><div class="table"><a name="id1168229437333"></a><p class="title"><b>Table 3.1. Special startup components</b></p><div class="table-contents"><table summary="Special startup components" border="1"><colgroup><col align="left"><col align="left"><col align="left"></colgroup><thead><tr><th align="left">Component</th><th align="left">Special</th><th align="left">Description</th></tr></thead><tbody><tr><td align="left">b10-auth</td><td align="left">auth</td><td align="left">Authoritative DNS server</td></tr><tr><td align="left">b10-resolver</td><td align="left">resolver</td><td align="left">DNS resolver</td></tr><tr><td align="left">b10-cmdctl</td><td align="left">cmdctl</td><td align="left">Command control (remote control interface)</td></tr></tbody></table></div></div><p><br class="table-break">
</p><p>
- The kind specifies how a failure of the component should
- be handled. If it is set to <span class="quote">“<span class="quote">dispensable</span>”</span>
- (the default unless you set something else), it will get
- started again if it fails. If it is set to <span class="quote">“<span class="quote">needed</span>”</span>
- and it fails at startup, the whole <span class="command"><strong>bind10</strong></span>
- shuts down and exits with error exit code. But if it fails
- some time later, it is just started again. If you set it
- to <span class="quote">“<span class="quote">core</span>”</span>, you indicate that the system is
- not usable without the component and if such component
- fails, the system shuts down no matter when the failure
- happened. This is the behaviour of the core components
- (the ones you can't turn off), but you can declare any
- other components as core as well if you wish (but you can
- turn these off, they just can't fail).
+ The <code class="varname">kind</code> specifies how a failure of the
+ component should be handled. If it is set to
+ <span class="quote">“<span class="quote">dispensable</span>”</span> (the default unless you set
+ something else), it will get started again if it fails. If
+ it is set to <span class="quote">“<span class="quote">needed</span>”</span> and it fails at startup,
+ the whole <span class="command"><strong>bind10</strong></span> 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 <span class="quote">“<span class="quote">core</span>”</span>,
+ you indicate that the system is not usable without the
+ component and if such component fails, the system shuts
+ down no matter when the failure happened. This is the
+ behaviour of the core components (the ones you can't turn
+ off), but you can declare any other components as core as
+ well if you wish (but you can turn these off, they just
+ can't fail).
</p><p>
- 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 you don't set it, 0 (zero) is used as the priority.
- Usually, leaving it at the default is enough.
+ The <code class="varname">priority</code> defines order in which the
+ components should start. The ones 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.
</p><p>
There are other parameters we didn't use in our example.
- One of them is <span class="quote">“<span class="quote">address</span>”</span>. It is the address
+ One of them is <code class="varname">address</code>. It is the address
used by the component on the <span class="command"><strong>b10-msgq</strong></span>
message bus. The special components already know their
address, but the usual ones don't. The address is by
would have <span class="quote">“<span class="quote">Stats</span>”</span> as its address).
</p><p>
- 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.
+ The last one is <code class="varname">process</code>. 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. (The special components also already know their
+ executable name.)
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- 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.
- </p></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
The configuration is quite powerful, but that includes
a lot of space for mistakes. You could turn off the
<span class="command"><strong>b10-cmdctl</strong></span>, but then you couldn't
In short, you should think twice before disabling something here.
</p></div><p>
It is possible to start some components multiple times (currently
- <span class="command"><strong>b10-auth</strong></span> and <span class="command"><strong>b10-resolzer</strong></span>).
+ <span class="command"><strong>b10-auth</strong></span> and <span class="command"><strong>b10-resolver</strong></span>).
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:
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.
+ Other components don't expect such a situation, so it would
+ probably not do what you want. Such support is yet to be
+ implemented.
</p></div></div><div class="chapter" title="Chapter 4. Command channel"><div class="titlepage"><div><div><h2 class="title"><a name="msgq"></a>Chapter 4. Command channel</h2></div></div></div><p>
The BIND 10 components use the <span class="command"><strong>b10-msgq</strong></span>
message routing daemon to communicate with other BIND 10 components.
</p><p>
Administrators do not communicate directly with the
<span class="command"><strong>b10-msgq</strong></span> daemon.
- By default, BIND 10 uses port 9912 for the
- <span class="command"><strong>b10-msgq</strong></span> service.
- It listens on 127.0.0.1.
+ By default, BIND 10 uses a UNIX domain socket file named
+ <code class="filename">/usr/local/var/bind10-devel/msg_socket</code>
+ for this interprocess communication.
</p></div><div class="chapter" title="Chapter 5. Configuration manager"><div class="titlepage"><div><div><h2 class="title"><a name="cfgmgr"></a>Chapter 5. Configuration manager</h2></div></div></div><p>
The configuration manager, <span class="command"><strong>b10-cfgmgr</strong></span>,
handles all BIND 10 system configuration. It provides
specifications and all current settings to the
<span class="command"><strong>bindctl</strong></span> client (via
<span class="command"><strong>b10-cmdctl</strong></span>).
- </p><p>
<span class="command"><strong>b10-cfgmgr</strong></span> relays configurations received
from <span class="command"><strong>b10-cmdctl</strong></span> to the appropriate modules.
</p><p>
The stored configuration file is at
<code class="filename">/usr/local/var/bind10-devel/b10-config.db</code>.
- (The full path is what was defined at build configure time for
+ (The directory is what was defined at build configure time for
<code class="option">--localstatedir</code>.
The default is <code class="filename">/usr/local/var/</code>.)
The format is loosely based on JSON and is directly parseable
redefined by using the <code class="option">--idle-timeout</code> command line argument.
</p><div class="section" title="6.1. Configuration specification for b10-cmdctl"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="cmdctl.spec"></a>6.1. Configuration specification for b10-cmdctl</h2></div></div></div><p>
The configuration items for <span class="command"><strong>b10-cmdctl</strong></span> are:
-key_file
-cert_file
-accounts_file
- </p><p>
- The control commands are:
-print_settings
-
-
-shutdown
+ <code class="varname">accounts_file</code> which defines the path to the
+ user accounts database (the default is
+ <code class="filename">/usr/local/etc/bind10-devel/cmdctl-accounts.csv</code>);
+ <code class="varname">cert_file</code> which defines the path to the
+ PEM certificate file (the default is
+ <code class="filename">/usr/local/etc/bind10-devel/cmdctl-certfile.pem</code>);
+ and
+ <code class="varname">key_file</code> which defines the path to the
+ PEM private key file (the default is
+ <code class="filename">/usr/local/etc/bind10-devel/cmdctl-keyfile.pem</code>).
</p></div></div><div class="chapter" title="Chapter 7. Control and configure user interface"><div class="titlepage"><div><div><h2 class="title"><a name="bindctl"></a>Chapter 7. Control and configure user interface</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
For this development prototype release, <span class="command"><strong>bindctl</strong></span>
is the only user interface. It is expected that upcoming
the details and relays (over a <span class="command"><strong>b10-msgq</strong></span> command
channel) the configuration on to the specified module.
</p><p>
- </p></div><div class="chapter" title="Chapter 8. Authoritative Server"><div class="titlepage"><div><div><h2 class="title"><a name="authserver"></a>Chapter 8. Authoritative Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p280304">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#idp323936">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#in-memory-datasource">8.2.1. In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-with-sqlite3-backend">8.2.2. In-memory Data Source With SQLite3 Backend</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-loading">8.2.3. Reloading an In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-disabling">8.2.4. Disabling In-memory Data Sources</a></span></dt></dl></dd><dt><span class="section"><a href="#idp357152">8.3. Loading Master Zones Files</a></span></dt></dl></div><p>
+ </p></div><div class="chapter" title="Chapter 8. Authoritative Server"><div class="titlepage"><div><div><h2 class="title"><a name="authserver"></a>Chapter 8. Authoritative Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229438312">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#id1168229438638">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#in-memory-datasource">8.2.1. In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-with-sqlite3-backend">8.2.2. In-memory Data Source with SQLite3 Backend</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-loading">8.2.3. Reloading an In-memory Data Source</a></span></dt><dt><span class="section"><a href="#in-memory-datasource-disabling">8.2.4. Disabling In-memory Data Sources</a></span></dt></dl></dd><dt><span class="section"><a href="#id1168229438940">8.3. Loading Master Zones Files</a></span></dt></dl></div><p>
The <span class="command"><strong>b10-auth</strong></span> is the authoritative DNS server.
- It supports EDNS0 and DNSSEC. It supports IPv6.
+ It supports EDNS0, DNSSEC, IPv6, and SQLite3 and in-memory zone
+ data backends.
Normally it is started by the <span class="command"><strong>bind10</strong></span> master
process.
- </p><div class="section" title="8.1. Server Configurations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p280304"></a>8.1. Server Configurations</h2></div></div></div><p>
+ </p><div class="section" title="8.1. Server Configurations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229438312"></a>8.1. Server Configurations</h2></div></div></div><p>
<span class="command"><strong>b10-auth</strong></span> is configured via the
<span class="command"><strong>b10-cfgmgr</strong></span> configuration manager.
The module name is <span class="quote">“<span class="quote">Auth</span>”</span>.
</p><div class="variablelist"><dl><dt><span class="term">database_file</span></dt><dd>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.
+Note: This may be a temporary setting because the DNS server
+can use various data source backends.
</dd><dt><span class="term">datasources</span></dt><dd>
<code class="varname">datasources</code> configures data sources.
The list items include:
and
<code class="varname">zones</code> to define
the <code class="varname">file</code> path name,
- the <code class="varname">filetype</code> (e.g., <code class="varname">sqlite3</code>),
+ the <code class="varname">filetype</code> (<span class="quote">“<span class="quote">sqlite3</span>”</span> to load
+ from a SQLite3 database file or <span class="quote">“<span class="quote">text</span>”</span> to
+ load from a master text file),
and the <code class="varname">origin</code> (default domain).
By default, this is empty.
if configured.)
</dd></dl></div><p>
- </p></div><div class="section" title="8.2. Data Source Backends"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p323936"></a>8.2. Data Source Backends</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ </p></div><div class="section" title="8.2. Data Source Backends"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229438638"></a>8.2. Data Source Backends</h2></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
For the development prototype release, <span class="command"><strong>b10-auth</strong></span>
supports a SQLite3 data source backend and in-memory data source
backend.
> <strong class="userinput"><code>config commit</code></strong></pre><p>
The authoritative server will begin serving it immediately
- after it is loaded.
- </p></div><div class="section" title="8.2.2. In-memory Data Source
With SQLite3 Backend"><div class="titlepage"><div><div><h3 class="title"><a name="in-memory-datasource-with-sqlite3-backend"></a>8.2.2. In-memory Data Source With SQLite3 Backend</h3></div></div></div><p>
+ after the zone data is loaded from the master text file.
+ </p></div><div class="section" title="8.2.2. In-memory Data Source
with SQLite3 Backend"><div class="titlepage"><div><div><h3 class="title"><a name="in-memory-datasource-with-sqlite3-backend"></a>8.2.2. In-memory Data Source with SQLite3 Backend</h3></div></div></div><p>
The following commands to <span class="command"><strong>bindctl</strong></span>
provide an example of configuring an in-memory data
> <strong class="userinput"><code>config commit</code></strong></pre><p>
The authoritative server will begin serving it immediately
- after it is loaded.
+ after the zone data is loaded from the database file.
</p></div><div class="section" title="8.2.3. Reloading an In-memory Data Source"><div class="titlepage"><div><div><h3 class="title"><a name="in-memory-datasource-loading"></a>8.2.3. Reloading an In-memory Data Source</h3></div></div></div><p>
Use the <span class="command"><strong>Auth loadzone</strong></span> command in
<span class="command"><strong>bindctl</strong></span> to reload a changed master
and/or <code class="varname">zones[<em class="replaceable"><code>0</code></em>]</code>
for the relevant zone as needed.)
- </p></div></div><div class="section" title="8.3. Loading Master Zones Files"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p357152"></a>8.3. Loading Master Zones Files</h2></div></div></div><p>
+ </p></div></div><div class="section" title="8.3. Loading Master Zones Files"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229438940"></a>8.3. Loading Master Zones Files</h2></div></div></div><p>
RFC 1035 style DNS master zone files may imported
into a BIND 10 SQLite3 data source by using the
<span class="command"><strong>b10-loadzone</strong></span> utility.
If you reload a zone already existing in the database,
all records from that prior zone disappear and a whole new set
appears.
- </p></div></div><div class="chapter" title="Chapter 9. Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title"><a name="xfrin"></a>Chapter 9. Incoming Zone Transfers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p375360">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp380704">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#idp397792">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#idp401488">9.5. Incoming Transfers with In-memory Datasource</a></span></dt></dl></div><p>
+ </p></div></div><div class="chapter" title="Chapter 9. Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title"><a name="xfrin"></a>Chapter 9. Incoming Zone Transfers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229439105">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#id1168229439142">9.2. Enabling IXFR</a></span></dt><dt><span class="section"><a href="#zonemgr">9.3. Secondary Manager</a></span></dt><dt><span class="section"><a href="#id1168229439316">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#id1168229439342">9.5. Incoming Transfers with In-memory Datasource</a></span></dt></dl></div><p>
Incoming zones are transferred using the <span class="command"><strong>b10-xfrin</strong></span>
process which is started by <span class="command"><strong>bind10</strong></span>.
When received, the zone is stored in the corresponding BIND 10
<span class="command"><strong>b10-auth</strong></span>.
In combination with <span class="command"><strong>b10-zonemgr</strong></span> (for
automated SOA checks), this allows the BIND 10 server to
- provide <span class="quote">“<span class="quote">secondary</span>”</span> service.
+ provide <span class="emphasis"><em>secondary</em></span> service.
</p><p>
The <span class="command"><strong>b10-xfrin</strong></span> process supports both AXFR and
IXFR. Due to some implementation limitations of the current
development release, however, it only tries AXFR by default,
and care should be taken to enable IXFR.
- </p><div class="section" title="9.1. Configuration for Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p375360"></a>9.1. Configuration for Incoming Zone Transfers</h2></div></div></div><p>
+ </p><div class="section" title="9.1. Configuration for Incoming Zone Transfers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439105"></a>9.1. Configuration for Incoming Zone Transfers</h2></div></div></div><p>
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
> <strong class="userinput"><code>config commit</code></strong></pre><p>
(We assume there has been no zone configuration before).
- </p></div><div class="section" title="9.2. Enabling IXFR"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p380704"></a>9.2. Enabling IXFR</h2></div></div></div><p>
+ </p></div><div class="section" title="9.2. Enabling IXFR"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439142"></a>9.2. Enabling IXFR</h2></div></div></div><p>
As noted above, <span class="command"><strong>b10-xfrin</strong></span> uses AXFR for
zone transfers by default. To enable IXFR for zone transfers
for a particular zone, set the <strong class="userinput"><code>use_ixfr</code></strong>
</p><pre class="screen">> <strong class="userinput"><code>config add Zonemgr/secondary_zones</code></strong>
> <strong class="userinput"><code>config set Zonemgr/secondary_zones[0]/name "<code class="option">example.com</code>"</code></strong>
-> <strong class="userinput"><code>config set Zonemgr/secondary_zones[0]/class "<code class="option">IN</code>"</code></strong>
> <strong class="userinput"><code>config commit</code></strong></pre><p>
-
-
</p><p>
If the zone does not exist in the data source already
(i.e. no SOA record for it), <span class="command"><strong>b10-zonemgr</strong></span>
will automatically tell <span class="command"><strong>b10-xfrin</strong></span>
to transfer the zone in.
- </p></div><div class="section" title="9.4. Trigger an Incoming Zone Transfer Manually"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p397792"></a>9.4. Trigger an Incoming Zone Transfer Manually</h2></div></div></div><p>
+ </p></div><div class="section" title="9.4. Trigger an Incoming Zone Transfer Manually"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439316"></a>9.4. Trigger an Incoming Zone Transfer Manually</h2></div></div></div><p>
To manually trigger a zone transfer to retrieve a remote zone,
you may use the <span class="command"><strong>bindctl</strong></span> utility.
For example, at the <span class="command"><strong>bindctl</strong></span> prompt run:
</p><pre class="screen">> <strong class="userinput"><code>Xfrin retransfer zone_name="<code class="option">foo.example.org</code>" master=<code class="option">192.0.2.99</code></code></strong></pre><p>
- </p></div><div class="section" title="9.5. Incoming Transfers with In-memory Datasource"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p401488"></a>9.5. Incoming Transfers with In-memory Datasource</h2></div></div></div><p>
+ </p></div><div class="section" title="9.5. Incoming Transfers with In-memory Datasource"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439342"></a>9.5. Incoming Transfers with In-memory Datasource</h2></div></div></div><p>
In the case of an incoming zone transfer, the received zone is
first stored in the corresponding BIND 10 datasource. In
case the secondary zone is served by an in-memory datasource
The administrator doesn't have to do anything for
<span class="command"><strong>b10-auth</strong></span> to serve the new version of the
zone, except for the configuration such as the one described in
- <a class="xref" href="#in-memory-datasource-with-sqlite3-backend" title="8.2.2. In-memory Data Source With SQLite3 Backend">Section 8.2.2, “In-memory Data Source With SQLite3 Backend”</a>.
+ <a class="xref" href="#in-memory-datasource-with-sqlite3-backend" title="8.2.2. In-memory Data Source with SQLite3 Backend">Section 8.2.2, “In-memory Data Source with SQLite3 Backend”</a>.
</p></div></div><div class="chapter" title="Chapter 10. Outbound Zone Transfers"><div class="titlepage"><div><div><h2 class="title"><a name="xfrout"></a>Chapter 10. Outbound Zone Transfers</h2></div></div></div><p>
The <span class="command"><strong>b10-xfrout</strong></span> process is started by
<span class="command"><strong>bind10</strong></span>.
When the <span class="command"><strong>b10-auth</strong></span> authoritative DNS server
receives an AXFR or IXFR request, <span class="command"><strong>b10-auth</strong></span>
internally forwards the request to <span class="command"><strong>b10-xfrout</strong></span>,
- which handles the rest of request processing.
+ which handles the rest of this request processing.
This is used to provide primary DNS service to share zones
to secondary name servers.
The <span class="command"><strong>b10-xfrout</strong></span> is also used to send
"key.example", you'll need to do this:
</p><pre class="screen">> <strong class="userinput"><code>config set tsig_keys/keys ["key.example:<base64-key>"]</code></strong>
> <strong class="userinput"><code>config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>Both Xfrout and Auth will use the system wide keyring to check
- TSIGs in the incoming messages and to sign responses.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+> <strong class="userinput"><code>config commit</code></strong></pre><p>Both <span class="command"><strong>b10-xfrout</strong></span> and <span class="command"><strong>b10-auth</strong></span>
+ will use the system wide keyring to check
+ TSIGs in the incoming messages and to sign responses.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
The way to specify zone specific configuration (ACLs, etc) is
likely to be changed.
- </p></div></div><div class="chapter" title="Chapter 11. Dynamic DNS Update"><div class="titlepage"><div><div><h2 class="title"><a name="ddns"></a>Chapter 11. Dynamic DNS Update</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p433840">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#idp448128">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#idp471872">11.3. Miscellaneous Operational Issues</a></span></dt></dl></div><p>
+ </p></div></div><div class="chapter" title="Chapter 11. Dynamic DNS Update"><div class="titlepage"><div><div><h2 class="title"><a name="ddns"></a>Chapter 11. Dynamic DNS Update</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229439633">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#id1168229439733">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#id1168229439954">11.3. Miscellaneous Operational Issues</a></span></dt></dl></div><p>
BIND 10 supports the server side of the Dynamic DNS Update
(DDNS) protocol as defined in RFC 2136.
This service is provided by the <span class="command"><strong>b10-ddns</strong></span>
When the <span class="command"><strong>b10-auth</strong></span> authoritative DNS server
receives an UPDATE request, it internally forwards the request
to <span class="command"><strong>b10-ddns</strong></span>, which handles the rest of
- request processing.
- When the processing is completed <span class="command"><strong>b10-ddns</strong></span>
- 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).
+ this request processing.
+ When the processing is completed, <span class="command"><strong>b10-ddns</strong></span>
+ 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 <span class="command"><strong>b10-xfrout</strong></span> so that other secondary
- servers will be notified via the DNS notify protocol.
+ servers will be notified via the DNS NOTIFY protocol.
In addition, if <span class="command"><strong>b10-auth</strong></span> serves the updated
zone from its in-memory cache (as described in
- <a class="xref" href="#in-memory-datasource-with-sqlite3-backend" title="8.2.2. In-memory Data Source With SQLite3 Backend">Section 8.2.2, “In-memory Data Source With SQLite3 Backend”</a>),
+ <a class="xref" href="#in-memory-datasource-with-sqlite3-backend" title="8.2.2. In-memory Data Source with SQLite3 Backend">Section 8.2.2, “In-memory Data Source with SQLite3 Backend”</a>),
<span class="command"><strong>b10-ddns</strong></span> will also
notify <span class="command"><strong>b10-auth</strong></span> so that <span class="command"><strong>b10-auth</strong></span>
will re-cache the updated zone content.
As of this writing <span class="command"><strong>b10-ddns</strong></span> 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.
+ immediately return a <span class="quote">“<span class="quote">not implemented</span>”</span> response.
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- For feature completeness update forwarding should be
- eventually supported. But right now it's considered a lower
+ 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.
</p></div><p>
- </p><div class="section" title="11.1. Enabling Dynamic Update"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p433840"></a>11.1. Enabling Dynamic Update</h2></div></div></div><p>
+ </p><div class="section" title="11.1. Enabling Dynamic Update"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439633"></a>11.1. Enabling Dynamic Update</h2></div></div></div><p>
First off, it must be made sure that a few components on which
<span class="command"><strong>b10-ddns</strong></span> depends are configured to run,
which are <span class="command"><strong>b10-auth</strong></span>
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 <span class="command"><strong>b10-ddns</strong></span> component
- configures itself with the data source referring to the
- <span class="quote">“<span class="quote">database_file</span>”</span> configuration parameter of
+ Also, in this development version, the <span class="command"><strong>b10-ddns</strong></span>
+ component configures itself with the data source referring to the
+ <code class="varname">database_file</code> configuration parameter of
<span class="command"><strong>b10-auth</strong></span>.
So this information must be configured correctly before starting
<span class="command"><strong>b10-ddns</strong></span>.
> <strong class="userinput"><code>config commit</code></strong>
</pre><p>
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
- 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
- <span class="command"><strong>b10-ddns</strong></span> would start and work without
- specifying it. But for it to shutdown gracefully this
- parameter should also be specified.
+ In theory <code class="varname">kind</code> 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 <span class="command"><strong>bindctl</strong></span> and you'll still need to
+ specify that explicitly. Likewise, <code class="varname">address</code>
+ may look unnecessary because <span class="command"><strong>b10-ddns</strong></span>
+ would start and work without specifying it. But for it
+ to shutdown gracefully this parameter should also be
+ specified.
</p></div><p>
- </p></div><div class="section" title="11.2. Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp448128"></a>11.2. Access Control</h2></div></div></div><p>
- By default <span class="command"><strong>b10-ddns</strong></span> rejects any update
- requests from any clients by returning a response with an RCODE
- of REFUSED.
+ </p></div><div class="section" title="11.2. Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id1168229439733"></a>11.2. Access Control</h2></div></div></div><p>
+ By default, <span class="command"><strong>b10-ddns</strong></span> 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
- <span class="quote">“<span class="quote">zones</span>”</span> configuration parameter of
+ <code class="varname">zones</code> configuration parameter of
<span class="command"><strong>b10-ddns</strong></span>.
This is a list of per-zone configurations regarding DDNS.
Each list element consists of the following parameters:
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 <span class="quote">“<span class="quote">example.org</span>”</span> of RR class <span class="quote">“<span class="quote">IN</span>”</span>
+ named <span class="quote">“<span class="quote">example.org</span>”</span> (of default RR class <span class="quote">“<span class="quote">IN</span>”</span>)
from clients that send requests signed with a TSIG whose
key name is "key.example.org" (and refuses all others):
</p><pre class="screen">
> <strong class="userinput"><code>config add DDNS/zones</code></strong>
> <strong class="userinput"><code>config set DDNS/zones[0]/origin example.org</code></strong>
-> <strong class="userinput"><code>config set DDNS/zones[0]/class IN</code></strong>
-(Note: "class" can be omitted)
> <strong class="userinput"><code>config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}</code></strong>
> <strong class="userinput"><code>config commit</code></strong>
</pre><p>
> <strong class="userinput"><code>config commit</code></strong>
</pre><p>
(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 new entry and sets it to the given rule.
+ have had only entry in <code class="varname">zones[0]/update_acl</code>.
+ The <span class="command"><strong>add</strong></span> 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).
+ a given rule.)
</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
The <span class="command"><strong>b10-ddns</strong></span> component accepts an ACL
rule that just allows updates from a specific IP address
arbitrary clients.
There have been other troubles that could have been avoided if
the ACL could be checked before the prerequisite check.
- </p></div></div><div class="section" title="11.3. Miscellaneous Operational Issues"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p471872"></a>11.3. Miscellaneous Operational Issues</h2></div></div></div><p>
+ </p></div></div><div class="section" title="11.3. Miscellaneous Operational Issues"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229439954"></a>11.3. Miscellaneous Operational Issues</h2></div></div></div><p>
Unlike BIND 9, BIND 10 currently does not support automatic
- resigning of DNSSEC-signed zone when it's updated via DDNS.
- It could be possible to resign the updated zone afterwards
+ re-signing of DNSSEC-signed zone when it's updated via DDNS.
+ It could be possible to 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
<span class="command"><strong>b10-zonemgr</strong></span>. Zones listed in
<span class="quote">“<span class="quote">secondary_zones</span>”</span> will never be updated via DDNS
regardless of the update ACL configuration;
- <span class="command"><strong>b10-ddns</strong></span> will return a response with an
- RCODE of NOTAUTH as specified in RFC 2136.
+ <span class="command"><strong>b10-ddns</strong></span> 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
IXFR.
This is done automatically; it does not require specific
configuration to make this possible.
- </p></div></div><div class="chapter" title="Chapter 12. Recursive Name Server"><div class="titlepage"><div><div><h2 class="title"><a name="resolverserver"></a>Chapter 12. Recursive Name Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p492912">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp509632">12.2. Forwarding</a></span></dt></dl></div><p>
+ </p></div></div><div class="chapter" title="Chapter 12. Recursive Name Server"><div class="titlepage"><div><div><h2 class="title"><a name="resolverserver"></a>Chapter 12. Recursive Name Server</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229440091">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#id1168229440276">12.2. Forwarding</a></span></dt></dl></div><p>
The <span class="command"><strong>b10-resolver</strong></span> process is started by
<span class="command"><strong>bind10</strong></span>.
</pre><p>
</p><p>(Replace the <span class="quote">“<span class="quote"><em class="replaceable"><code>2</code></em></span>”</span>
as needed; run <span class="quote">“<span class="quote"><strong class="userinput"><code>config show
- Resolver/listen_on</code></strong></span>”</span> if needed.)</p><div class="section" title="12.1. Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p492912"></a>12.1. Access Control</h2></div></div></div><p>
+ Resolver/listen_on</code></strong></span>”</span> if needed.)</p><div class="section" title="12.1. Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229440091"></a>12.1. Access Control</h2></div></div></div><p>
By default, the <span class="command"><strong>b10-resolver</strong></span> daemon only accepts
DNS queries from the localhost (127.0.0.1 and ::1).
The <code class="option">Resolver/query_acl</code> configuration may
</pre><p>(Replace the <span class="quote">“<span class="quote"><em class="replaceable"><code>2</code></em></span>”</span>
as needed; run <span class="quote">“<span class="quote"><strong class="userinput"><code>config show
Resolver/query_acl</code></strong></span>”</span> if needed.)</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This prototype access control configuration
- syntax may be changed.</p></div></div><div class="section" title="12.2. Forwarding"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p509632"></a>12.2. Forwarding</h2></div></div></div><p>
+ syntax may be changed.</p></div></div><div class="section" title="12.2. Forwarding"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229440276"></a>12.2. Forwarding</h2></div></div></div><p>
To enable forwarding, the upstream address and port must be
configured to forward queries to, such as:
}
}
</pre><p>
- </p></div><div class="chapter" title="Chapter 17. Logging"><div class="titlepage"><div><div><h2 class="title"><a name="logging"></a>Chapter 17. Logging</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
p609968">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp611664">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp648032">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp673088">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp704416">17.2. Logging Message Format</a></span></dt></dl></div><div class="section" title="17.1. Logging configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp609968"></a>17.1. Logging configuration</h2></div></div></div><p>
+ </p></div><div class="chapter" title="Chapter 17. Logging"><div class="titlepage"><div><div><h2 class="title"><a name="logging"></a>Chapter 17. Logging</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id
1168229440926">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#id1168229440937">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#id1168229441248">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#id1168229441431">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#id1168229441640">17.2. Logging Message Format</a></span></dt></dl></div><div class="section" title="17.1. Logging configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id1168229440926"></a>17.1. Logging configuration</h2></div></div></div><p>
The logging system in BIND 10 is configured through the
Logging module. All BIND 10 modules will look at the
- </p><div class="section" title="17.1.1. Loggers"><div class="titlepage"><div><div><h3 class="title"><a name="id
p611664"></a>17.1.1. Loggers</h3></div></div></div><p>
+ </p><div class="section" title="17.1.1. Loggers"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229440937"></a>17.1.1. Loggers</h3></div></div></div><p>
Within BIND 10, a message is logged through a component
called a "logger". Different parts of BIND 10 log messages
(what to log), and the <code class="option">output_options</code>
(where to log).
- </p><div class="section" title="17.1.1.1. name (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p615424"></a>17.1.1.1. name (string)</h4></div></div></div><p>
+ </p><div class="section" title="17.1.1.1. name (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229440962"></a>17.1.1.1. name (string)</h4></div></div></div><p>
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,
<span class="quote">“<span class="quote">Auth.cache</span>”</span> logger will appear in the output
with a logger name of <span class="quote">“<span class="quote">b10-auth.cache</span>”</span>).
- </p></div><div class="section" title="17.1.1.2. severity (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p631472"></a>17.1.1.2. severity (string)</h4></div></div></div><p>
+ </p></div><div class="section" title="17.1.1.2. severity (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441130"></a>17.1.1.2. severity (string)</h4></div></div></div><p>
This specifies the category of messages logged.
Each message is logged with an associated severity which
- </p></div><div class="section" title="17.1.1.3. output_options (list)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p638448"></a>17.1.1.3. output_options (list)</h4></div></div></div><p>
+ </p></div><div class="section" title="17.1.1.3. output_options (list)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441180"></a>17.1.1.3. output_options (list)</h4></div></div></div><p>
Each logger can have zero or more
<code class="option">output_options</code>. These specify where log
The other options for a logger are:
- </p></div><div class="section" title="17.1.1.4. debuglevel (integer)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p640720"></a>17.1.1.4. debuglevel (integer)</h4></div></div></div><p>
+ </p></div><div class="section" title="17.1.1.4. debuglevel (integer)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441197"></a>17.1.1.4. debuglevel (integer)</h4></div></div></div><p>
When a logger's severity is set to DEBUG, this value
specifies what debug messages should be printed. It ranges
If severity for the logger is not DEBUG, this value is ignored.
- </p></div><div class="section" title="17.1.1.5. additive (true or false)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p643104"></a>17.1.1.5. additive (true or false)</h4></div></div></div><p>
+ </p></div><div class="section" title="17.1.1.5. additive (true or false)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441212"></a>17.1.1.5. additive (true or false)</h4></div></div></div><p>
If this is true, the <code class="option">output_options</code> from
the parent will be used. For example, if there are two
- </p></div></div><div class="section" title="17.1.2. Output Options"><div class="titlepage"><div><div><h3 class="title"><a name="id
p648032"></a>17.1.2. Output Options</h3></div></div></div><p>
+ </p></div></div><div class="section" title="17.1.2. Output Options"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229441248"></a>17.1.2. Output Options</h3></div></div></div><p>
The main settings for an output option are the
<code class="option">destination</code> and a value called
<code class="option">output</code>, the meaning of which depends on
the destination that is set.
- </p><div class="section" title="17.1.2.1. destination (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p650112"></a>17.1.2.1. destination (string)</h4></div></div></div><p>
+ </p><div class="section" title="17.1.2.1. destination (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441264"></a>17.1.2.1. destination (string)</h4></div></div></div><p>
The destination is the type of output. It can be one of:
- </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> console </li><li class="listitem"> file </li><li class="listitem"> syslog </li></ul></div></div><div class="section" title="17.1.2.2. output (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
p654176"></a>17.1.2.2. output (string)</h4></div></div></div><p>
+ </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"> console </li><li class="listitem"> file </li><li class="listitem"> syslog </li></ul></div></div><div class="section" title="17.1.2.2. output (string)"><div class="titlepage"><div><div><h4 class="title"><a name="id
1168229441296"></a>17.1.2.2. output (string)</h4></div></div></div><p>
Depending on what is set as the output destination, this
value is interpreted as follows:
The other options for <code class="option">output_options</code> are:
- </p><div class="section" title="17.1.2.2.1. flush (true of false)"><div class="titlepage"><div><div><h5 class="title"><a name="id
p667136"></a>17.1.2.2.1. flush (true of false)</h5></div></div></div><p>
+ </p><div class="section" title="17.1.2.2.1. flush (true of false)"><div class="titlepage"><div><div><h5 class="title"><a name="id
1168229441389"></a>17.1.2.2.1. flush (true of false)</h5></div></div></div><p>
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.
- </p></div><div class="section" title="17.1.2.2.2. maxsize (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="id
p668576"></a>17.1.2.2.2. maxsize (integer)</h5></div></div></div><p>
+ </p></div><div class="section" title="17.1.2.2.2. maxsize (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="id
1168229441400"></a>17.1.2.2.2. maxsize (integer)</h5></div></div></div><p>
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.
etc.)
</p><p>
If this is 0, no maximum file size is used.
- </p></div><div class="section" title="17.1.2.2.3. maxver (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="id
p670640"></a>17.1.2.2.3. maxver (integer)</h5></div></div></div><p>
+ </p></div><div class="section" title="17.1.2.2.3. maxver (integer)"><div class="titlepage"><div><div><h5 class="title"><a name="id
1168229441413"></a>17.1.2.2.3. maxver (integer)</h5></div></div></div><p>
Maximum number of old log files to keep around when
rolling the output file. Only relevant when
<code class="option">destination</code> is <span class="quote">“<span class="quote">file</span>”</span>.
- </p></div></div></div><div class="section" title="17.1.3. Example session"><div class="titlepage"><div><div><h3 class="title"><a name="id
p673088"></a>17.1.3. Example session</h3></div></div></div><p>
+ </p></div></div></div><div class="section" title="17.1.3. Example session"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229441431"></a>17.1.3. Example session</h3></div></div></div><p>
In this example we want to set the global logging to
write to the file <code class="filename">/var/log/my_bind10.log</code>,
And every module will now be using the values from the
logger named <span class="quote">“<span class="quote">*</span>”</span>.
- </p></div></div><div class="section" title="17.2. Logging Message Format"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p704416"></a>17.2. Logging Message Format</h2></div></div></div><p>
+ </p></div></div><div class="section" title="17.2. Logging Message Format"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
1168229441640"></a>17.2. Logging Message Format</h2></div></div></div><p>
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
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.
1.1. Supported Platforms
- 1.2. Required Software
+ 1.2. Required Software at Run-time
1.3. Starting and Stopping the Server
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
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
List of Tables
- 3.1.
+ 3.1. Special startup components
Preface
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.
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
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
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
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
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
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.
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
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:
$ 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
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:
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.
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
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
> 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
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
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:
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
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
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
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
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
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
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
> 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
> 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
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
> 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
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
> 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
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
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
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
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
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
> 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
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.
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
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
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.
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
projects / thirdparty / kea.git / commitdiff
