journal file. This file is automatically created by the server when the
first dynamic update takes place. The name of the journal file is formed
by appending the extension ``.jnl`` to the name of the corresponding
-zone file, unless specifically overridden. The journal file is in a
+zone file unless specifically overridden. The journal file is in a
binary format and should not be edited manually.
The server also occasionally writes ("dumps") the complete contents
RSASHA256 and ECDSAP256SHA256; ECDSAP256SHA256 is recommended for
current and future deployments.
-The following command generates a ECDSAP256SHA256 key for the
+The following command generates an ECDSAP256SHA256 key for the
``child.example`` zone:
``dnssec-keygen -a ECDSAP256SHA256 -n ZONE child.example.``
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
+resulting name. For example, the following commands produce a reverse name
lookup for a host with address ``2001:db8::1``:
::
To use the catalog zone feature to serve a new member zone:
-- Set up the the member zone to be served on the primary as normal. This
+- Set up the member zone to be served on the primary as normal. This
can be done by editing ``named.conf`` or by running
``rndc addzone``.
member zone name.
``zone-directory``
- This option causes local copies of member zones'
- 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.
+ This option causes local copies of member zones' 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.
``min-update-interval``
- This option sets the minimum interval between
- processing of updates to catalog zones, in seconds. If an update to a
- catalog zone (for example, via IXFR) happens less than
- ``min-update-interval`` seconds after the most recent update, the
- changes are not carried out until this interval has elapsed. The
- default is 5 seconds.
+ This option sets the minimum interval between updates to catalog
+ zones, in seconds. If an update to a catalog zone (for example, via
+ IXFR) happens less than ``min-update-interval`` seconds after the
+ most recent update, the changes are not carried out until this
+ 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
::
dlz other {
- database "dlopen driver.so args";
- search no;
+ database "dlopen driver.so args";
+ search no;
};
zone "." {
- type redirect;
- dlz other;
+ type redirect;
+ dlz other;
};
::
dlz other {
- database "dlopen driver.so example.nil";
+ database "dlopen driver.so example.nil";
};
Dynamic DNS Update Method
~~~~~~~~~~~~~~~~~~~~~~~~~
-To perform key rollovers via dynamic update, the ``K*``
+To perform key rollovers via a dynamic update, the ``K*``
files for the new keys must be added so that ``named`` can find them.
The new DNSKEY RRs can then be added via dynamic update. ``named`` then causes the
zone to be signed with the new keys; when the signing is complete, the
:rfc:`4398` - S. Josefsson. *Storing Certificates in the Domain Name System (DNS).* March 2006.
-:rfc:`4470` - S. Weiler and J. Ihren. *Minimally Covering NSEC Records and
+:rfc:`4470` - S. Weiler and J. Ihren. *Minimally covering NSEC Records and
DNSSEC On-line Signing.* April 2006. [5]
:rfc:`4509` - W. Hardaker. *Use of SHA-256 in DNSSEC Delegation Signer
[4] Compliance is with loading and serving of A6 records only. A6 records were moved
to the experimental category by :rfc:`3363`.
-[5] Minimally covering NSEC records are accepted but not generated.
+[5] Minimally Covering NSEC records are accepted but not generated.
[6] BIND 9 interoperates with correctly designed experiments.
Stealth Servers
^^^^^^^^^^^^^^^
-Usually, all of the zone's authoritative servers are listed in NS records
-in the parent zone. These NS records constitute a *delegation* of the
-zone from the parent. The authoritative servers are also listed in the
-zone file itself, at the *top level* or *apex* of the zone.
-Servers that are not in the parent's
-NS delegation can be listed in the zone's top-level NS records, but servers that are not present at the zone's top level
-cannot be listed in the parent's delegation.
+Usually, all of the zone's authoritative servers are listed in NS
+records in the parent zone. These NS records constitute a *delegation*
+of the zone from the parent. The authoritative servers are also listed
+in the zone file itself, at the *top level* or *apex* of the zone.
+Servers that are not in the parent's NS delegation can be listed in the
+zone's top-level NS records, but servers that are not present at the
+zone's top level cannot be listed in the parent's delegation.
A *stealth server* is a server that is authoritative for a zone but is
not listed in that zone's NS records. Stealth servers can be used for
Note: eventually ``named`` will have to stop treating such timeouts as due to :rfc:`1034` non-compliance and start treating it as plain packet loss. Falsely classifying packet loss as due to :rfc:`1034` non-compliance impacts DNSSEC validation, which requires EDNS for the DNSSEC records to be returned.
``general``
- Catch-all for many things that still are not classified into categories.
+ A catch-all for many things that still are not classified into categories.
``lame-servers``
Misconfigurations in remote servers, discovered by BIND 9 when trying to query those servers during resolution.
NSID options received from upstream servers.
``queries``
- Location where queries should be logged.
+ A location where queries should be logged.
At startup, specifying the category ``queries`` also enables query logging unless the ``querylog`` option has been specified.
https://github.com/opendnssec/SoftHSMv2. It is a software library
developed by the OpenDNSSEC project (https://www.opendnssec.org) which
provides a PKCS#11 interface to a virtual HSM, implemented in the form
-of a SQLite3 database on the local filesystem. It provides less security
+of an SQLite3 database on the local filesystem. It provides less security
than a true HSM, but it allows users to experiment with native PKCS#11
when an HSM is not available. SoftHSMv2 can be configured to use either
OpenSSL or the Botan library to perform cryptographic functions, but
For name server-intensive environments, there are two
configurations that may be used. The first is one where clients and any
-second-level internal name servers query a main name server, which has
+second-level internal name servers query the main name server, which has
enough memory to build a large cache; this approach minimizes the
bandwidth used by external name lookups. The second alternative is to
set up second-level internal name servers to make queries independently.
allow-query { !{ !10/8; any; }; key example; };
Within the nested ACL, any address that is *not* in the 10/8 network
-prefix is rejected, which terminates processing of the ACL.
+prefix is rejected, which terminates the processing of the ACL.
Any address that *is* in the 10/8 network prefix is accepted, but
this causes a negative match of the nested ACL, so the containing ACL
continues processing. The query is accepted if it is signed by
projects / thirdparty / bind9.git / commitdiff
