mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

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

Browse Source 
Resolve "Additional text edits to BIND ARM"

Closes #1925

See merge request isc-projects/bind9!3800
This commit is contained in:
Ondřej Surý
2020-07-03 07:20:48 +00:00
parent 494d1246eb 4cd6be18d3
commit ee5b77ccb0
7 changed files with 116 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/arm/general.rst
View File

@@ -37,7 +37,7 @@ identifier is the address of an individual interface on a given network;
in IPv6, addresses belong to interfaces rather than to machines.
The subnetting capability of IPv6 is much more flexible than that of
IPv4: subnetting can be carried out on bit boundaries, in much the same
IPv4; subnetting can be carried out on bit boundaries, in much the same
way as Classless InterDomain Routing (CIDR), and the DNS PTR
representation ("nibble" format) makes setting up reverse zones easier.
@@ -45,7 +45,7 @@ The interface identifier must be unique on the local link, and is
usually generated automatically by the IPv6 implementation, although it
is usually possible to override the default setting if necessary. A
typical IPv6 address might look like:
``2001:db8:201:9:a00:20ff:fe81:2b32``
``2001:db8:201:9:a00:20ff:fe81:2b32``.
IPv6 address specifications often contain long strings of zeros, so the
architects have included a shorthand for specifying them. The double
@@ -72,7 +72,7 @@ Specification documents for the Internet protocol suite, including the
DNS, are published as part of the Request for Comments (RFCs) series of
technical notes. The standards themselves are defined by the Internet
Engineering Task Force (IETF) and the Internet Engineering Steering
Group (IESG). RFCs can be viewed online at: https://datatracker.ietf.org/doc/.
Group (IESG). RFCs can be viewed online at: https://datatracker.ietf.org/doc/ .
Some of these RFCs, though DNS-related, are not concerned with implementing
software.

10
doc/arm/history.rst
View File

@@ -46,7 +46,8 @@ and Mike Schwartz. BIND maintenance was subsequently handled by Mike
Karels and Øivind Kure.
BIND versions 4.9 and 4.9.1 were released by Digital Equipment
Corporation (now Compaq Computer Corporation). Paul Vixie, then a DEC
Corporation (which became Compaq Computer Corporation and eventually merged
with Hewlett-Packard). Paul Vixie, then a DEC
employee, became BIND's primary caretaker. He was assisted by Phil
Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew
Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran,
@@ -57,7 +58,7 @@ In 1994, BIND version 4.9.2 was sponsored by Vixie Enterprises. Paul
Vixie became BIND's principal architect/programmer.
BIND versions from 4.9.3 onward have been developed and maintained by
the Internet Systems Consortium and its predecessor, the Internet
Internet Systems Consortium and its predecessor, the Internet
Software Consortium, with support provided by ISC's sponsors.
As co-architects/programmers, Bob Halley and Paul Vixie released the
@@ -70,5 +71,6 @@ BIND versions 4 and 8 are officially deprecated. No additional
development is done on BIND version 4 or BIND version 8.
BIND development work is made possible today by the sponsorship of
corporations who purchase professional support services from ISC (https://www.isc.org/contact/) and/or donate to our mission, and by the tireless efforts of numerous
individuals.
corporations who purchase professional support services from ISC
(https://www.isc.org/contact/) and/or donate to our mission, and by the
tireless efforts of numerous individuals.

1
doc/arm/manpages.rst
View File

@@ -35,6 +35,7 @@ Manual Pages
.. include:: ../../bin/tools/named-journalprint.rst
.. include:: ../../bin/tools/named-nzd2nzf.rst
.. include:: ../../bin/tools/named-rrchecker.rst
.. include:: ../../bin/named/named.conf.rst
.. include:: ../../bin/named/named.rst
.. include:: ../../bin/tools/nsec3hash.rst
.. include:: ../../bin/dig/nslookup.rst

8
doc/arm/notes.rst
View File

@@ -20,13 +20,13 @@ BIND 9.17 is an unstable development release of BIND. This document
summarizes new features and functional changes that have been introduced
on this branch. With each development release leading up to the stable
BIND 9.18 release, this document will be updated with additional
features added and bugs fixed. Please see the file CHANGES for a more
features added and bugs fixed. Please see the CHANGES file for a more
detailed list of changes and bug fixes.
Supported Platforms
-------------------
To build on UNIX-like systems, BIND requires support for POSIX.1c
To build on Unix-like systems, BIND requires support for POSIX.1c
threads (IEEE Std 1003.1c-1995), the Advanced Sockets API for IPv6
(:rfc:`3542`), and standard atomic operations provided by the C
compiler.
@@ -82,8 +82,8 @@ End of Life
BIND 9.17 is an unstable development branch. When its development is
complete, it will be renamed to BIND 9.18, which will be a stable
branch. The end of life date for BIND 9.18 has not yet been determined.
For those needing long term support, the current Extended Support
branch. The end-of-life date for BIND 9.18 has not yet been determined.
For those needing long-term stability, the current Extended Support
Version (ESV) is BIND 9.11, which will be supported until at least
December 2021. See https://kb.isc.org/docs/aa-00896 for details of
ISC's software support policy.

154
doc/arm/reference.rst
View File

@@ -5057,10 +5057,10 @@ Zone Types
^^^^^^^^^^
The ``type`` keyword is required for the ``zone`` configuration unless
it is an ``in-view`` configuration. Its acceptable values include:
it is an ``in-view`` configuration. Its acceptable values are:
``primary`` (or ``master``), ``secondary`` (or ``slave``), ``mirror``,
``delegation-only``, ``forward``, ``hint``, ``redirect``,
``static-stub``, and ``stub``.
``hint``, ``stub``, ``static-stub``, ``forward``, ``redirect``,
or ``delegation-only``.
``primary``
A primary zone has a master copy of the data for the zone and is able
@@ -5071,7 +5071,7 @@ it is an ``in-view`` configuration. Its acceptable values include:
A secondary zone is a replica of a primary zone. Type ``slave`` is a
synonym for ``secondary``. The ``primaries`` list specifies one or more IP
addresses of primary servers that the secondary contacts to update
its copy of the zone. Primaires list elements can
its copy of the zone. Primaries list elements can
also be names of other primaries lists. By default,
transfers are made from port 53 on the servers;
this can be changed for all servers by specifying
@@ -5118,7 +5118,6 @@ it is an ``in-view`` configuration. Its acceptable values include:
servers for the IANA root zone is built into ``named`` and thus its mirroring
can be enabled using the following configuration:
::
zone "." {
@@ -5134,9 +5133,8 @@ it is an ``in-view`` configuration. Its acceptable values include:
To make mirror zone contents persist between ``named`` restarts, use the
:ref:`file <file-option>` option.
When configuring NOTIFY for a mirror zone, only ``notify no;`` and ``notify
explicit;`` can be used at the zone level. Using any other ``notify``
explicit;`` can be used at the zone level; any other ``notify``
setting at the zone level is a configuration error. Using any other
``notify`` setting at the ``options`` or ``view`` level causes that
setting to be overridden with ``notify explicit;`` for the mirror zone. The
@@ -5147,7 +5145,7 @@ it is an ``in-view`` configuration. Its acceptable values include:
enabled using :ref:`allow-transfer <allow-transfer-access>`.
.. note::
Using this zone type with any zone other than the root zone should
Use of this zone type with any zone other than the root should
be considered *experimental* and may cause performance issues, especially
for zones which are large and/or frequently updated.
@@ -5167,11 +5165,12 @@ it is an ``in-view`` configuration. Its acceptable values include:
Stub zones can be used to eliminate the need for a glue NS record in a parent
zone, at the expense of maintaining a stub zone entry and a set of name
server addresses in ``named.conf``. This usage is not recommended for
new configurations, and BIND 9 supports it only in a limited way. If a BIND 9 primary, serving a parent zone, has child stub
new configurations, and BIND 9 supports it only in a limited way. If a BIND 9
primary, serving a parent zone, has child stub
zones configured, all the secondary servers for the parent zone also need to
have the same child stub zones configured.
Stub zones can also be used as a way of forcing the resolution of a given
Stub zones can also be used as a way to force the resolution of a given
domain to use a particular set of authoritative servers. For example, the
caching name servers on a private network using :rfc:`1918` addressing may be
configured with stub zones for ``10.in-addr.arpa`` to use a set of
@@ -5182,7 +5181,7 @@ it is an ``in-view`` configuration. Its acceptable values include:
exceptions: the zone data is statically configured, rather than
transferred from a primary server; and when recursion is necessary for a query
that matches a static-stub zone, the locally configured data (name server
names and glue addresses) are always used, even if different authoritative
names and glue addresses) is always used, even if different authoritative
information is cached.
Zone data is configured via the ``server-addresses`` and ``server-names``
@@ -5212,7 +5211,7 @@ it is an ``in-view`` configuration. Its acceptable values include:
for the domain, canceling the effects of any forwarders in the ``options``
statement. Thus, to use this type of zone to change the
behavior of the global ``forward`` option (that is, "forward first" to,
then "forward only", or vice versa), but using the same servers as set
then "forward only", or vice versa), but use the same servers as set
globally, re-specify the global forwarders.
``redirect``
@@ -5227,8 +5226,8 @@ it is an ``in-view`` configuration. Its acceptable values include:
To redirect all NXDOMAIN responses to 100.100.100.2 and
2001:ffff:ffff::100.100.100.2, configure a type ``redirect`` zone
named ".", with the zone file containing wildcard records that point to
the desired addresses: ``"*. IN A 100.100.100.2"`` and
``"*. IN AAAA 2001:ffff:ffff::100.100.100.2"``.
the desired addresses: ``*. IN A 100.100.100.2`` and
``*. IN AAAA 2001:ffff:ffff::100.100.100.2``.
As another example, to redirect all Spanish names (under .ES), use similar entries
but with the names ``*.ES.`` instead of ``*.``. To redirect all commercial
@@ -5260,6 +5259,17 @@ it is an ``in-view`` configuration. Its acceptable values include:
See caveats in :ref:`root-delegation-only <root-delegation-only>`.
``in-view``
When using multiple views, a ``primary`` or ``secondary`` zone configured
in one view can be referenced in a subsequent view. This allows both views
to use the same zone without the overhead of loading it more than once. This
is configured using a ``zone`` statement, with an ``in-view`` option
specifying the view in which the zone is defined. A ``zone`` statement
containing ``in-view`` does not need to specify a type, since that is part
of the zone definition in the other view.
See :ref:`multiple_views` for more information.
Class
^^^^^
@@ -5316,7 +5326,7 @@ Zone Options
This option is used to restrict the character set and syntax of
certain domain names in primary files and/or DNS responses received
from the network. The default varies according to zone type. For
``primary`` zones the default is ``fail``. For ``secondary`` zones the
``primary`` zones the default is ``fail``; for ``secondary`` zones the
default is ``warn``. It is not implemented for ``hint`` zones.
``check-mx``
@@ -5353,14 +5363,14 @@ Zone Options
See the description of ``try-tcp-refresh`` in :ref:`boolean_options`.
``database``
This specifies the type of database to be used for storing the zone data.
This specifies the type of database to be used to store the zone data.
The string following the ``database`` keyword is interpreted as a
list of whitespace-delimited words. The first word identifies the
database type, and any subsequent words are passed as arguments to
the database to be interpreted in a way specific to the database
type.
The default is ``"rbt"``, BIND 9's native in-memory red-black tree
The default is ``rbt``, BIND 9's native in-memory red-black tree
database. This database does not take arguments.
Other values are possible if additional database drivers have been
@@ -5458,15 +5468,15 @@ Zone Options
2001:db8::1234.
``server-names``
This is only meaningful for static-stub zones. This is a list of domain names
This option is only meaningful for static-stub zones. This is a list of domain names
of name servers that act as authoritative servers of the static-stub
zone. These names are resolved to IP addresses when ``named``
needs to send queries to these servers. To make this supplemental
resolution successful, these names must not be a subdomain of the
needs to send queries to these servers. For this supplemental
resolution to be successful, these names must not be a subdomain of the
origin name of the static-stub zone. That is, when "example.net" is the
origin of a static-stub zone, "ns.example" and "master.example.com"
can be specified in the ``server-names`` option, but "ns.example.net"
cannot, and is rejected by the configuration parser.
cannot; it is rejected by the configuration parser.
A non-empty list for this option internally configures the apex
NS RR with the specified names. For example, if "example.com" is
@@ -5519,7 +5529,7 @@ Zone Options
``notify-source-v6``
See the description of ``notify-source-v6`` in :ref:`zone_transfers`.
``min-refresh-time``; \ ``max-refresh-time``; \ ``min-retry-time``; \ ``max-retry-time``
``min-refresh-time``; ``max-refresh-time``; ``min-retry-time``; ``max-retry-time``
See the descriptions in :ref:`tuning`.
``ixfr-from-differences``
@@ -5538,7 +5548,7 @@ Zone Options
``inline-signing``
If ``yes``, this enables "bump in the wire" signing of a zone, where
a unsigned zone is transferred in or loaded from disk and a signed
an unsigned zone is transferred in or loaded from disk and a signed
version of the zone is served with, possibly, a different serial
number. This behavior is disabled by default.
@@ -5628,7 +5638,7 @@ field), and the type of the record to be updated matches the ``types``
field. Details for each rule type are described below.
The ``identity`` field must be set to a fully qualified domain name. In
most cases, this represensts the name of the TSIG or SIG(0) key that
most cases, this represents the name of the TSIG or SIG(0) key that
must be used to sign the update request. If the specified name is a
wildcard, it is subject to DNS wildcard expansion, and the rule may
apply to multiple identities. When a TKEY exchange has been used to
@@ -5637,11 +5647,11 @@ TKEY exchange is used as the identity of the shared secret. Some
rule types use identities matching the client's Kerberos principal (e.g,
``"host/machine@REALM"``) or Windows realm (``machine$@REALM``).
The name field also specifies a fully qualified domain name. This often
The ``name`` field also specifies a fully qualified domain name. This often
represents the name of the record to be updated. Interpretation of this
field is dependent on rule type.
If no types are explicitly specified, then a rule matches all types
If no ``types`` are explicitly specified, then a rule matches all types
except RRSIG, NS, SOA, NSEC, and NSEC3. Types may be specified by name,
including ``ANY``; ANY matches all types except NSEC and NSEC3, which can
never be updated. Note that when an attempt is made to delete all
@@ -5673,27 +5683,27 @@ Typical use with a rule ``grant * tcp-self . PTR(1);`` in the zone
send
EOF
The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
``self``, ``selfsub``, ``selfwild``, ``krb5-self``, ``ms-self``,
``krb5-selfsub``, ``ms-selfsub``, ``krb5-subdomain``, ``ms-subdomain``,
``tcp-self``, ``6to4-self``, ``zonesub``, and ``external``.
The ruletype field has 16 values: ``name``, ``subdomain``, ``zonesub``, ``wildcard``,
``self``, ``selfsub``, ``selfwild``, ``ms-self``, ``ms-selfsub``, ``ms-subdomain``,
``krb5-self``, ``krb5-selfsub``, ``krb5-subdomain``,
``tcp-self``, ``6to4-self``, and ``external``.
``name``
With exact-match semantics, this rule matches when the name being updated is identical to the contents of the name field.
With exact-match semantics, this rule matches when the name being updated is identical to the contents of the ``name`` field.
``subdomain``
This rule matches when the name being updated is a subdomain of, or identical to, the contents of the name field.
This rule matches when the name being updated is a subdomain of, or identical to, the contents of the ``name`` field.
``zonesub``
This rule is similar to subdomain, except that it matches when the name being updated is a subdomain of the zone in which the ``update-policy`` statement appears. This obviates the need to type the zone name twice, and enables the use of a standard ``update-policy`` statement in multiple zones without modification.
When this rule is used, the name field is omitted.
When this rule is used, the ``name`` field is omitted.
``wildcard``
The name field is subject to DNS wildcard expansion, and this rule matches when the name being updated is a valid expansion of the wildcard.
The ``name`` field is subject to DNS wildcard expansion, and this rule matches when the name being updated is a valid expansion of the wildcard.
``self``
This rule matches when the name of the record being updated matches the contents of the identity field. The name field is ignored. To avoid confusion, it is recommended that this field be set to the same value as the identity field or to "."
The ``self`` rule type is most useful when allowing one key per name to update, where the key has the same name as the record to be updated. In this case, the identity field can be specified as ``*`` (asterisk).
This rule matches when the name of the record being updated matches the contents of the ``identity`` field. The ``name`` field is ignored. To avoid confusion, it is recommended that this field be set to the same value as the ``identity`` field or to "."
The ``self`` rule type is most useful when allowing one key per name to update, where the key has the same name as the record to be updated. In this case, the ``identity`` field can be specified as ``*`` (asterisk).
``selfsub``
This rule is similar to ``self``, except that subdomains of ``self`` can also be updated.
@@ -5704,9 +5714,9 @@ The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
``ms-self``
When a client sends an UPDATE using a Windows machine principal (for example, ``machine$@REALM``), this rule allows records with the absolute name of ``machine.REALM`` to be updated.
The realm to be matched is specified in the identity field.
The realm to be matched is specified in the ``identity`` field.
The name field has no effect on this rule; it should be set to "." as a placeholder.
The ``name`` field has no effect on this rule; it should be set to "." as a placeholder.
For example, ``grant EXAMPLE.COM ms-self . A AAAA`` allows any machine with a valid principal in the realm ``EXAMPLE.COM`` to update its own address records.
@@ -5716,18 +5726,18 @@ The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
``ms-subdomain``
When a client sends an UPDATE using a Windows machine principal (for example, ``machine$@REALM``), this rule allows any machine in the specified realm to update any record in the zone or in a specified subdomain of the zone.
The realm to be matched is specified in the identity field.
The realm to be matched is specified in the ``identity`` field.
The name field specifies the subdomain that may be updated. If set to "." or any other name at or above the zone apex, any name in the zone can be updated.
The ``name`` field specifies the subdomain that may be updated. If set to "." or any other name at or above the zone apex, any name in the zone can be updated.
For example, if ``update-policy`` for the zone "example.com" includes ``grant EXAMPLE.COM ms-subdomain hosts.example.com. AA AAAA``, any machine with a valid principal in the realm ``EXAMPLE.COM`` is able to update address records at or below ``hosts.example.com``.
``krb5-self``
When a client sends an UPDATE using a Kerberos machine principal (for example, ``host/machine@REALM``), this rule allows records with the absolute name of ``machine`` to be updated, provided it has been authenticated by REALM. This is similar but not identical to ``ms-self``, due to the ``machine`` part of the Kerberos principal being an absolute name instead of a unqualified name.
When a client sends an UPDATE using a Kerberos machine principal (for example, ``host/machine@REALM``), this rule allows records with the absolute name of ``machine`` to be updated, provided it has been authenticated by REALM. This is similar but not identical to ``ms-self``, due to the ``machine`` part of the Kerberos principal being an absolute name instead of an unqualified name.
The realm to be matched is specified in the identity field.
The realm to be matched is specified in the ``identity`` field.
The name field has no effect on this rule; it should be set to "." as a placeholder.
The ``name`` field has no effect on this rule; it should be set to "." as a placeholder.
For example, ``grant EXAMPLE.COM krb5-self . A AAAA`` allows any machine with a valid principal in the realm ``EXAMPLE.COM`` to update its own address records.
@@ -5738,7 +5748,7 @@ The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
This rule is identical to ``ms-subdomain``, except that it works with Kerberos machine principals (i.e., ``host/machine@REALM``) rather than Windows machine principals.
``tcp-self``
This rule allows updates that have been sent via TCP and for which the standard mapping from the client's IP address into the ``in-addr.arpa`` and ``ip6.arpa`` namespaces match the name to be updated. The ``identity`` field must match that name. The ``name`` field should be set to ".". Note that, since identity is based on the client's IP address, it is not necessary for update request messages to be signed.
This rule allows updates that have been sent via TCP and for which the standard mapping from the client's IP address into the ``in-addr.arpa`` and ``ip6.arpa`` namespaces matches the name to be updated. The ``identity`` field must match that name. The ``name`` field should be set to ".". Note that, since identity is based on the client's IP address, it is not necessary for update request messages to be signed.
.. note::
It is theoretically possible to spoof these TCP sessions.
@@ -5756,7 +5766,7 @@ The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
``external``
This rule allows ``named`` to defer the decision of whether to allow a given update to an external daemon.
The method of communicating with the daemon is specified in the identity field, the format of which is "``local:``\ path", where "path" is the location of a Unix-domain socket. (Currently, "local" is the only supported mechanism.)
The method of communicating with the daemon is specified in the ``identity`` field, the format of which is "``local:``\ path", where "path" is the location of a Unix-domain socket. (Currently, "local" is the only supported mechanism.)
Requests to the external daemon are sent over the Unix-domain socket as datagrams with the following format:
@@ -5776,7 +5786,7 @@ The ruletype field has 16 values: ``name``, ``subdomain``, ``wildcard``,
.. _multiple_views:
Multiple views
Multiple Views
^^^^^^^^^^^^^^
When multiple views are in use, a zone may be referenced by more than
@@ -5784,7 +5794,7 @@ one of them. Often, the views contain different zones with the same
name, allowing different clients to receive different answers for the
same queries. At times, however, it is desirable for multiple views to
contain identical zones. The ``in-view`` zone option provides an
efficient way to do this: it allows a view to reference a zone that was
efficient way to do this; it allows a view to reference a zone that was
defined in a previously configured view. For example:
::
@@ -5793,7 +5803,7 @@ defined in a previously configured view. For example:
match-clients { 10/8; };
zone example.com {
type master;
type primary;
file "example-external.db";
};
};
@@ -5814,9 +5824,9 @@ other options, with the exception of ``forward`` and ``forwarders``.
(These options control the behavior of the containing view, rather than
change the zone object itself.)
Zone level ACLs (e.g., allow-query, allow-transfer), and other
Zone-level ACLs (e.g., allow-query, allow-transfer), and other
configuration details of the zone, are all set in the view the referenced
zone is defined in. Care needs to be taken to ensure that ACLs are wide
zone is defined in. Be careful to ensure that ACLs are wide
enough for all views referencing the zone.
An ``in-view`` zone cannot be used as a response policy zone.
@@ -5862,7 +5872,7 @@ TTL
The time-to-live of the RR. This field is a 32-bit integer in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded.
class
An encoded 16-bit value that identifies a protocol family or instance of a protocol.
An encoded 16-bit value that identifies a protocol family or an instance of a protocol.
RDATA
The resource data. The format of the data is type- and sometimes class-specific.
@@ -5890,7 +5900,7 @@ being described.
The TTL field is a time limit on how long an RR can be
kept in a cache. This limit does not apply to authoritative data in
zones; it is also timed out, but by the refreshing policies for the
zones; that also times out, but follows the refreshing policies for the
zone. The TTL is assigned by the administrator for the zone where the
data originates. While short TTLs can be used to minimize caching, and a
zero TTL prohibits caching, the realities of Internet performance
@@ -5905,7 +5915,7 @@ binary strings and domain names. The domain names are frequently used as
.. _rr_text:
Textual expression of RRs
Textual Expression of RRs
^^^^^^^^^^^^^^^^^^^^^^^^^
RRs are represented in binary form in the packets of the DNS protocol,
@@ -5952,7 +5962,7 @@ format to contain a 32-bit Internet address.
The above example shows six RRs, with two RRs at each of three domain
names.
Here's another possible example:
Here is another possible example:
+----------------------+---------------+-------------------------------+
| ``XX.LCS.MIT.EDU.`` | ``IN A`` | ``10.0.0.44`` |
@@ -5985,7 +5995,7 @@ falls back to the next largest priority. Priority numbers do not
have any absolute meaning; they are relevant only respective to other
MX records for that domain name. The domain name given is the machine to
which the mail is delivered. It *must* have an associated address
record (A or AAAA) — CNAME is not sufficient.
record (A or AAAA); CNAME is not sufficient.
For a given domain, if there is both a CNAME record and an MX record,
the MX record is in error and is ignored. Instead, the mail is
@@ -6005,7 +6015,7 @@ CNAME. For example:
+------------------------+--------+--------+--------------+------------------------+
Mail delivery is attempted to ``mail.example.com`` and
``mail2.example.com`` (in any order); if neither of those succeed,
``mail2.example.com`` (in any order); if neither of those succeeds,
delivery to ``mail.backup.org`` is attempted.
.. _Setting_TTLs:
@@ -6013,10 +6023,10 @@ delivery to ``mail.backup.org`` is attempted.
Setting TTLs
~~~~~~~~~~~~
The time-to-live of the RR field is a 32-bit integer represented in
The time-to-live (TTL) of the RR field is a 32-bit integer represented in
units of seconds, and is primarily used by resolvers when they cache
RRs. The TTL describes how long a RR can be cached before it should be
discarded. The following three types of TTL are currently used in a zone
RRs. The TTL describes how long an RR can be cached before it should be
discarded. The following three types of TTLs are currently used in a zone
file.
SOA
@@ -6091,7 +6101,7 @@ Syntax: ``$ORIGIN`` domain-name [comment]
``$ORIGIN`` sets the domain name that is appended to any
unqualified records. When a zone is first read, there is an implicit
``$ORIGIN`` <``zone_name``>\ ``.``, followed by a trailing dot. The
``$ORIGIN`` <``zone_name``>``.``; note the trailing dot. The
current ``$ORIGIN`` is appended to the domain specified in the
``$ORIGIN`` argument if it is not absolute.
@@ -6135,21 +6145,21 @@ The ``$TTL`` Directive
Syntax: ``$TTL`` default-ttl [comment]
This sets the default Time To Live (TTL) for subsequent records with undefined
This sets the default Time-To-Live (TTL) for subsequent records with undefined
TTLs. Valid TTLs are of the range 0-2147483647 seconds.
``$TTL`` is defined in :rfc:`2308`.
.. _generate_directive:
BIND Master File Extension: the ``$GENERATE`` Directive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BIND Primary File Extension: the ``$GENERATE`` Directive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Syntax: ``$GENERATE`` range lhs [ttl] [class] type rhs [comment]
``$GENERATE`` is used to create a series of resource records that only
differ from each other by an iterator. ``$GENERATE`` can be used to
easily generate the sets of records required to support sub /24 reverse
easily generate the sets of records required to support sub-/24 reverse
delegations described in :rfc:`2317`.
::
@@ -6199,7 +6209,7 @@ is equivalent to
``owner``
This describes the owner name of the resource records to be created. Any single ``$`` (dollar sign) symbols within the ``owner`` string are replaced by the iterator value. To get a ``$`` in the output, escape the ``$`` using a backslash ``\``, e.g., ``\$``. The ``$`` may optionally be followed by modifiers which change the offset from the iterator, field width, and base.
Modifiers are introduced by a ``{`` (left brace) immediately following the ``$`` as in ``${offset[,width[,base]]}``. For example, ``${-20,3,d}`` subtracts 20 from the current value and prints the result as a decimal in a zero-padded field of width 3. Available output forms are decimal (``d``), octal (``o``), hexadecimal (``x`` or ``X`` for uppercase), and nibble (``n`` or ``N`` for uppercase).
Modifiers are introduced by a ``{`` (left brace) immediately following the ``$``, as in ``${offset[,width[,base]]}``. For example, ``${-20,3,d}`` subtracts 20 from the current value and prints the result as a decimal in a zero-padded field of width 3. Available output forms are decimal (``d``), octal (``o``), hexadecimal (``x`` or ``X`` for uppercase), and nibble (``n`` or ``N`` for uppercase).
The default modifier is ``${0,0,d}``. If the ``owner`` is not absolute, the current ``$ORIGIN`` is appended to the name.
@@ -6306,9 +6316,9 @@ Cache DB RRsets
nonexistent. Counters named for RR types indicate the number of active
RRsets for each type in the cache database.
If an RR type name is preceded by an exclamation mark (!), it represents the
If an RR type name is preceded by an exclamation point (!), it represents the
number of records in the cache which indicate that the type does not exist
for a particular name (this is also known as "NXRRSET"). If an RR type name
for a particular name; this is also known as "NXRRSET". If an RR type name
is preceded by a hash mark (#), it represents the number of RRsets for this
type that are present in the cache but whose TTLs have expired; these RRsets
may only be used if stale answers are enabled. If an RR type name is
@@ -6329,7 +6339,7 @@ view name is omitted when the server is not configured with explicit
views.
There are currently two user interfaces to get access to the statistics.
One is in the plain text format dumped to the file specified by the
One is in plain-text format, dumped to the file specified by the
``statistics-file`` configuration option; the other is remotely
accessible via a statistics channel when the ``statistics-channels``
statement is specified in the configuration file (see :ref:`statschannels`.)
@@ -6528,16 +6538,16 @@ Zone Maintenance Statistics Counters
This indicates the number of IPv6 SOA queries sent.
``AXFRReqv4``
This indicates the requested IPv4 AXFR.
This indicates the number of requested IPv4 AXFRs.
``AXFRReqv6``
This indicates the requested IPv6 AXFR.
This indicates the number of requested IPv6 AXFRs.
``IXFRReqv4``
This indicates the requested IPv4 IXFR.
This indicates the number of requested IPv4 IXFRs.
``IXFRReqv6``
This indicates the requested IPv6 IXFR.
This indicates the number of requested IPv6 IXFRs.
``XfrSuccess``
This indicates the number of successful zone transfer requests.

26
doc/arm/security.rst
View File

@@ -24,7 +24,7 @@ and nicknamed for future use in ``allow-notify``, ``allow-query``,
``allow-transfer``, ``match-clients``, etc.
ACLs give users finer control over who can access the
name server, without cluttering up config files with huge lists of
name server, without cluttering up configuration files with huge lists of
IP addresses.
It is a *good idea* to use ACLs, and to control access.
@@ -33,8 +33,8 @@ spoofing and denial of service (DoS) attacks against the server.
ACLs match clients on the basis of up to three characteristics: 1) The
client's IP address; 2) the TSIG or SIG(0) key that was used to sign the
request, if any; and 3) an address prefix encoded in an EDNS Client
Subnet option, if any.
request, if any; and 3) an address prefix encoded in an EDNS
Client-Subnet option, if any.
Here is an example of ACLs based on client addresses:
@@ -62,7 +62,7 @@ Here is an example of ACLs based on client addresses:
};
zone "example.com" {
type master;
type primary;
file "m/example.com";
allow-query { any; };
};
@@ -88,7 +88,7 @@ are ``country``, ``region``, ``city``, ``continent``, ``postal`` (postal code),
if it contains spaces or other special characters. An ``asnum`` search for
autonomous system number can be specified using the string "ASNNNN" or the
integer NNNN. If a ``country`` search is specified with a string that is two characters
long, it must be a standard ISO-3166-1 two-letter country code; otherwise
long, it must be a standard ISO-3166-1 two-letter country code; otherwise,
it is interpreted as the full name of the country. Similarly, if
``region`` is the search term and the string is two characters long, it is treated as a
standard two-letter state or province abbreviation; otherwise, it is treated as the
@@ -118,7 +118,7 @@ Some example GeoIP ACLs:
geoip tz "America/Los_Angeles";
geoip org "Internet Systems Consortium";
ACLs use a "first-match" logic rather than "best-match": if an address
ACLs use a "first-match" logic rather than "best-match"; if an address
prefix matches an ACL element, then that ACL is considered to have
matched even if a later element would have matched more specifically.
For example, the ACL ``{ 10/8; !10.0.0.1; }`` would actually match a
@@ -129,7 +129,7 @@ When using "nested" ACLs (that is, ACLs included or referenced within
other ACLs), a negative match of a nested ACL tells the containing ACL to
continue looking for matches. This enables complex ACLs to be
constructed, in which multiple client characteristics can be checked at
the same time. For example, to construct an ACL which allows queries
the same time. For example, to construct an ACL which allows a query
only when it originates from a particular network *and* only when it is
signed with a particular key, use:
@@ -156,7 +156,7 @@ On Unix servers, it is possible to run BIND in a *chrooted* environment
"sandbox," which limits the damage done if a server is compromised.
Another useful feature in the Unix version of BIND is the ability to run
the daemon as an unprivileged user ( ``-u`` user ). We suggest running
the daemon as an unprivileged user (``-u`` user). We suggest running
as an unprivileged user when using the ``chroot`` feature.
Here is an example command line to load BIND in a ``chroot`` sandbox,
@@ -207,7 +207,7 @@ 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
insecure since the source address of the update UDP packet is easily
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
performs forwarding of dynamic updates, the primary can be trivially
@@ -218,10 +218,10 @@ 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
names, not IP addresses or network prefixes. Alternatively, the new
names, not IP addresses or network prefixes. Alternatively, the
``update-policy`` option can be used.
Some sites choose to keep all dynamically-updated DNS data in a
Some sites choose to keep all dynamically updated DNS data in a
subdomain and delegate that subdomain to a separate zone. This way, the
top-level zone containing critical data such as the IP addresses of
public web and mail servers need not allow dynamic updates at all.
top-level zone containing critical data, such as the IP addresses of
public web and mail servers, need not allow dynamic updates at all.

6
doc/arm/troubleshooting.rst
View File

@@ -46,7 +46,7 @@ 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, specifying ``edns no`` or
``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
@@ -72,7 +72,7 @@ Incrementing and Changing the Serial Number
Zone serial numbers are just numbers — they are not date-related. However, many
people set them to a number that represents a date, usually of the
form YYYYMMDDRR. Occasionally they will make a mistake and set the serial number to a
form YYYYMMDDRR. Occasionally they make a mistake and set the serial number to a
date in the future, then try to correct it by setting it to the
current date. This causes problems because serial numbers are used to
indicate that a zone has been updated. If the serial number on the secondary
@@ -97,7 +97,7 @@ peer user support. In addition, ISC maintains a Knowledgebase of helpful article
at https://kb.isc.org.
Internet Systems Consortium (ISC) offers annual support agreements
for BIND 9, ISC DHCP and Kea DHCP.
for BIND 9, ISC DHCP, and Kea DHCP.
All paid support contracts include advance security notifications; some levels include
service level agreements (SLAs), premium software features, and increased priority on bug fixes
and feature requests.