Commit c4fcafe0 authored by Ondřej Surý's avatar Ondřej Surý
Browse files

Merge branch '1925-additional-text-edits-to-bind-arm' into 'main'

Resolve "Additional text edits to BIND ARM"

Closes #1925

See merge request isc-projects/bind9!3679
parents e1d42c5f 5aa5ad5a
......@@ -8,16 +8,6 @@
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. Advanced:
Advanced DNS Features
......@@ -42,7 +32,7 @@ The ``NOTIFY`` protocol is specified in :rfc:`1996`.
As a secondary zone can also be a primary to other secondaries, ``named``, by
default, sends ``NOTIFY`` messages for every zone it loads.
Specifying ``notify master-only;`` causes ``named`` to only send
Specifying ``notify primary-only;`` causes ``named`` to only send
``NOTIFY`` for primary zones that it loads.
.. _dynamic_update:
......@@ -108,8 +98,8 @@ that the zone file of a dynamic zone is up-to-date is to run
``rndc stop``.
To make changes to a dynamic zone manually, follow these steps:
First, disable dynamic updates to the zone using
``rndc freeze zone``; this updates the zone's master file with the
first, disable dynamic updates to the zone using
``rndc freeze zone``. This updates the zone file with the
changes stored in its ``.jnl`` file. Then, edit the zone file. Finally, run
``rndc thaw zone`` to reload the changed zone and re-enable dynamic
updates.
......@@ -156,21 +146,21 @@ Split DNS
---------
Setting up different views of the DNS space to internal
and external resolvers is usually referred to as a Split DNS setup.
There are several reasons an organization would want to set up its DNS
and external resolvers is usually referred to as a *split DNS* setup.
There are several reasons an organization might want to set up its DNS
this way.
One common reason to use Split DNS is to hide
One common reason to use split DNS is to hide
"internal" DNS information from "external" clients on the Internet.
There is some debate as to whether this is actually useful.
Internal DNS information leaks out in many ways (via email headers, for
example) and most savvy "attackers" can find the information they need
using other means. However, since listing addresses of internal servers
that external clients cannot possibly reach can result in connection
delays and other annoyances, an organization may choose to use Split
delays and other annoyances, an organization may choose to use split
DNS to present a consistent view of itself to the outside world.
Another common reason for setting up a Split DNS system is to allow
Another common reason for setting up a split DNS system is to allow
internal networks that are behind filters or in :rfc:`1918` space (reserved
IP space, as documented in :rfc:`1918`) to resolve DNS on the Internet.
Split DNS can also be used to allow mail from outside back into the
......@@ -295,7 +285,7 @@ Internal DNS server config:
// sample primary zone
zone "site1.example.com" {
type master;
type primary;
file "m/site1.example.com";
// do normal iterative resolution (do not forward)
forwarders { };
......@@ -305,16 +295,16 @@ Internal DNS server config:
// sample secondary zone
zone "site2.example.com" {
type slave;
type secondary;
file "s/site2.example.com";
masters { 172.16.72.3; };
primaries { 172.16.72.3; };
forwarders { };
allow-query { internals; externals; };
allow-transfer { internals; };
};
zone "site1.internal" {
type master;
type primary;
file "m/site1.internal";
forwarders { };
allow-query { internals; };
......@@ -322,9 +312,9 @@ Internal DNS server config:
};
zone "site2.internal" {
type slave;
type secondary;
file "s/site2.internal";
masters { 172.16.72.3; };
primaries { 172.16.72.3; };
forwarders { };
allow-query { internals };
allow-transfer { internals; }
......@@ -355,13 +345,13 @@ External (bastion host) DNS server configuration:
// sample secondary zone
zone "site1.example.com" {
type master;
type primary;
file "m/site1.foo.com";
allow-transfer { internals; externals; };
};
zone "site2.example.com" {
type slave;
type secondary;
file "s/site2.foo.com";
masters { another_bastion_host_maybe; };
allow-transfer { internals; externals; }
......@@ -398,8 +388,8 @@ configuration syntax and the process of creating TSIG keys.
the tools included with BIND support it for sending messages to
``named``:
* :ref:`man_nsupdate` supports TSIG via the ``-k``, ``-l`` and ``-y`` command line options, or via the ``key`` command when running interactively.
* :ref:`man_dig` supports TSIG via the ``-k`` and ``-y`` command line options.
* :ref:`man_nsupdate` supports TSIG via the ``-k``, ``-l``, and ``-y`` command-line options, or via the ``key`` command when running interactively.
* :ref:`man_dig` supports TSIG via the ``-k`` and ``-y`` command-line options.
Generating a Shared Key
~~~~~~~~~~~~~~~~~~~~~~~
......@@ -407,12 +397,12 @@ Generating a Shared Key
TSIG keys can be generated using the ``tsig-keygen`` command; the output
of the command is a ``key`` directive suitable for inclusion in
``named.conf``. The key name, algorithm, and size can be specified by
command line parameters; the defaults are "tsig-key", HMAC-SHA256, and
command-line parameters; the defaults are "tsig-key", HMAC-SHA256, and
256 bits, respectively.
Any string which is a valid DNS name can be used as a key name. For
example, a key to be shared between servers called ``host1`` and ``host2``
could be called "host1-host2.", and this key could be generated using:
could be called "host1-host2.", and this key can be generated using:
::
......@@ -463,7 +453,7 @@ Instructing the Server to Use a Key
A server sending a request to another server must be told whether to use
a key, and if so, which key to use.
For example, a key may be specified for each server in the ``masters``
For example, a key may be specified for each server in the ``primaries``
statement in the definition of a secondary zone; in this case, all SOA QUERY
messages, NOTIFY messages, and zone transfer requests (AXFR or IXFR)
are signed using the specified key. Keys may also be specified in
......@@ -499,7 +489,7 @@ TSIG keys may be specified in ACL definitions and ACL directives such as
``allow-query``, ``allow-transfer``, and ``allow-update``. The above key
would be denoted in an ACL element as ``key host1-host2.``
Here's an example of an ``allow-update`` directive using a TSIG key:
Here is an example of an ``allow-update`` directive using a TSIG key:
::
......@@ -566,7 +556,7 @@ SIG(0)
BIND partially supports DNSSEC SIG(0) transaction signatures as
specified in :rfc:`2535` and :rfc:`2931`. SIG(0) uses public/private keys to
authenticate messages. Access control is performed in the same manner as
authenticate messages. Access control is performed in the same manner as with
TSIG keys; privileges can be granted or denied in ACL directives based
on the key name.
......@@ -594,8 +584,7 @@ which must be followed. BIND 9 ships with several tools that are used in
this process, which are explained in more detail below. In all cases,
the ``-h`` option prints a full list of parameters. Note that the DNSSEC
tools require the keyset files to be in the working directory or the
directory specified by the ``-d`` option, and that the tools shipped
with BIND 9.2.x and earlier are not compatible with the current versions.
directory specified by the ``-d`` option.
There must also be communication with the administrators of the parent
and/or child zone to transmit keys. A zone's security status must be
......@@ -603,8 +592,8 @@ indicated by the parent zone for a DNSSEC-capable resolver to trust its
data. This is done through the presence or absence of a ``DS`` record at
the delegation point.
For other servers to trust data in this zone, they must either be
statically configured with this zone's zone key or the zone key of
For other servers to trust data in this zone, they must be
statically configured with either this zone's zone key or the zone key of
another zone above this one in the DNS tree.
.. _generating_dnssec_keys:
......@@ -640,7 +629,7 @@ To generate another key with the same properties but with a different
key tag, repeat the above command.
The ``dnssec-keyfromlabel`` program is used to get a key pair from a
crypto hardware and build the key files. Its usage is similar to
crypto hardware device and build the key files. Its usage is similar to
``dnssec-keygen``.
The public keys should be inserted into the zone file by including the
......@@ -668,7 +657,7 @@ it is in a file called ``zone.child.example``:
One output file is produced: ``zone.child.example.signed``. This file
should be referenced by ``named.conf`` as the input file for the zone.
``dnssec-signzone`` also produces a keyset and dsset files. These are used
``dnssec-signzone`` also produces keyset and dsset files. These are used
to provide the parent zone administrators with the ``DNSKEYs`` (or their
corresponding ``DS`` records) that are the secure entry point to the zone.
......@@ -829,7 +818,7 @@ Address Lookups Using AAAA Records
The IPv6 AAAA record is a parallel to the IPv4 A record, and, unlike the
deprecated A6 record, specifies the entire IPv6 address in a single
record. For example,
record. For example:
::
......@@ -846,7 +835,7 @@ Address-to-Name Lookups Using Nibble Format
When looking up an address in nibble format, the address components are
simply reversed, just as in IPv4, and ``ip6.arpa.`` is appended to the
resulting name. For example, the following would provide reverse name
lookup for a host with address ``2001:db8::1``.
lookup for a host with address ``2001:db8::1``:
::
......
......@@ -8,16 +8,6 @@
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _catz-info:
Catalog Zones
......@@ -37,7 +27,7 @@ standard AXFR/IXFR zone transfer mechanism.
Catalog zones' format and behavior are specified as an Internet draft
for interoperability among DNS implementations. The
latest revision of the DNS catalog zones draft can be found here:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/.
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ .
Principle of Operation
~~~~~~~~~~~~~~~~~~~~~~
......@@ -68,14 +58,14 @@ To use the catalog zone feature to serve a new member zone:
``rndc addzone``.
- Add an entry to the catalog zone for the new member zone. This can
be done by editing the catalog zone's master file and running
be done by editing the catalog zone's zone file and running
``rndc reload``, or by updating the zone using ``nsupdate``.
The change to the catalog zone is propagated from the primary to all
secondaries using the normal AXFR/IXFR mechanism. When the secondary receives the
update to the catalog zone, it detects the entry for the new member
zone, creates an instance of that zone on the secondary server, and points
that instance to the ``masters`` specified in the catalog zone data. The
that instance to the ``primaries`` specified in the catalog zone data. The
newly created member zone is a normal secondary zone, so BIND
immediately initiates a transfer of zone contents from the primary. Once
complete, the secondary starts serving the member zone.
......@@ -100,7 +90,7 @@ Catalog zones are configured with a ``catalog-zones`` statement in the
catalog-zones {
zone "catalog.example"
default-masters { 10.53.0.1; }
default-primaries { 10.53.0.1; }
in-memory no
zone-directory "catzones"
min-update-interval 10;
......@@ -129,7 +119,7 @@ specified in any order.
``zone-directory``
This option causes local copies of member zones'
master files to be stored in
zone files to be stored in
the specified directory, if ``in-memory`` is not set to ``yes``. The default is to store zone files in the
server's working directory. A non-absolute pathname in
``zone-directory`` is assumed to be relative to the working directory.
......@@ -165,7 +155,7 @@ then a catalog zone may not be used by that server.
version.catalog.example. IN TXT "1"
Note that this record must have the domain name
version.catalog-zone-name. The data
``version.catalog-zone-name``. The data
stored in a catalog zone is indicated by the domain name label
immediately before the catalog zone domain.
......@@ -178,27 +168,27 @@ Global options are set at the apex of the catalog zone, e.g.:
::
masters.catalog.example. IN AAAA 2001:db8::1
primaries.catalog.example. IN AAAA 2001:db8::1
BIND currently supports the following options:
- A simple ``masters`` definition:
- A simple ``primaries`` definition:
::
masters.catalog.example. IN A 192.0.2.1
primaries.catalog.example. IN A 192.0.2.1
This option defines a primary server for the member zones - it can be
This option defines a primary server for the member zones, which can be
either an A or AAAA record. If multiple primaries are set, the order in
which they are used is random.
- A ``masters`` with a TSIG key defined:
- A ``primaries`` with a TSIG key defined:
::
label.masters.catalog.example. IN A 192.0.2.2
label.masters.catalog.example. IN TXT "tsig_key_name"
label.primaries.catalog.example. IN A 192.0.2.2
label.primaries.catalog.example. IN TXT "tsig_key_name"
This option defines a primary server for the member zone with a TSIG
......@@ -235,9 +225,9 @@ options, but in the member zone subdomain:
::
masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN TXT "tsig_key"
primaries.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.primaries.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2
label.primaries.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN TXT "tsig_key"
allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
Options defined for a specific zone override the
......
......@@ -8,22 +8,12 @@
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. Configuration:
Name Server Configuration
=========================
In this chapter we provide some suggested configurations along with
In this chapter we provide some suggested configurations, along with
guidelines for their use. We suggest reasonable values for certain
option settings.
......@@ -40,7 +30,7 @@ A Caching-only Name Server
The following sample configuration is appropriate for a caching-only
name server for use by clients internal to a corporation. All queries
from outside clients are refused using the ``allow-query`` option.
Alternatively, the same effect could be achieved using suitable firewall
The same effect can be achieved using suitable firewall
rules.
::
......@@ -56,7 +46,7 @@ rules.
// Provide a reverse mapping for the loopback
// address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
type primary;
file "localhost.rev";
notify no;
};
......@@ -67,7 +57,7 @@ An Authoritative-only Name Server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This sample configuration is for an authoritative-only server that is
the primary (master) server for ``example.com`` and a secondary (slave) server for the subdomain
the primary server for ``example.com`` and a secondary server for the subdomain
``eng.example.com``.
::
......@@ -86,26 +76,26 @@ the primary (master) server for ``example.com`` and a secondary (slave) server f
// Provide a reverse mapping for the loopback
// address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
type primary;
file "localhost.rev";
notify no;
};
// We are the master server for example.com
// We are the primary server for example.com
zone "example.com" {
type master;
type primary;
file "example.com.db";
// IP addresses of slave servers allowed to
// IP addresses of secondary servers allowed to
// transfer example.com
allow-transfer {
192.168.4.14;
192.168.5.53;
};
};
// We are a slave server for eng.example.com
// We are a secondary server for eng.example.com
zone "eng.example.com" {
type slave;
type secondary;
file "eng.example.com.bk";
// IP address of eng.example.com master server
// IP address of eng.example.com primary server
masters { 192.168.4.12; };
};
......@@ -118,8 +108,8 @@ A primitive form of load balancing can be achieved in the DNS by using
multiple records (such as multiple A records) for one name.
For example, assuming three HTTP servers with network addresses of
10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the following
means that clients will connect to each machine one third of the time:
10.0.0.1, 10.0.0.2, and 10.0.0.3, a set of records such as the following
means that clients will connect to each machine one-third of the time:
+-----------+------+----------+----------+----------------------------+
| Name | TTL | CLASS | TYPE | Resource Record (RR) Data |
......@@ -166,12 +156,12 @@ output format.
``dig``
``dig`` is the most versatile and complete of these lookup tools. It
has two modes: simple interactive mode for a single query, and batch
mode which executes a query for each in a list of several query
mode, which executes a query for each in a list of several query
lines. All query options are accessible from the command line.
``dig [@server] domain [query-type][query-class][+query-option][-dig-option][%comment]``
The usual simple use of ``dig`` will take the form
The usual simple use of ``dig`` takes the form
``dig @server domain query-type query-class``
......@@ -183,7 +173,8 @@ output format.
default, it converts between host names and Internet addresses, but
its functionality can be extended with the use of options.
``host [-aCdlnrsTwv][-c class][-N ndots][-t type][-W timeout][-R retries][-m flag][-4][-6] hostname [server]``
``host [-aCdlnrsTwv][-c class][-N ndots][-t type][-W timeout][-R retries]
[-m flag][-4][-6] hostname [server]``
For more information and a list of available commands and options,
see the ``host`` man page.
......@@ -191,7 +182,7 @@ output format.
``nslookup``
``nslookup`` has two modes: interactive and non-interactive.
Interactive mode allows the user to query name servers for
information about various hosts and domains or to print a list of
information about various hosts and domains, or to print a list of
hosts in a domain. Non-interactive mode is used to print just the
name and requested information for a host or domain.
......@@ -225,10 +216,11 @@ server.
``named-checkconf [-jvz][-t directory][filename]``
``named-checkzone``
The ``named-checkzone`` program checks a master file for syntax and
The ``named-checkzone`` program checks a zone file for syntax and
consistency.
``named-checkzone [-djqvD][-c class][-o output][-t directory][-w directory][-k (ignore|warn|fail)][-n (ignore|warn|fail)][-W (ignore|warn)] zone [filename]``
``named-checkzone [-djqvD][-c class][-o output][-t directory][-w directory]
[-k (ignore|warn|fail)][-n (ignore|warn|fail)][-W (ignore|warn)] zone [filename]``
``named-compilezone``
This tool is similar to ``named-checkzone,`` but it always dumps the zone content
......@@ -237,7 +229,7 @@ server.
``rndc``
The remote name daemon control (``rndc``) program allows the system
administrator to control the operation of a name server. If ``rndc`` is run
without any options, it will display a usage message as
without any options, it displays a usage message as
follows:
``rndc [-c config][-s server][-p port][-y key] command [command...]``
......@@ -251,7 +243,7 @@ server.
with a configuration file. The default location for the ``rndc``
configuration file is ``/etc/rndc.conf``, but an alternate location
can be specified with the ``-c`` option. If the configuration file is
not found, ``rndc`` will also look in ``/etc/rndc.key`` (or whatever
not found, ``rndc`` also looks in ``/etc/rndc.key`` (or whatever
``sysconfdir`` was defined when the BIND build was configured). The
``rndc.key`` file is generated by running ``rndc-confgen -a`` as
described in :ref:`controls_statement_definition_and_usage`.
......@@ -264,7 +256,7 @@ server.
The ``options`` statement has three clauses: ``default-server``,
``default-key``, and ``default-port``. ``default-server`` takes a
host name or address argument and represents the server that will be
host name or address argument and represents the server that is
contacted if no ``-s`` option is provided on the command line.
``default-key`` takes the name of a key as its argument, as defined
by a ``key`` statement. ``default-port`` specifies the port to which
......@@ -275,13 +267,13 @@ server.
authenticating with ``named``. Its syntax is identical to the ``key``
statement in ``named.conf``. The keyword ``key`` is followed by a key
name, which must be a valid domain name, though it need not actually
be hierarchical; thus, a string like "``rndc_key``" is a valid name.
be hierarchical; thus, a string like ``rndc_key`` is a valid name.
The ``key`` statement has two clauses: ``algorithm`` and ``secret``.
While the configuration parser will accept any string as the argument
to the algorithm, currently only the strings ``hmac-md5``,
While the configuration parser accepts any string as the argument
to ``algorithm``, currently only the strings ``hmac-md5``,
``hmac-sha1``, ``hmac-sha224``, ``hmac-sha256``,
``hmac-sha384``, and ``hmac-sha512`` have any meaning. The secret
is a Base64 encoded string as specified in :rfc:`3548`.
is a Base64-encoded string as specified in :rfc:`3548`.
The ``server`` statement associates a key defined using the ``key``
statement with a server. The keyword ``server`` is followed by a host
......@@ -309,7 +301,7 @@ server.
``$ rndc reload``
to connect to 127.0.0.1 port 953 and cause the name server to reload,
to connect to 127.0.0.1 port 953 and causes the name server to reload,
if a name server on the local machine is running with the following
controls statements:
......@@ -322,16 +314,16 @@ server.
and it has an identical key statement for ``rndc_key``.
Running the ``rndc-confgen`` program conveniently creates a
Running the ``rndc-confgen`` program conveniently creates an
``rndc.conf`` file, and also displays the corresponding
``controls`` statement needed to add to ``named.conf``.
Alternatively, it is possible to run ``rndc-confgen -a`` to set up a
Alternatively, it is possible to run ``rndc-confgen -a`` to set up an
``rndc.key`` file and not modify ``named.conf`` at all.
Signals
~~~~~~~
Certain UNIX signals cause the name server to take specific actions, as
Certain Unix signals cause the name server to take specific actions, as
described in the following table. These signals can be sent using the
``kill`` command.
......
......@@ -8,13 +8,6 @@
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _dlz-info:
Dynamically Loadable Zones (DLZ)
......@@ -37,7 +30,7 @@ dynamically at runtime, via the DLZ "dlopen" driver, which acts as a
generic wrapper around a shared object implementing the DLZ API. The
"dlopen" driver is linked into ``named`` by default, so configure
options are no longer necessary when using these dynamically linkable
drivers, but are still needed for the older drivers in
drivers; they are still needed for the older drivers in
``contrib/dlz/drivers``.
The DLZ module provides data to ``named`` in text
......@@ -45,7 +38,7 @@ format, which is then converted to DNS wire format by ``named``. This
conversion, and the lack of any internal caching, places significant
limits on the query performance of DLZ modules. Consequently, DLZ is not
recommended for use on high-volume servers. However, it can be used in a
hidden primary (master) configuration, with secondaries retrieving zone updates via
hidden primary configuration, with secondaries retrieving zone updates via
AXFR. Note, however, that DLZ has no built-in support for DNS notify;
secondary servers are not automatically informed of changes to the zones in the
database.
......@@ -129,7 +122,7 @@ querying client and alter its response on the basis of this
information. To demonstrate this feature, the example driver responds to
queries for "source-addr.``zonename``>/TXT" with the source address of
the query. Note, however, that this record will *not* be included in
AXFR or ANY responses. Normally, this feature would be used to alter
AXFR or ANY responses. Normally, this feature is used to alter
responses in some other fashion, e.g., by providing different address
records for a particular name depending on the network from which the
query arrived.
......
......@@ -8,16 +8,6 @@
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _dnssec.dynamic.zones:
DNSSEC, Dynamic Zones, and Automatic Signing
......@@ -26,7 +16,7 @@ DNSSEC, Dynamic Zones, and Automatic Signing
Converting From Insecure to Secure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changing a zone from insecure to secure can be done in two ways: using a
A zone can be changed from insecure to secure in two ways: using a
dynamic DNS update, or via the ``auto-dnssec`` zone option.
For either method, ``named`` must be configured so that it can see
......@@ -38,7 +28,7 @@ key-directory, as specified in ``named.conf``:
::
zone example.net {
type master;
type primary;
update-policy local;
file "dynamic/example.net/example.net";
key-directory "dynamic/example.net";
......@@ -63,7 +53,7 @@ To insert the keys via dynamic update:
> send
While the update request completes almost immediately, the zone is
not completely signed until ``named`` has had time to walk the zone
not completely signed until ``named`` has had time to "walk" the zone
and generate the NSEC and RRSIG records. The NSEC record at the apex
is added last, to signal that there is a complete NSEC chain.
......@@ -109,9 +99,9 @@ the keys' timing metadata. (See :ref:`man_dnssec-keygen` and
``named`` periodically searches the key directory for keys matching
the zone; if the keys' metadata indicates that any change should be
made to the zone, such as adding, removing, or revoking a key, then that
made to the zone - such as adding, removing, or revoking a key - then that
action is carried out. By default, the key directory is checked for
changes every 60 minutes; this period can be adjusted with the
changes every 60 minutes; this period can be adjusted with
``dnssec-loadkeys-interval``, up to a maximum of 24 hours. The
``rndc loadkeys`` command forces ``named`` to check for key updates immediately.
......@@ -138,34 +128,34 @@ allow dynamic updates, by adding an ``allow-update`` or
``update-policy`` statement to the zone configuration. If this has not
been done, the configuration fails.
Private-type Records
Private Type Records
~~~~~~~~~~~~~~~~~~~~
The state of the signing process is signaled by private-type records
The state of the signing process is signaled by private type records
(with a default type value of 65534). When signing is complete, those
records with a nonzero initial octet have a nonzero value for the final octet.
records with a non-zero initial octet have a non-zero value for the final octet.
If the first octet of a private-type record is non-zero, the
If the first octet of a private type record is non-zero, the
record indicates either that the zone needs to be signed with the key matching
the record, or that all signatures that match the record should be
removed.
removed. Here are the meanings of the different values of the first octet:
algorithm (octet 1)
- algorithm (octet 1)