ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Remove trailing whitespace from all text files

Browse Source 
I've used the following command to remove the trailing whitespace for
all tracked text files:

git grep -Il '' | xargs sed -i 's/[ \t]*$//'
This commit is contained in:
Tom Krizek
2023-06-07 16:00:00 +02:00
parent 589752fc69
commit 5893debf46
87 changed files with 764 additions and 764 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/arm/dns-ops.inc.rst
View File

@@ -19,7 +19,7 @@ Name Server Operations
Tools for Use With the Name Server Daemon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes several indispensable diagnostic, administrative,
This section describes several indispensable diagnostic, administrative,
and monitoring tools available to the system administrator for
controlling and debugging the name server daemon.

104
doc/arm/intro-dns-bind.inc.rst
View File

@@ -14,14 +14,14 @@
The Domain Name System (DNS)
----------------------------
This is a brief description of the functionality and organization of the Domain Name System (DNS).
It is provided to familiarize users with the concepts involved, the (often confusing) terminology
used, and how all the parts fit together to form an operational system.
This is a brief description of the functionality and organization of the Domain Name System (DNS).
It is provided to familiarize users with the concepts involved, the (often confusing) terminology
used, and how all the parts fit together to form an operational system.
All network systems operate with network addresses, such as IPv4 and IPv6. The vast majority of
humans find it easier to work with names rather than seemingly endless strings of network address digits. The earliest ARPANET systems
(from which the Internet evolved) mapped names to addresses using a **hosts** file that was distributed to all entities
whenever changes occurred. Operationally, such a system became rapidly unsustainable once there were more
All network systems operate with network addresses, such as IPv4 and IPv6. The vast majority of
humans find it easier to work with names rather than seemingly endless strings of network address digits. The earliest ARPANET systems
(from which the Internet evolved) mapped names to addresses using a **hosts** file that was distributed to all entities
whenever changes occurred. Operationally, such a system became rapidly unsustainable once there were more
than 100 networked entities, which led to the specification and implementation of the Domain Name System that we use today.
.. _dns_fundamentals:
@@ -29,16 +29,16 @@ than 100 networked entities, which led to the specification and implementation o
DNS Fundamentals
~~~~~~~~~~~~~~~~
The DNS naming system is organized as a tree structure comprised of multiple levels and
thus it naturally creates a distributed system. Each node
in the tree is given a label which defines its **Domain** (its area or zone) of **Authority**.
The DNS naming system is organized as a tree structure comprised of multiple levels and
thus it naturally creates a distributed system. Each node
in the tree is given a label which defines its **Domain** (its area or zone) of **Authority**.
The topmost node in the tree is the **Root Domain**; it delegates to **Domains** at the next level which are generically
known as the **Top-Level Domains (TLDs)**. They in turn delegate to **Second-Level Domains (SLDs)**, and so on.
known as the **Top-Level Domains (TLDs)**. They in turn delegate to **Second-Level Domains (SLDs)**, and so on.
The Top-Level Domains (TLDs) include a special group of TLDs called the **Country Code Top-Level Domains (ccTLDs)**,
in which every country is assigned a unique two-character country code from ISO 3166 as its domain.
.. Note:: The Domain Name System is controlled by ICANN (https://www.icann.org) (a 501c non-profit entity); their current policy
is that any new TLD, consisting of three or more characters, may be proposed by any group of commercial sponsors and
.. Note:: The Domain Name System is controlled by ICANN (https://www.icann.org) (a 501c non-profit entity); their current policy
is that any new TLD, consisting of three or more characters, may be proposed by any group of commercial sponsors and
if it meets ICANN's criteria will be added to the TLDs.
The concept of delegation and authority flows down the DNS tree (the DNS hierarchy) as shown:
@@ -48,7 +48,7 @@ The concept of delegation and authority flows down the DNS tree (the DNS hierarc
Delegation and Authority in the DNS Name Space
A domain is the label of a node in the tree. A **domain name** uniquely identifies any node in the DNS tree and is written, left to right,
A domain is the label of a node in the tree. A **domain name** uniquely identifies any node in the DNS tree and is written, left to right,
by combining all the domain labels (each of which are unique within their parent's zone or domain of authority), with a dot
separating each component, up to the root domain. In the above diagram the following are all domain names:
@@ -60,7 +60,7 @@ separating each component, up to the root domain. In the above diagram the follo
us
org
The root has a unique label of "." (dot), which is normally omitted when it is written as
The root has a unique label of "." (dot), which is normally omitted when it is written as
a domain name, but when it is written as a **Fully Qualified Domain Name (FQDN)** the dot must be present. Thus:
.. code-block::
@@ -71,11 +71,11 @@ a domain name, but when it is written as a **Fully Qualified Domain Name (FQDN)*
Authority and Delegation
~~~~~~~~~~~~~~~~~~~~~~~~
Each domain (node) has been **delegated** the authority from its parent domain. The delegated authority includes
specific responsibilities to ensure that every domain it delegates has a unique name or label within its zone or domain of authority, and
that it maintains an **authoritative** list of its delegated domains. The responsibilities further include an operational requirement to
operate two (or more) name servers (which may be contracted to a third party) which will contain the authoritative data
for all the domain labels within its zone of authority in a :ref:`zone file<zone_file>`. Again, the
Each domain (node) has been **delegated** the authority from its parent domain. The delegated authority includes
specific responsibilities to ensure that every domain it delegates has a unique name or label within its zone or domain of authority, and
that it maintains an **authoritative** list of its delegated domains. The responsibilities further include an operational requirement to
operate two (or more) name servers (which may be contracted to a third party) which will contain the authoritative data
for all the domain labels within its zone of authority in a :ref:`zone file<zone_file>`. Again, the
tree structure ensures that the DNS name space is naturally distributed.
The following diagram illustrates that **Authoritative Name Servers** exist for every level and every domain in the DNS name space:
@@ -85,8 +85,8 @@ The following diagram illustrates that **Authoritative Name Servers** exist for
Authoritative Name Servers in the DNS Name Space
.. Note:: The difference between a domain and a zone can appear confusing. Practically, the terms are generally used synonymously in the DNS.
If, however, you are into directed graphs and tree structure theory or similar exotica, a zone can be considered as
.. Note:: The difference between a domain and a zone can appear confusing. Practically, the terms are generally used synonymously in the DNS.
If, however, you are into directed graphs and tree structure theory or similar exotica, a zone can be considered as
an arc through any node (or domain) with the domain at its apex. The zone therefore encompasses all the name space below the domain.
This can, however, lead to the concept of subzones and these were indeed defined in the original DNS specifications.
Thankfully the term subzone has been lost in the mists of time.
@@ -96,35 +96,35 @@ The following diagram illustrates that **Authoritative Name Servers** exist for
Root Servers
~~~~~~~~~~~~
The **root servers** are a critical part of the DNS authoritative infrastructure. There are 13 root servers (*a.root-servers.net*
to *m.root-servers.net*). The number 13 is historically based on the maximum amount of name and IPv4 data
The **root servers** are a critical part of the DNS authoritative infrastructure. There are 13 root servers (*a.root-servers.net*
to *m.root-servers.net*). The number 13 is historically based on the maximum amount of name and IPv4 data
that could be packed into a 512-byte UDP message, and not a perverse affinity for a number that certain
cultures treat as unlucky. The 512-byte UDP data limit
cultures treat as unlucky. The 512-byte UDP data limit
is no longer a limiting factor and all root servers now support both IPv4 and IPv6. In addition, almost all the
root servers use **anycast**, with well over
300 instances of the root servers now providing service worldwide (see further information at https://www.root-servers.org).
root servers use **anycast**, with well over
300 instances of the root servers now providing service worldwide (see further information at https://www.root-servers.org).
The root servers are the starting point for all **name resolution** within the DNS.
Name Resolution
~~~~~~~~~~~~~~~
So far all the emphasis has been on how the DNS stores its authoritative domain (zone) data. End-user systems
use names (an email address or a web address) and need to access this authoritative data to obtain an IP address, which
they use to contact the required network resources such as web, FTP, or mail servers. The process of converting a
domain name to a result (typically an IP address, though other types of data may be obtained) is generically called **name resolution**, and is handled by
**resolvers** (also known as **caching name servers** and many other terms). The following diagram shows the typical name resolution process:
So far all the emphasis has been on how the DNS stores its authoritative domain (zone) data. End-user systems
use names (an email address or a web address) and need to access this authoritative data to obtain an IP address, which
they use to contact the required network resources such as web, FTP, or mail servers. The process of converting a
domain name to a result (typically an IP address, though other types of data may be obtained) is generically called **name resolution**, and is handled by
**resolvers** (also known as **caching name servers** and many other terms). The following diagram shows the typical name resolution process:
.. figure:: name-resolution.png
:align: center
Authoritative Name Servers and Name Resolution
An end-user application, such as a browser (1), when needing to resolve a name such as **www.example.com**, makes an
internal system call to a minimal function resolution entity called a **stub resolver** (2). The stub resolver (using stored
IP addresses) contacts a resolver (a caching name server or full-service resolver) (3), which in turn contacts all the necessary
An end-user application, such as a browser (1), when needing to resolve a name such as **www.example.com**, makes an
internal system call to a minimal function resolution entity called a **stub resolver** (2). The stub resolver (using stored
IP addresses) contacts a resolver (a caching name server or full-service resolver) (3), which in turn contacts all the necessary
authoritative name servers (4, 5, and 6) to provide the answer that it then returns to the user (2, 1). To improve performance,
all resolvers (including most stub resolvers) cache (store) their results such that a subsequent request for the same data
is taken from the resolver's cache, removing the need to repeat the name resolution process and use time-consuming resources. All communication between
all resolvers (including most stub resolvers) cache (store) their results such that a subsequent request for the same data
is taken from the resolver's cache, removing the need to repeat the name resolution process and use time-consuming resources. All communication between
the stub resolver, the resolver, and the authoritative name servers uses the DNS protocol's query and response message pair.
.. _referral:
@@ -136,7 +136,7 @@ the stub resolver, the resolver, and the authoritative name servers uses the DNS
DNS Protocol and Queries
~~~~~~~~~~~~~~~~~~~~~~~~
DNS **queries** use the UDP protocol over the reserved port 53 (but both TCP and TLS can optionally be used in some parts of the network).
DNS **queries** use the UDP protocol over the reserved port 53 (but both TCP and TLS can optionally be used in some parts of the network).
The following diagram shows the name resolution process expressed in terms of DNS queries and responses.
@@ -145,7 +145,7 @@ The following diagram shows the name resolution process expressed in terms of DN
Resolvers and Queries
The stub resolver sends a **recursive query** message (with the required domain name in the QUESTION section of the query) (2) to the resolver.
The stub resolver sends a **recursive query** message (with the required domain name in the QUESTION section of the query) (2) to the resolver.
A **recursive** query simply requests the resolver to find the complete answer. A stub resolver only ever sends recursive queries
and always needs the service of a resolver. The response to a recursive query can be:
@@ -153,8 +153,8 @@ and always needs the service of a resolver. The response to a recursive query ca
2. An error (such as NXDOMAIN - the name does not exist).
The resolver, on receipt of the user's recursive query, either responds immediately, if the ANSWER is in its cache, or accesses
the DNS hierarchy to obtain the answer. The resolver always starts with root servers and sends an **iterative query** (4, 5, and 6). The
The resolver, on receipt of the user's recursive query, either responds immediately, if the ANSWER is in its cache, or accesses
the DNS hierarchy to obtain the answer. The resolver always starts with root servers and sends an **iterative query** (4, 5, and 6). The
response to an iterative query can be:
1. The answer to the resolver's QUESTION in the ANSWER section of the query response.
@@ -164,19 +164,19 @@ and typically IP addresses in the ADDITIONAL section of the response).
3. An error (such as NXDOMAIN - the name does not exist).
If the response is either an answer or an error, these are returned immediately to the user (and cached for future use). If the response
If the response is either an answer or an error, these are returned immediately to the user (and cached for future use). If the response
is a referral, the resolver needs to take additional action to respond to the user's recursive query.
A referral, in essence, indicates that the queried server does not know the answer (the ANSWER section of the response is empty), but it
refers the resolver to the authoritative name servers (in the AUTHORITY section of the response) which it knows about in the
domain name supplied in the QUESTION section of the query. Thus, if the QUESTION is for the domain name **www.example.com**, the root
server to which the iterative query was sent adds a list of the **.com authoritative name servers** in the AUTHORITY section.
The resolver selects one of the servers from the AUTHORITY section and sends an
iterative query to it. Similarly, the .com authoritative name servers send a referral containing a list of the **example.com** authoritative name servers.
This process continues down the DNS hierarchy until either an ANSWER or an error is received, at which point the user's original recursive query
A referral, in essence, indicates that the queried server does not know the answer (the ANSWER section of the response is empty), but it
refers the resolver to the authoritative name servers (in the AUTHORITY section of the response) which it knows about in the
domain name supplied in the QUESTION section of the query. Thus, if the QUESTION is for the domain name **www.example.com**, the root
server to which the iterative query was sent adds a list of the **.com authoritative name servers** in the AUTHORITY section.
The resolver selects one of the servers from the AUTHORITY section and sends an
iterative query to it. Similarly, the .com authoritative name servers send a referral containing a list of the **example.com** authoritative name servers.
This process continues down the DNS hierarchy until either an ANSWER or an error is received, at which point the user's original recursive query
is sent a response.
.. Note:: The DNS hierarchy is always accessed starting at the root servers and working down; there is no concept of "up" in the DNS hierarchy. Clearly,
.. Note:: The DNS hierarchy is always accessed starting at the root servers and working down; there is no concept of "up" in the DNS hierarchy. Clearly,
if the resolver has already cached the list of .com authoritative name servers and the user's recursive query QUESTION contains a domain name
ending in .com, it can omit access to the root servers. However, that is simply an artifact (in this case a performance benefit) of
caching and does not change the concept of top-down access within the DNS hierarchy.
@@ -188,10 +188,10 @@ DNS and BIND 9
BIND 9 is a complete implementation of the DNS protocol. BIND 9 can be configured (using its ``named.conf`` file) as
an authoritative name server, a resolver, and, on supported hosts, a stub resolver. While large operators
usually dedicate DNS servers to a single function per system, smaller operators will find that
usually dedicate DNS servers to a single function per system, smaller operators will find that
BIND 9's flexible configuration features support multiple functions, such as a single DNS server acting
as both an authoritative name server and a resolver.
Example configurations of basic :ref:`authoritative name servers<config_auth_samples>` and
:ref:`resolvers and forwarding resolvers<config_resolver_samples>`, as
:ref:`resolvers and forwarding resolvers<config_resolver_samples>`, as
well as :ref:`advanced configurations<Advanced>` and :ref:`secure configurations<Security>`, are provided.

62
doc/arm/intro-security.inc.rst
View File

@@ -14,20 +14,20 @@
DNS Security Overview
---------------------
DNS is a communications protocol. All communications protocols are potentially
DNS is a communications protocol. All communications protocols are potentially
vulnerable to both subversion and eavesdropping. It is important for
users to audit their exposure to the various threats within their operational environment and implement the
appropriate solutions. BIND 9, a specific implementation of the DNS protocol,
provides an extensive set of security features. The purpose of this section
is to help users to select from the range of available security features those
users to audit their exposure to the various threats within their operational environment and implement the
appropriate solutions. BIND 9, a specific implementation of the DNS protocol,
provides an extensive set of security features. The purpose of this section
is to help users to select from the range of available security features those
required for their specific user environment.
A generic DNS network is shown below, followed by text descriptions. In general,
the further one goes from the left-hand side of the diagram, the more complex
A generic DNS network is shown below, followed by text descriptions. In general,
the further one goes from the left-hand side of the diagram, the more complex
the implementation.
.. Note:: Historically, DNS data was regarded as public and security was
concerned, primarily, with ensuring the integrity of DNS data. DNS data privacy
.. Note:: Historically, DNS data was regarded as public and security was
concerned, primarily, with ensuring the integrity of DNS data. DNS data privacy
is increasingly regarded as an important dimension of overall security, specifically :ref:`DNS over TLS<dns_over_tls>`.
.. figure:: dns-security-overview.png
@@ -37,40 +37,40 @@ the implementation.
The following notes refer to the numbered elements in the above diagram.
1. A variety of system administration techniques and methods may be used to secure
BIND 9's local environment, including :ref:`file permissions <file_permissions>`, running
1. A variety of system administration techniques and methods may be used to secure
BIND 9's local environment, including :ref:`file permissions <file_permissions>`, running
BIND 9 in a :ref:`jail <chroot_and_setuid>`, and the use of :ref:`Access_Control_Lists`.
2. The remote name daemon control (:ref:`rndc<ops_rndc>`) program allows the system
administrator to control the operation of a name server. The majority of BIND 9 packages
or ports come preconfigured with local (loopback address) security preconfigured.
administrator to control the operation of a name server. The majority of BIND 9 packages
or ports come preconfigured with local (loopback address) security preconfigured.
If ``rndc`` is being invoked from a remote host, further configuration is required.
The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically
change the contents of the zone file(s). ``nsupdate`` access and security may be controlled
The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically
change the contents of the zone file(s). ``nsupdate`` access and security may be controlled
using ``named.conf`` :ref:`statements or using TSIG or SIG(0) cryptographic methods <dynamic_update_security>`.
Clearly, if the remote hosts used for either ``rndc`` or DDNS lie within a network entirely
Clearly, if the remote hosts used for either ``rndc`` or DDNS lie within a network entirely
under the user's control, the security threat may be regarded as non-existent. Any implementation requirements,
therefore, depend on the site's security policy.
3. Zone transfer from a **primary** to one or more **secondary** authoritative name servers across a
public network carries risk. The zone transfer may be secured using
3. Zone transfer from a **primary** to one or more **secondary** authoritative name servers across a
public network carries risk. The zone transfer may be secured using
``named.conf`` :ref:`statements, TSIG cryptographic methods or TLS<sec_file_transfer>`.
Clearly, if the secondary authoritative name server(s) all lie within a network entirely
under the user's control, the security threat may be regarded as non-existent. Any implementation requirements
Clearly, if the secondary authoritative name server(s) all lie within a network entirely
under the user's control, the security threat may be regarded as non-existent. Any implementation requirements
again depend on the site's security policy.
4. If the operator of an authoritative name server (primary or secondary) wishes to ensure that
DNS responses to user-initiated queries about the zone(s) for which they are responsible can only
have come from their server, that the data received by the user is the same as that sent, and that
non-existent names are genuine, then :ref:`DNSSEC` is the only solution. DNSSEC requires configuration
and operational changes both to the authoritative name servers and to any resolver which accesses
4. If the operator of an authoritative name server (primary or secondary) wishes to ensure that
DNS responses to user-initiated queries about the zone(s) for which they are responsible can only
have come from their server, that the data received by the user is the same as that sent, and that
non-existent names are genuine, then :ref:`DNSSEC` is the only solution. DNSSEC requires configuration
and operational changes both to the authoritative name servers and to any resolver which accesses
those servers.
5. The typical Internet-connected end-user device (PCs, laptops, and even mobile phones) either has
a stub resolver or operates via a DNS proxy. A stub resolver requires the services of an area
or full-service resolver to completely answer user queries. Stub resolvers on the majority of PCs and laptops
typically have a caching capability to increase performance. At this time there are no standard stub resolvers or proxy
5. The typical Internet-connected end-user device (PCs, laptops, and even mobile phones) either has
a stub resolver or operates via a DNS proxy. A stub resolver requires the services of an area
or full-service resolver to completely answer user queries. Stub resolvers on the majority of PCs and laptops
typically have a caching capability to increase performance. At this time there are no standard stub resolvers or proxy
DNS tools that implement DNSSEC. BIND 9 may be configured to provide such capability on supported Linux or Unix platforms.
:ref:`DNS over TLS <dns_over_tls>` may be configured to verify the integrity of the data between the stub resolver and
area (or full-service) resolver. However, unless the resolver and the Authoritative Name Server implements DNSSEC, end-to-end integrity (from
:ref:`DNS over TLS <dns_over_tls>` may be configured to verify the integrity of the data between the stub resolver and
area (or full-service) resolver. However, unless the resolver and the Authoritative Name Server implements DNSSEC, end-to-end integrity (from
authoritative name server to stub resolver) cannot be guaranteed.

12
doc/arm/introduction.inc.rst
View File

@@ -42,7 +42,7 @@ Organization of This Document
:ref:`introduction` introduces the basic DNS and BIND concepts. Some tutorial material on
:ref:`dns_overview` is presented for those unfamiliar with DNS. A
:ref:`intro_dns_security` is provided to allow BIND operators to implement
:ref:`intro_dns_security` is provided to allow BIND operators to implement
appropriate security for their operational environment.
:ref:`requirements` describes the hardware and environment requirements for BIND 9
@@ -51,13 +51,13 @@ and lists both the supported and unsupported platforms.
:ref:`configuration` is intended as a quickstart guide for newer users. Sample files
are included for :ref:`config_auth_samples` (both :ref:`primary<sample_primary>` and
:ref:`secondary<sample_secondary>`), as well as a simple :ref:`config_resolver_samples` and
a :ref:`sample_forwarding`. Some reference material on the :ref:`Zone File<zone_file>` is included.
a :ref:`sample_forwarding`. Some reference material on the :ref:`Zone File<zone_file>` is included.
:ref:`ns_operations` covers basic BIND 9 software and DNS operations, including some
useful tools, Unix signals, and plugins.
:ref:`advanced` builds on the configurations of :ref:`configuration`, adding
functions and features the system administrator may need.
functions and features the system administrator may need.
:ref:`security` covers most aspects of BIND 9 security, including file permissions,
running BIND 9 in a "jail," and securing file transfers and dynamic updates.
@@ -65,14 +65,14 @@ running BIND 9 in a "jail," and securing file transfers and dynamic updates.
:ref:`dnssec` describes the theory and practice of cryptographic authentication of DNS
information. The :ref:`dnssec_guide` is a practical guide to implementing DNSSEC.
:ref:`Reference` gives exhaustive descriptions of all supported blocks, statements,
:ref:`Reference` gives exhaustive descriptions of all supported blocks, statements,
and grammars used in BIND 9's ``named.conf`` configuration file.
:ref:`troubleshooting` provides information on identifying and solving BIND 9 and DNS
problems. Information about bug-reporting procedures is also provided.
:ref:`build_bind` is a definitive guide for those occasions where the user requires
special options not provided in the standard Linux or Unix distributions.
:ref:`build_bind` is a definitive guide for those occasions where the user requires
special options not provided in the standard Linux or Unix distributions.
The **Appendices** contain useful reference information, such as a bibliography and historic
information related to BIND and the Domain Name System, as well as the current *man*

12
doc/arm/logging-categories.inc.rst
View File

@@ -35,9 +35,9 @@
``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.
Note: the log message can also be due to packet loss. Before reporting servers for non-:rfc:`1034` compliance they should be re-tested to determine the nature of the non-compliance. This testing should prevent or reduce the number of false-positive reports.
Note: eventually :iscman:`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``
@@ -57,16 +57,16 @@
``queries``
A location where queries should be logged.
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].
``client 127.0.0.1#62536 (www.example.com):``
``query: www.example.com IN AAAA +SE``
``client ::1#62537 (www.example.net):``
``query: www.example.net IN AAAA -SE``
The first part of this log message, showing the client address/port number and query name, is repeated in all subsequent log messages related to the same query.
``query-errors``
@@ -74,7 +74,7 @@
``rate-limit``
Start, periodic, and final notices of the rate limiting of a stream of responses that are logged at ``info`` severity in this category. These messages include a hash value of the domain name of the response and the name itself, except when there is insufficient memory to record the name for the final notice. The final notice is normally delayed until about one minute after rate limiting stops. A lack of memory can hurry the final notice, which is indicated by an initial asterisk (\*). Various internal events are logged at debug level 1 and higher.
Rate limiting of individual requests is logged in the ``query-errors`` category.
``resolver``

2
doc/arm/reference.rst
View File

@@ -2576,7 +2576,7 @@ Boolean Options
``configure --disable-auto-validation``, in which case the default is
``yes``.
The default root trust anchor is compiled into :iscman:`named`
The default root trust anchor is compiled into :iscman:`named`
and is current as of the release date. If the root key changes, a
running BIND server will detect this and roll smoothly to the new
key, but newly-installed servers will be unable to start validation,

2
doc/arm/security.inc.rst
View File

@@ -179,7 +179,7 @@ point of view, ``/var/named`` is the root of the filesystem;
the values of options like :any:`directory` and :any:`pid-file`
must be adjusted to account for this.
Unlike with earlier versions of BIND,
Unlike with earlier versions of BIND,
:iscman:`named` does *not* typically need to be compiled statically, nor do shared libraries need to be installed under the new
root. However, depending on the operating system, it may be necessary to set
up locations such as ``/dev/zero``, ``/dev/random``, ``/dev/log``, and

2
doc/arm/troubleshooting.inc.rst
View File

@@ -151,7 +151,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.