Commit 4724623b authored by Jeremy C. Reed's avatar Jeremy C. Reed
Browse files

[master] regen guide

parent 36601beb
This diff is collapsed.
......@@ -221,18 +221,22 @@ Chapter 1. Introduction
processes as needed. The processes started by the bind10 command have
names starting with "b10-", including:
o b10-msgq -- Message bus daemon. This process coordinates communication
between all of the other BIND 10 processes.
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-msgq -- Message bus daemon. This process coordinates communication
between all of the other BIND 10 processes.
o b10-resolver -- Recursive name server. This process handles incoming
queries.
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
reports statistics data.
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
transfer a new copy of a zone into BIND 10, when acting as a secondary
server.
......@@ -249,8 +253,9 @@ Chapter 1. Introduction
Once BIND 10 is running, a few commands are used to interact directly with
the system:
o bindctl -- interactive administration interface. This is a
command-line tool which allows an administrator to control BIND 10.
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
masterfile-format zone files into BIND 10.
o b10-cmdctl-usermgr -- user access control. This tool allows an
......@@ -491,10 +496,11 @@ Chapter 3. Starting BIND10 with bind10
b10-sockcreator will allocate sockets for the rest of the system.
In its default configuration, the bind10 master process will also start up
b10-cmdctl for admins to communicate with the system, b10-auth for
authoritative DNS service, b10-stats for statistics collection, b10-xfrin
for inbound DNS zone transfers, b10-xfrout for outbound DNS zone
transfers, and b10-zonemgr for secondary service.
b10-cmdctl for administration tools to communicate with the system,
b10-auth for authoritative DNS service, b10-stats for statistics
collection, b10-stats-httpd for statistics reporting, b10-xfrin for
inbound DNS zone transfers, b10-xfrout for outbound DNS zone transfers,
and b10-zonemgr for secondary service.
3.1. Starting BIND 10
......@@ -600,6 +606,22 @@ Chapter 3. Starting BIND10 with bind10
In short, you should think twice before disabling something here.
It is possible to start some components multiple times (currently b10-auth
and b10-resolzer). You might want to do that to gain more performance
(each one uses only single core). Just put multiple entries under
different names, like this, with the same config:
> config add Boss/components b10-resolver-2
> config set Boss/components/b10-resolver-2/special resolver
> config set Boss/components/b10-resolver-2/kind needed
> config commit
However, this is work in progress and the support is not yet complete. For
example, each resolver will have its own cache, each authoritative server
will keep its own copy of in-memory data and there could be problems with
locking the sqlite database, if used. The configuration might be changed
to something more convenient in future.
Chapter 4. Command channel
The BIND 10 components use the b10-msgq message routing daemon to
......@@ -939,26 +961,22 @@ Chapter 10. Outbound Zone Transfers
In the above example the lines for transfer_acl were divided for
readability. In the actual input it must be in a single line.
If you want to require TSIG in access control, a separate TSIG "key ring"
must be configured specifically for b10-xfrout as well as a system wide
key ring, both containing a consistent set of keys. For example, to change
the previous example to allowing requests from 192.0.2.1 signed by a TSIG
with a key name of "key.example", you'll need to do this:
If you want to require TSIG in access control, a system wide TSIG "key
ring" must be configured. For example, to change the previous example to
allowing requests from 192.0.2.1 signed by a TSIG with a key name of
"key.example", you'll need to do this:
> config set tsig_keys/keys ["key.example:<base64-key>"]
> config set Xfrout/tsig_keys/keys ["key.example:<base64-key>"]
> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]
> config commit
The first line of configuration defines a system wide key ring. This is
necessary because the b10-auth server also checks TSIGs and it uses the
system wide configuration.
Both Xfrout and Auth will use the system wide keyring to check TSIGs in
the incomming messages and to sign responses.
Note
In a future version, b10-xfrout will also use the system wide TSIG
configuration. The way to specify zone specific configuration (ACLs, etc)
is likely to be changed, too.
The way to specify zone specific configuration (ACLs, etc) is likely to be
changed.
Chapter 11. Recursive Name Server
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment