mirror of
https://gitlab.isc.org/isc-projects/bind9
synced 2025-08-29 13:38:26 +00:00
Merge branch 'pspacek/arm-hyperlinks' into 'main'
ARM hyperlinking See merge request isc-projects/bind9!6509
This commit is contained in:
Petr Špaček
commit
1994e2bc47
@ -256,7 +256,7 @@ The command formats and their meanings are as follows:
|
||||
in ``krb5.conf``. If no realm is specified, the saved realm is
|
||||
cleared.
|
||||
|
||||
``check-names [yes_or_no]``
|
||||
``check-names [boolean]``
|
||||
This command turns on or off check-names processing on records to be added.
|
||||
Check-names has no effect on prerequisites or records to be deleted.
|
||||
By default check-names processing is on. If check-names processing
|
||||
|
||||
@ -21,7 +21,7 @@ rndc - name server control utility
|
||||
Synopsis
|
||||
~~~~~~~~
|
||||
|
||||
:program:`rndc` [**-b** source-address] [**-c** config-file] [**-k** key-file] [**-s** server] [**-p** port] [**-q**] [**-r**] [**-V**] [**-y** key_id] [[**-4**] | [**-6**]] {command}
|
||||
:program:`rndc` [**-b** source-address] [**-c** config-file] [**-k** key-file] [**-s** server] [**-p** port] [**-q**] [**-r**] [**-V**] [**-y** server_key] [[**-4**] | [**-6**]] {command}
|
||||
|
||||
Description
|
||||
~~~~~~~~~~~
|
||||
@ -38,7 +38,7 @@ algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224,
|
||||
HMAC-SHA256 (default), HMAC-SHA384, and HMAC-SHA512. They use a shared
|
||||
secret on each end of the connection, which provides TSIG-style
|
||||
authentication for the command request and the name server's response.
|
||||
All commands sent over the channel must be signed by a key_id known to
|
||||
All commands sent over the channel must be signed by a server_key known to
|
||||
the server.
|
||||
|
||||
:program:`rndc` reads a configuration file to determine how to contact the name
|
||||
@ -101,10 +101,10 @@ Options
|
||||
|
||||
This option enables verbose logging.
|
||||
|
||||
.. option:: -y key_id
|
||||
.. option:: -y server_key
|
||||
|
||||
This option indicates use of the key ``key_id`` from the configuration file. For control message validation to succeed, ``key_id`` must be known
|
||||
by :iscman:`named` with the same algorithm and secret string. If no ``key_id`` is specified,
|
||||
This option indicates use of the key ``server_key`` from the configuration file. For control message validation to succeed, ``server_key`` must be known
|
||||
by :iscman:`named` with the same algorithm and secret string. If no ``server_key`` is specified,
|
||||
:program:`rndc` first looks for a key clause in the server statement of
|
||||
the server being used, or if no server statement is present for that
|
||||
host, then in the default-key clause of the options statement. Note that
|
||||
@ -650,7 +650,7 @@ would specify a zone called "-redirect".)
|
||||
Limitations
|
||||
~~~~~~~~~~~
|
||||
|
||||
There is currently no way to provide the shared secret for a ``key_id``
|
||||
There is currently no way to provide the shared secret for a ``server_key``
|
||||
without using the configuration file.
|
||||
|
||||
Several error messages could be clearer.
|
||||
|
||||
@ -23,17 +23,17 @@ Dynamic update is a method for adding, replacing, or deleting records in
|
||||
a primary server by sending it a special form of DNS messages. The format
|
||||
and meaning of these messages is specified in :rfc:`2136`.
|
||||
|
||||
Dynamic update is enabled by including an ``allow-update`` or an
|
||||
``update-policy`` clause in the ``zone`` statement.
|
||||
Dynamic update is enabled by including an :any:`allow-update` or an
|
||||
:any:`update-policy` clause in the :any:`zone` statement.
|
||||
|
||||
If the zone's ``update-policy`` is set to ``local``, updates to the zone
|
||||
If the zone's :any:`update-policy` is set to ``local``, updates to the zone
|
||||
are permitted for the key ``local-ddns``, which is generated by
|
||||
:iscman:`named` at startup. See :ref:`dynamic_update_policies` for more details.
|
||||
|
||||
Dynamic updates using Kerberos-signed requests can be made using the
|
||||
TKEY/GSS protocol, either by setting the ``tkey-gssapi-keytab`` option
|
||||
or by setting both the ``tkey-gssapi-credential`` and
|
||||
``tkey-domain`` options. Once enabled, Kerberos-signed requests are
|
||||
TKEY/GSS protocol, either by setting the :any:`tkey-gssapi-keytab` option
|
||||
or by setting both the :any:`tkey-gssapi-credential` and
|
||||
:any:`tkey-domain` options. Once enabled, Kerberos-signed requests are
|
||||
matched against the update policies for the zone, using the Kerberos
|
||||
principal as the signer for the request.
|
||||
|
||||
@ -121,12 +121,12 @@ necessary change history information is available. These include primary
|
||||
zones maintained by dynamic update and secondary zones whose data was
|
||||
obtained by IXFR. For manually maintained primary zones, and for secondary
|
||||
zones obtained by performing a full zone transfer (AXFR), IXFR is
|
||||
supported only if the option ``ixfr-from-differences`` is set to
|
||||
supported only if the option :any:`ixfr-from-differences` is set to
|
||||
``yes``.
|
||||
|
||||
When acting as a secondary server, BIND 9 attempts to use IXFR unless it is
|
||||
explicitly disabled. For more information about disabling IXFR, see the
|
||||
description of the ``request-ixfr`` clause of the ``server`` statement.
|
||||
description of the :any:`request-ixfr` clause of the :namedconf:ref:`server` statement.
|
||||
|
||||
When a secondary server receives a zone via AXFR, it creates a new copy of the
|
||||
zone database and then swaps it into place; during the loading process, queries
|
||||
@ -136,7 +136,7 @@ degrade query performance during the transfer. If a server receiving an IXFR
|
||||
request determines that the response size would be similar in size to an AXFR
|
||||
response, it may wish to send AXFR instead. The threshold at which this
|
||||
determination is made can be configured using the
|
||||
``max-ixfr-ratio`` option.
|
||||
:any:`max-ixfr-ratio` option.
|
||||
|
||||
.. _split_dns:
|
||||
|
||||
|
||||
@ -47,10 +47,10 @@ removes, or reconfigures member zones based on the data received.
|
||||
|
||||
To use a catalog zone, it must first be set up as a normal zone on both the
|
||||
primary and secondary servers that are configured to use it. It
|
||||
must also be added to a ``catalog-zones`` list in the ``options`` or
|
||||
``view`` statement in :iscman:`named.conf`. This is comparable to the way a
|
||||
must also be added to a :any:`catalog-zones` list in the :namedconf:ref:`options` or
|
||||
:any:`view` statement in :iscman:`named.conf`. This is comparable to the way a
|
||||
policy zone is configured as a normal zone and also listed in a
|
||||
``response-policy`` statement.
|
||||
:any:`response-policy` statement.
|
||||
|
||||
To use the catalog zone feature to serve a new member zone:
|
||||
|
||||
@ -66,7 +66,7 @@ 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 ``primaries`` specified in the catalog zone data. The
|
||||
that instance to the :any:`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.
|
||||
@ -85,8 +85,8 @@ Configuring Catalog Zones
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. namedconf:statement:: catalog-zones
|
||||
|
||||
Catalog zones are configured with a ``catalog-zones`` statement in the
|
||||
``options`` or ``view`` section of :iscman:`named.conf`. For example:
|
||||
Catalog zones are configured with a :any:`catalog-zones` statement in the
|
||||
:namedconf:ref:`options` or :any:`view` section of :iscman:`named.conf`. For example:
|
||||
|
||||
::
|
||||
|
||||
@ -117,7 +117,7 @@ specified in any order.
|
||||
``in-memory``
|
||||
This option, if set to ``yes``, causes member zones to be
|
||||
stored only in memory. This is functionally equivalent to configuring a
|
||||
secondary zone without a ``file`` option. The default is ``no``; member
|
||||
secondary zone without a :any:`file` option. The default is ``no``; member
|
||||
zones' content is stored locally in a file whose name is
|
||||
automatically generated from the view name, catalog zone name, and
|
||||
member zone name.
|
||||
@ -137,8 +137,8 @@ specified in any order.
|
||||
interval has elapsed. The default is 5 seconds.
|
||||
|
||||
Catalog zones are defined on a per-view basis. Configuring a non-empty
|
||||
``catalog-zones`` statement in a view automatically turns on
|
||||
``allow-new-zones`` for that view. This means that :option:`rndc addzone`
|
||||
:any:`catalog-zones` statement in a view automatically turns on
|
||||
:any:`allow-new-zones` for that view. This means that :option:`rndc addzone`
|
||||
and :option:`rndc delzone` also work in any view that supports catalog
|
||||
zones.
|
||||
|
||||
@ -202,7 +202,7 @@ Global custom properties are set at the apex of the catalog zone, e.g.:
|
||||
|
||||
BIND currently supports the following custom properties:
|
||||
|
||||
- A simple ``primaries`` definition:
|
||||
- A simple :any:`primaries` definition:
|
||||
|
||||
::
|
||||
|
||||
@ -213,9 +213,9 @@ BIND currently supports the following custom properties:
|
||||
either an A or AAAA record. If multiple primaries are set, the order in
|
||||
which they are used is random.
|
||||
|
||||
Note: ``masters`` can be used as a synonym for ``primaries``.
|
||||
Note: ``masters`` can be used as a synonym for :any:`primaries`.
|
||||
|
||||
- A ``primaries`` with a TSIG key defined:
|
||||
- A :any:`primaries` with a TSIG key defined:
|
||||
|
||||
::
|
||||
|
||||
@ -227,9 +227,9 @@ BIND currently supports the following custom properties:
|
||||
key set. The TSIG key must be configured in the configuration file.
|
||||
``label`` can be any valid DNS label.
|
||||
|
||||
Note: ``masters`` can be used as a synonym for ``primaries``.
|
||||
Note: ``masters`` can be used as a synonym for :any:`primaries`.
|
||||
|
||||
- ``allow-query`` and ``allow-transfer`` ACLs:
|
||||
- :any:`allow-query` and :any:`allow-transfer` ACLs:
|
||||
|
||||
::
|
||||
|
||||
@ -237,8 +237,8 @@ BIND currently supports the following custom properties:
|
||||
allow-transfer.ext.catalog.example. IN APL !1:10.0.0.1/32 1:10.0.0.0/24
|
||||
|
||||
|
||||
These custom properties are the equivalents of ``allow-query`` and
|
||||
``allow-transfer`` options in a zone declaration in the :iscman:`named.conf`
|
||||
These custom properties are the equivalents of :any:`allow-query` and
|
||||
:any:`allow-transfer` options in a zone declaration in the :iscman:`named.conf`
|
||||
configuration file. The ACL is processed in order; if there is no
|
||||
match to any rule, the default policy is to deny access. For the
|
||||
syntax of the APL RR, see :rfc:`3123`.
|
||||
@ -256,12 +256,12 @@ custom properties, but in the member zone subdomain:
|
||||
|
||||
Custom properties defined for a specific zone override the
|
||||
global custom properties defined in the catalog zone. These in turn override the
|
||||
global options defined in the ``catalog-zones`` statement in the
|
||||
global options defined in the :any:`catalog-zones` statement in the
|
||||
configuration file.
|
||||
|
||||
Note that none of the global records for a custom property are inherited if any
|
||||
records are defined for that custom property for the specific zone. For example,
|
||||
if the zone had a ``primaries`` record of type A but not AAAA, it
|
||||
if the zone had a :any:`primaries` record of type A but not AAAA, it
|
||||
would *not* inherit the type AAAA record from the global custom property
|
||||
or from the global option in the configuration file.
|
||||
|
||||
|
||||
@ -39,8 +39,6 @@ may support any combination of primary and secondary zones.
|
||||
For reasons of backward compatibility BIND 9 treats "primary" and "master" as
|
||||
synonyms, as well as "secondary" and "slave."
|
||||
|
||||
.. _notify:
|
||||
|
||||
The following diagram shows the relationship between the primary and secondary
|
||||
name servers. The text below explains the process in detail.
|
||||
|
||||
@ -168,10 +166,10 @@ the :iscman:`named.conf` file has been modified as shown:
|
||||
|
||||
The added statements and blocks are commented in the above file.
|
||||
|
||||
The :ref:`zone<zone_clause>` block, and :ref:`allow-query<allow-query>`,
|
||||
The :any:`zone` block, and :ref:`allow-query<allow-query>`,
|
||||
:any:`allow-query-cache`,
|
||||
:ref:`allow-transfer<allow-transfer>`, :ref:`file<file>`,
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
|
||||
statements are described in detail in the appropriate sections.
|
||||
|
||||
.. _sample_secondary:
|
||||
@ -250,11 +248,11 @@ The :ref:`named.conf<named_conf>` file has been modified as shown:
|
||||
|
||||
The statements and blocks added are all commented in the above file.
|
||||
|
||||
The :ref:`zone<zone_clause>` block, and :ref:`allow-query<allow-query>`,
|
||||
The :any:`zone` block, and :ref:`allow-query<allow-query>`,
|
||||
:any:`allow-query-cache`,
|
||||
:ref:`allow-transfer<allow-transfer>`, :ref:`file<file>`,
|
||||
:ref:`notify<notify_st>`, :ref:`primaries<primaries>`,
|
||||
:ref:`recursion<recursion>`, and :ref:`type<type>` statements are described in
|
||||
:ref:`recursion<recursion>`, and :any:`type` statements are described in
|
||||
detail in the appropriate sections.
|
||||
|
||||
If NOTIFY is not being used, no changes are required in this
|
||||
|
||||
@ -79,7 +79,7 @@ as required by the user.
|
||||
};
|
||||
|
||||
The :ref:`logging<logging_grammar>` and :ref:`options<options_grammar>` blocks
|
||||
and :ref:`category<the_category_phrase>`, :ref:`channel<channel>`,
|
||||
and :ref:`category<the_category_phrase>`, :any:`channel`,
|
||||
:ref:`directory<directory>`, :ref:`file<file>`, and :ref:`severity<severity>`
|
||||
statements are all described further in the appropriate sections of this ARM.
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@ as the file ``named.root`` (normally found in /etc/namedb or
|
||||
Consult the appropriate distribution documentation for the actual file name.
|
||||
|
||||
|
||||
The hint zone file is referenced using the :ref:`type hint;<type>` statement and
|
||||
The hint zone file is referenced using the :any:`type hint` statement and
|
||||
a zone (domain) name of "." (the generally silent dot).
|
||||
|
||||
.. Note:: The root server IP addresses have been stable for a number of
|
||||
@ -262,10 +262,10 @@ It is therefore a **closed** resolver and cannot be used in wider network attack
|
||||
notify no;
|
||||
};
|
||||
|
||||
The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
|
||||
The :any:`zone` and :any:`acl` blocks, and the
|
||||
:ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
|
||||
:ref:`file<file>`, :ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and
|
||||
:ref:`type<type>` statements are described in detail in the appropriate
|
||||
:any:`type` statements are described in detail in the appropriate
|
||||
sections.
|
||||
|
||||
As a reminder, the configuration of this resolver does **not** access the DNS
|
||||
@ -279,7 +279,7 @@ hierarchy (does not use the public network) for any recursive query for which:
|
||||
|
||||
4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
|
||||
|
||||
5. Is a reverse-map query for any local IP (``empty-zones-enable``
|
||||
5. Is a reverse-map query for any local IP (:any:`empty-zones-enable`
|
||||
statement).
|
||||
|
||||
All other recursive queries will result in access to the DNS hierarchy to
|
||||
@ -380,10 +380,10 @@ provided<selective_forward_sample>`.
|
||||
notify no;
|
||||
};
|
||||
|
||||
The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
|
||||
The :any:`zone` and :any:`acl` blocks, and the
|
||||
:ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
|
||||
:ref:`file<file>`, :ref:`forward<forward>`, :ref:`forwarders<forwarders>`,
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
|
||||
statements are described in detail in the appropriate sections.
|
||||
|
||||
As a reminder, the configuration of this forwarding resolver does **not**
|
||||
@ -397,7 +397,7 @@ forward any recursive query for which:
|
||||
|
||||
4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
|
||||
|
||||
5. Is a reverse-map query for any local IP (``empty-zones-enable`` statement).
|
||||
5. Is a reverse-map query for any local IP (:any:`empty-zones-enable` statement).
|
||||
|
||||
All other recursive queries will be forwarded to resolve the query.
|
||||
|
||||
@ -507,10 +507,10 @@ those IPs from which it will accept recursive queries.
|
||||
};
|
||||
|
||||
|
||||
The :ref:`zone<zone_clause>` and :ref:`acl<acl_grammar>` blocks, and the
|
||||
The :any:`zone` and :any:`acl` blocks, and the
|
||||
:ref:`allow-query<allow-query>`, :ref:`empty-zones-enable<empty-zones-enable>`,
|
||||
:ref:`file<file>`, :ref:`forward<forward>`, :ref:`forwarders<forwarders>`,
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :ref:`type<type>`
|
||||
:ref:`notify<notify_st>`, :ref:`recursion<recursion>`, and :any:`type`
|
||||
statements are described in detail in the appropriate sections.
|
||||
|
||||
As a reminder, the configuration of this resolver does **not** access the DNS
|
||||
|
||||
@ -34,7 +34,7 @@ Configuring DLZ
|
||||
~~~~~~~~~~~~~~~
|
||||
.. namedconf:statement:: dlz
|
||||
|
||||
A DLZ database is configured with a ``dlz`` statement in :iscman:`named.conf`:
|
||||
A DLZ database is configured with a :any:`dlz` statement in :iscman:`named.conf`:
|
||||
|
||||
::
|
||||
|
||||
@ -46,19 +46,19 @@ A DLZ database is configured with a ``dlz`` statement in :iscman:`named.conf`:
|
||||
|
||||
This specifies a DLZ module to search when answering queries; the module
|
||||
is implemented in ``driver.so`` and is loaded at runtime by the dlopen
|
||||
DLZ driver. Multiple ``dlz`` statements can be specified.
|
||||
DLZ driver. Multiple :any:`dlz` statements can be specified.
|
||||
|
||||
|
||||
.. namedconf:statement:: search
|
||||
|
||||
When answering a query, all DLZ modules with ``search`` set to ``yes`` are
|
||||
When answering a query, all DLZ modules with :namedconf:ref:`search` set to ``yes`` are
|
||||
queried to see whether they contain an answer for the query name. The best
|
||||
available answer is returned to the client.
|
||||
|
||||
The ``search`` option in the above example can be omitted, because
|
||||
The :namedconf:ref:`search` option in the above example can be omitted, because
|
||||
``yes`` is the default value.
|
||||
|
||||
If ``search`` is set to ``no``, this DLZ module is *not* searched
|
||||
If :namedconf:ref:`search` is set to ``no``, this DLZ module is *not* searched
|
||||
for the best match when a query is received. Instead, zones in this DLZ
|
||||
must be separately specified in a zone statement. This allows users to
|
||||
configure a zone normally using standard zone-option semantics, but
|
||||
@ -86,7 +86,7 @@ For guidance in the implementation of DLZ modules, the directory
|
||||
``contrib/dlz/example`` contains a basic dynamically linkable DLZ
|
||||
module - i.e., one which can be loaded at runtime by the "dlopen" DLZ
|
||||
driver. The example sets up a single zone, whose name is passed to the
|
||||
module as an argument in the ``dlz`` statement:
|
||||
module as an argument in the :any:`dlz` statement:
|
||||
|
||||
::
|
||||
|
||||
|
||||
@ -110,51 +110,51 @@ server.
|
||||
described in :ref:`controls_statement_definition_and_usage`.
|
||||
|
||||
The format of the configuration file is similar to that of
|
||||
:iscman:`named.conf`, but is limited to only four statements: the ``options``,
|
||||
``key``, ``server``, and ``include`` statements. These statements are
|
||||
:iscman:`named.conf`, but is limited to only three blocks: the :rndcconf:ref:`options`,
|
||||
:rndcconf:ref:`key`, :rndcconf:ref:`server`, and the :ref:`include_grammar`. These blocks are
|
||||
what associate the secret keys to the servers with which they are
|
||||
meant to be shared. The order of statements is not significant.
|
||||
meant to be shared. The order of blocks is not significant.
|
||||
|
||||
.. rndcconf:statement:: options
|
||||
|
||||
.. rndcconf:statement:: default-server
|
||||
|
||||
``default-server`` takes a
|
||||
:any:`default-server` takes a
|
||||
host name or address argument and represents the server that is
|
||||
contacted if no :option:`-s <rndc -s>` option is provided on the command line.
|
||||
|
||||
.. rndcconf:statement:: default-key
|
||||
|
||||
``default-key`` takes the name of a key as its argument, as defined
|
||||
by a ``key`` statement.
|
||||
:any:`default-key` takes the name of a key as its argument, as defined
|
||||
by a :rndcconf:ref:`key` block.
|
||||
|
||||
.. rndcconf:statement:: default-port
|
||||
|
||||
``default-port`` specifies the port to which
|
||||
:any:`default-port` specifies the port to which
|
||||
:iscman:`rndc` should connect if no port is given on the command line or in
|
||||
a ``server`` statement.
|
||||
a :rndcconf:ref:`server` block.
|
||||
|
||||
.. rndcconf:statement:: default-source-address
|
||||
.. rndcconf:statement:: default-source-address-v6
|
||||
|
||||
``default-source-address`` and ``default-source-address-v6`` specify
|
||||
:any:`default-source-address` and :any:`default-source-address-v6` specify
|
||||
the IPv4 and IPv6 source address used to communicate with the server
|
||||
if no address is given on the command line or in a
|
||||
:rndcconf:ref:`server` block.
|
||||
|
||||
.. rndcconf:statement:: key
|
||||
|
||||
The ``key`` statement defines a key to be used by :iscman:`rndc` when
|
||||
authenticating with :iscman:`named`. Its syntax is identical to the ``key``
|
||||
statement in :iscman:`named.conf`. The keyword ``key`` is followed by a key
|
||||
The :rndcconf:ref:`key` block defines a key to be used by :iscman:`rndc` when
|
||||
authenticating with :iscman:`named`. Its syntax is identical to the :namedconf:ref:`key`
|
||||
statement in :iscman:`named.conf`. The keyword :rndcconf:ref:`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.
|
||||
The ``key`` statement has two clauses: ``algorithm`` and ``secret``.
|
||||
The :rndcconf:ref:`key` block has two statements: :rndcconf:ref:`algorithm` and :rndcconf:ref:`secret`.
|
||||
|
||||
.. rndcconf:statement:: algorithm
|
||||
|
||||
While the configuration parser accepts any string as the argument
|
||||
to ``algorithm``, currently only the strings ``hmac-md5``,
|
||||
to :rndcconf:ref:`algorithm`, currently only the strings ``hmac-md5``,
|
||||
``hmac-sha1``, ``hmac-sha224``, ``hmac-sha256``,
|
||||
``hmac-sha384``, and ``hmac-sha512`` have any meaning.
|
||||
|
||||
@ -165,7 +165,7 @@ server.
|
||||
|
||||
.. rndcconf:statement:: server
|
||||
|
||||
The ``server`` statement specifies connection parameters for a given server.
|
||||
The :rndcconf:ref:`server` block specifies connection parameters for a given server.
|
||||
The server can be specified as a host name or address.
|
||||
|
||||
.. rndcconf:statement:: addresses
|
||||
@ -217,11 +217,11 @@ server.
|
||||
allow { localhost; } keys { rndc_key; };
|
||||
};
|
||||
|
||||
and it has an identical key statement for ``rndc_key``.
|
||||
and it has an identical key block for ``rndc_key``.
|
||||
|
||||
Running the :iscman:`rndc-confgen` program conveniently creates an
|
||||
:iscman:`rndc.conf` file, and also displays the corresponding
|
||||
``controls`` statement needed to add to :iscman:`named.conf`.
|
||||
:any:`controls` statement needed to add to :iscman:`named.conf`.
|
||||
Alternatively, it is possible to run :option:`rndc-confgen -a` to set up an
|
||||
``rndc.key`` file and not modify :iscman:`named.conf` at all.
|
||||
|
||||
|
||||
@ -107,7 +107,7 @@ care of any DNSSEC maintenance for this zone, including replacing signatures
|
||||
that are about to expire and managing :ref:`key_rollovers`.
|
||||
|
||||
.. note::
|
||||
``dnssec-policy`` needs write access to the zone. Please see
|
||||
:any:`dnssec-policy` needs write access to the zone. Please see
|
||||
:ref:`dnssec_policy` for more details about implications for zone storage.
|
||||
|
||||
The default policy creates one key that is used to sign the complete zone,
|
||||
@ -115,7 +115,7 @@ and uses ``NSEC`` to enable authenticated denial of existence (a secure way
|
||||
to tell which records do not exist in a zone). This policy is recommended
|
||||
and typically does not need to be changed.
|
||||
|
||||
If needed, a custom policy can be defined by adding a ``dnssec-policy`` statement
|
||||
If needed, a custom policy can be defined by adding a :any:`dnssec-policy` statement
|
||||
into the configuration:
|
||||
|
||||
.. code-block:: none
|
||||
@ -155,7 +155,7 @@ needs.
|
||||
Key Rollover
|
||||
============
|
||||
|
||||
When using a ``dnssec-policy``, a key lifetime can be set to trigger
|
||||
When using a :any:`dnssec-policy`, a key lifetime can be set to trigger
|
||||
key rollovers. ZSK rollovers are fully automatic, but for KSK and CSK rollovers
|
||||
a DS record needs to be submitted to the parent. See
|
||||
:ref:`secure_delegation` for possible ways to do so.
|
||||
@ -222,7 +222,7 @@ adjusts the zone's DNSSEC keys on a schedule according to the key timing
|
||||
metadata. However, keys still need to be generated separately, for
|
||||
example with :iscman:`dnssec-keygen`.
|
||||
|
||||
Of course, dynamic zones can also use ``dnssec-policy`` to fully automate DNSSEC
|
||||
Of course, dynamic zones can also use :any:`dnssec-policy` to fully automate DNSSEC
|
||||
maintenance. The next sections assume that more key
|
||||
management control is needed, and describe how to use dynamic DNS update to perform
|
||||
various DNSSEC operations.
|
||||
@ -235,7 +235,7 @@ As an alternative to fully automated zone signing using :ref:`dnssec-policy
|
||||
<dnssec_kasp>`, a zone can be changed from insecure to secure using a dynamic
|
||||
DNS update. :iscman:`named` must be configured so that it can see the ``K*``
|
||||
files which contain the public and private parts of the `zone keys`_ that are
|
||||
used to sign the zone. Key files should be placed in the ``key-directory``, as
|
||||
used to sign the zone. Key files should be placed in the :any:`key-directory`, as
|
||||
specified in :iscman:`named.conf`:
|
||||
|
||||
::
|
||||
@ -273,7 +273,7 @@ To insert the keys via dynamic update:
|
||||
> send
|
||||
|
||||
In order to sign with these keys, the corresponding key files should also be
|
||||
placed in the ``key-directory``.
|
||||
placed in the :any:`key-directory`.
|
||||
|
||||
.. _dnssec_dynamic_zones_nsec3:
|
||||
|
||||
@ -354,10 +354,10 @@ To convert a signed zone to unsigned using dynamic DNS, delete all the
|
||||
``NSEC`` or ``NSEC3`` chains, and associated ``NSEC3PARAM`` records are removed
|
||||
automatically when the zone is supposed to be re-signed.
|
||||
|
||||
This requires the ``dnssec-secure-to-insecure`` option to be set to ``yes`` in
|
||||
This requires the :any:`dnssec-secure-to-insecure` option to be set to ``yes`` in
|
||||
:iscman:`named.conf`.
|
||||
|
||||
In addition, if the ``auto-dnssec maintain`` or a ``dnssec-policy`` is used, it
|
||||
In addition, if the ``auto-dnssec maintain`` or a :any:`dnssec-policy` is used, it
|
||||
should be removed or changed to ``allow`` instead; otherwise it will re-sign.
|
||||
|
||||
.. _dnssec_tools:
|
||||
@ -471,7 +471,7 @@ This trust anchor is provided as part of BIND and is kept up-to-date using
|
||||
To validate answers, the resolver needs at least one trusted starting point,
|
||||
a "trust anchor." Essentially, trust anchors are copies of ``DNSKEY`` RRs for
|
||||
zones that are used to form the first link in the cryptographic chain of trust.
|
||||
Alternative trust anchors can be specified using :ref:`trust_anchors`, but
|
||||
Alternative trust anchors can be specified using :any:`trust-anchors`, but
|
||||
this setup is very unusual and is recommended only for expert use.
|
||||
For more information, see :ref:`trust_anchors_description` in the
|
||||
:doc:`dnssec-guide`.
|
||||
|
||||
@ -35,7 +35,7 @@ Configuring DynDB
|
||||
~~~~~~~~~~~~~~~~~
|
||||
.. namedconf:statement:: dyndb
|
||||
|
||||
A DynDB database is configured with a ``dyndb`` statement in
|
||||
A DynDB database is configured with a :any:`dyndb` statement in
|
||||
:iscman:`named.conf`:
|
||||
|
||||
::
|
||||
@ -46,7 +46,7 @@ A DynDB database is configured with a ``dyndb`` statement in
|
||||
|
||||
|
||||
The file ``driver.so`` is a DynDB module which implements the full DNS
|
||||
database API. Multiple ``dyndb`` statements can be specified, to load
|
||||
database API. Multiple :any:`dyndb` statements can be specified, to load
|
||||
different drivers or multiple instances of the same driver. Zones
|
||||
provided by a DynDB module are added to the view's zone table, and are
|
||||
treated as normal authoritative zones when BIND responds to
|
||||
@ -62,7 +62,7 @@ Sample DynDB Module
|
||||
For guidance in the implementation of DynDB modules, the directory
|
||||
``bin/tests/system/dyndb/driver`` contains a basic DynDB module. The
|
||||
example sets up two zones, whose names are passed to the module as
|
||||
arguments in the ``dyndb`` statement:
|
||||
arguments in the :any:`dyndb` statement:
|
||||
|
||||
::
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@
|
||||
Logging options for those categories where no specific configuration has been defined.
|
||||
|
||||
``delegation-only``
|
||||
Queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a ``delegation-only`` in a forward, hint, or stub zone declaration.
|
||||
Queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a :any:`delegation-only` in a forward, hint, or stub zone declaration.
|
||||
|
||||
``dispatch``
|
||||
Dispatching of incoming packets to the server modules where they are to be processed.
|
||||
@ -34,7 +34,7 @@
|
||||
DNSSEC and TSIG protocol processing.
|
||||
|
||||
``dnstap``
|
||||
The "dnstap" DNS traffic capture system.
|
||||
The :any:`dnstap` DNS traffic capture system.
|
||||
|
||||
``edns-disabled``
|
||||
Log queries that have been forced to use plain DNS due to timeouts. This is often due to the remote servers not being :rfc:`1034`-compliant (not always returning FORMERR or similar to EDNS queries and other extensions to the DNS when they are not understood). In other words, this is targeted at servers that fail to respond to DNS queries that they don't understand.
|
||||
@ -61,7 +61,7 @@
|
||||
``queries``
|
||||
A location where queries should be logged.
|
||||
|
||||
At startup, specifying the category ``queries`` also enables query logging unless the ``querylog`` option has been specified.
|
||||
At startup, specifying the category ``queries`` also enables query logging unless the :any:`querylog` option has been specified.
|
||||
|
||||
The query log entry first reports a client object identifier in @0x<hexadecimal-number> format. Next, it reports the client's IP address and port number, and the query name, class, and type. Next, it reports whether the Recursion Desired flag was set (+ if set, - if not set), whether the query was signed (S), whether EDNS was in use along with the EDNS version number (E(#)), whether TCP was used (T), whether DO (DNSSEC Ok) was set (D), whether CD (Checking Disabled) was set (C), whether a valid DNS Server COOKIE was received (V), and whether a DNS COOKIE option without a valid Server COOKIE was present (K). After this, the destination address the query was sent to is reported. Finally, if any CLIENT-SUBNET option was present in the client query, it is included in square brackets in the format [ECS address/source/scope].
|
||||
|
||||
@ -102,10 +102,10 @@
|
||||
TLS pre-master secrets (for debugging purposes).
|
||||
|
||||
``trust-anchor-telemetry``
|
||||
Trust-anchor-telemetry requests received by :iscman:`named`.
|
||||
:any:`trust-anchor-telemetry` requests received by :iscman:`named`.
|
||||
|
||||
``unmatched``
|
||||
Messages that :iscman:`named` was unable to determine the class of, or for which there was no matching ``view``. A one-line summary is also logged to the ``client`` category. This category is best sent to a file or stderr; by default it is sent to the ``null`` channel.
|
||||
Messages that :iscman:`named` was unable to determine the class of, or for which there was no matching :any:`view`. A one-line summary is also logged to the ``client`` category. This category is best sent to a file or stderr; by default it is sent to the :any:`null` channel.
|
||||
|
||||
``update``
|
||||
Dynamic updates.
|
||||
|
||||
@ -23,9 +23,9 @@ Validating Resolver
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To configure a validating resolver to use :rfc:`5011` to maintain a trust
|
||||
anchor, configure the trust anchor using a ``trust-anchors`` statement and
|
||||
anchor, configure the trust anchor using a :any:`trust-anchors` statement and
|
||||
the ``initial-key`` keyword. Information about this can be found in
|
||||
:ref:`trust-anchors`.
|
||||
the :any:`trust-anchors` statement description.
|
||||
|
||||
Authoritative Server
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -36,7 +36,7 @@ Configuring Plugins
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
.. namedconf:statement:: plugin
|
||||
|
||||
A plugin is configured with the ``plugin`` statement in :iscman:`named.conf`:
|
||||
A plugin is configured with the :any:`plugin` statement in :iscman:`named.conf`:
|
||||
|
||||
::
|
||||
|
||||
@ -48,7 +48,7 @@ A plugin is configured with the ``plugin`` statement in :iscman:`named.conf`:
|
||||
In this example, file ``library.so`` is the plugin library. ``query``
|
||||
indicates that this is a query plugin.
|
||||
|
||||
Multiple ``plugin`` statements can be specified, to load different
|
||||
Multiple :any:`plugin` statements can be specified, to load different
|
||||
plugins or multiple instances of the same plugin.
|
||||
|
||||
``parameters`` are passed as an opaque string to the plugin's initialization
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -300,7 +300,7 @@ transfers possible.
|
||||
|
||||
Administrators who edit or periodically regenerate a DNS RPZ rule set and
|
||||
whose primary name server uses BIND can enable the
|
||||
``ixfr-from-differences`` option, which tells the primary name server to
|
||||
:any:`ixfr-from-differences` option, which tells the primary name server to
|
||||
calculate the differences between each new zone and the preceding version,
|
||||
and to make these differences available as a stream of deltas for use in
|
||||
incremental zone transfers to the subscribing name servers. This will look
|
||||
@ -750,7 +750,7 @@ To accomplish this using RPZ:
|
||||
};
|
||||
|
||||
3. Enable use of the Response Policy Zone for all incoming queries
|
||||
by adding the ``response-policy`` directive into the ``options {}``
|
||||
by adding the :any:`response-policy` directive into the ``options {}``
|
||||
section:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
@ -22,9 +22,9 @@ Access Control Lists
|
||||
--------------------
|
||||
|
||||
Access Control Lists (ACLs) are address match lists that can be set up
|
||||
and nicknamed for future use in ``allow-notify``, ``allow-query``,
|
||||
``allow-query-on``, ``allow-recursion``, ``blackhole``,
|
||||
``allow-transfer``, ``match-clients``, etc.
|
||||
and nicknamed for future use in :any:`allow-notify`, :any:`allow-query`,
|
||||
:any:`allow-query-on`, :any:`allow-recursion`, :any:`blackhole`,
|
||||
:any:`allow-transfer`, :any:`match-clients`, etc.
|
||||
|
||||
ACLs give users finer control over who can access the
|
||||
name server, without cluttering up configuration files with huge lists of
|
||||
@ -97,12 +97,12 @@ it is interpreted as the full name of the country. Similarly, if
|
||||
standard two-letter state or province abbreviation; otherwise, it is treated as the
|
||||
full name of the state or province.
|
||||
|
||||
The ``database`` field indicates which GeoIP database to search for a match. In
|
||||
The :any:`database` field indicates which GeoIP database to search for a match. In
|
||||
most cases this is unnecessary, because most search fields can only be found in
|
||||
a single database. However, searches for ``continent`` or ``country`` can be
|
||||
answered from either the ``city`` or ``country`` databases, so for these search
|
||||
types, specifying a ``database`` forces the query to be answered from that
|
||||
database and no other. If a ``database`` is not specified, these queries
|
||||
types, specifying a :any:`database` forces the query to be answered from that
|
||||
database and no other. If a :any:`database` is not specified, these queries
|
||||
are first answered from the ``city`` database if it is installed, and then from the ``country``
|
||||
database if it is installed. Valid database names are ``country``,
|
||||
``city``, ``asnum``, ``isp``, and ``domain``.
|
||||
@ -176,7 +176,7 @@ For a ``chroot`` environment to work properly in a particular
|
||||
directory (for example, ``/var/named``), the
|
||||
environment must include everything BIND needs to run. From BIND's
|
||||
point of view, ``/var/named`` is the root of the filesystem;
|
||||
the values of options like ``directory`` and ``pid-file``
|
||||
the values of options like :any:`directory` and :any:`pid-file`
|
||||
must be adjusted to account for this.
|
||||
|
||||
Unlike with earlier versions of BIND,
|
||||
@ -209,10 +209,10 @@ Dynamic Update Security
|
||||
Access to the dynamic update facility should be strictly limited. In
|
||||
earlier versions of BIND, the only way to do this was based on the IP
|
||||
address of the host requesting the update, by listing an IP address or
|
||||
network prefix in the ``allow-update`` zone option. This method is
|
||||
network prefix in the :any:`allow-update` zone option. This method is
|
||||
insecure, since the source address of the update UDP packet is easily
|
||||
forged. Also note that if the IP addresses allowed by the
|
||||
``allow-update`` option include the address of a secondary server which
|
||||
:any:`allow-update` option include the address of a secondary server which
|
||||
performs forwarding of dynamic updates, the primary can be trivially
|
||||
attacked by sending the update to the secondary, which forwards it to
|
||||
the primary with its own source IP address - causing the primary to approve
|
||||
@ -220,9 +220,9 @@ it without question.
|
||||
|
||||
For these reasons, we strongly recommend that updates be
|
||||
cryptographically authenticated by means of transaction signatures
|
||||
(TSIG). That is, the ``allow-update`` option should list only TSIG key
|
||||
(TSIG). That is, the :any:`allow-update` option should list only TSIG key
|
||||
names, not IP addresses or network prefixes. Alternatively, the
|
||||
``update-policy`` option can be used.
|
||||
:any:`update-policy` option can be used.
|
||||
|
||||
Some sites choose to keep all dynamically updated DNS data in a
|
||||
subdomain and delegate that subdomain to a separate zone. This way, the
|
||||
|
||||
@ -47,10 +47,10 @@ was implemented in BIND as of release 9.14.0.
|
||||
|
||||
As a result, some domains may be non-resolvable without manual
|
||||
intervention. In these cases, resolution can be restored by adding
|
||||
``server`` clauses for the offending servers, or by specifying ``edns no`` or
|
||||
:namedconf:ref:`server` clauses for the offending servers, or by specifying ``edns no`` or
|
||||
``send-cookie no``, depending on the specific noncompliance.
|
||||
|
||||
To determine which ``server`` clause to use, run the following commands
|
||||
To determine which :namedconf:ref:`server` clause to use, run the following commands
|
||||
to send queries to the authoritative servers for the broken domain:
|
||||
|
||||
::
|
||||
@ -85,11 +85,11 @@ to make :iscman:`named` prepare such a file, set the ``SSLKEYLOGFILE``
|
||||
environment variable to either:
|
||||
|
||||
- the string ``config`` (``SSLKEYLOGFILE=config``); this requires
|
||||
defining a ``logging`` :ref:`channel <logging_grammar>` which will
|
||||
defining a :any:`logging` :ref:`channel <logging_grammar>` which will
|
||||
handle messages belonging to the ``sslkeylog`` category,
|
||||
|
||||
- the path to the key file to write (``SSLKEYLOGFILE=/path/to/file``);
|
||||
this is equivalent to the following ``logging`` :ref:`stanza
|
||||
this is equivalent to the following :any:`logging` :ref:`stanza
|
||||
<logging_grammar>`:
|
||||
|
||||
::
|
||||
@ -105,7 +105,7 @@ environment variable to either:
|
||||
.. note::
|
||||
|
||||
When using ``SSLKEYLOGFILE=config``, augmenting the log channel
|
||||
output using options like ``print-time`` or ``print-severity`` is
|
||||
output using options like :any:`print-time` or :any:`print-severity` is
|
||||
strongly discouraged as it will likely make the key log file
|
||||
unusable.
|
||||
|
||||
|
||||
@ -96,14 +96,14 @@ 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 ``primaries``
|
||||
For example, a key may be specified for each server in the :any:`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
|
||||
the ``also-notify`` statement of a primary or secondary zone, causing NOTIFY
|
||||
the :any:`also-notify` statement of a primary or secondary zone, causing NOTIFY
|
||||
messages to be signed using the specified key.
|
||||
|
||||
Keys can also be specified in a ``server`` directive. Adding the
|
||||
Keys can also be specified in a :namedconf:ref:`server` directive. Adding the
|
||||
following on ``host1``, if the IP address of ``host2`` is 10.1.2.3, would
|
||||
cause *all* requests from ``host1`` to ``host2``, including normal DNS
|
||||
queries, to be signed using the ``host1-host2.`` key:
|
||||
@ -114,7 +114,7 @@ queries, to be signed using the ``host1-host2.`` key:
|
||||
keys { host1-host2. ;};
|
||||
};
|
||||
|
||||
Multiple keys may be present in the ``keys`` statement, but only the
|
||||
Multiple keys may be present in the :any:`keys` statement, but only the
|
||||
first one is used. As this directive does not contain secrets, it can be
|
||||
used in a world-readable file.
|
||||
|
||||
@ -129,10 +129,10 @@ TSIG-Based Access Control
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
TSIG keys may be specified in ACL definitions and ACL directives such as
|
||||
``allow-query``, ``allow-transfer``, and ``allow-update``. The above key
|
||||
:any:`allow-query`, :any:`allow-transfer`, and :any:`allow-update`. The above key
|
||||
would be denoted in an ACL element as ``key host1-host2.``
|
||||
|
||||
Here is an example of an ``allow-update`` directive using a TSIG key:
|
||||
Here is an example of an :any:`allow-update` directive using a TSIG key:
|
||||
|
||||
::
|
||||
|
||||
@ -143,7 +143,7 @@ from an address in ``localnets``, *and* if it is signed using the
|
||||
``host1-host2.`` key.
|
||||
|
||||
See :ref:`dynamic_update_policies` for a
|
||||
discussion of the more flexible ``update-policy`` statement.
|
||||
discussion of the more flexible :any:`update-policy` statement.
|
||||
|
||||
Errors
|
||||
~~~~~~
|
||||
|
||||
@ -38,7 +38,7 @@ The components of a Resource Record are:
|
||||
owner name
|
||||
The domain name where the RR is found.
|
||||
|
||||
type
|
||||
RR type
|
||||
An encoded 16-bit value that specifies the type of the resource record.
|
||||
For a list of *types* of valid RRs, including those that have been obsoleted, please refer to
|
||||
`https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4`.
|
||||
|
||||
@ -342,7 +342,7 @@ In contrast, for a small zone the difference is operationally negligible
|
||||
and the drawbacks outweigh the benefits.
|
||||
|
||||
If NSEC3 opt-out is truly essential for a zone, the following
|
||||
configuration can be added to ``dnssec-policy``; for example, to create an
|
||||
configuration can be added to :any:`dnssec-policy`; for example, to create an
|
||||
NSEC3 chain using the SHA-1 hash algorithm, with the opt-out flag,
|
||||
no additional iterations, and no extra salt, use:
|
||||
|
||||
@ -883,7 +883,7 @@ roll over DNSKEYs to a new algorithm, e.g., from RSASHA1 (algorithm 5 or
|
||||
7) to RSASHA256 (algorithm 8). The algorithm rollover steps must be followed with
|
||||
care to avoid breaking DNSSEC validation.
|
||||
|
||||
If you are managing DNSSEC by using the ``dnssec-policy`` configuration,
|
||||
If you are managing DNSSEC by using the :any:`dnssec-policy` configuration,
|
||||
:iscman:`named` handles the rollover for you. Simply change the algorithm
|
||||
for the relevant keys, and :iscman:`named` uses the new algorithm when the
|
||||
key is next rolled. It performs a smooth transition to the new
|
||||
@ -900,9 +900,9 @@ In any case, the first step is to put DNSKEYs in place using the new algorithm.
|
||||
You must generate the ``K*`` files for the new algorithm and put
|
||||
them in the zone's key directory, where :iscman:`named` can access them. Take
|
||||
care to set appropriate ownership and permissions on the keys. If the
|
||||
``auto-dnssec`` zone option is set to ``maintain``, :iscman:`named`
|
||||
:any:`auto-dnssec` zone option is set to ``maintain``, :iscman:`named`
|
||||
automatically signs the zone with the new keys, based on their timing
|
||||
metadata when the ``dnssec-loadkeys-interval`` elapses or when you issue the
|
||||
metadata when the :any:`dnssec-loadkeys-interval` elapses or when you issue the
|
||||
:option:`rndc loadkeys` command. Otherwise, for primary zones, you can use
|
||||
:iscman:`nsupdate` to add the new DNSKEYs to the zone; this causes :iscman:`named`
|
||||
to use them to sign the zone. For secondary zones, e.g., on a
|
||||
@ -924,7 +924,7 @@ so that the old DS records disappear from all resolver caches.
|
||||
The next step is to remove the DNSKEYs using the old algorithm from your
|
||||
zone. Again this can be accomplished using :iscman:`nsupdate` to delete the
|
||||
old DNSKEYs (for primary zones only) or by automatic key rollover when
|
||||
``auto-dnssec`` is set to ``maintain``. You can cause the automatic key
|
||||
:any:`auto-dnssec` is set to ``maintain``. You can cause the automatic key
|
||||
rollover to take place immediately by using the :iscman:`dnssec-settime`
|
||||
utility to set the *Delete* date on all keys to any time in the past.
|
||||
(See the :option:`dnssec-settime -D date/offset <dnssec-settime -D>` option.)
|
||||
|
||||
@ -149,7 +149,7 @@ Can I use the same key for multiple zones?
|
||||
logins. First, categorize your zones: high-value zones (or zones that have
|
||||
specific key rollover requirements) get their own key pairs, while other,
|
||||
more "generic" zones can use a single key pair for easier management. Note that
|
||||
at present (mid-2020), fully automatic signing (using the ``dnssec-policy``
|
||||
at present (mid-2020), fully automatic signing (using the :any:`dnssec-policy`
|
||||
clause in your :iscman:`named` configuration file) does not support reuse of keys
|
||||
except when the same zone appears in multiple views (see next question).
|
||||
To use the same key for multiple zones, sign your
|
||||
@ -157,7 +157,7 @@ Can I use the same key for multiple zones?
|
||||
should point to the same key directory.
|
||||
|
||||
How do I sign the different instances of a zone that appears in multiple views?
|
||||
Add a ``dnssec-policy`` statement to each ``zone`` definition in the
|
||||
Add a :any:`dnssec-policy` statement to each :any:`zone` definition in the
|
||||
configuration file. To avoid problems when a single computer accesses
|
||||
different instances of the zone while information is still in its cache
|
||||
(e.g., a laptop moving from your office to a customer site), you
|
||||
@ -167,6 +167,6 @@ How do I sign the different instances of a zone that appears in multiple views?
|
||||
|
||||
Will there be any problems if I change the DNSSEC policy for a zone?
|
||||
If you are using fully automatic signing, no. Just change the parameters in the
|
||||
``dnssec-policy`` statement and reload the configuration file. :iscman:`named`
|
||||
:any:`dnssec-policy` statement and reload the configuration file. :iscman:`named`
|
||||
makes a smooth transition to the new policy, ensuring that your zone
|
||||
remains valid at all times.
|
||||
|
||||
@ -53,7 +53,7 @@ on them.
|
||||
|
||||
Using the method described in
|
||||
:ref:`easy_start_guide_for_authoritative_servers`, we just need to
|
||||
add a ``dnssec-policy`` statement to the relevant zone clause. This is
|
||||
add a :any:`dnssec-policy` statement to the relevant zone clause. This is
|
||||
what the :iscman:`named.conf` zone statement looks like on the primary server, 192.168.1.1:
|
||||
|
||||
::
|
||||
@ -167,7 +167,7 @@ like this:
|
||||
Rollovers
|
||||
~~~~~~~~~
|
||||
|
||||
If you are signing your zone using a ``dnssec-policy`` statement, this
|
||||
If you are signing your zone using a :any:`dnssec-policy` statement, this
|
||||
section is not really relevant to you. In the policy statement, you set how long
|
||||
you want your keys to be valid for, the time
|
||||
taken for information to propagate through your zone, the time it takes
|
||||
@ -246,7 +246,7 @@ Make sure the successor keys are readable by :iscman:`named`.
|
||||
|
||||
:iscman:`named`'s logging messages indicate when the next
|
||||
key checking event is scheduled to occur, the frequency of which can be
|
||||
controlled by ``dnssec-loadkeys-interval``. The log message looks like
|
||||
controlled by :any:`dnssec-loadkeys-interval`. The log message looks like
|
||||
this:
|
||||
|
||||
::
|
||||
@ -323,7 +323,7 @@ the new ZSK is in effect:
|
||||
|
||||
These are all the manual tasks you need to perform for a ZSK rollover.
|
||||
If you have followed the configuration examples in this guide of using
|
||||
``inline-signing`` and ``auto-dnssec``, everything else is automated for
|
||||
:any:`inline-signing` and :any:`auto-dnssec`, everything else is automated for
|
||||
you by BIND.
|
||||
|
||||
Day of ZSK Rollover
|
||||
@ -503,7 +503,7 @@ one to keep the output small and hopefully clearer.
|
||||
|
||||
Make sure the successor keys are readable by :iscman:`named`.
|
||||
|
||||
The ``syslog`` message indicates when the next key
|
||||
The :any:`syslog` message indicates when the next key
|
||||
checking event is. The log message looks like this:
|
||||
|
||||
::
|
||||
@ -793,7 +793,7 @@ according to the steps described in
|
||||
NSEC3 will fall back to treating the zone as unsecured (rather than
|
||||
"bogus"), as described in Section 2 of :rfc:`5155`.
|
||||
|
||||
To enable NSEC3, update your ``dnssec-policy`` and add the desired NSEC3
|
||||
To enable NSEC3, update your :any:`dnssec-policy` and add the desired NSEC3
|
||||
parameters. The example below enables NSEC3 for zones with the ``standard``
|
||||
DNSSEC policy, using 0 additional iterations, no opt-out, and a zero-length salt:
|
||||
|
||||
@ -836,8 +836,8 @@ parameters, please see :ref:`advanced_discussions_nsec3param`.
|
||||
Migrating from NSEC3 to NSEC
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Migrating from NSEC3 back to NSEC is easy; just remove the ``nsec3param``
|
||||
configuration option from your ``dnssec-policy`` and reconfigure the name
|
||||
Migrating from NSEC3 back to NSEC is easy; just remove the :any:`nsec3param`
|
||||
configuration option from your :any:`dnssec-policy` and reconfigure the name
|
||||
server. You can tell that it worked if you see these messages in the log:
|
||||
|
||||
::
|
||||
@ -997,7 +997,7 @@ Here is what :iscman:`named.conf` looks like when it is signed:
|
||||
dnssec-policy "default";
|
||||
};
|
||||
|
||||
To indicate the reversion to unsigned, change the ``dnssec-policy`` line:
|
||||
To indicate the reversion to unsigned, change the :any:`dnssec-policy` line:
|
||||
|
||||
.. code-block:: none
|
||||
:emphasize-lines: 4
|
||||
@ -1075,6 +1075,6 @@ After a while, the zone is reverted back to the traditional, insecure DNS
|
||||
format. This can be verified by checking that all DNSKEY and RRSIG records have been
|
||||
removed from the zone.
|
||||
|
||||
The ``dnssec-policy`` line can then be removed from :iscman:`named.conf` and
|
||||
The :any:`dnssec-policy` line can then be removed from :iscman:`named.conf` and
|
||||
the zone reloaded. The zone will no longer be subject to any DNSSEC
|
||||
maintenance.
|
||||
|
||||
@ -53,7 +53,7 @@ Enabling Automated DNSSEC Zone Maintenance and Key Generation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To sign a zone, add the following statement to its
|
||||
``zone`` clause in the BIND 9 configuration file:
|
||||
:any:`zone` clause in the BIND 9 configuration file:
|
||||
|
||||
::
|
||||
|
||||
@ -69,7 +69,7 @@ To sign a zone, add the following statement to its
|
||||
...
|
||||
};
|
||||
|
||||
The ``dnssec-policy`` statement causes the zone to be signed and turns
|
||||
The :any:`dnssec-policy` statement causes the zone to be signed and turns
|
||||
on automatic maintenance for the zone. This includes re-signing the zone
|
||||
as signatures expire and replacing keys on a periodic basis. The value
|
||||
``default`` selects the default policy, which contains values suitable
|
||||
@ -86,13 +86,13 @@ reload the configuration file by running :option:`rndc reconfig`:
|
||||
|
||||
And that's it - BIND signs your zone.
|
||||
|
||||
At this point, before you go away and merrily add ``dnssec-policy``
|
||||
At this point, before you go away and merrily add :any:`dnssec-policy`
|
||||
statements to all your zones, we should mention that, like a number of
|
||||
other BIND configuration options, its scope depends on where it is placed. In
|
||||
the example above, we placed it in a ``zone`` clause, so it applied only
|
||||
to the zone in question. If we had placed it in a ``view`` clause, it
|
||||
the example above, we placed it in a :any:`zone` clause, so it applied only
|
||||
to the zone in question. If we had placed it in a :any:`view` clause, it
|
||||
would have applied to all zones in the view; and if we had placed it in
|
||||
the ``options`` clause, it would have applied to all zones served by
|
||||
the :namedconf:ref:`options` clause, it would have applied to all zones served by
|
||||
this instance of BIND.
|
||||
|
||||
.. _signing_verification:
|
||||
@ -143,8 +143,8 @@ simulate what a validating resolver will check, by telling
|
||||
:iscman:`delv` to use a specific trust anchor.
|
||||
|
||||
First, we need to make a copy of the key created by BIND. This
|
||||
is in the directory you set with the ``directory`` statement in
|
||||
your configuration file's ``options`` clause, and is named something
|
||||
is in the directory you set with the :any:`directory` statement in
|
||||
your configuration file's :namedconf:ref:`options` clause, and is named something
|
||||
like ``Kexample.com.+013.10376.key``:
|
||||
|
||||
::
|
||||
@ -161,7 +161,7 @@ and comments omitted):
|
||||
...
|
||||
example.com. 3600 IN DNSKEY 257 3 13 6saiq99qDB...dqp+o0dw==
|
||||
|
||||
We want to edit the copy to be in the ``trust-anchors`` format, so that
|
||||
We want to edit the copy to be in the :any:`trust-anchors` format, so that
|
||||
it looks like this:
|
||||
|
||||
::
|
||||
@ -637,7 +637,7 @@ That is quite complex, and it is all handled in BIND 9 with the single
|
||||
setting up our own DNSSEC policy with customized parameters. However, in many
|
||||
cases the defaults are adequate.
|
||||
|
||||
At the time of this writing (mid-2020), ``dnssec-policy`` is still a
|
||||
At the time of this writing (mid-2020), :any:`dnssec-policy` is still a
|
||||
relatively new feature in BIND. Although it is the preferred
|
||||
way to run DNSSEC in a zone, it is not yet able to automatically implement
|
||||
all the features that are available
|
||||
@ -729,7 +729,7 @@ you are not already familiar with DNSSEC, it may be worth reading that chapter
|
||||
first.
|
||||
|
||||
Setting up your own DNSSEC policy means that you must include a
|
||||
``dnssec-policy`` clause in the zone file. This sets values for the
|
||||
:any:`dnssec-policy` clause in the zone file. This sets values for the
|
||||
various parameters that affect the signing of zones and the rolling of
|
||||
keys. The following is an example of such a clause:
|
||||
|
||||
@ -759,7 +759,7 @@ The policy has multiple parts:
|
||||
done by giving each policy a name, such as ``standard`` in the above
|
||||
example.
|
||||
|
||||
- The ``keys`` clause lists all keys that should be in the zone, along
|
||||
- The :any:`keys` clause lists all keys that should be in the zone, along
|
||||
with their associated parameters. In this example, we are using the
|
||||
conventional KSK/ZSK split, with the KSK changed every year and the
|
||||
ZSK changed every two months (the ``default`` DNSSEC policy sets a
|
||||
@ -787,15 +787,15 @@ The policy has multiple parts:
|
||||
|
||||
- The parameters ending in ``-safety`` are there to give
|
||||
you a bit of leeway in case a key roll doesn't go to plan. When
|
||||
introduced into the zone, the ``publish-safety`` time is the amount
|
||||
introduced into the zone, the :any:`publish-safety` time is the amount
|
||||
of additional time, over and above that calculated from the other
|
||||
parameters, during which the new key is in the zone but before BIND starts
|
||||
to sign records with it. Similarly, the ``retire-safety`` is the
|
||||
to sign records with it. Similarly, the :any:`retire-safety` is the
|
||||
amount of additional time, over and above that calculated from the
|
||||
other parameters, during which the old key is retained in the zone before
|
||||
being removed.
|
||||
|
||||
- Finally, the ``purge-keys`` option allows you to clean up key files
|
||||
- Finally, the :any:`purge-keys` option allows you to clean up key files
|
||||
automatically after a period of time. If a key has been removed from the
|
||||
zone, this option will determine how long its key files will be retained
|
||||
on disk.
|
||||
@ -813,10 +813,10 @@ during the process.
|
||||
Having defined a new policy called "standard", we now need to tell
|
||||
:iscman:`named` to use it. We do this by adding a ``dnssec-policy standard;``
|
||||
statement to the configuration file. Like many other configuration
|
||||
statements, it can be placed in the ``options`` statement (thus applying
|
||||
to all zones on the server), a ``view`` statement (applying to all zones
|
||||
in the view), or a ``zone`` statement (applying only to that zone). In
|
||||
this example, we'll add it to the ``zone`` statement:
|
||||
statements, it can be placed in the :namedconf:ref:`options` statement (thus applying
|
||||
to all zones on the server), a :any:`view` statement (applying to all zones
|
||||
in the view), or a :any:`zone` statement (applying only to that zone). In
|
||||
this example, we'll add it to the :any:`zone` statement:
|
||||
|
||||
::
|
||||
|
||||
@ -892,7 +892,7 @@ CDS and a CDNSKEY record for the key in question to the apex of the
|
||||
zone. If your parent zone supports polling for CDS/CDNSKEY records, they
|
||||
are uploaded and the DS record published in the parent - at least ideally.
|
||||
|
||||
If BIND is configured with ``parental-agents``, it will check for the DS
|
||||
If BIND is configured with :any:`parental-agents`, it will check for the DS
|
||||
presence. Let's look at the following configuration excerpt:
|
||||
|
||||
::
|
||||
@ -943,10 +943,10 @@ to tell :iscman:`named` that the DS record has been published.
|
||||
Alternate Ways of Signing a Zone
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Although use of the automatic ``dnssec-policy`` is the preferred way to sign zones in
|
||||
Although use of the automatic :any:`dnssec-policy` is the preferred way to sign zones in
|
||||
BIND, there are occasions where a more manual approach may be
|
||||
needed, such as when external hardware is used to
|
||||
generate and sign the zone. ``dnssec-policy`` does not currently support
|
||||
generate and sign the zone. :any:`dnssec-policy` does not currently support
|
||||
the use of external hardware, so if your security policy requires it, you
|
||||
need to use one of the methods described here.
|
||||
|
||||
@ -987,15 +987,15 @@ Manual
|
||||
|
||||
Semi-Automatic
|
||||
The first step in DNSSEC automation came with BIND 9.7, when the
|
||||
``auto-dnssec`` option was added. This causes :iscman:`named` to
|
||||
:any:`auto-dnssec` option was added. This causes :iscman:`named` to
|
||||
periodically search the directory holding the key files (see
|
||||
:ref:`generate_keys` for a description) and to
|
||||
use the information in them to both add and remove keys and sign the
|
||||
zone.
|
||||
|
||||
Use of ``auto-dnssec`` alone requires that the zone be dynamic,
|
||||
Use of :any:`auto-dnssec` alone requires that the zone be dynamic,
|
||||
something not suitable for a number of situations, so BIND 9.9 added the
|
||||
``inline-signing`` option. With this, :iscman:`named` essentially keeps the
|
||||
:any:`inline-signing` option. With this, :iscman:`named` essentially keeps the
|
||||
signed and unsigned copies of the zone separate. The signed zone is
|
||||
created from the unsigned one using the key information; when the
|
||||
unsigned zone is updated and the zone reloaded, :iscman:`named` detects the
|
||||
@ -1026,11 +1026,11 @@ Fully Automatic with ``dnssec-keymgr``
|
||||
determine when to add and remove keys, and when to sign with them.
|
||||
|
||||
In BIND 9.17.0 and later, this method of handling DNSSEC
|
||||
policies has been replaced by the ``dnssec-policy`` statement in the
|
||||
policies has been replaced by the :any:`dnssec-policy` statement in the
|
||||
configuration file.
|
||||
|
||||
Fully Automatic with ``dnssec-policy``
|
||||
Introduced a BIND 9.16, ``dnssec-policy`` replaces ``dnssec-keymgr`` from BIND
|
||||
Fully Automatic with :any:`dnssec-policy`
|
||||
Introduced a BIND 9.16, :any:`dnssec-policy` replaces ``dnssec-keymgr`` from BIND
|
||||
9.17 onwards and avoids the need to run a separate program. It also
|
||||
handles the creation of keys if a zone is added (``dnssec-keymgr``
|
||||
requires an initial key) and deletes old key files as they are
|
||||
@ -1040,7 +1040,7 @@ Fully Automatic with ``dnssec-policy``
|
||||
We now look at some of these methods in more detail. We cover
|
||||
semi-automatic signing first, as that contains a lot of useful
|
||||
information about keys and key timings. After that, we
|
||||
touch on fully automatic signing with ``dnssec-policy``. Since this has
|
||||
touch on fully automatic signing with :any:`dnssec-policy`. Since this has
|
||||
already been described in
|
||||
:ref:`easy_start_guide_for_authoritative_servers`, we will just
|
||||
mention a few additional points. Finally, we briefly describe manual signing.
|
||||
@ -1051,15 +1051,15 @@ Semi-Automatic Signing
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
As noted above, the term semi-automatic signing has been used in this
|
||||
document to indicate the mode of signing enabled by the ``auto-dnssec``
|
||||
and ``inline-signing`` keywords. :iscman:`named` signs the zone without any
|
||||
document to indicate the mode of signing enabled by the :any:`auto-dnssec`
|
||||
and :any:`inline-signing` keywords. :iscman:`named` signs the zone without any
|
||||
manual intervention, based purely on the timing information in the
|
||||
DNSSEC key files. The files, however, must be created manually.
|
||||
|
||||
By appropriately setting the key parameters and the timing information
|
||||
in the key files, you can implement any DNSSEC policy you want for your
|
||||
zones. But why manipulate the key information yourself rather than rely
|
||||
on ``dnssec-policy`` to do it for you? The answer
|
||||
on :any:`dnssec-policy` to do it for you? The answer
|
||||
is that semi-automatic signing allows you to do things that, at the time of this writing
|
||||
(mid-2020), are currently not possible with one of the key managers: for
|
||||
example, the ability to use an HSM to store keys, or the ability to use
|
||||
@ -1347,19 +1347,19 @@ before a rollover depends on your organization's security policy.
|
||||
|
||||
.. _advanced_discussions_automatic_dnssec-policy:
|
||||
|
||||
Fully Automatic Signing With ``dnssec-policy``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Fully Automatic Signing With :any:`dnssec-policy`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Since BIND 9.16, key management is fully integrated ingo :iscman:`named`.
|
||||
Managing the signing process and rolling of these keys has been described in
|
||||
:ref:`easy_start_guide_for_authoritative_servers` and is not
|
||||
repeated here. A few points are worth noting, though:
|
||||
|
||||
- The ``dnssec-policy`` statement in the :iscman:`named` configuration file
|
||||
- The :any:`dnssec-policy` statement in the :iscman:`named` configuration file
|
||||
describes all aspects of the DNSSEC policy, including the signing.
|
||||
|
||||
- When using ``dnssec-policy``, there is no need to set the
|
||||
``auto-dnssec`` and ``inline-signing`` options for a zone. The zone's
|
||||
- When using :any:`dnssec-policy`, there is no need to set the
|
||||
:any:`auto-dnssec` and :any:`inline-signing` options for a zone. The zone's
|
||||
``policy`` statement implicitly does this.
|
||||
|
||||
.. _advanced_discussions_manual_key_management_and_signing:
|
||||
|
||||
@ -148,7 +148,7 @@ DNSSEC errors.
|
||||
Basic Logging
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
DNSSEC validation error messages show up in ``syslog`` as a
|
||||
DNSSEC validation error messages show up in :any:`syslog` as a
|
||||
query error by default. Here is an example of what it may look like:
|
||||
|
||||
::
|
||||
@ -173,11 +173,11 @@ logging is thus not recommended for production servers.
|
||||
|
||||
With that said, sometimes it may become necessary to temporarily enable
|
||||
BIND debug logging to see more details of how and whether DNSSEC is
|
||||
validating. DNSSEC-related messages are not recorded in ``syslog`` by default,
|
||||
even if query log is enabled; only DNSSEC errors show up in ``syslog``.
|
||||
validating. DNSSEC-related messages are not recorded in :any:`syslog` by default,
|
||||
even if query log is enabled; only DNSSEC errors show up in :any:`syslog`.
|
||||
|
||||
The example below shows how to enable debug level 3 (to see full DNSSEC
|
||||
validation messages) in BIND 9 and have it sent to ``syslog``:
|
||||
validation messages) in BIND 9 and have it sent to :any:`syslog`:
|
||||
|
||||
::
|
||||
|
||||
@ -205,7 +205,7 @@ The example below shows how to log DNSSEC messages to their own file
|
||||
|
||||
After turning on debug logging and restarting BIND, a large
|
||||
number of log messages appear in
|
||||
``syslog``. The example below shows the log messages as a result of
|
||||
:any:`syslog`. The example below shows the log messages as a result of
|
||||
successfully looking up and validating the domain name ``ftp.isc.org``.
|
||||
|
||||
::
|
||||
@ -279,7 +279,7 @@ Below is an example attempting to resolve the A record for a test domain
|
||||
name ``www.example.net``. From the user's perspective, as described in
|
||||
:ref:`how_do_i_know_validation_problem`, only a SERVFAIL
|
||||
message is returned. On the validating resolver, we see the
|
||||
following messages in ``syslog``:
|
||||
following messages in :any:`syslog`:
|
||||
|
||||
::
|
||||
|
||||
@ -404,7 +404,7 @@ Unable to Load Keys
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This is a simple yet common issue. If the key files are present but
|
||||
unreadable by :iscman:`named` for some reason, the ``syslog`` returns clear error
|
||||
unreadable by :iscman:`named` for some reason, the :any:`syslog` returns clear error
|
||||
messages, as shown below:
|
||||
|
||||
::
|
||||
@ -415,7 +415,7 @@ messages, as shown below:
|
||||
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521
|
||||
|
||||
However, if no keys are found, the error is not as obvious. Below shows
|
||||
the ``syslog`` messages after executing ``rndc
|
||||
the :any:`syslog` messages after executing ``rndc
|
||||
reload`` with the key files missing from the key directory:
|
||||
|
||||
::
|
||||
@ -463,7 +463,7 @@ Invalid Trust Anchors
|
||||
|
||||
In most cases, you never need to explicitly configure trust
|
||||
anchors. :iscman:`named` supplies the current root trust anchor and,
|
||||
with the default setting of ``dnssec-validation``, updates it on the
|
||||
with the default setting of :any:`dnssec-validation`, updates it on the
|
||||
infrequent occasions when it is changed.
|
||||
|
||||
However, in some circumstances you may need to explicitly configure
|
||||
|
||||
@ -40,7 +40,7 @@ described in :ref:`how_to_test_recursive_server`.
|
||||
|
||||
In earlier versions of BIND, including 9.11-ESV, DNSSEC
|
||||
validation must be explicitly enabled. To do this, you only need to
|
||||
add one line to the ``options`` section of your configuration file:
|
||||
add one line to the :namedconf:ref:`options` section of your configuration file:
|
||||
|
||||
::
|
||||
|
||||
@ -280,7 +280,7 @@ name fails:
|
||||
;; MSG SIZE rcvd: 78
|
||||
|
||||
On the other hand, if DNSSEC validation is disabled (by adding the
|
||||
statement ``dnssec-validation no;`` to the ``options`` clause in the
|
||||
statement ``dnssec-validation no;`` to the :namedconf:ref:`options` clause in the
|
||||
configuration file), the lookup succeeds:
|
||||
|
||||
::
|
||||
@ -372,8 +372,8 @@ take a closer look at what DNSSEC validation actually does, and some other optio
|
||||
|
||||
.. _dnssec_validation_explained:
|
||||
|
||||
``dnssec-validation``
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
:any:`dnssec-validation`
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
::
|
||||
|
||||
@ -382,9 +382,9 @@ take a closer look at what DNSSEC validation actually does, and some other optio
|
||||
};
|
||||
|
||||
This “auto” line enables automatic DNSSEC trust anchor configuration
|
||||
using the ``managed-keys`` feature. In this case, no manual key
|
||||
using the :any:`managed-keys` feature. In this case, no manual key
|
||||
configuration is needed. There are three possible choices for the
|
||||
``dnssec-validation`` option:
|
||||
:any:`dnssec-validation` option:
|
||||
|
||||
- *yes*: DNSSEC validation is enabled, but a trust anchor must be
|
||||
manually configured. No validation actually takes place until
|
||||
@ -396,11 +396,11 @@ configuration is needed. There are three possible choices for the
|
||||
- *auto*: DNSSEC validation is enabled, and a default trust anchor
|
||||
(included as part of BIND 9) for the DNS root zone is used. This is the
|
||||
default; BIND automatically does this if there is no
|
||||
``dnssec-validation`` line in the configuration file.
|
||||
:any:`dnssec-validation` line in the configuration file.
|
||||
|
||||
Let's discuss the difference between *yes* and *auto*. If set to
|
||||
*yes*, the trust anchor must be manually defined and maintained
|
||||
using the ``trust-anchors`` statement (with either the ``static-key`` or
|
||||
using the :any:`trust-anchors` statement (with either the ``static-key`` or
|
||||
``static-ds`` modifier) in the configuration file; if set to
|
||||
*auto* (the default, and as shown in the example), then no further
|
||||
action should be required as BIND includes a copy [#]_ of the root key.
|
||||
@ -565,7 +565,7 @@ the client.
|
||||
.. [#]
|
||||
BIND technically includes two copies of the root key: one is in
|
||||
``bind.keys.h`` and is built into the executable, and one is in
|
||||
``bind.keys`` as a ``trust-anchors`` statement. The two copies of the
|
||||
``bind.keys`` as a :any:`trust-anchors` statement. The two copies of the
|
||||
key are identical.
|
||||
|
||||
.. _trust_anchors_description:
|
||||
@ -649,7 +649,7 @@ anchor) configured. How did it get here, and how do we maintain it?
|
||||
|
||||
If you followed the recommendation in
|
||||
:ref:`easy_start_guide_for_recursive_servers`, by setting
|
||||
``dnssec-validation`` to *auto*, there is nothing left to do.
|
||||
:any:`dnssec-validation` to *auto*, there is nothing left to do.
|
||||
BIND already includes a copy of the root key (in the file
|
||||
``bind.keys``), and automatically updates it when the root key
|
||||
changes. [#]_ It looks something like this:
|
||||
@ -668,7 +668,7 @@ changes. [#]_ It looks something like this:
|
||||
};
|
||||
|
||||
You can, of course, decide to manage this key manually yourself.
|
||||
First, you need to make sure that ``dnssec-validation`` is set
|
||||
First, you need to make sure that :any:`dnssec-validation` is set
|
||||
to *yes* rather than *auto*:
|
||||
|
||||
::
|
||||
@ -679,7 +679,7 @@ to *yes* rather than *auto*:
|
||||
|
||||
Then, download the root key manually from a trustworthy source, such as
|
||||
`<https://www.isc.org/bind-keys>`__. Finally, take the root key you
|
||||
manually downloaded and put it into a ``trust-anchors`` statement as
|
||||
manually downloaded and put it into a :any:`trust-anchors` statement as
|
||||
shown below:
|
||||
|
||||
::
|
||||
@ -695,7 +695,7 @@ shown below:
|
||||
R1AkUTV74bU=";
|
||||
};
|
||||
|
||||
While this ``trust-anchors`` statement and the one in the ``bind.keys``
|
||||
While this :any:`trust-anchors` statement and the one in the ``bind.keys``
|
||||
file appear similar, the definition of the key in ``bind.keys`` has the
|
||||
``initial-key`` modifier, whereas in the statement in the configuration
|
||||
file, that is replaced by ``static-key``. There is an important
|
||||
|
||||
@ -284,7 +284,7 @@ When using GSS\-TSIG, this command specifies the use of \fBrealm_name\fP rather
|
||||
in \fBkrb5.conf\fP\&. If no realm is specified, the saved realm is
|
||||
cleared.
|
||||
.TP
|
||||
.B \fBcheck\-names [yes_or_no]\fP
|
||||
.B \fBcheck\-names [boolean]\fP
|
||||
This command turns on or off check\-names processing on records to be added.
|
||||
Check\-names has no effect on prerequisites or records to be deleted.
|
||||
By default check\-names processing is on. If check\-names processing
|
||||
|
||||
@ -32,7 +32,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||||
rndc \- name server control utility
|
||||
.SH SYNOPSIS
|
||||
.sp
|
||||
\fBrndc\fP [\fB\-b\fP source\-address] [\fB\-c\fP config\-file] [\fB\-k\fP key\-file] [\fB\-s\fP server] [\fB\-p\fP port] [\fB\-q\fP] [\fB\-r\fP] [\fB\-V\fP] [\fB\-y\fP key_id] [[\fB\-4\fP] | [\fB\-6\fP]] {command}
|
||||
\fBrndc\fP [\fB\-b\fP source\-address] [\fB\-c\fP config\-file] [\fB\-k\fP key\-file] [\fB\-s\fP server] [\fB\-p\fP port] [\fB\-q\fP] [\fB\-r\fP] [\fB\-V\fP] [\fB\-y\fP server_key] [[\fB\-4\fP] | [\fB\-6\fP]] {command}
|
||||
.SH DESCRIPTION
|
||||
.sp
|
||||
\fBrndc\fP controls the operation of a name server. If \fBrndc\fP is
|
||||
@ -47,7 +47,7 @@ algorithms are HMAC\-MD5 (for compatibility), HMAC\-SHA1, HMAC\-SHA224,
|
||||
HMAC\-SHA256 (default), HMAC\-SHA384, and HMAC\-SHA512. They use a shared
|
||||
secret on each end of the connection, which provides TSIG\-style
|
||||
authentication for the command request and the name server\(aqs response.
|
||||
All commands sent over the channel must be signed by a key_id known to
|
||||
All commands sent over the channel must be signed by a server_key known to
|
||||
the server.
|
||||
.sp
|
||||
\fBrndc\fP reads a configuration file to determine how to contact the name
|
||||
@ -119,9 +119,9 @@ This option enables verbose logging.
|
||||
.UNINDENT
|
||||
.INDENT 0.0
|
||||
.TP
|
||||
.B \-y key_id
|
||||
This option indicates use of the key \fBkey_id\fP from the configuration file. For control message validation to succeed, \fBkey_id\fP must be known
|
||||
by \fI\%named\fP with the same algorithm and secret string. If no \fBkey_id\fP is specified,
|
||||
.B \-y server_key
|
||||
This option indicates use of the key \fBserver_key\fP from the configuration file. For control message validation to succeed, \fBserver_key\fP must be known
|
||||
by \fI\%named\fP with the same algorithm and secret string. If no \fBserver_key\fP is specified,
|
||||
\fBrndc\fP first looks for a key clause in the server statement of
|
||||
the server being used, or if no server statement is present for that
|
||||
host, then in the default\-key clause of the options statement. Note that
|
||||
@ -706,7 +706,7 @@ zone. To specify a redirect zone, use the special zone name
|
||||
would specify a zone called "\-redirect".)
|
||||
.SH LIMITATIONS
|
||||
.sp
|
||||
There is currently no way to provide the shared secret for a \fBkey_id\fP
|
||||
There is currently no way to provide the shared secret for a \fBserver_key\fP
|
||||
without using the configuration file.
|
||||
.sp
|
||||
Several error messages could be clearer.
|
||||
|
||||
@ -29,11 +29,11 @@ New Features
|
||||
- Catalog Zones schema version 2, as described in the
|
||||
"DNS Catalog Zones" IETF draft version 5 document, is now supported by
|
||||
:iscman:`named`. All of the previously supported BIND-specific catalog
|
||||
zone custom properties (``primaries``, ``allow-query``, and
|
||||
``allow-transfer``), as well as the new Change of Ownership (``coo``)
|
||||
zone custom properties (:any:`primaries`, :any:`allow-query`, and
|
||||
:any:`allow-transfer`), as well as the new Change of Ownership (``coo``)
|
||||
property, are now implemented. Schema version 1 is still supported,
|
||||
with some additional validation rules applied from schema version 2:
|
||||
for example, the ``version`` property is mandatory, and a member zone
|
||||
for example, the :any:`version` property is mandatory, and a member zone
|
||||
PTR RRset must not contain more than one record. In the event of a
|
||||
validation error, a corresponding error message is logged to help with
|
||||
diagnosing the problem. :gl:`#3221` :gl:`#3222` :gl:`#3223`
|
||||
|
||||
@ -15,14 +15,14 @@ Notes for BIND 9.19.2
|
||||
Feature Changes
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
- New ``dnssec-policy`` configuration checks have been added to detect
|
||||
- New :any:`dnssec-policy` configuration checks have been added to detect
|
||||
unusual policies, such as missing KSK and/or ZSK and too-short key
|
||||
lifetimes and re-sign periods. :gl:`#1611`
|
||||
|
||||
Bug Fixes
|
||||
~~~~~~~~~
|
||||
|
||||
- The ``fetches-per-server`` quota is designed to adjust itself downward
|
||||
- The :any:`fetches-per-server` quota is designed to adjust itself downward
|
||||
automatically when an authoritative server times out too frequently.
|
||||
Due to a coding error, that adjustment was applied incorrectly, so
|
||||
that the quota for a congested server was always set to 1. This has
|
||||
@ -31,7 +31,7 @@ Bug Fixes
|
||||
- DNSSEC-signed catalog zones were not being processed correctly. This
|
||||
has been fixed. :gl:`#3380`
|
||||
|
||||
- Key files were updated every time the ``dnssec-policy`` key manager
|
||||
- Key files were updated every time the :any:`dnssec-policy` key manager
|
||||
ran, whether the metadata had changed or not. :iscman:`named` now
|
||||
checks whether changes were applied before writing out the key files.
|
||||
:gl:`#3302`
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user