bind10-guide.xml 44.2 KB
Newer Older
1
2
3
4
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY mdash  "&#x2014;" >
5
6
<!ENTITY % version SYSTEM "version.ent">
%version;
7
8
]>
<book>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
9
  <?xml-stylesheet href="bind10-guide.css" type="text/css"?>
10

11
  <bookinfo>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
12
    <title>BIND 10 Guide</title>
13
14
15
16
17
18
    <subtitle>Administrator Reference for BIND 10</subtitle>

    <copyright>
      <year>2010</year><holder>Internet Systems Consortium, Inc.</holder>
    </copyright>

19
    <abstract>
20
21
22
23
      <para>BIND 10 is a Domain Name System (DNS) suite managed by
	Internet Systems Consortium (ISC). It includes DNS libraries
	and modular components for controlling authoritative and
	recursive DNS servers.
24
      </para>
25
26
27
28
29
30
31
32
33
      <para>
        This is the reference guide for BIND 10 version &__VERSION__;.
	The most up-to-date version of this document, along with
	other documents for BIND 10, can be found at <ulink
	url="http://bind10.isc.org/docs"/>.  </para> </abstract>

      <releaseinfo>This is the reference guide for BIND 10 version
        &__VERSION__;.</releaseinfo>

34
35
36
37
38
39
40
  </bookinfo>

  <chapter id="intro">
    <title>Introduction</title>
    <para>
      BIND is the popular implementation of a DNS server, developer
      interfaces, and DNS tools.
41
42
      BIND 10 is a rewrite of BIND 9.  BIND 10 is written in C++ and Python
      and provides a modular environment for serving and maintaining DNS.
43
44
    </para>

45
46
    <note>
      <para>
47
48
        This guide covers the experimental prototype of
        BIND 10 version &__VERSION__;.
49
50
      </para>
    </note>
51

52
53
    <note>
      <para>
54
        BIND 10 provides a EDNS0- and DNSSEC-capable
55
56
        authoritative DNS server and a caching recursive name server
        which also provides forwarding.
57
58
      </para>
    </note>
59

60
    <section>
61
62
      <title>Supported Platforms</title>
      <para>
63
  BIND 10 builds have been tested on Debian GNU/Linux 5,
64
  Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, and CentOS
65
  Linux 5.3.
66

67
68
  It has been tested on Sparc, i386, and amd64 hardware
  platforms.
69
70
71
72
73
74
75
76
77
78

        It is planned for BIND 10 to build, install and run on
        Windows and standard Unix-type platforms.
      </para>
    </section>

    <section>
      <title>Required Software</title>
      <para>
        BIND 10 requires Python 3.1.  Later versions may work, but Python
79
        3.1 is the minimum version which will work.
80
81
82
      </para>

      <note><para>
83
	The authoritative server requires SQLite 3.3.9 or newer.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
84
85
86
	The <command>b10-xfrin</command>, <command>b10-xfrout</command>,
	and <command>b10-zonemgr</command> modules require the
	libpython3 library and the Python _sqlite3.so module.
87
88
89
90
91
92
      </para></note>
<!-- TODO: this will change ... -->

<!-- TODO: list where to get these from -->

      <note>
93
94
95
96
97
98
99
        <para>
          Some operating systems do not provide these dependencies
          in their default installation nor standard packages
          collections.
          You may need to install them separately.
        </para>
      </note>
100
    </section>
101

102
103
    <section id="starting_stopping">
      <title>Starting and Stopping the Server</title>
104

105
106
107
      <para>
        BIND 10 is modular.  Part of this modularity is
        accomplished using multiple cooperating processes which, together,
108
109
110
	provide the server functionality.  This is a change from
	the previous generation of BIND software, which used a
	single process.
111
112
113
      </para>

      <para>
114
115
116
117
118
119
120
	At first, running many different processes may seem confusing.
	However, these processes are started, stopped, and maintained
	by a single command, <command>bind10</command>.
	This command starts a master process which will start other
	processes as needed.
	The processes started by the <command>bind10</command>
	command have names starting with "b10-", including:
121
      </para>
122
123
      
      <para>
124

125
        <itemizedlist>
126

127
128
          <listitem>
            <simpara>
129
              <command>b10-msgq</command> &mdash;
130
              Message bus daemon.
131
132
              This process coordinates communication between all of the other
              BIND 10 processes.
133
134
            </simpara>
          </listitem>
135

136
137
138
          <listitem>
            <simpara>
              <command>b10-auth</command> &mdash;
139
              Authoritative DNS server.
140
              This process serves DNS requests.
141
142
            </simpara>
          </listitem>
143

144
145
146
          <listitem>
            <simpara>
              <command>b10-cfgmgr</command> &mdash;
147
              Configuration manager.
148
              This process maintains all of the configuration for BIND 10.
149
150
            </simpara>
          </listitem>
151

152
153
154
          <listitem>
            <simpara>
              <command>b10-cmdctl</command> &mdash;
155
              Command and control service.
156
              This process allows external control of the BIND 10 system.
157
158
            </simpara>
          </listitem>
159

160
161
162
163
164
165
166
167
168
          <listitem>
            <simpara>
              <command>b10-resolver</command> &mdash;
              Recursive name server.
              This process handles incoming queries.
<!-- TODO: -->
            </simpara>
          </listitem>

169
170
171
172
173
174
175
176
          <listitem>
            <simpara>
              <command>b10-stats</command> &mdash;
              Statistics collection daemon.
              This process collects and reports statistics data.
            </simpara>
          </listitem>

177
178
179
          <listitem>
            <simpara>
              <command>b10-xfrin</command> &mdash;
180
              Incoming zone transfer service.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
181
              This process is used to transfer a new copy
182
              of a zone into BIND 10, when acting as a secondary server.
183
184
            </simpara>
          </listitem>
185

Jeremy C. Reed's avatar
Jeremy C. Reed committed
186
187
188
189
190
191
192
193
194
195
          <listitem>
            <simpara>
              <command>b10-xfrout</command> &mdash;
              Outgoing zone transfer service.
	      This process is used to handle transfer requests to
	      send a local zone to a remote secondary server,
	      when acting as a master server.
            </simpara>
          </listitem>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
196
197
198
199
200
201
202
203
204
          <listitem>
            <simpara>
              <command>b10-zonemgr</command> &mdash;
              Secondary manager.
	      This process keeps track of timers and other
              necessary information for BIND 10 to act as a slave server.
            </simpara>
          </listitem>

205
206
        </itemizedlist>
      </para>
207
208
209
210
211
212

      <para>
	These are ran automatically by <command>bind10</command>
	and do not need to be run manually.
      </para>

213
    </section>
214

215
216
217
218
    <section id="managing_once_running">
      <title>Managing BIND 10</title>
      
      <para>
219
220
	Once BIND 10 is running, a few commands are used to interact
	directly with the system:
221
222
223
224
        <itemizedlist>
          <listitem>
            <simpara>
              <command>bindctl</command> &mdash;
225
226
227
              interactive administration interface.
              This is a command-line tool which allows an administrator
              to control BIND 10.
228
229
230
231
232
            </simpara>
          </listitem>
          <listitem>
            <simpara>
              <command>b10-loadzone</command> &mdash;
233
234
235
              zone file loader.
              This tool will load standard masterfile-format zone files into
              BIND 10.
236
237
            </simpara>
          </listitem>
238
239
240
241
242
          <listitem>
            <simpara>
              <command>b10-cmdctl-usermgr</command> &mdash;
              user access control.
              This tool allows an administrator to authorize additional users
243
              to manage BIND 10.
244
245
            </simpara>
          </listitem>
246
247
248
249
  <!-- TODO usermgr -->
        </itemizedlist>
      </para>
    </section>
250
251

    <para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
252
      The tools and modules are covered in full detail in this guide.
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
<!-- TODO point to these -->
      In addition, manual pages are also provided in the default installation.
    </para>
      
<!--
bin/
  bindctl*
  host*
lib/
  libauth
  libdns
  libexceptions
  python3.1/site-packages/isc/{cc,config}
sbin/
  bind10
share/
269
  share/bind10/
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
    auth.spec
    b10-cmdctl.pem
    bob.spec
    passwd.csv
  man/
var/
  bind10/b10-config.db
-->

    <para>
      BIND 10 also provides libraries and programmer interfaces
      for C++ and Python for the message bus, configuration backend,
      and, of course, DNS. These include detailed developer
      documentation and code examples.
<!-- TODO point to this -->
    </para>

  </chapter>

289
290
  <chapter id="installation">
    <title>Installation</title>
291

292
293
    <section>
      <title>Building Requirements</title>
294
        <note>
295
          <simpara>
296
297
298
            Some operating systems have split their distribution packages into
            a run-time and a development package.  You will need to install
            the development package versions, which include header files and
Michael Graff's avatar
Michael Graff committed
299
            libraries, to build BIND 10 from source code.
300
          </simpara>
301
302
        </note>

303
304
        <para>
          Building from source code requires the Boost
305
          build-time headers. At least Boost version 1.35 is required.
306
307
308
309
  <!-- TODO: we don't check for this version -->
  <!-- NOTE: jreed has tested with 1.34, 1.38, and 1.41. -->
        </para>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
310
        <para>
311
312
	  The Python Library and Python _sqlite3 module are required to
          enable the Xfrout and Xfrin support.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
313
314
315
316
317
318
319
        </para>

        <note><simpara>
          The Python related libraries and modules need to be built
          for Python 3.1.
        </simpara></note>

320
321
        <para>
          Building BIND 10 also requires a C++ compiler and
322
          standard development headers, make, and pkg-config.
323
          BIND 10 builds have been tested with GCC g++ 3.4.3, 4.1.2,
Jeremy C. Reed's avatar
Jeremy C. Reed committed
324
          4.1.3, 4.2.1, 4.3.2, and 4.4.1.
325
326
327
        </para>
    </section>

328
329
    <section id="quickstart">
      <title>Quick start</title>
330
331
332
333
334
      <note>
        <simpara>
          This quickly covers the standard steps for installing
          and deploying BIND 10 as an authoritative name server using
          its defaults. For troubleshooting, full customizations and further
Jeremy C. Reed's avatar
Jeremy C. Reed committed
335
          details, see the respective chapters in the BIND 10 guide.
336
337
        </simpara>
      </note>
338

339
340
      <note>
        <simpara>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
341
          The development prototype of the b10-auth server listens on
342
343
344
345
          0.0.0.0 (all interfaces) port 5300. (This is not the standard
          domain service port.)
        </simpara>
      </note>
346

347
348
349
350
351
      <para>
        To quickly get started with BIND 10, follow these steps.
      </para>

      <orderedlist>
352
353
    
        <listitem>
354
355
356
          <simpara>
            Install required build dependencies.
          </simpara>
357
        </listitem>
358

359
        <listitem>
360
361
362
          <simpara>
            Download the BIND 10 source tar file from
            <ulink url="ftp://ftp.isc.org/isc/bind10/"/>.
363
364
          </simpara>
        </listitem>
365

366
367
368
369
370
        <listitem>
          <para>Extract the tar file:
          <screen>$ <userinput>gzcat bind10-<replaceable>VERSION</replaceable>.tar.gz | tar -xvf -</userinput></screen>
          </para>
        </listitem>
371

372
373
374
375
376
377
        <listitem>
          <para>Go into the source and run configure:
            <screen>$ <userinput>cd bind10-<replaceable>VERSION</replaceable></userinput>
  $ <userinput>./configure</userinput></screen>
          </para>
        </listitem>
378

379
380
381
382
383
        <listitem>
          <para>Build it:
            <screen>$ <userinput>make</userinput></screen>
          </para>
        </listitem>
384

385
386
387
388
389
        <listitem>
          <para>Install it (to default /usr/local):
            <screen>$ <userinput>make install</userinput></screen>
          </para>
        </listitem>
390

391
392
393
394
395
        <listitem>
          <para>Start the server:
            <screen>$ <userinput>/usr/local/sbin/bind10</userinput></screen>
          </para>
        </listitem>
396

397
        <listitem>
398

399
400
401
402
403
404
405
406
407
408
409
410
         <para>Test it; for example:
            <screen>$ <userinput>dig @127.0.0.1 -p 5300 -c CH -t TXT authors.bind</userinput></screen>
         </para>
        </listitem>

        <listitem>
          <para>Load desired zone file(s), for example:
            <screen>$ <userinput>b10-loadzone <replaceable>your.zone.example.org</replaceable></userinput></screen>
          </para>
        </listitem>

        <listitem>
411
412
          <simpara>
            Test the new zone.
413
414
          </simpara>
        </listitem>
415

416
      </orderedlist>
417
418
419
420
421

    </section>

    <section id="install">
      <title>Installation from source</title>
422
      <para>
423
424
        BIND 10 is open source software written in C++ and Python.
        It is freely available in source code form from ISC via
425
        the Git code revision control system or as a downloadable
426
427
        tar file. It may also be available in pre-compiled ready-to-use
        packages from operating system vendors.
428
429
      </para>

430
431
      <section>
        <title>Download Tar File</title>
432
433
434
435
436
437
438
        <para>
          Downloading a release tar file is the recommended method to
          obtain the source code.
        </para>
        
        <para>
          The BIND 10 releases are available as tar file downloads from
439
440
          <ulink url="ftp://ftp.isc.org/isc/bind10/"/>.
          Periodic development snapshots may also be available.
441
442
443
444
445
        </para>
  <!-- TODO -->
      </section>

      <section>
446
        <title>Retrieve from Git</title>
447
448
449
450
451
        <para>
          Downloading this "bleeding edge" code is recommended only for
          developers or advanced users.  Using development code in a production
          environment is not recommended.
        </para>
452
453
454

        <note>
          <para>
455
            When using source code retrieved via Git additional
456
            software will be required:  automake (v1.11 or newer),
457
            libtoolize, and autoconf (2.59 or newer).
458
459
460
461
            These may need to be installed.
          </para>
        </note>

462
463
464
        <para>
          The latest development code, including temporary experiments
          and un-reviewed code, is available via the BIND 10 code revision
465
          control system. This is powered by Git and all the BIND 10
466
          development is public.
467
          The leading development is done in the <quote>master</quote>.
468
469
        </para>
        <para>
470
471
472
          The code can be checked out from
          <filename>git://bind10.isc.org/bind10</filename>;
          for example:
473

474
        <screen>$ <userinput>git clone git://bind10.isc.org/bind10</userinput></screen>
475
        </para>
476

477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
        <para>
          When checking out the code from
          the code version control system, it doesn't include the
          generated configure script, Makefile.in files, nor the
          related configure files.
          They can be created by running <command>autoreconf</command>
          with the <option>--install</option> switch.
          This will run <command>autoconf</command>,
          <command>aclocal</command>,
          <command>libtoolize</command>,
          <command>autoheader</command>,
          <command>automake</command>,
          and related commands.
        </para>

492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
      </section>


      <section>
        <title>Configure before the build</title>
        <para>
          BIND 10 uses the GNU Build System to discover build environment
          details.
          To generate the makefiles using the defaults, simply run:
          <screen>$ <userinput>./configure</userinput></screen>
        </para>
        <para>
          Run <command>./configure</command> with the <option>--help</option>
          switch to view the different options. The commonly-used options are:

          <variablelist>

          <varlistentry>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
510
511
512
513
514
515
516
517
518
519
            <term>--prefix</term>
            <listitem>
              <simpara>Define the the installation location (the
                default is <filename>/usr/local/</filename>).
              </simpara>
            </listitem> 
          </varlistentry>

          <varlistentry>
            <term>--with-boost-include</term>
520
            <listitem> 
Jeremy C. Reed's avatar
Jeremy C. Reed committed
521
              <simpara>Define the path to find the Boost headers.
522
523
524
525
526
              </simpara>
            </listitem> 
          </varlistentry>

          <varlistentry>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
527
528
529
530
531
532
533
534
535
536
537
538
539
540
            <term>--with-pythonpath</term>
            <listitem> 
              <simpara>Define the path to Python 3.1 if it is not in the
                standard execution path.
              </simpara>
            </listitem> 
          </varlistentry>

          <varlistentry>
            <term>--with-gtest</term>
            <listitem> 
              <simpara>Enable building the C++ Unit Tests using the
                Google Tests framework. Optionally this can define the
                path to the gtest header files and library.
541
542
543
544
545
546
547
              </simpara>
            </listitem> 
          </varlistentry>

          </variablelist>

        </para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
548
  <!-- TODO: lcov -->
549
550

        <para>
551
          For example, the following configures it to
552
    find the Boost headers, find the
553
    Python interpreter, and sets the installation location:
554

555
          <screen>$ <userinput>./configure \
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
      --with-boost-include=/usr/pkg/include \
      --with-pythonpath=/usr/pkg/bin/python3.1 \
      --prefix=/opt/bind10</userinput></screen>
        </para>

        <para>
          If the configure fails, it may be due to missing or old
          dependencies.
        </para>

      </section>

      <section>
        <title>Build</title>
        <para>
571
572
    After the configure step is complete, to build the executables
    from the C++ code and prepare the Python scripts, run:
573
574
575
576
577
578
579
580

          <screen>$ <userinput>make</userinput></screen>
        </para>
      </section>

      <section>
        <title>Install</title>
        <para>
Michael Graff's avatar
Michael Graff committed
581
582
          To install the BIND 10 executables, support files,
          and documentation, run:
583
584
          <screen>$ <userinput>make install</userinput></screen>
        </para>
Michael Graff's avatar
Michael Graff committed
585
        <note>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
586
          <para>The install step may require superuser privileges.</para>
Michael Graff's avatar
Michael Graff committed
587
        </note>
588
589
590
591
592
593
594
595
596

      </section>

  <!-- TODO: tests -->

      <section>
        <title>Install Hierarchy</title>
        <para>
          The following is the layout of the complete BIND 10 installation:
597
598
599
600
601
602
603
604
605
          <itemizedlist>
            <listitem>
              <simpara>
                <filename>bin/</filename> &mdash;
                general tools and diagnostic clients.
              </simpara>
            </listitem>
            <listitem>
            <simpara>
606
              <filename>etc/bind10-devel/</filename> &mdash;
607
608
609
610
611
612
613
614
615
616
617
              configuration files.
            </simpara>
            </listitem>
            <listitem>
              <simpara>
                <filename>lib/</filename> &mdash;
                libraries and python modules.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
618
                <filename>libexec/bind10-devel/</filename> &mdash;
619
620
621
622
623
624
625
626
627
628
629
630
631
632
                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 <command>bind10</command> tool.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
                <filename>sbin/</filename> &mdash;
                commands used by the system administrator.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
633
                <filename>share/bind10-devel/</filename> &mdash;
634
635
636
637
638
639
640
641
642
643
644
                configuration specifications.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
                <filename>share/man/</filename> &mdash;
                manual pages (online documentation).
              </simpara>
            </listitem>
            <listitem>
              <simpara>
645
                <filename>var/bind10-devel/</filename> &mdash;
646
647
648
649
650
                data source and configuration databases.
              </simpara>
            </listitem>
          </itemizedlist>
        </para>
651
652
653
654
655
656
657
658
659
660
      </section>
    </section>

  <!--
      <section id="install.troubleshooting">
        <title>Troubleshooting</title>
        <para>
        </para>
      </section>
  -->
661
662
  
  </chapter>
663

664
  <chapter id="bind10">
Michael Graff's avatar
Michael Graff committed
665
    <title>Starting BIND10 with <command>bind10</command></title>
666
667
    <para>
      BIND 10 provides the <command>bind10</command> command which 
Michael Graff's avatar
Michael Graff committed
668
669
670
671
      starts up the required processes.
      <command>bind10</command>
      will also restart processes that exit unexpectedly.
      This is the only command needed to start the BIND 10 system.
672
673
674
    </para>

    <para>
675
      After starting the <command>b10-msgq</command> communications channel,
676
677
678
      <command>bind10</command> connects to it, 
      runs the configuration manager, and reads its own configuration.
      Then it starts the other modules.
679
680
681
    </para>

    <para>
682
683
      The <command>b10-msgq</command> and <command>b10-cfgmgr</command>
      services make up the core. The <command>b10-msgq</command> daemon
684
      provides the communication channel between every part of the system.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
685
      The <command>b10-cfgmgr</command> daemon is always needed by every
686
687
688
      module, if only to send information about themselves somewhere,
      but more importantly to ask about their own settings, and
      about other modules.
689
      The <command>bind10</command> master process will also start up
Jeremy C. Reed's avatar
Jeremy C. Reed committed
690
      <command>b10-cmdctl</command> for admins to communicate with the
691
692
      system, <command>b10-auth</command> for authoritative DNS service or
      <command>b10-resolver</command> for recursive name service,
693
      <command>b10-stats</command> for statistics collection,
694
695
      <command>b10-xfrin</command> for inbound DNS zone transfers,
      <command>b10-xfrout</command> for outbound DNS zone transfers,
Jeremy C. Reed's avatar
Jeremy C. Reed committed
696
      and <command>b10-zonemgr</command> for secondary service.
697
698
    </para>

699
    <section id="start">
700
701
702
      <title>Starting BIND 10</title>
      <para>
        To start the BIND 10 service, simply run <command>bind10</command>.
703
        Run it with the <option>--verbose</option> switch to
704
705
706
        get additional debugging or diagnostic output.
      </para>
<!-- TODO: note it doesn't go into background -->
707
    </section>
708
709
710

  </chapter>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
711
712
713
714
  <chapter id="msgq">
    <title>Command channel</title>

      <para>
715
        The BIND 10 components use the <command>b10-msgq</command>
Michael Graff's avatar
Michael Graff committed
716
        message routing daemon to communicate with other BIND 10 components.
717
        The <command>b10-msgq</command> implements what is called the
Michael Graff's avatar
Michael Graff committed
718
719
720
721
722
        <quote>Command Channel</quote>.
        Processes intercommunicate by sending messages on the command
        channel.
        Example messages include shutdown, get configurations, and set
        configurations.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
723
        This Command Channel is not used for DNS message passing.
Michael Graff's avatar
Michael Graff committed
724
725
        It is used only to control and monitor the BIND 10 system.
      </para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
726
727
728

      <para>
        Administrators do not communicate directly with the
729
        <command>b10-msgq</command> daemon.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
730
        By default, BIND 10 uses port 9912 for the
731
        <command>b10-msgq</command> service.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
732
733
        It listens on 127.0.0.1.
      </para>
Michael Graff's avatar
Michael Graff committed
734
      
Jeremy C. Reed's avatar
Jeremy C. Reed committed
735
<!-- TODO: this is broken, see Trac #111
Michael Graff's avatar
Michael Graff committed
736
      <para>
737
        To select an alternate port for the <command>b10-msgq</command> to
Michael Graff's avatar
Michael Graff committed
738
        use, run <command>bind10</command> specifying the option:
Jeremy C. Reed's avatar
Jeremy C. Reed committed
739
        <screen> $ <userinput>bind10 -TODO-msgq-port 9912</userinput></screen>
Michael Graff's avatar
Michael Graff committed
740
      </para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
741
-->
Jeremy C. Reed's avatar
Jeremy C. Reed committed
742
743
744
745
746
747
748

<!-- TODO: upcoming plans:
Unix domain sockets
-->

  </chapter>

749
750
751
752
  <chapter id="cfgmgr">
    <title>Configuration manager</title>

      <para>
Michael Graff's avatar
Michael Graff committed
753
754
755
756
757
         The configuration manager, <command>b10-cfgmgr</command>,
         handles all BIND 10 system configuration.  It provides
         persistent storage for configuration, and notifies running
         modules of configuration changes.
      </para>
758
759

      <para>
Michael Graff's avatar
Michael Graff committed
760
761
        The <command>b10-auth</command> and <command>b10-xfrin</command>
        daemons and other components receive their configurations
762
        from the configuration manager over the <command>b10-msgq</command>
Michael Graff's avatar
Michael Graff committed
763
        command channel.
764
765
      </para>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
766
767
768
769
      <para>The administrator doesn't connect to it directly, but
        uses a user interface to communicate with the configuration
        manager via <command>b10-cmdctl</command>'s REST-ful interface.
        <command>b10-cmdctl</command> is covered in <xref linkend="cmdctl"/>.
770
771
772
      </para>

<!-- TODO -->
Michael Graff's avatar
Michael Graff committed
773
774
      <note>
        <para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
775
          The development prototype release only provides the
Michael Graff's avatar
Michael Graff committed
776
777
778
779
780
781
          <command>bindctl</command> as a user interface to
          <command>b10-cmdctl</command>.
          Upcoming releases will provide another interactive command-line
          interface and a web-based interface.
        </para>
      </note>
782
783
784
785

      <para>
        The <command>b10-cfgmgr</command> daemon can send all
        specifications and all current settings to the
Michael Graff's avatar
Michael Graff committed
786
787
        <command>bindctl</command> client (via
        <command>b10-cmdctl</command>).
788
789
      </para>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
      <para>
        <command>b10-cfgmgr</command> relays configurations received
        from <command>b10-cmdctl</command> to the appropriate modules.
      </para>
<!-- TODO:
        Configuration settings for itself are defined as ConfigManager.
TODO: show examples
-->

<!-- TODO:
config changes are actually commands to cfgmgr
-->

<!-- TODO: what about run time config to change this? -->
<!-- jelte: > config set cfgmgr/config_database <file> -->
<!-- TODO: what about command line switch to change this? -->
      <para>
        The stored configuration file is at
808
        <filename>/usr/local/var/bind10-devel/b10-config.db</filename>.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
809
        (The full path is what was defined at build configure time for
810
811
        <option>--localstatedir</option>.
        The default is <filename>/usr/local/var/</filename>.)
Michael Graff's avatar
Michael Graff committed
812
813
814
815
        The format is loosely based on JSON and is directly parseable
        python, but this may change in a future version.
        This configuration data file is not manually edited by the
        administrator.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
816
      </para>
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831

<!--

Well the specfiles have a more fixed format (they must contain specific
stuff), but those are also directly parseable python structures (and
'coincidentally', our data::element string representation is the same)

loosely based on json, tweaked to be directly parseable in python, but a
subset of that.
wiki page is http://bind10.isc.org/wiki/DataElementDesign

nope, spec files are written by module developers, and db should be done
through bindctl and friends

-->
832
833

    <para>
834
835
836
837
838
839
840
841
842
      The configuration manager does not have any command line arguments.
      Normally it is not started manually, but is automatically
      started using the <command>bind10</command> master process
      (as covered in <xref linkend="bind10"/>).
    </para>

<!-- TODO: upcoming plans:
configuration for configuration manager itself. And perhaps we might
change the messaging protocol, but an admin should never see any of that
Jeremy C. Reed's avatar
Jeremy C. Reed committed
843
844
845
846
847
848
849
-->

<!-- TODO: show examples, test this -->
<!--
, so an admin can simply run bindctl,
do config show, and it shows all modules; config show >module> shows all
options for that module
850
851
852
853
854
855
856
-->

  </chapter>

  <chapter id="cmdctl">
    <title>Remote control daemon</title>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
857
858
859
860
861
862
863
864
    <para>
      <command>b10-cmdctl</command> is the gateway between
      administrators and the BIND 10 system.
      It is a HTTPS server that uses standard HTTP Digest
      Authentication for username and password validation.
      It provides a REST-ful interface for accessing and controlling
      BIND 10.
    </para>
865
866
<!-- TODO: copy examples from wiki, try with wget -->

Jeremy C. Reed's avatar
Jeremy C. Reed committed
867
    <para>
868
      When <command>b10-cmdctl</command> starts, it firsts
869
870
      asks <command>b10-cfgmgr</command> about what modules are
      running and what their configuration is (over the
871
      <command>b10-msgq</command> channel). Then it will start listening
Jeremy C. Reed's avatar
Jeremy C. Reed committed
872
873
874
875
876
877
878
879
880
      on HTTPS for clients &mdash; the user interface &mdash; such
      as <command>bindctl</command>.
    </para>

    <para>
      <command>b10-cmdctl</command> directly sends commands
      (received from the user interface) to the specified component.
      Configuration changes are actually commands to
      <command>b10-cfgmgr</command> so are sent there.
881
    </para>
882

Jeremy C. Reed's avatar
Jeremy C. Reed committed
883
884
885
886
887
888
889
890
891
892
893
894
895
<!--
TODO:
"For bindctl to list a module's available configurations and
available commands, it communicates over the cmdctl REST interface.
cmdctl then asks cfgmgr over the msgq command channel. Then cfgmgr
asks the module for its specification and also cfgmgr looks in its
own configuration database for current values."

(05:32:03) jelte: i think cmdctl doesn't request it upon a incoming
GET, but rather requests it once and then listens in for updates,
but you might wanna check with likun
-->

896
897
<!-- TODO: replace /usr/local -->
<!-- TODO: permissions -->
898
899
900
    <para>The HTTPS server requires a private key,
      such as a RSA PRIVATE KEY.
      The default location is at
901
      <filename>/usr/local/etc/bind10-devel/cmdctl-keyfile.pem</filename>.
902
      (A sample key is at
903
      <filename>/usr/local/share/bind10-devel/cmdctl-keyfile.pem</filename>.)
904
      It also uses a certificate located at
905
      <filename>/usr/local/etc/bind10-devel/cmdctl-certfile.pem</filename>.
906
      (A sample certificate is at
907
      <filename>/usr/local/share/bind10-devel/cmdctl-certfile.pem</filename>.)
908
      This may be a self-signed certificate or purchased from a
909
910
      certification authority.
    </para>
911
912

    <note><para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
913
914
915
916
917
      The HTTPS server doesn't support a certificate request from a
      client (at this time).
<!-- TODO: maybe allow request from server side -->
      The <command>b10-cmdctl</command> daemon does not provide a
      public service. If any client wants to control BIND 10, then
Jeremy C. Reed's avatar
Jeremy C. Reed committed
918
      a certificate needs to be first received from the BIND 10
Jeremy C. Reed's avatar
Jeremy C. Reed committed
919
920
      administrator.
      The BIND 10 installation provides a sample PEM bundle that matches
921
922
923
      the sample key and certificate.
    </para></note>
<!-- TODO: cross-ref -->
Jeremy C. Reed's avatar
Jeremy C. Reed committed
924
925
926
927
928

<!-- TODO
openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
but that is a single file, maybethis should go back to that format?
-->
929
930
931
932
933
934
935

<!--
    <para>
(08:20:56) shane: It is in theory possible to run without cmdctl.
(08:21:02) shane: I think we discussed this.
    </para>
-->
936
937
938
939
940
941
942

<!-- TODO: Please check https://bind10.isc.org/wiki/cmd-ctrld -->


    <para>
      The <command>b10-cmdctl</command> daemon also requires
      the user account file located at
943
      <filename>/usr/local/etc/bind10-devel/cmdctl-accounts.csv</filename>.
944
945
946
      This comma-delimited file lists the accounts with a user name,
      hashed password, and salt.
      (A sample file is at
947
      <filename>/usr/local/share/bind10-devel/cmdctl-accounts.csv</filename>.
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
      It contains the user named <quote>root</quote> with the password
      <quote>bind10</quote>.)
    </para>

    <para>
      The administrator may create a user account with the
      <command>b10-cmdctl-usermgr</command> tool.
    </para>
<!-- TODO: show example -->

<!-- TODO: does cmdctl need to be restarted to change cert or key
or accounts database -->

    <para>
      By default the HTTPS server listens on the localhost port 8080.
963
964
      The port can be set by using the <option>--port</option> command line option.
      The address to listen on can be set using the <option>--address</option> command
965
966
967
      line argument.
      Each HTTPS connection is stateless and timesout in 1200 seconds
      by default.  This can be
968
      redefined by using the <option>--idle-timeout</option> command line argument.
969
970
    </para>

971
    <section id="cmdctl.spec">
972
      <title>Configuration specification for b10-cmdctl</title>
973
      <para>
974
975
976
977
        The configuration items for <command>b10-cmdctl</command> are:
key_file
cert_file
accounts_file
978
      </para>
979
980
<!-- TODO -->

981
      <para>
982
983
        The control commands are:
print_settings
984
985
<!-- TODO: remove that -->

986
shutdown
987
      </para>
988
<!-- TODO -->
989
    </section>
990
991
992

<!--
TODO
993
994
(12:21:30) jinmei: I'd like to have sample session using a command line www client such as wget
(12:21:33) jinmei: btw
995
996
-->

997
998
  </chapter>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
999
1000
1001
1002
  <chapter id="bindctl">
    <title>Control and configure user interface</title>

    <note><para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1003
      For this development prototype release, <command>bindctl</command>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
      is the only user interface. It is expected that upcoming
      releases will provide another interactive command-line
      interface and a web-based interface for controlling and
      configuring BIND 10.
    </para></note>

    <para>
      The <command>bindctl</command> tool provides an interactive
      prompt for configuring, controlling, and querying the BIND 10
      components.
1014
      It communicates directly with a REST-ful interface over HTTPS
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
      provided by <command>b10-cmdctl</command>. It doesn't
      communicate to any other components directly.
    </para>

<!-- TODO: explain and show interface -->

    <para>
      Configuration changes are actually commands to
      <command>b10-cfgmgr</command>. So when <command>bindctl</command>
      sends a configuration, it is sent to <command>b10-cmdctl</command>
      (over a HTTPS connection); then <command>b10-cmdctl</command>
1026
      sends the command (over a <command>b10-msgq</command> command
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1027
      channel) to <command>b10-cfgmgr</command> which then stores
1028
      the details and relays (over a <command>b10-msgq</command> command
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1029
1030
1031
1032
1033
1034
1035
1036
      channel) the configuration on to the specified module.
    </para>

    <para>
    </para>

  </chapter>

1037
1038
  <chapter id="authserver">
    <title>Authoritative Server</title>
1039

1040
    <para>
1041
1042
1043
1044
      The <command>b10-auth</command> is the authoritative DNS server.
      It supports EDNS0 and DNSSEC. It supports IPv6.
      Normally it is started by the <command>bind10</command> master
      process.
1045
1046
    </para>

1047
    <note><simpara>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1048
1049
      This development prototype release listens on all interfaces
      and the non-standard port 5300.
1050
1051
    </simpara></note>

1052
    <section>
1053
      <title>Server Configurations</title>
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081

<!-- TODO: offers command line options but not used
since we used bind10 -->

      <para>
        <command>b10-auth</command> is configured via the
        <command>b10-cfgmgr</command> configuration manager.
        The module name is <quote>Auth</quote>.
        The configuration data item is:

        <variablelist>
    
          <varlistentry>
            <term>database_file</term>
            <listitem> 
              <simpara>This is an optional string to define the path to find
                 the SQLite3 database file.
<!-- TODO: -->
Note: Later the DNS server will use various data source backends.
This may be a temporary setting until then.
              </simpara>
            </listitem>
          </varlistentry>

        </variablelist>

      </para>

1082
      <para>
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098

        The configuration command is:

        <variablelist>

          <varlistentry>
            <term>shutdown</term>
            <listitem> 
              <simpara>Stop the authoritative DNS server.
              </simpara>
<!-- TODO: what happens when this is sent, will bind10 restart? -->
            </listitem>
          </varlistentry>

        </variablelist>

1099
      </para>
1100
1101
1102

<!-- TODO: examples of setting or running above? -->

1103
    </section>
1104

1105
    <section>
1106
      <title>Data Source Backends</title>
1107
1108

      <note><para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1109
        For the development prototype release, <command>b10-auth</command>
1110
1111
        supports a SQLite3 data source backend and in-memory data source
        backend.
1112
        Upcoming versions will be able to use multiple different
1113
        data sources, such as MySQL and Berkeley DB.
1114
1115
1116
      </para></note>


1117
      <para>
1118
        By default, the SQLite3 backend uses the data file located at
1119
        <filename>/usr/local/var/bind10-devel/zone.sqlite3</filename>.
1120
1121
1122
        (The full path is what was defined at build configure time for
        <option>--localstatedir</option>.
        The default is <filename>/usr/local/var/</filename>.)
1123
1124
  This data file location may be changed by defining the
  <quote>database_file</quote> configuration.
1125
      </para>
1126

1127
    </section>
1128

1129
    <section>
1130
      <title>Loading Master Zones Files</title>
1131

1132
      <para>
1133
1134
1135
1136
        RFC 1035 style DNS master zone files may imported
        into a BIND 10 data source by using the
        <command>b10-loadzone</command> utility.
      </para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1137

1138
1139
1140
      <para>
        <command>b10-loadzone</command> supports the following
        special directives (control entries):
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1141

1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
        <variablelist>

          <varlistentry>
            <term>$INCLUDE</term>
            <listitem> 
              <simpara>Loads an additional zone file. This may be recursive.
              </simpara>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>$ORIGIN</term>
            <listitem> 
              <simpara>Defines the relative domain name.
              </simpara>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>$TTL</term>
            <listitem> 
              <simpara>Defines the time-to-live value used for following
                records that don't include a TTL.
              </simpara>
            </listitem>
          </varlistentry>

        </variablelist>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1170

1171
      </para>
1172
1173
1174
1175
1176
1177
1178
1179

      <para>
        The <option>-o</option> argument may be used to define the
        default origin for loaded zone file records.
      </para>

      <note>
      <para>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1180
1181
        In the development prototype release, only the SQLite3 back
        end is used.
1182
        By default, it stores the zone data in
1183
        <filename>/usr/local/var/bind10-devel/zone.sqlite3</filename>
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1184
        unless the <option>-d</option> switch is used to set the
1185
1186
1187
1188
1189
1190
1191
        database filename.
        Multiple zones are stored in a single SQLite3 zone database.
      </para>
      </note>

      <para>
        If you reload a zone already existing in the database,
Jeremy C. Reed's avatar
typo    
Jeremy C. Reed committed
1192
        all records from that prior zone disappear and a whole new set
1193
1194
1195
1196
1197
        appears.
      </para>

<!--TODO: permissions for xfrin or loadzone to create the file -->

1198
    </section>
1199

1200
1201
<!--
TODO
1202
    <section>
1203
1204
      <title>Troubleshooting</title>
      <para>
1205
      </para>
1206
    </section>
1207
-->
1208
1209
1210

  </chapter>

Jeremy C. Reed's avatar
Jeremy C. Reed committed
1211
1212
1213
1214
  <chapter id="xfrin">
    <title>Incoming Zone Transfers</title>

    <para>
1215
1216
1217
      Incoming zones are transferred using the <command>b10-xfrin</command>
      process which is started by <command>bind10</command>.
      When received, the zone is stored in the BIND 10
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1218
1219
      data store, and its records can be served by
      <command>b10-auth</command>.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1220
1221
1222
      In combination with <command>b10-zonemgr</command> (for
      automated SOA checks), this allows the BIND 10 server to
      provide <quote>secondary</quote> service.
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1223
1224
1225
1226
1227
    </para>

    <note><simpara>
     The current development release of BIND 10 only supports
     AXFR. (IXFR is not supported.) 
1228
1229
1230

<!-- TODO: sqlite3 data source only? -->

Jeremy C. Reed's avatar
Jeremy C. Reed committed
1231
1232
    </simpara></note>

1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
<!-- TODO:

how to tell bind10 you are a secondary?

when will it first attempt to check for new zone? (using REFRESH?)
what if zonemgr is not running?

what if a NOTIFY is sent?

-->

Jeremy C. Reed's avatar
Jeremy C. Reed committed
1244
1245
1246
1247
1248
1249
1250
1251
    <para>
       To manually trigger a zone transfer to retrieve a remote zone,
       you may use the <command>bindctl</command> utility.
       For example, at the <command>bindctl</command> prompt run:

       <screen>&gt; <userinput>Xfrin retransfer zone_name="<option>foo.example.org</option>" master=<option>192.0.2.99</option></userinput></screen>
    </para>

1252
<!-- TODO: can that retransfer be used to identify a new zone? -->
Jeremy C. Reed's avatar
Jeremy C. Reed committed
1253
<!-- TODO: what if doesn't exist at that master IP? -->
1254

Jeremy C. Reed's avatar
Jeremy C. Reed committed
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
  </chapter>

  <chapter id="xfrout">
    <title>Outbound Zone Transfers</title>

    <para>
      The <command>b10-xfrout</command> process is started by
      <command>bind10</command>.
      When the <command>b10-auth</command> authoritative DNS server
      receives an AXFR request, <command>b10-xfrout</command>
      sends the zone.
      This is used to provide master DNS service to share zones
      to secondary name servers.