-<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="id
1168229451102"></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
+<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="id
p65824"></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
20120712.</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 with development managed by Internet Systems Consortium (ISC).
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
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
+ </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id
p72592">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="#idp78528">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="#idp187568">2.5.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp190304">2.5.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp199184">2.5.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp212528">2.5.4. Build</a></span></dt><dt><span class="section"><a href="#idp214512">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="#idp328704">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#datasrc">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#datasource-types">8.2.1. Data source types</a></span></dt><dt><span class="section"><a href="#datasrc-examples">8.2.2. Examples</a></span></dt></dl></dd><dt><span class="section"><a href="#idp398368">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="#idp416624">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp421968">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="#idp437744">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#idp441440">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="#idp475472">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#idp491056">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#idp515968">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="#idp537024">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp553744">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="#idp654128">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp655824">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp692192">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp717248">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp748576">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="#idp241344">Special startup components</a></dt></dl></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="idp72592"></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
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>
+ 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
p78528">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 and ISC DHCP.
</p><p>
This guide covers the experimental prototype of
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>
+ </p><div class="section" title="1.1. Supported Platforms"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id
p78528"></a>1.1. Supported Platforms</h2></div></div></div><p>
BIND 10 builds have been tested on (in no particular order)
Debian GNU/Linux 6 and unstable, Ubuntu 9.10, NetBSD 5,
Solaris 10 and 11, FreeBSD 7 and 8, CentOS Linux 5.3,
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="#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="#id
1168229436957">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>
+ </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="#id
p187568">2.5.1. Download Tar File</a></span></dt><dt><span class="section"><a href="#idp190304">2.5.2. Retrieve from Git</a></span></dt><dt><span class="section"><a href="#idp199184">2.5.3. Configure before the build</a></span></dt><dt><span class="section"><a href="#idp212528">2.5.4. Build</a></span></dt><dt><span class="section"><a href="#idp214512">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.
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="id
1168229436957"></a>2.5.1. Download Tar File</h3></div></div></div><p>
+ </p><div class="section" title="2.5.1. Download Tar File"><div class="titlepage"><div><div><h3 class="title"><a name="id
p187568"></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.5.2. Retrieve from Git"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229436977"></a>2.5.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="id
p190304"></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.
<span class="command"><strong>autoheader</strong></span>,
<span class="command"><strong>automake</strong></span>,
and related commands.
- </p></div><div class="section" title="2.5.3. Configure before the build"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229437037"></a>2.5.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="id
p199184"></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><p>
If the configure fails, it may be due to missing or old
dependencies.
- </p></div><div class="section" title="2.5.4. Build"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229437136"></a>2.5.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="id
p212528"></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.5.5. Install"><div class="titlepage"><div><div><h3 class="title"><a name="id
1168229437150"></a>2.5.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="id
p214512"></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>
started in a special way, with the value of special used
for them:
- </p><div class="table"><a name="id
1168229437333"></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><div class="table"><a name="id
p241344"></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 <code class="varname">kind</code> specifies how a failure of the
component should be handled. If it is set to
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
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>
+ </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
p328704">8.1. Server Configurations</a></span></dt><dt><span class="section"><a href="#datasrc">8.2. Data Source Backends</a></span></dt><dd><dl><dt><span class="section"><a href="#datasource-types">8.2.1. Data source types</a></span></dt><dt><span class="section"><a href="#datasrc-examples">8.2.2. Examples</a></span></dt></dl></dd><dt><span class="section"><a href="#idp398368">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, 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
1168229438312"></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
p328704"></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>.
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="id1168229438638"></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.
+ </p></div><div class="section" title="8.2. Data Source Backends"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="datasrc"></a>8.2. Data Source Backends</h2></div></div></div><p>
+ Bind 10 has the concept of data sources. A data source is a place
+ where authoritative zone data reside and where they can be served
+ from. This can be a master file, a database or something completely
+ different.
+ </p><p>
+ Once a query arrives, <span class="command"><strong>b10-auth</strong></span> goes through a
+ configured list of data sources and finds the one containing a best
+ matching zone. From the equally good ones, the first one is taken.
+ This data source is then used to answer the query.
+ </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ In the development prototype release, <span class="command"><strong>b10-auth</strong></span>
+ can serve data from a SQLite3 data source backend and from master
+ files.
Upcoming versions will be able to use multiple different
data sources, such as MySQL and Berkeley DB.
</p></div><p>
- By default, the SQLite3 backend uses the data file located at
+ The configuration is located in data_sources/classes. Each item there
+ represents one RR class and a list used to answer queries for that
+ class. The default contains two classes. The CH class contains a static
+ data source — one that serves things like
+ <span class="quote">“<span class="quote">AUTHORS.BIND.</span>”</span>. The IN class contains single SQLite3
+ data source with database file located at
<code class="filename">/usr/local/var/bind10-devel/zone.sqlite3</code>.
- (The full path is what was defined at build configure time for
- <code class="option">--localstatedir</code>.
- The default is <code class="filename">/usr/local/var/</code>.)
- This data file location may be changed by defining the
- <span class="quote">“<span class="quote">database_file</span>”</span> configuration.
- </p><div class="section" title="8.2.1. In-memory Data Source"><div class="titlepage"><div><div><h3 class="title"><a name="in-memory-datasource"></a>8.2.1. In-memory Data Source</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
- source containing the <span class="quote">“<span class="quote">example.com</span>”</span> zone
- with the zone file named <span class="quote">“<span class="quote">example.com.zone</span>”</span>:
-
-
+ </p><p>
+ Each data source has several options. The first one is
+ <code class="varname">type</code>, which specifies the type of data source to
+ use. Valid types include the ones listed below, but bind10 uses
+ dynamically loaded modules for them, so there may be more in your
+ case. This option is mandatory.
+ </p><p>
+ Another option is <code class="varname">params</code>. This option is type
+ specific; it holds different data depending on the type
+ above. Also, depending on the type, it could be possible to omit it.
+ </p><p>
+ There are two options related to the so-called cache. If you enable
+ cache, zone data from the data source are loaded into memory.
+ Then, when answering a query, <span class="command"><strong>b10-auth</strong></span> looks
+ into the memory only instead of the data source, which speeds
+ answering up. The first option is <code class="varname">cache-enable</code>,
+ a boolean value turning the cache on and off (off is the default).
+ The second one, <code class="varname">cache-zones</code>, is a list of zone
+ origins to load into in-memory. Remember that zones in the data source
+ not listed here will not be loaded and will not be available at all.
+ </p><div class="section" title="8.2.1. Data source types"><div class="titlepage"><div><div><h3 class="title"><a name="datasource-types"></a>8.2.1. Data source types</h3></div></div></div><p>
+ As mentioned, the type used by default is <span class="quote">“<span class="quote">sqlite3</span>”</span>.
+ It has single configuration option inside <code class="varname">params</code>
+ — <code class="varname">database_file</code>, which contains the path
+ to the sqlite3 file containing the data.
+ </p><p>
+ Another type is called <span class="quote">“<span class="quote">MasterFiles</span>”</span>. This one is
+ slightly special. The data are stored in RFC1034 master files.
+ Because answering directly from them would be impractical,
+ this type mandates the cache to be enabled. Also, the list of
+ zones (<code class="varname">cache-zones</code>) should be omitted. The
+ <code class="varname">params</code> is a dictionary mapping from zone
+ origins to the files they reside in.
+ </p></div><div class="section" title="8.2.2. Examples"><div class="titlepage"><div><div><h3 class="title"><a name="datasrc-examples"></a>8.2.2. Examples</h3></div></div></div><p>
+ As this is one of the more complex configurations of Bind10,
+ we show some examples. They all assume they start with default
+ configuration.
+ </p><p>
+ First, let's disable the static data source
+ (<span class="quote">“<span class="quote">VERSION.BIND</span>”</span> and friends). As it is the only
+ data source in the CH class, we can remove the whole class.
- </p><pre class="screen">> <strong class="userinput"><code>config add Auth/datasources</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[0]/type "<code class="option">memory</code>"</code></strong>
-> <strong class="userinput"><code>config add Auth/datasources[0]/zones</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[0]/zones[0]/origin "<code class="option">example.com</code>"</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[0]/zones[0]/file "<code class="option">example.com.zone</code>"</code></strong>
+ </p><pre class="screen">> <strong class="userinput"><code>config remove data_sources/classes CH</code></strong>
> <strong class="userinput"><code>config commit</code></strong></pre><p>
-
- The authoritative server will begin serving it immediately
- 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
- source containing the <span class="quote">“<span class="quote">example.org</span>”</span> zone
- with a SQLite3 backend file named <span class="quote">“<span class="quote">example.org.sqlite3</span>”</span>:
-
-
-
- </p><pre class="screen">> <strong class="userinput"><code>config add Auth/datasources</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[1]/type "<code class="option">memory</code>"</code></strong>
-> <strong class="userinput"><code>config add Auth/datasources[1]/zones</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[1]/zones[0]/origin "<code class="option">example.org</code>"</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[1]/zones[0]/file "<code class="option">example.org.sqlite3</code>"</code></strong>
-> <strong class="userinput"><code>config set Auth/datasources[1]/zones[0]/filetype "<code class="option">sqlite3</code>"</code></strong>
+ </p><p>
+ Another one, let's say our default data source contains zones
+ <span class="quote">“<span class="quote">example.org.</span>”</span> and <span class="quote">“<span class="quote">example.net.</span>”</span>.
+ We want them to be served from memory to make the answering
+ faster.
+
+ </p><pre class="screen">> <strong class="userinput"><code>config set data_sources/classes/IN[0]/cache-enable true</code></strong>
+> <strong class="userinput"><code>config add data_sources/classes/IN[0]/cache-zones example.org.</code></strong>
+> <strong class="userinput"><code>config add data_sources/classes/IN[0]/cache-zones example.net.</code></strong>
> <strong class="userinput"><code>config commit</code></strong></pre><p>
- The authoritative server will begin serving it immediately
- 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
- file into memory; for example:
-
- </p><pre class="screen">> <strong class="userinput"><code>Auth loadzone origin="example.com"</code></strong>
-</pre><p>
-
- </p></div><div class="section" title="8.2.4. Disabling In-memory Data Sources"><div class="titlepage"><div><div><h3 class="title"><a name="in-memory-datasource-disabling"></a>8.2.4. Disabling In-memory Data Sources</h3></div></div></div><p>
- By default, the memory data source is disabled; it must be
- configured explicitly. To disable all the in-memory zones,
- specify a null list for <code class="varname">Auth/datasources</code>:
-
-
-
- </p><pre class="screen">> <strong class="userinput"><code>config set Auth/datasources/ []</code></strong>
-> <strong class="userinput"><code>config commit</code></strong></pre><p>
- </p><p>
- The following example stops serving a specific zone:
+ Now every time the zone in the data source is changed by the
+ operator, Bind10 needs to be told to reload it, by
+ </p><pre class="screen">> <strong class="userinput"><code>Auth loadzone example.org</code></strong></pre><p>
+ You don't need to do this when the zone is modified by
+ XfrIn, it does so automatically.
+ </p><p>
+ Now, the last example is when there are master files we want to
+ serve in addition to whatever is inside the sqlite3 database.
- </p><pre class="screen">> <strong class="userinput"><code>config remove Auth/datasources[<code class="option">0</code>]/zones[<code class="option">0</code>]</code></strong>
+ </p><pre class="screen">> <strong class="userinput"><code>config add data_sources/classes/IN</code></strong>
+> <strong class="userinput"><code>config set data_sources/classes/IN[1]/type MasterFiles</code></strong>
+> <strong class="userinput"><code>config set data_sources/classes/IN[1]/cache-enable true</code></strong>
+> <strong class="userinput"><code>config set data_sources/classes/IN[1]/params { "example.org": "/path/to/example.org", "example.com": "/path/to/example.com" }</code></strong>
> <strong class="userinput"><code>config commit</code></strong></pre><p>
- (Replace the list number(s) in
- <code class="varname">datasources[<em class="replaceable"><code>0</code></em>]</code>
- 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="id1168229438940"></a>8.3. Loading Master Zones Files</h2></div></div></div><p>
+ Initially, a map value has to be set, but this value may be an
+ empty map. After that, key/value pairs can be added with 'config
+ add' and keys can be removed with 'config remove'. The initial
+ value may be an empty map, but it has to be set before zones are
+ added or removed.
+
+ </p><pre class="screen">
+> <strong class="userinput"><code>config set data_sources/classes/IN[1]/params {}</code></strong>
+> <strong class="userinput"><code>config add data_sources/classes/IN[1]/params another.example.org /path/to/another.example.org</code></strong>
+> <strong class="userinput"><code>config add data_sources/classes/IN[1]/params another.example.com /path/to/another.example.com</code></strong>
+> <strong class="userinput"><code>config remove data_sources/classes/IN[1]/params another.example.org</code></strong>
+ </pre><p>
+
+ <span class="command"><strong>bindctl</strong></span>. To reload a zone, you the same command
+ as above.
+ </p></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+ There's also <code class="varname">Auth/database_file</code> configuration
+ variable, pointing to a sqlite3 database file. This is no longer
+ used by <span class="command"><strong>b10-auth</strong></span>, but it is left in place for
+ now, since other modules use it. Once <span class="command"><strong>b10-xfrin</strong></span>,
+ <span class="command"><strong>b10-xfrout</strong></span> and <span class="command"><strong>b10-ddns</strong></span>
+ are ported to the new configuration, this will disappear. But for
+ now, make sure that if you use any of these modules, the new
+ and old configuration correspond. The defaults are consistent, so
+ unless you tweaked either the new or the old configuration, you're
+ good.
+ </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="idp398368"></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
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>
+ </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
p416624">9.1. Configuration for Incoming Zone Transfers</a></span></dt><dt><span class="section"><a href="#idp421968">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="#idp437744">9.4. Trigger an Incoming Zone Transfer Manually</a></span></dt><dt><span class="section"><a href="#idp441440">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
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
1168229439105"></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
p416624"></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
1168229439142"></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
p421968"></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>
(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
1168229439316"></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
p437744"></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
1168229439342"></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
p441440"></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="#datasrc" title="8.2. Data Source Backends">Section 8.2, “Data Source Backends”</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>.
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
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>
+ </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
p475472">11.1. Enabling Dynamic Update</a></span></dt><dt><span class="section"><a href="#idp491056">11.2. Access Control</a></span></dt><dt><span class="section"><a href="#idp515968">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>
notify <span class="command"><strong>b10-xfrout</strong></span> so that other secondary
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>),
+ zone (as described in
+ <a class="xref" href="#datasrc" title="8.2. Data Source Backends">Section 8.2, “Data Source Backends”</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.
+ will re-cache the updated zone content if necessary.
</p><p>
The <span class="command"><strong>b10-ddns</strong></span> component supports requests over
both UDP and TCP, and both IPv6 and IPv4; for TCP requests,
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
1168229439633"></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
p475472"></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>
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="id
1168229439733"></a>11.2. Access Control</h2></div></div></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="id
p491056"></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
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
1168229439954"></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
p515968"></a>11.3. Miscellaneous Operational Issues</h2></div></div></div><p>
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 re-sign the updated zone afterwards
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
1168229440091">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#id1168229440276">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
p537024">12.1. Access Control</a></span></dt><dt><span class="section"><a href="#idp553744">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
1168229440091"></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
p537024"></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
1168229440276"></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
p553744"></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
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>
+ </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
p654128">17.1. Logging configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp655824">17.1.1. Loggers</a></span></dt><dt><span class="section"><a href="#idp692192">17.1.2. Output Options</a></span></dt><dt><span class="section"><a href="#idp717248">17.1.3. Example session</a></span></dt></dl></dd><dt><span class="section"><a href="#idp748576">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="idp654128"></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
1168229440937"></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
p655824"></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
1168229440962"></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
p659584"></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
1168229441130"></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
p675632"></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
1168229441180"></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
p682608"></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
1168229441197"></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
p684880"></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
1168229441212"></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
p687264"></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
1168229441248"></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
p692192"></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
1168229441264"></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
p694272"></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
1168229441296"></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
p698336"></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
1168229441389"></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
p711296"></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
1168229441400"></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
p712736"></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
1168229441413"></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
p714800"></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
1168229441431"></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
p717248"></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
1168229441640"></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
p748576"></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
This is the reference guide for BIND 10 version 20120712.
- Copyright (c) 2010-2012 Internet Systems Consortium, Inc.
+ Copyright © 2010-2012 Internet Systems Consortium, Inc.
Abstract
8.2. Data Source Backends
- 8.2.1. In-memory Data Source
+ 8.2.1. Data source types
- 8.2.2. In-memory Data Source with SQLite3
- Backend
-
- 8.2.3. Reloading an In-memory Data Source
-
- 8.2.4. Disabling In-memory Data Sources
+ 8.2.2. Examples
8.3. Loading Master Zones Files
1. Acknowledgements
-1. Acknowledgements
+1. Acknowledgements
ISC would like to acknowledge generous support for BIND 10 development of
DHCPv4 and DHCPv6 components provided by Comcast.
-Chapter 1. Introduction
+Chapter 1. Introduction
Table of Contents
This guide covers the experimental prototype of BIND 10 version 20120712.
-1.1. Supported Platforms
+1.1. Supported Platforms
BIND 10 builds have been tested on (in no particular order) Debian
GNU/Linux 6 and unstable, Ubuntu 9.10, NetBSD 5, Solaris 10 and 11,
planned for BIND 10 to build, install and run on Windows and standard
Unix-type platforms.
-1.2. Required Software at Run-time
+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".)
+ (For the build requirements, also see Section 2.3, “Building
+ Requirements”.)
BIND 10 requires at least Python 3.1 (http://www.python.org/). It also
works with Python 3.2.
included with Python). Python modules need to be built for the
corresponding Python 3.
-1.3. Starting and Stopping the Server
+1.3. Starting and Stopping the Server
BIND 10 is modular. Part of this modularity is accomplished using multiple
cooperating processes which, together, provide the server functionality.
processes as needed. The processes started by the bind10 command have
names starting with "b10-", including:
- o b10-auth -- Authoritative DNS server. This process serves DNS
- requests.
- o b10-cfgmgr -- Configuration manager. This process maintains all of the
+ o b10-auth — Authoritative DNS server. This process serves DNS requests.
+ o b10-cfgmgr — Configuration manager. This process maintains all of the
configuration for BIND 10.
- o b10-cmdctl -- Command and control service. This process allows
- external control of the BIND 10 system.
- o b10-ddns -- Dynamic DNS update service. This process is used to handle
+ o b10-cmdctl — Command and control service. This process allows external
+ control of the BIND 10 system.
+ o b10-ddns — Dynamic DNS update service. This process is used to handle
incoming DNS update requests to allow granted clients to update zones
for which BIND 10 is serving as a primary server.
- o b10-msgq -- Message bus daemon. This process coordinates communication
+ 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
+ o b10-resolver — Recursive name server. This process handles incoming
DNS queries and provides answers from its cache or by recursively
doing remote lookups.
- o b10-sockcreator -- Socket creator daemon. This process creates sockets
+ 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
+ o b10-stats — Statistics collection daemon. This process collects and
reports statistics data.
- o b10-stats-httpd -- HTTP server for statistics reporting. This process
+ o b10-stats-httpd — HTTP server for statistics reporting. This process
reports statistics data in XML format over HTTP.
- o b10-xfrin -- Incoming zone transfer service. This process is used to
+ o b10-xfrin — Incoming zone transfer service. This process is used to
transfer a new copy of a zone into BIND 10, when acting as a secondary
server.
- o b10-xfrout -- Outgoing zone transfer service. This process is used to
+ 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.
- o b10-zonemgr -- Secondary zone manager. This process keeps track of
+ 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 by bind10 and do not need to be manually started
independently.
-1.4. Managing BIND 10
+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
Python for the message bus, configuration backend, and, of course, DNS.
These include detailed developer documentation and code examples.
-Chapter 2. Installation
+Chapter 2. Installation
Table of Contents
2.5.5. Install
-2.1. Packages
+2.1. Packages
Some operating systems or softare package vendors may provide
ready-to-use, pre-built software packages for the BIND 10 suite.
FreeBSD ports, NetBSD pkgsrc, and Debian testing package collections
provide all the prerequisite packages.
-2.2. Install Hierarchy
+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
+ 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
+ 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.
+ o share/man/ — manual pages (online documentation).
+ o var/bind10-devel/ — data source and configuration databases.
-2.3. Building Requirements
+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
+ 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
http://bind10.isc.org/wiki/SystemSpecificNotes for system-specific
installation tips.
-2.4. Quick start
+2.4. Quick start
Note
To quickly get started with BIND 10, follow these steps.
- 1. Install required run-time and build dependencies.
- 2. Download the BIND 10 source tar file from
+ 1. Install required run-time and build dependencies.
+ 2. Download the BIND 10 source tar file from
ftp://ftp.isc.org/isc/bind10/.
- 3. Extract the tar file:
+ 3. Extract the tar file:
$ gzcat bind10-VERSION.tar.gz | tar -xvf -
- 4. Go into the source and run configure:
+ 4. Go into the source and run configure:
$ cd bind10-VERSION
$ ./configure
- 5. Build it:
+ 5. Build it:
$ make
- 6. Install it (to default /usr/local):
+ 6. Install it (to default /usr/local):
$ make install
- 7. Start the server:
+ 7. Start the server:
$ /usr/local/sbin/bind10
- 8. Test it; for example:
+ 8. Test it; for example:
$ dig @127.0.0.1 -c CH -t TXT authors.bind
- 9. Load desired zone file(s), for example:
+ 9. Load desired zone file(s), for example:
$ b10-loadzone your.zone.example.org
- 10. Test the new zone.
+ 10. Test the new zone.
-2.5. 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 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.5.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.5.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
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.
+ development is done in the “master” branch.
The code can be checked out from git://git.bind10.isc.org/bind10; for
example:
the --install switch. This will run autoconf, aclocal, libtoolize,
autoheader, automake, and related commands.
- 2.5.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:
If the configure fails, it may be due to missing or old dependencies.
- 2.5.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.5.5. Install
+ 2.5.5. Install
To install the BIND 10 executables, support files, and documentation, run:
The install step may require superuser privileges.
-Chapter 3. Starting BIND10 with bind10
+Chapter 3. Starting BIND10 with bind10
Table of Contents
b10-cmdctl for administration tools to communicate with the system, and
b10-stats for statistics collection.
-3.1. Starting BIND 10
+3.1. Starting BIND 10
To start the BIND 10 service, simply run bind10. Run it with the --verbose
switch to get additional debugging or diagnostic output.
If the setproctitle Python module is detected at start up, the process
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.
+ instead of just “python”. This is not needed on some operating systems.
-3.2. Configuration to start processes
+3.2. Configuration to start processes
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
> 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
+ 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.
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. Special startup components
+ Table 3.1. Special startup components
+----------------------------------------------------------------------+
| Component | Special | Description |
+----------------------------------------------------------------------+
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
+ 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 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
+ to “core”, 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
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).
+ 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
a situation, so it would probably not do what you want. Such support is
yet to be implemented.
-Chapter 4. Command channel
+Chapter 4. Command channel
The BIND 10 components use the b10-msgq message routing daemon to
communicate with other BIND 10 components. The b10-msgq implements what is
- called the "Command Channel". Processes intercommunicate by sending
+ called the “Command Channel”. Processes intercommunicate by sending
messages on the command channel. Example messages include shutdown, get
configurations, and set configurations. This Command Channel is not used
for DNS message passing. It is used only to control and monitor the BIND
/usr/local/var/bind10-devel/msg_socket for this interprocess
communication.
-Chapter 5. Configuration manager
+Chapter 5. Configuration manager
The configuration manager, b10-cfgmgr, handles all BIND 10 system
configuration. It provides persistent storage for configuration, and
The administrator doesn't connect to it directly, but uses a user
interface to communicate with the configuration manager via b10-cmdctl's
- REST-ful interface. b10-cmdctl is covered in Chapter 6, Remote control
+ REST-ful interface. b10-cmdctl is covered in Chapter 6, Remote control
daemon.
Note
The configuration manager does not have any command line arguments.
Normally it is not started manually, but is automatically started using
- the bind10 master process (as covered in Chapter 3, Starting BIND10 with
+ the bind10 master process (as covered in Chapter 3, Starting BIND10 with
bind10).
-Chapter 6. Remote control daemon
+Chapter 6. Remote control daemon
Table of Contents
When b10-cmdctl starts, it firsts asks b10-cfgmgr about what modules are
running and what their configuration is (over the b10-msgq channel). Then
- it will start listening on HTTPS for clients -- the user interface -- such
+ it will start listening on HTTPS for clients — the user interface — such
as bindctl.
b10-cmdctl directly sends commands (received from the user interface) to
/usr/local/etc/bind10-devel/cmdctl-accounts.csv. This comma-delimited file
lists the accounts with a user name, hashed password, and salt. (A sample
file is at /usr/local/share/bind10-devel/cmdctl-accounts.csv. It contains
- the user named "root" with the password "bind10".)
+ the user named “root” with the password “bind10”.)
The administrator may create a user account with the b10-cmdctl-usermgr
tool.
connection is stateless and times out in 1200 seconds by default. This can
be redefined by using the --idle-timeout command line argument.
-6.1. Configuration specification for b10-cmdctl
+6.1. Configuration specification for b10-cmdctl
The configuration items for b10-cmdctl are: accounts_file which defines
the path to the user accounts database (the default is
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
+Chapter 7. Control and configure user interface
Note
b10-cfgmgr which then stores the details and relays (over a b10-msgq
command channel) the configuration on to the specified module.
-Chapter 8. Authoritative Server
+Chapter 8. Authoritative Server
Table of Contents
8.2. Data Source Backends
- 8.2.1. In-memory Data Source
-
- 8.2.2. In-memory Data Source with SQLite3 Backend
+ 8.2.1. Data source types
- 8.2.3. Reloading an In-memory Data Source
-
- 8.2.4. Disabling In-memory Data Sources
+ 8.2.2. Examples
8.3. Loading Master Zones Files
IPv6, and SQLite3 and in-memory zone data backends. Normally it is started
by the bind10 master process.
-8.1. Server Configurations
+8.1. Server Configurations
b10-auth is configured via the b10-cfgmgr configuration manager. The
- module name is "Auth". The configuration data items are:
+ module name is “Auth”. The configuration data items are:
database_file
This is an optional string to define the path to find the SQLite3
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 ("sqlite3" to load from a
- SQLite3 database file or "text" to load from a master text file),
+ 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 (“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
There are plans to solve the problem such that the server handles
it by itself. But until it is actually implemented, it is
- recommended to alter the configuration -- remove the wildcard
+ recommended to alter the configuration — remove the wildcard
addresses and list all addresses explicitly. Then the server will
answer on the same interface the request came on, preserving the
correct address.
loadzone
loadzone tells b10-auth to load or reload a zone file. The
arguments include: class which optionally defines the class (it
- defaults to "IN"); origin is the domain name of the zone; and
+ defaults to “IN”); origin is the domain name of the zone; and
datasrc optionally defines the type of datasource (it defaults to
- "memory").
+ “memory”).
Note
argument to select the process ID to stop. (Note that the BIND 10
boss process may restart this service if configured.)
-8.2. Data Source Backends
+8.2. Data Source Backends
+
+ Bind 10 has the concept of data sources. A data source is a place where
+ authoritative zone data reside and where they can be served from. This can
+ be a master file, a database or something completely different.
+
+ Once a query arrives, b10-auth goes through a configured list of data
+ sources and finds the one containing a best matching zone. From the
+ equally good ones, the first one is taken. This data source is then used
+ to answer the query.
Note
- For the development prototype release, b10-auth supports a SQLite3 data
- source backend and in-memory data source backend. Upcoming versions will
+ In the development prototype release, b10-auth can serve data from a
+ SQLite3 data source backend and from master files. Upcoming versions will
be able to use multiple different data sources, such as MySQL and Berkeley
DB.
- By default, the SQLite3 backend uses the data file located at
- /usr/local/var/bind10-devel/zone.sqlite3. (The full path is what was
- defined at build configure time for --localstatedir. The default is
- /usr/local/var/.) This data file location may be changed by defining the
- "database_file" configuration.
-
- 8.2.1. In-memory Data Source
-
- The following commands to bindctl provide an example of configuring an
- in-memory data source containing the "example.com" zone with the zone file
- named "example.com.zone":
-
- > config add Auth/datasources
- > config set Auth/datasources[0]/type "memory"
- > config add Auth/datasources[0]/zones
- > config set Auth/datasources[0]/zones[0]/origin "example.com"
- > config set Auth/datasources[0]/zones[0]/file "example.com.zone"
+ The configuration is located in data_sources/classes. Each item there
+ represents one RR class and a list used to answer queries for that class.
+ The default contains two classes. The CH class contains a static data
+ source — one that serves things like “AUTHORS.BIND.”. The IN class
+ contains single SQLite3 data source with database file located at
+ /usr/local/var/bind10-devel/zone.sqlite3.
+
+ Each data source has several options. The first one is type, which
+ specifies the type of data source to use. Valid types include the ones
+ listed below, but bind10 uses dynamically loaded modules for them, so
+ there may be more in your case. This option is mandatory.
+
+ Another option is params. This option is type specific; it holds different
+ data depending on the type above. Also, depending on the type, it could be
+ possible to omit it.
+
+ There are two options related to the so-called cache. If you enable cache,
+ zone data from the data source are loaded into memory. Then, when
+ answering a query, b10-auth looks into the memory only instead of the data
+ source, which speeds answering up. The first option is cache-enable, a
+ boolean value turning the cache on and off (off is the default). The
+ second one, cache-zones, is a list of zone origins to load into in-memory.
+ Remember that zones in the data source not listed here will not be loaded
+ and will not be available at all.
+
+ 8.2.1. Data source types
+
+ As mentioned, the type used by default is “sqlite3”. It has single
+ configuration option inside params — database_file, which contains the
+ path to the sqlite3 file containing the data.
+
+ Another type is called “MasterFiles”. This one is slightly special. The
+ data are stored in RFC1034 master files. Because answering directly from
+ them would be impractical, this type mandates the cache to be enabled.
+ Also, the list of zones (cache-zones) should be omitted. The params is a
+ dictionary mapping from zone origins to the files they reside in.
+
+ 8.2.2. Examples
+
+ As this is one of the more complex configurations of Bind10, we show some
+ examples. They all assume they start with default configuration.
+
+ First, let's disable the static data source (“VERSION.BIND” and friends).
+ As it is the only data source in the CH class, we can remove the whole
+ class.
+
+ > config remove data_sources/classes CH
> config commit
- 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
+ Another one, let's say our default data source contains zones
+ “example.org.” and “example.net.”. We want them to be served from memory
+ to make the answering faster.
- The following commands to bindctl provide an example of configuring an
- in-memory data source containing the "example.org" zone with a SQLite3
- backend file named "example.org.sqlite3":
-
- > config add Auth/datasources
- > config set Auth/datasources[1]/type "memory"
- > config add Auth/datasources[1]/zones
- > config set Auth/datasources[1]/zones[0]/origin "example.org"
- > config set Auth/datasources[1]/zones[0]/file "example.org.sqlite3"
- > config set Auth/datasources[1]/zones[0]/filetype "sqlite3"
+ > config set data_sources/classes/IN[0]/cache-enable true
+ > config add data_sources/classes/IN[0]/cache-zones example.org.
+ > config add data_sources/classes/IN[0]/cache-zones example.net.
> config commit
- The authoritative server will begin serving it immediately after the zone
- data is loaded from the database file.
+ Now every time the zone in the data source is changed by the operator,
+ Bind10 needs to be told to reload it, by
+
+ > Auth loadzone example.org
- 8.2.3. Reloading an In-memory Data Source
+ You don't need to do this when the zone is modified by XfrIn, it does so
+ automatically.
- Use the Auth loadzone command in bindctl to reload a changed master file
- into memory; for example:
+ Now, the last example is when there are master files we want to serve in
+ addition to whatever is inside the sqlite3 database.
- > Auth loadzone origin="example.com"
+ > config add data_sources/classes/IN
+ > config set data_sources/classes/IN[1]/type MasterFiles
+ > config set data_sources/classes/IN[1]/cache-enable true
+ > config set data_sources/classes/IN[1]/params { "example.org": "/path/to/example.org", "example.com": "/path/to/example.com" }
+ > config commit
- 8.2.4. Disabling In-memory Data Sources
+ Initially, a map value has to be set, but this value may be an empty map.
+ After that, key/value pairs can be added with 'config add' and keys can be
+ removed with 'config remove'. The initial value may be an empty map, but
+ it has to be set before zones are added or removed.
- By default, the memory data source is disabled; it must be configured
- explicitly. To disable all the in-memory zones, specify a null list for
- Auth/datasources:
+ > config set data_sources/classes/IN[1]/params {}
+ > config add data_sources/classes/IN[1]/params another.example.org /path/to/another.example.org
+ > config add data_sources/classes/IN[1]/params another.example.com /path/to/another.example.com
+ > config remove data_sources/classes/IN[1]/params another.example.org
- > config set Auth/datasources/ []
- > config commit
- The following example stops serving a specific zone:
+ bindctl. To reload a zone, you the same command as above.
- > config remove Auth/datasources[0]/zones[0]
- > config commit
+ Note
- (Replace the list number(s) in datasources[0] and/or zones[0] for the
- relevant zone as needed.)
+ There's also Auth/database_file configuration variable, pointing to a
+ sqlite3 database file. This is no longer used by b10-auth, but it is left
+ in place for now, since other modules use it. Once b10-xfrin, b10-xfrout
+ and b10-ddns are ported to the new configuration, this will disappear. But
+ for now, make sure that if you use any of these modules, the new and old
+ configuration correspond. The defaults are consistent, so unless you
+ tweaked either the new or the old configuration, you're good.
-8.3. Loading Master Zones Files
+8.3. Loading Master Zones Files
RFC 1035 style DNS master zone files may imported into a BIND 10 SQLite3
data source by using the b10-loadzone utility.
If you reload a zone already existing in the database, all records from
that prior zone disappear and a whole new set appears.
-Chapter 9. Incoming Zone Transfers
+Chapter 9. Incoming Zone Transfers
Table of Contents
implementation limitations of the current development release, however, it
only tries AXFR by default, and care should be taken to enable IXFR.
-9.1. Configuration for Incoming Zone Transfers
+9.1. Configuration for Incoming Zone Transfers
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
(We assume there has been no zone configuration before).
-9.2. Enabling IXFR
+9.2. Enabling IXFR
As noted above, b10-xfrin uses AXFR for zone transfers by default. To
enable IXFR for zone transfers for a particular zone, set the use_ixfr
be implemented in a near future version, at which point we will enable
IXFR by default.
-9.3. Secondary Manager
+9.3. Secondary Manager
The b10-zonemgr process is started by bind10. It keeps track of SOA
refresh, retry, and expire timers and other details for BIND 10 to perform
for it), b10-zonemgr will automatically tell b10-xfrin to transfer the
zone in.
-9.4. Trigger an Incoming Zone Transfer Manually
+9.4. Trigger an Incoming Zone Transfer Manually
To manually trigger a zone transfer to retrieve a remote zone, you may use
the bindctl utility. For example, at the bindctl prompt run:
> Xfrin retransfer zone_name="foo.example.org" master=192.0.2.99
-9.5. Incoming Transfers with In-memory Datasource
+9.5. Incoming Transfers with In-memory Datasource
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
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, “Data Source Backends”.
-Chapter 10. Outbound Zone Transfers
+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
The way to specify zone specific configuration (ACLs, etc) is likely to be
changed.
-Chapter 11. Dynamic DNS Update
+Chapter 11. Dynamic DNS Update
Table of Contents
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.
+ addition, if b10-auth serves the updated zone (as described in
+ Section 8.2, “Data Source Backends”), b10-ddns will also notify b10-auth
+ so that b10-auth will re-cache the updated zone content if necessary.
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 "not implemented" response.
+ will immediately return a “not implemented” response.
Note
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
+11.1. Enabling Dynamic Update
First off, it must be made sure that a few components on which b10-ddns
depends are configured to run, which are b10-auth and b10-zonemgr. In
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
+11.2. Access Control
By default, b10-ddns rejects any update requests from any clients by
returning a REFUSED response. To allow updates to take effect, an access
The zone's origin name
class
- The RR class of the zone (normally "IN", and in that case can be
+ The RR class of the zone (normally “IN”, and in that case can be
omitted in configuration)
update_acl
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 default RR class "IN") from
+ 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[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}
> config commit
- The TSIG key must be configured system wide (see Chapter 10, Outbound Zone
+ The TSIG key must be configured system wide (see Chapter 10, Outbound Zone
Transfers.)
Multiple rules can be specified in the ACL, and an ACL rule can consist of
which is rejecting any requests in the case of b10-ddns.
Other actions than "ACCEPT", namely "REJECT" and "DROP", can be used, too.
- See Chapter 12, Recursive Name Server about their effects.
+ See Chapter 12, Recursive Name Server about their effects.
Currently update ACL can only control updates per zone basis; it's not
possible to specify access control with higher granularity such as for
clients. There have been other troubles that could have been avoided if
the ACL could be checked before the prerequisite check.
-11.3. Miscellaneous Operational Issues
+11.3. Miscellaneous Operational Issues
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
operation. In general, it's not advisable to allow DDNS for a signed zone
at this moment.
- Also unlike BIND 9, it's currently not possible to "freeze" a zone
+ Also unlike BIND 9, it's currently not possible to “freeze” a zone
temporarily in order to suspend DDNS while you manually update the zone.
If you need to make manual updates to a dynamic zone, you'll need to
temporarily reject any updates to the zone via the update ACLs.
Dynamic updates are only applicable to primary zones. In order to avoid
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
+ “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 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
+ “secondary_zones”, be careful not to allow DDNS for the zone; it would be
quite likely to lead to inconsistent state between different servers.
Normally this should not be a problem because the default update ACL
rejects any update requests, but you may want to take an extra care about
can be retrieved in the form of outbound IXFR. This is done automatically;
it does not require specific configuration to make this possible.
-Chapter 12. Recursive Name Server
+Chapter 12. Recursive Name Server
Table of Contents
> config set Resolver/listen_on[2]/port 53
> config commit
- (Replace the "2" as needed; run "config show Resolver/listen_on" if
+ (Replace the “2” as needed; run “config show Resolver/listen_on” if
needed.)
-12.1. Access Control
+12.1. Access Control
By default, the b10-resolver daemon only accepts DNS queries from the
localhost (127.0.0.1 and ::1). The Resolver/query_acl configuration may be
used to reject, drop, or allow specific IPs or networks. This
configuration list is first match.
- The configuration's action item may be set to "ACCEPT" to allow the
- incoming query, "REJECT" to respond with a DNS REFUSED return code, or
- "DROP" to ignore the query without any response (such as a blackhole). For
+ The configuration's action item may be set to “ACCEPT” to allow the
+ incoming query, “REJECT” to respond with a DNS REFUSED return code, or
+ “DROP” to ignore the query without any response (such as a blackhole). For
more information, see the respective debugging messages:
RESOLVER_QUERY_ACCEPTED, RESOLVER_QUERY_REJECTED, and
RESOLVER_QUERY_DROPPED.
The required configuration's from item is set to an IPv4 or IPv6 address,
addresses with an network mask, or to the special lowercase keywords
- "any6" (for any IPv6 address) or "any4" (for any IPv4 address).
+ “any6” (for any IPv6 address) or “any4” (for any IPv4 address).
For example to allow the 192.168.1.0/24 network to use your recursive name
server, at the bindctl prompt run:
> config set Resolver/query_acl[2]/from "192.168.1.0/24"
> config commit
- (Replace the "2" as needed; run "config show Resolver/query_acl" if
+ (Replace the “2” as needed; run “config show Resolver/query_acl” if
needed.)
Note
This prototype access control configuration syntax may be changed.
-12.2. Forwarding
+12.2. Forwarding
To enable forwarding, the upstream address and port must be configured to
forward queries to, such as:
> config set Resolver/forward_addresses []
> config commit
-Chapter 13. DHCPv4 Server
+Chapter 13. DHCPv4 Server
Table of Contents
clients. Even though principles of both DHCPv4 and DHCPv6 are somewhat
similar, these are two radically different protocols. BIND10 offers server
implementations for both DHCPv4 and DHCPv6. This chapter is about DHCP for
- IPv4. For a description of the DHCPv6 server, see Chapter 14, DHCPv6
+ IPv4. For a description of the DHCPv6 server, see Chapter 14, DHCPv6
Server.
The DHCPv4 server component is currently under intense development. You
developers mailing list.
The DHCPv4 and DHCPv6 components in BIND10 architecture are internally
- code named "Kea".
+ code named “Kea”.
Note
servers. That means that while they are capable of performing DHCP
configuration, they are not fully functional yet. In particular, neither
has functional lease databases. This means that they will assign the same,
- fixed, hardcoded addresses to any client that will ask. See Section 13.4,
- "DHCPv4 Server Limitations" and Section 14.4, "DHCPv6 Server Limitations"
+ fixed, hardcoded addresses to any client that will ask. See Section 13.4,
+ “DHCPv4 Server Limitations” and Section 14.4, “DHCPv6 Server Limitations”
for detailed description.
-13.1. DHCPv4 Server Usage
+13.1. DHCPv4 Server Usage
BIND10 provides the DHCPv4 server component since December 2011. It is a
skeleton server and can be described as an early prototype that is not
fully functional yet. It is mature enough to conduct first tests in lab
- environment, but it has significant limitations. See Section 13.4, "DHCPv4
- Server Limitations" for details.
+ environment, but it has significant limitations. See Section 13.4, “DHCPv4
+ Server Limitations” for details.
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
started directly, but rather via bind10. Please be aware of this planned
change.
-13.2. DHCPv4 Server Configuration
+13.2. DHCPv4 Server Configuration
The DHCPv4 server does not have a lease database implemented yet nor any
support for configuration, so every time the same set of configuration
Lease database and configuration support is planned for 2012.
-13.3. Supported standards
+13.3. Supported standards
The following standards and draft standards are currently supported:
- o RFC2131: Supported messages are DISCOVER, OFFER, REQUEST, and ACK.
- o RFC2132: Supported options are: PAD (0), END(255), Message Type(53),
+ o RFC2131: Supported messages are DISCOVER, OFFER, REQUEST, and ACK.
+ o RFC2132: Supported options are: PAD (0), END(255), Message Type(53),
DHCP Server Identifier (54), Domain Name (15), DNS Servers (6), IP
Address Lease Time (51), Subnet mask (1), and Routers (3).
-13.4. DHCPv4 Server Limitations
+13.4. DHCPv4 Server Limitations
These are the current limitations of the DHCPv4 server software. Most of
them are reflections of the early stage of development and should be
- treated as "not implemented yet", rather than actual limitations.
+ treated as “not implemented yet”, rather than actual limitations.
- o During initial IPv4 node configuration, the server is expected to send
+ o During initial IPv4 node configuration, the server is expected to send
packets to a node that does not have IPv4 address assigned yet. The
server requires certain tricks (or hacks) to transmit such packets.
This is not implemented yet, therefore DHCPv4 server supports relayed
traffic only (that is, normal point to point communication).
- o b10-dhcp4 provides a single, fixed, hardcoded lease to any client that
+ o b10-dhcp4 provides a single, fixed, hardcoded lease to any client that
asks. There is no lease manager implemented. If two clients request
addresses, they will both get the same fixed address.
- o b10-dhcp4 does not support any configuration mechanisms yet. The whole
+ o b10-dhcp4 does not support any configuration mechanisms yet. The whole
configuration is currently hardcoded. The only way to tweak
- 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
+ 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.
- o PRL (Parameter Request List, a list of options requested by a client)
+ 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.
- o b10-dhcp4 does not support BOOTP. That is a design choice. This
+ o b10-dhcp4 does not support BOOTP. That is a design choice. This
limitation is permanent. If you have legacy nodes that can't use DHCP
and require BOOTP support, please use latest version of ISC DHCP
http://www.isc.org/software/dhcp.
- o Interface detection is currently working on Linux only. See
- Section 15.1, "Interface detection" for details.
- o b10-dhcp4 does not verify that assigned address is unused. According
+ o Interface detection is currently working on Linux only. See
+ Section 15.1, “Interface detection” for details.
+ o b10-dhcp4 does not verify that assigned address is unused. According
to RFC2131, the allocating server should verify that address is no
used by sending ICMP echo request.
- o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
+ o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
duplication report (DECLINE) and release (RELEASE) are not supported
yet.
- o DNS Update is not supported yet.
- o -v (verbose) command line option is currently the default, and cannot
+ o DNS Update is not supported yet.
+ o -v (verbose) command line option is currently the default, and cannot
be disabled.
-Chapter 14. DHCPv6 Server
+Chapter 14. DHCPv6 Server
Table of Contents
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is specified in
RFC3315. BIND10 provides DHCPv6 server implementation that is described in
this chapter. For a description of the DHCPv4 server implementation, see
- Chapter 13, DHCPv4 Server.
+ Chapter 13, DHCPv4 Server.
The DHCPv6 server component is currently under intense development. You
may want to check out BIND10 DHCP (Kea) wiki and recent posts on BIND10
developers mailing list.
The DHCPv4 and DHCPv6 components in BIND10 architecture are internally
- code named "Kea".
+ code named “Kea”.
Note
servers. That means that while they are capable of performing DHCP
configuration, they are not fully functional yet. In particular, neither
has functional lease databases. This means that they will assign the same,
- fixed, hardcoded addresses to any client that will ask. See Section 13.4,
- "DHCPv4 Server Limitations" and Section 14.4, "DHCPv6 Server Limitations"
+ fixed, hardcoded addresses to any client that will ask. See Section 13.4,
+ “DHCPv4 Server Limitations” and Section 14.4, “DHCPv6 Server Limitations”
for detailed description.
-14.1. DHCPv6 Server Usage
+14.1. DHCPv6 Server Usage
BIND10 provides the DHCPv6 server component since September 2011. It is a
skeleton server and can be described as an early prototype that is not
fully functional yet. It is mature enough to conduct first tests in lab
- environment, but it has significant limitations. See Section 14.4, "DHCPv6
- Server Limitations" for details.
+ environment, but it has significant limitations. See Section 14.4, “DHCPv6
+ Server Limitations” for details.
The DHCPv6 server is implemented as b10-dhcp6 daemon. As it is not
configurable yet, it is fully autonomous, that is it does not interact
started directly, but rather via bind10. Please be aware of this planned
change.
-14.2. DHCPv6 Server Configuration
+14.2. DHCPv6 Server Configuration
The DHCPv6 server does not have lease database implemented yet or any
support for configuration, so every time the same set of configuration
Lease database and configuration support is planned for 2012.
-14.3. Supported DHCPv6 Standards
+14.3. Supported DHCPv6 Standards
The following standards and draft standards are currently supported:
- o RFC3315: Supported messages are SOLICIT, ADVERTISE, REQUEST, and
+ o RFC3315: Supported messages are SOLICIT, ADVERTISE, REQUEST, and
REPLY. Supported options are SERVER_ID, CLIENT_ID, IA_NA, and
IAADDRESS.
- o RFC3646: Supported option is DNS_SERVERS.
+ o RFC3646: Supported option is DNS_SERVERS.
-14.4. DHCPv6 Server Limitations
+14.4. DHCPv6 Server Limitations
These are the current limitations of the DHCPv6 server software. Most of
them are reflections of the early stage of development and should be
- treated as "not implemented yet", rather than actual limitations.
+ treated as “not implemented yet”, rather than actual limitations.
- o Relayed traffic is not supported.
- o b10-dhcp6 provides a single, fixed, hardcoded lease to any client that
+ o Relayed traffic is not supported.
+ o b10-dhcp6 provides a single, fixed, hardcoded lease to any client that
asks. There is no lease manager implemented. If two clients request
addresses, they will both get the same fixed address.
- o b10-dhcp6 does not support any configuration mechanisms yet. The whole
+ o b10-dhcp6 does not support any configuration mechanisms yet. The whole
configuration is currently hardcoded. The only way to tweak
- configuration is to directly modify source code. See see Section 14.2,
- "DHCPv6 Server Configuration" for details.
- o Upon start, the server will open sockets on all interfaces that are
+ configuration is to directly modify source code. See see Section 14.2,
+ “DHCPv6 Server Configuration” for details.
+ o Upon start, the server will open sockets on all interfaces that are
not loopback, are up, running and are multicast capable and have IPv6
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-dhcp6 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.
- o ORO (Option Request Option, a list of options requested by a client)
+ o ORO (Option Request Option, a list of options requested by a client)
is currently ignored and server assigns DNS SERVER option.
- o Temporary addresses are not supported yet.
- o Prefix delegation is not supported yet.
- o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
+ o Temporary addresses are not supported yet.
+ o Prefix delegation is not supported yet.
+ o Address renewal (RENEW), rebinding (REBIND), confirmation (CONFIRM),
duplication report (DECLINE) and release (RELEASE) are not supported
yet.
- o DNS Update is not supported yet.
- o Interface detection is currently working on Linux only. See
- Section 15.1, "Interface detection" for details.
- o -v (verbose) command line option is currently the default, and cannot
+ o DNS Update is not supported yet.
+ o Interface detection is currently working on Linux only. See
+ Section 15.1, “Interface detection” for details.
+ o -v (verbose) command line option is currently the default, and cannot
be disabled.
-Chapter 15. libdhcp++ library
+Chapter 15. libdhcp++ library
Table of Contents
is designed to be portable, universal library useful for any kind of
DHCP-related software.
-15.1. Interface detection
+15.1. Interface detection
Both DHCPv4 and DHCPv6 components share network interface detection
routines. Interface detection is currently only supported on Linux
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
+15.2. DHCPv4/DHCPv6 packet handling
TODO: Describe packet handling here, with pointers to wiki
-Chapter 16. Statistics
+Chapter 16. Statistics
The b10-stats process is started by bind10. It periodically collects
statistics data from various modules and aggregates it.
}
-Chapter 17. Logging
+Chapter 17. Logging
Table of Contents
17.2. Logging Message Format
-17.1. Logging configuration
+17.1. Logging configuration
The logging system in BIND 10 is configured through the Logging module.
All BIND 10 modules will look at the configuration in Logging to see what
should be logged and to where.
- 17.1.1. Loggers
+ 17.1.1. Loggers
Within BIND 10, a message is logged through a component called a "logger".
Different parts of BIND 10 log messages through different loggers, and
(the component that is generating the messages), the severity (what to
log), and the output_options (where to log).
- 17.1.1.1. name (string)
+ 17.1.1.1. name (string)
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, you add an entry for a logger named "Resolver".
+ for the resolver module, you add an entry for a logger named “Resolver”.
This configuration will then be used by the loggers in the Resolver
module, and all the libraries used by it.
If you want to specify logging for one specific library within the module,
you set the name to module.library. For example, the logger used by the
- nameserver address store component has the full name of "Resolver.nsas".
+ nameserver address store component has the full name of “Resolver.nsas”.
If there is no entry in Logging for a particular library, it will use the
configuration given for the module.
To illustrate this, suppose you want the cache library to log messages of
severity DEBUG, and the rest of the resolver code to log messages of
severity INFO. To achieve this you specify two loggers, one with the name
- "Resolver" and severity INFO, and one with the name "Resolver.cache" with
+ “Resolver” and severity INFO, and one with the name “Resolver.cache” with
severity DEBUG. As there are no entries for other libraries (e.g. the
- nsas), they will use the configuration for the module ("Resolver"), so
+ nsas), they will use the configuration for the module (“Resolver”), so
giving the desired behavior.
- One special case is that of a module name of "*" (asterisks), which is
+ One special case is that of a module name of “*” (asterisks), which is
interpreted as any module. You can set global logging options by using
this, including setting the logging configuration for a library that is
- used by multiple modules (e.g. "*.config" specifies the configuration
+ used by multiple modules (e.g. “*.config” specifies the configuration
library code in whatever module is using it).
If there are multiple logger specifications in the configuration that
might match a particular logger, the specification with the more specific
logger name takes precedence. For example, if there are entries for for
- both "*" and "Resolver", the resolver module -- and all libraries it uses
- -- will log messages according to the configuration in the second entry
- ("Resolver"). All other modules will use the configuration of the first
- entry ("*"). If there was also a configuration entry for "Resolver.cache",
+ both “*” and “Resolver”, the resolver module — and all libraries it uses —
+ will log messages according to the configuration in the second entry
+ (“Resolver”). All other modules will use the configuration of the first
+ entry (“*”). If there was also a configuration entry for “Resolver.cache”,
the cache library within the resolver would use that in preference to the
- entry for "Resolver".
+ entry for “Resolver”.
One final note about the naming. When specifying the module name within a
logger, use the name of the module as specified in bindctl, e.g.
- "Resolver" for the resolver module, "Xfrout" for the xfrout module, etc.
+ “Resolver” for the resolver module, “Xfrout” for the xfrout module, etc.
When the message is logged, the message will include the name of the
logger generating the message, but with the module name replaced by the
name of the process implementing the module (so for example, a message
- generated by the "Auth.cache" logger will appear in the output with a
- logger name of "b10-auth.cache").
+ generated by the “Auth.cache” logger will appear in the output with a
+ logger name of “b10-auth.cache”).
- 17.1.1.2. severity (string)
+ 17.1.1.2. severity (string)
This specifies the category of messages logged. Each message is logged
with an associated severity which may be one of the following (in
descending order of severity):
- o FATAL
- o ERROR
- o WARN
- o INFO
- o DEBUG
+ o FATAL
+ o ERROR
+ o WARN
+ o INFO
+ o DEBUG
When the severity of a logger is set to one of these values, it will only
log messages of that severity, and the severities above it. The severity
may also be set to NONE, in which case all messages from that logger are
inhibited.
- 17.1.1.3. output_options (list)
+ 17.1.1.3. output_options (list)
Each logger can have zero or more output_options. These specify where log
messages are sent to. These are explained in detail below.
The other options for a logger are:
- 17.1.1.4. debuglevel (integer)
+ 17.1.1.4. debuglevel (integer)
When a logger's severity is set to DEBUG, this value specifies what debug
messages should be printed. It ranges from 0 (least verbose) to 99 (most
If severity for the logger is not DEBUG, this value is ignored.
- 17.1.1.5. additive (true or false)
+ 17.1.1.5. additive (true or false)
If this is true, the output_options from the parent will be used. For
- example, if there are two loggers configured; "Resolver" and
- "Resolver.cache", and additive is true in the second, it will write the
- log messages not only to the destinations specified for "Resolver.cache",
+ example, if there are two loggers configured; “Resolver” and
+ “Resolver.cache”, and additive is true in the second, it will write the
+ log messages not only to the destinations specified for “Resolver.cache”,
but also to the destinations as specified in the output_options in the
- logger named "Resolver".
+ logger named “Resolver”.
- 17.1.2. Output Options
+ 17.1.2. Output Options
The main settings for an output option are the destination and a value
called output, the meaning of which depends on the destination that is
set.
- 17.1.2.1. destination (string)
+ 17.1.2.1. destination (string)
The destination is the type of output. It can be one of:
- o console
- o file
- o syslog
+ o console
+ o file
+ o syslog
- 17.1.2.2. output (string)
+ 17.1.2.2. output (string)
Depending on what is set as the output destination, this value is
interpreted as follows:
- destination is "console"
+ destination is “console”
- The value of output must be one of "stdout" (messages printed to
- standard output) or "stderr" (messages printed to standard error).
+ The value of output must be one of “stdout” (messages printed to
+ standard output) or “stderr” (messages printed to standard error).
- Note: if output is set to "stderr" and a lot of messages are
+ Note: if output is set to “stderr” and a lot of messages are
produced in a short time (e.g. if the logging level is set to
DEBUG), you may occasionally see some messages jumbled up
together. This is due to a combination of the way that messages
are written to the screen and the unbuffered nature of the
standard error stream. If this occurs, it is recommended that
- output be set to "stdout".
+ output be set to “stdout”.
- destination is "file"
+ destination is “file”
The value of output is interpreted as a file name; log messages
will be appended to this file.
- destination is "syslog"
+ destination is “syslog”
The value of output is interpreted as the syslog facility (e.g.
local0) that should be used for log messages.
The other options for output_options are:
- 17.1.2.2.1. flush (true of false)
+ 17.1.2.2.1. flush (true of false)
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.
- 17.1.2.2.2. maxsize (integer)
+ 17.1.2.2.2. maxsize (integer)
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. (For example, a ".1" is appended to the
- name -- if a ".1" file exists, it is renamed ".2", etc.)
+ name — if a ".1" file exists, it is renamed ".2", etc.)
If this is 0, no maximum file size is used.
- 17.1.2.2.3. maxver (integer)
+ 17.1.2.2.3. maxver (integer)
Maximum number of old log files to keep around when rolling the output
- file. Only relevant when destination is "file".
+ file. Only relevant when destination is “file”.
- 17.1.3. Example session
+ 17.1.3. Example session
In this example we want to set the global logging to write to the file
/var/log/my_bind10.log, at severity WARN. We want the authoritative server
> config remove Logging/loggers[1]
> config commit
- And every module will now be using the values from the logger named "*".
+ And every module will now be using the values from the logger named “*”.
-17.2. Logging Message Format
+17.2. Logging Message Format
Each message written by BIND 10 to the configured logging destinations
comprises a number of components that identify the origin of the message
projects / thirdparty / kea.git / commitdiff
