mirror of
https://gitlab.nic.cz/knot/knot-dns.git
synced 2026-05-28 04:02:31 -04:00
doc: replace terms master/slave with primary/secondary where suitable
As per RFC 8499, section 6. https://tools.ietf.org/html/rfc8499#section-6
This commit is contained in:
David Vašek
Daniel Salzman
parent
fec8408999
commit
327451626b
10 changed files with 122 additions and 110 deletions
|
|
@ -159,15 +159,15 @@ See the following examples and :ref:`ACL section`.
|
|||
.. TIP::
|
||||
In order to restrict regular DNS queries, use module :ref:`queryacl<mod-queryacl>`.
|
||||
|
||||
Slave zone
|
||||
==========
|
||||
Secondary (slave) zone
|
||||
======================
|
||||
|
||||
Knot DNS doesn't strictly differ between master and slave zones. The
|
||||
only requirement is to have a :ref:`master<zone_master>` statement set for
|
||||
the given zone. Also note that you need to explicitly allow incoming zone
|
||||
changed notifications via ``notify`` :ref:`acl_action` through a zone's
|
||||
:ref:`zone_acl` list, otherwise the update will be rejected by the server.
|
||||
If the zone file doesn't exist it will be bootstrapped over AXFR::
|
||||
Knot DNS doesn't strictly differ between primary (formerly known as master)
|
||||
and secondary (formerly known as slave) zones. The only requirement for a secondary
|
||||
zone is to have a :ref:`zone_master` statement set. Also note that you need
|
||||
to explicitly allow incoming zone changed notifications via ``notify`` :ref:`acl_action`
|
||||
through a zone's :ref:`zone_acl` list, otherwise the update will be rejected by the
|
||||
server. If the zone file doesn't exist it will be bootstrapped over AXFR::
|
||||
|
||||
remote:
|
||||
- id: master
|
||||
|
|
@ -222,8 +222,8 @@ independent::
|
|||
* Shorten TIME_WAIT timeout (tcp_fin_timeout)
|
||||
* Increase available local port count
|
||||
|
||||
Master zone
|
||||
===========
|
||||
Primary (master) zone
|
||||
=====================
|
||||
|
||||
An ACL with the ``transfer`` action must be configured to allow outgoing zone
|
||||
transfers. An ACL rule consists of a single address or a network subnet::
|
||||
|
|
@ -270,7 +270,7 @@ Optionally, a TSIG key can be specified::
|
|||
address: 192.168.3.0/24
|
||||
action: transfer
|
||||
|
||||
Note that a slave zone may serve as a master zone at the same time::
|
||||
Note that a secondary zone may serve as a primary zone at the same time::
|
||||
|
||||
remote:
|
||||
- id: master
|
||||
|
|
@ -303,11 +303,11 @@ Dynamic updates
|
|||
===============
|
||||
|
||||
Dynamic updates for the zone are allowed via proper ACL rule with the
|
||||
``update`` action. If the zone is configured as a slave and a DNS update
|
||||
``update`` action. If the zone is configured as a secondary and a DNS update
|
||||
message is accepted, the server forwards the message to its primary master.
|
||||
The master's response is then forwarded back to the originator.
|
||||
The primary master's response is then forwarded back to the originator.
|
||||
|
||||
However, if the zone is configured as a master, the update is accepted and
|
||||
However, if the zone is configured as a primary, the update is accepted and
|
||||
processed::
|
||||
|
||||
acl:
|
||||
|
|
@ -407,12 +407,12 @@ additional options in :ref:`policy section <Policy section>`, mostly specifying
|
|||
desired (finite) lifetime for KSK: ::
|
||||
|
||||
remote:
|
||||
- id: test_zone_server
|
||||
- id: parent_zone_server
|
||||
address: 192.168.12.1@53
|
||||
|
||||
submission:
|
||||
- id: test_zone_sbm
|
||||
parent: [test_zone_server]
|
||||
- id: parent_zone_sbm
|
||||
parent: [parent_zone_server]
|
||||
|
||||
policy:
|
||||
- id: rsa
|
||||
|
|
@ -421,7 +421,7 @@ desired (finite) lifetime for KSK: ::
|
|||
zsk-size: 1024
|
||||
zsk-lifetime: 30d
|
||||
ksk-lifetime: 365d
|
||||
ksk-submission: test_zone_sbm
|
||||
ksk-submission: parent_zone_sbm
|
||||
|
||||
zone:
|
||||
- domain: myzone.test
|
||||
|
|
@ -431,7 +431,7 @@ desired (finite) lifetime for KSK: ::
|
|||
After the initially-generated KSK reaches its lifetime, new KSK is published and after
|
||||
convenience delay the submission is started. The server publishes CDS and CDNSKEY records
|
||||
and the user shall propagate them to the parent. The server periodically checks for
|
||||
DS at the master and when positive, finishes the rollover.
|
||||
DS at the parent zone and when positive, finishes the rollover.
|
||||
|
||||
To share KSKs among zones, set the ksk-shared policy parameter. It is strongly discouraged to
|
||||
change the policy ``id`` afterwards! The shared key's creation timestamp will be equal for all
|
||||
|
|
@ -558,24 +558,24 @@ DNSSEC re-sign will happen.
|
|||
|
||||
.. _dnssec-on-slave-signing:
|
||||
|
||||
On-slave signing
|
||||
----------------
|
||||
On-secondary (on-slave) signing
|
||||
-------------------------------
|
||||
|
||||
It is possible to enable automatic DNSSEC zone signing even on a slave
|
||||
It is possible to enable automatic DNSSEC zone signing even on a secondary
|
||||
server. If enabled, the zone is signed after every AXFR/IXFR transfer
|
||||
from master, so that the slave always serves a signed up-to-date version
|
||||
from primary, so that the secondary always serves a signed up-to-date version
|
||||
of the zone.
|
||||
|
||||
It is strongly recommended to block any outside access to the master
|
||||
server, so that only the slave's signed version of the zone is served.
|
||||
It is strongly recommended to block any outside access to the primary
|
||||
server, so that only the secondary server's signed version of the zone is served.
|
||||
|
||||
Enabled on-slave signing introduces events when the slave zone changes
|
||||
while the master zone remains unchanged, such as a key rollover or
|
||||
Enabled on-secondary signing introduces events when the secondary zone changes
|
||||
while the primary zone remains unchanged, such as a key rollover or
|
||||
refreshing of RRSIG records, which cause inequality of zone SOA serial
|
||||
between master and slave. The slave server handles this by saving the
|
||||
master's SOA serial in a special variable inside KASP DB and appropriately
|
||||
between primary and secondary. The secondary server handles this by saving the
|
||||
primary's SOA serial in a special variable inside KASP DB and appropriately
|
||||
modifying AXFR/IXFR queries/answers to keep the communication with
|
||||
master consistent while applying the changes with a different serial.
|
||||
primary server consistent while applying the changes with a different serial.
|
||||
|
||||
.. _catalog-zones:
|
||||
|
||||
|
|
@ -584,19 +584,19 @@ Catalog zones
|
|||
|
||||
Catalog zones are a concept whereby a list of zones to be configured is maintained
|
||||
as contents of a separate, special zone. This approach has the benefit of simple
|
||||
propagation of a zone list to slave servers, especially when the list is
|
||||
propagation of a zone list to secondary servers, especially when the list is
|
||||
frequently updated. Currently, catalog zones are described in this `Internet Draft
|
||||
<https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones>`_.
|
||||
|
||||
Terminology first. *Catalog zone* is a meta-zone which shall not be a part
|
||||
of the DNS tree, but it contains information about the set of member zones and
|
||||
is transferable to slaves using common AXFR/IXFR techniques.
|
||||
is transferable to secondary servers using common AXFR/IXFR techniques.
|
||||
*Catalog-member zone* (or just *member zone*) is a zone based on
|
||||
information from the catalog zone and not from configuration file/database.
|
||||
|
||||
A catalog zone is handled almost in the same way as a regular zone:
|
||||
It can be configured using all the standard options (but for example
|
||||
DNSSEC signing would be useless), including master/slave configuration
|
||||
DNSSEC signing would be useless), including primary/secondary configuration
|
||||
and ACLs. A catalog zone is indicated by setting the option
|
||||
:ref:`zone_catalog-role`. The difference is that standard DNS
|
||||
queries to a catalog zone are answered with REFUSED as though the zone
|
||||
|
|
@ -629,10 +629,10 @@ where the mentioned group of labels shall match:
|
|||
- *<catalog-zone>* — Name of the catalog zone.
|
||||
|
||||
All records other than PTR are ignored. They remain in the catalog
|
||||
zone, however, and might be for example transferred to a slave, which may interpret
|
||||
catalog zones differently. SOA still needs to be present in the catalog zone
|
||||
and its serial handled appropriately. An apex NS record should be present
|
||||
for the sake of interoperability. The version record ``version 0 IN TXT "2"``
|
||||
zone, however, and might be for example transferred to a secondary server,
|
||||
which may interpret catalog zones differently. SOA still needs to be present in
|
||||
the catalog zone and its serial handled appropriately. An apex NS record should be
|
||||
present for the sake of interoperability. The version record ``version 0 IN TXT "2"``
|
||||
is required at the catalog zone apex.
|
||||
|
||||
A catalog zone may be modified using any standard means (e.g. AXFR/IXFR, DDNS,
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Knot DNS features
|
|||
|
||||
DNS features:
|
||||
|
||||
* Master and slave operation
|
||||
* Primary and secondary server operation
|
||||
* Internet class (IN)
|
||||
* DNS extension (EDNS0)
|
||||
* TCP and UDP protocols
|
||||
|
|
|
|||
|
|
@ -115,9 +115,10 @@ Prints the current NSEC3 salt used for signing. If \fInew_salt\fP is specified,
|
|||
The salt is printed and expected in hexadecimal, or dash if empty.
|
||||
.TP
|
||||
\fBlocal\-serial\fP [\fInew_serial\fP]
|
||||
Print SOA serial stored in KASP database when using on\-slave DNSSEC signing. If \fInew_serial\fP is specified,
|
||||
the serial is overwritten. After updating the serial, expire the zone (\fBzone\-purge +expire +zonefile +journal\fP)
|
||||
if the server is running, or remove corresponding zone file and journal contents if the server is stopped.
|
||||
Print SOA serial stored in KASP database when using on\-secondary DNSSEC signing.
|
||||
If \fInew_serial\fP is specified, the serial is overwritten. After updating the serial, expire the zone
|
||||
(\fBzone\-purge +expire +zonefile +journal\fP) if the server is running, or remove corresponding zone file
|
||||
and journal contents if the server is stopped.
|
||||
.TP
|
||||
\fBset\fP \fIkey_spec\fP [\fIarguments\fP\&...]
|
||||
Changes a timing argument (or ksk/zsk) of an existing key to a new value. \fIKey_spec\fP is either the
|
||||
|
|
|
|||
|
|
@ -328,7 +328,7 @@ on FreeBSD). Due to the lack of one shared socket, the server can offer
|
|||
higher response rate processing over TCP. However, in the case of
|
||||
time\-consuming requests (e.g. zone transfers of a TLD zone), enabled reuseport
|
||||
may result in delayed or not being responded client requests. So it is
|
||||
advisable to use this option on slave servers.
|
||||
advisable to use this option on secondary servers.
|
||||
.sp
|
||||
Change of this parameter requires restart of the Knot server to take effect.
|
||||
.sp
|
||||
|
|
@ -604,7 +604,7 @@ durability but is generally slower.
|
|||
.IP \(bu 2
|
||||
\fBasynchronous\fP – The journal database disk synchronization is optimized for
|
||||
better performance at the expense of lower database durability in the case of
|
||||
a crash. This mode is recommended on slave nodes with many zones.
|
||||
a crash. This mode is recommended on secondary servers with many zones.
|
||||
.UNINDENT
|
||||
.sp
|
||||
\fIDefault:\fP robust
|
||||
|
|
@ -767,7 +767,7 @@ A key name identifier.
|
|||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
This value MUST be exactly the same as the name of the TSIG key on the
|
||||
opposite master/slave server(s).
|
||||
opposite primary/secondary server(s).
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SS algorithm
|
||||
|
|
@ -850,8 +850,8 @@ the communication with the remote server.
|
|||
\fIDefault:\fP not set
|
||||
.SS block\-notify\-after\-transfer
|
||||
.sp
|
||||
When incoming AXFR/IXFR from this remote (as a master), suppress sending
|
||||
NOTIFY messages to all configured slaves.
|
||||
When incoming AXFR/IXFR from this remote (as a primary server), suppress
|
||||
sending NOTIFY messages to all configured secondary servers.
|
||||
.sp
|
||||
\fIDefault:\fP off
|
||||
.SH ACL SECTION
|
||||
|
|
@ -1224,7 +1224,8 @@ Zero (aka infinity) value causes no ZSK rollover as a result.
|
|||
.SS propagation\-delay
|
||||
.sp
|
||||
An extra delay added for each key rollover step. This value should be high
|
||||
enough to cover propagation of data from the master server to all slaves.
|
||||
enough to cover propagation of data from the primary server to all
|
||||
secondary servers.
|
||||
.sp
|
||||
\fBNOTE:\fP
|
||||
.INDENT 0.0
|
||||
|
|
@ -1250,7 +1251,7 @@ time period is not counted to the signature lifetime.
|
|||
.SS rrsig\-refresh
|
||||
.sp
|
||||
A period how long at least before a signature expiration the signature will be refreshed,
|
||||
in order to prevent expired RRSIGs on slaves or resolvers\(aq caches.
|
||||
in order to prevent expired RRSIGs on secondary servers or resolvers\(aq caches.
|
||||
.sp
|
||||
\fIDefault:\fP 7 days
|
||||
.SS rrsig\-pre\-refresh
|
||||
|
|
@ -1504,13 +1505,14 @@ where DDD is corresponding decimal ASCII code.
|
|||
\fIDefault:\fP \fI\%storage\fP/\fB%s\fP\&.zone
|
||||
.SS master
|
||||
.sp
|
||||
An ordered list of \fI\%references\fP to zone master servers.
|
||||
An ordered list of \fI\%references\fP to zone primary servers
|
||||
(formerly known as master servers).
|
||||
.sp
|
||||
\fIDefault:\fP not set
|
||||
.SS ddns\-master
|
||||
.sp
|
||||
A \fI\%reference\fP to zone primary master server.
|
||||
If not specified, the first \fI\%master\fP server is used.
|
||||
A \fI\%reference\fP to zone primary master. If not specified,
|
||||
the first \fI\%master\fP server is used.
|
||||
.sp
|
||||
\fIDefault:\fP not set
|
||||
.SS notify
|
||||
|
|
@ -1742,7 +1744,7 @@ Use dateserial only if you expect less than 100 updates per day per zone.
|
|||
\fIDefault:\fP increment
|
||||
.SS refresh\-min\-interval
|
||||
.sp
|
||||
Forced minimum zone refresh interval to avoid flooding master.
|
||||
Forced minimum zone refresh interval to avoid flooding primary server.
|
||||
.sp
|
||||
\fIDefault:\fP 2
|
||||
.SS refresh\-max\-interval
|
||||
|
|
|
|||
|
|
@ -104,22 +104,25 @@ when semantic check warning appears. (*)
|
|||
.TP
|
||||
\fBzone\-reload\fP [\fIzone\fP\&...]
|
||||
Trigger a zone reload from a disk without checking its modification time. For
|
||||
slave zone, the refresh from a master server is scheduled; for master zone,
|
||||
the notification of slave servers is scheduled. An open zone transaction
|
||||
will be aborted! If invoked with the force option, also zone modules will be
|
||||
re\-loaded, but blocking mode might not work reliably. (#)
|
||||
secondary zone, the refresh event from primary server(s) is scheduled;
|
||||
for primary zone, the notify event to secondary server(s) is scheduled. An open
|
||||
zone transaction will be aborted! If invoked with the force option, also zone
|
||||
modules will be re\-loaded, but blocking mode might not work reliably. (#)
|
||||
.TP
|
||||
\fBzone\-refresh\fP [\fIzone\fP\&...]
|
||||
Trigger a check for the zone serial on the zone\(aqs master. If the master has a
|
||||
newer zone, a transfer is scheduled. This command is valid for slave zones. (#)
|
||||
Trigger a check for the zone serial on the zone\(aqs primary server. If
|
||||
the primary server has a newer zone, a transfer is scheduled. This command is
|
||||
valid for secondary zones. (#)
|
||||
.TP
|
||||
\fBzone\-retransfer\fP [\fIzone\fP\&...]
|
||||
Trigger a zone transfer from the zone\(aqs master. The server doesn\(aqt check the
|
||||
serial of the master\(aqs zone. This command is valid for slave zones. (#)
|
||||
Trigger a zone transfer from the zone\(aqs primary server. The server
|
||||
doesn\(aqt check the serial of the primary server\(aqs zone. This command is valid
|
||||
for secondary zones. (#)
|
||||
.TP
|
||||
\fBzone\-notify\fP [\fIzone\fP\&...]
|
||||
Trigger a NOTIFY message to all configured remotes. This can help in cases
|
||||
when previous NOTIFY had been lost or the slaves offline. (#)
|
||||
when previous NOTIFY had been lost or the secondary servers have been
|
||||
offline. (#)
|
||||
.TP
|
||||
\fBzone\-flush\fP [\fIzone\fP\&...] [\fB+outdir\fP \fIdirectory\fP]
|
||||
Trigger a zone journal flush to the configured zone file. If an output
|
||||
|
|
@ -316,7 +319,7 @@ $ knotc conf\-read zone.domain
|
|||
.fi
|
||||
.UNINDENT
|
||||
.UNINDENT
|
||||
.SS Get the master remotes for the example.com zone
|
||||
.SS Get the primary servers for the example.com zone
|
||||
.INDENT 0.0
|
||||
.INDENT 3.5
|
||||
.sp
|
||||
|
|
|
|||
|
|
@ -88,9 +88,10 @@ Commands
|
|||
The salt is printed and expected in hexadecimal, or dash if empty.
|
||||
|
||||
**local-serial** [*new_serial*]
|
||||
Print SOA serial stored in KASP database when using on-slave DNSSEC signing. If *new_serial* is specified,
|
||||
the serial is overwritten. After updating the serial, expire the zone (**zone-purge +expire +zonefile +journal**)
|
||||
if the server is running, or remove corresponding zone file and journal contents if the server is stopped.
|
||||
Print SOA serial stored in KASP database when using on-secondary DNSSEC signing.
|
||||
If *new_serial* is specified, the serial is overwritten. After updating the serial, expire the zone
|
||||
(**zone-purge +expire +zonefile +journal**) if the server is running, or remove corresponding zone file
|
||||
and journal contents if the server is stopped.
|
||||
|
||||
**set** *key_spec* [*arguments*...]
|
||||
Changes a timing argument (or ksk/zsk) of an existing key to a new value. *Key_spec* is either the
|
||||
|
|
|
|||
|
|
@ -81,22 +81,25 @@ Actions
|
|||
|
||||
**zone-reload** [*zone*...]
|
||||
Trigger a zone reload from a disk without checking its modification time. For
|
||||
slave zone, the refresh from a master server is scheduled; for master zone,
|
||||
the notification of slave servers is scheduled. An open zone transaction
|
||||
will be aborted! If invoked with the force option, also zone modules will be
|
||||
re-loaded, but blocking mode might not work reliably. (#)
|
||||
secondary zone, the refresh event from primary server(s) is scheduled;
|
||||
for primary zone, the notify event to secondary server(s) is scheduled. An open
|
||||
zone transaction will be aborted! If invoked with the force option, also zone
|
||||
modules will be re-loaded, but blocking mode might not work reliably. (#)
|
||||
|
||||
**zone-refresh** [*zone*...]
|
||||
Trigger a check for the zone serial on the zone's master. If the master has a
|
||||
newer zone, a transfer is scheduled. This command is valid for slave zones. (#)
|
||||
Trigger a check for the zone serial on the zone's primary server. If
|
||||
the primary server has a newer zone, a transfer is scheduled. This command is
|
||||
valid for secondary zones. (#)
|
||||
|
||||
**zone-retransfer** [*zone*...]
|
||||
Trigger a zone transfer from the zone's master. The server doesn't check the
|
||||
serial of the master's zone. This command is valid for slave zones. (#)
|
||||
Trigger a zone transfer from the zone's primary server. The server
|
||||
doesn't check the serial of the primary server's zone. This command is valid
|
||||
for secondary zones. (#)
|
||||
|
||||
**zone-notify** [*zone*...]
|
||||
Trigger a NOTIFY message to all configured remotes. This can help in cases
|
||||
when previous NOTIFY had been lost or the slaves offline. (#)
|
||||
when previous NOTIFY had been lost or the secondary servers have been
|
||||
offline. (#)
|
||||
|
||||
**zone-flush** [*zone*...] [**+outdir** *directory*]
|
||||
Trigger a zone journal flush to the configured zone file. If an output
|
||||
|
|
@ -285,8 +288,8 @@ Get the list of the current zones
|
|||
|
||||
$ knotc conf-read zone.domain
|
||||
|
||||
Get the master remotes for the example.com zone
|
||||
...............................................
|
||||
Get the primary servers for the example.com zone
|
||||
................................................
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -171,21 +171,21 @@ An example of possible configuration initialization::
|
|||
$ knotc conf-diff
|
||||
$ knotc conf-commit
|
||||
|
||||
.. _Running a slave server:
|
||||
.. _Secondary mode:
|
||||
|
||||
Slave mode
|
||||
==========
|
||||
Secondary (slave) mode
|
||||
======================
|
||||
|
||||
Running the server as a slave is very straightforward as you usually
|
||||
bootstrap zones over AXFR and thus avoid any manual zone operations.
|
||||
Running the server as a secondary server is very straightforward as you
|
||||
usually bootstrap zones over AXFR and thus avoid any manual zone operations.
|
||||
In contrast to AXFR, when the incremental transfer finishes, it stores
|
||||
the differences in the journal file and doesn't update the zone file
|
||||
immediately but after the :ref:`zone_zonefile-sync` period elapses.
|
||||
|
||||
.. _Running a master server:
|
||||
.. _Primary mode:
|
||||
|
||||
Master mode
|
||||
===========
|
||||
Primary (master) mode
|
||||
=====================
|
||||
|
||||
If you just want to check the zone files before starting, you can use::
|
||||
|
||||
|
|
@ -381,8 +381,8 @@ Keep the zone file updated::
|
|||
These are default values. The user can always check the current zone
|
||||
contents in the zone file, and also modify it (recommended with server turned-off or
|
||||
taking the :ref:`safe way<Editing zone file>`). The journal serves here just as a source of
|
||||
history for slaves' IXFR. Some users dislike that the server overwrites their prettily
|
||||
prepared zone file.
|
||||
history for secondary servers' IXFR. Some users dislike that the server overwrites their
|
||||
prettily prepared zone file.
|
||||
|
||||
Example 2
|
||||
---------
|
||||
|
|
@ -397,7 +397,7 @@ Zone contents are stored only in the journal. The zone is updated by DDNS,
|
|||
zone transfer, or via the control interface. The user might have filled the
|
||||
zone contents initially from a zone file by setting :ref:`zone_zonefile-load` to
|
||||
`whole` temporarily.
|
||||
It's also a good setup for slaves. Anyway, it's recommended to carefully tune
|
||||
It's also a good setup for secondary servers. Anyway, it's recommended to carefully tune
|
||||
the journal-size-related options to avoid surprises like the journal getting full.
|
||||
|
||||
Example 3
|
||||
|
|
@ -930,7 +930,7 @@ restarting the server. This can be done with::
|
|||
|
||||
$ knotc reload
|
||||
|
||||
If you want to refresh the slave zones, you can do this with::
|
||||
If you want to refresh the secondary zones, you can do this with::
|
||||
|
||||
$ knotc zone-refresh
|
||||
|
||||
|
|
@ -1021,7 +1021,7 @@ of obsolete signing keys.
|
|||
:ref:`propagation-delay <policy_propagation-delay>` to the sum of:
|
||||
|
||||
- The maximum delay between beginning of the zone signing and publishing
|
||||
re-signed zone on all public slave servers.
|
||||
re-signed zone on all public secondary servers.
|
||||
- How long it takes for the backup server to start up with the restored data.
|
||||
- The period between taking backup snapshots of the live environment.
|
||||
|
||||
|
|
|
|||
|
|
@ -323,7 +323,7 @@ on FreeBSD). Due to the lack of one shared socket, the server can offer
|
|||
higher response rate processing over TCP. However, in the case of
|
||||
time-consuming requests (e.g. zone transfers of a TLD zone), enabled reuseport
|
||||
may result in delayed or not being responded client requests. So it is
|
||||
advisable to use this option on slave servers.
|
||||
advisable to use this option on secondary servers.
|
||||
|
||||
Change of this parameter requires restart of the Knot server to take effect.
|
||||
|
||||
|
|
@ -657,7 +657,7 @@ Possible values:
|
|||
durability but is generally slower.
|
||||
- ``asynchronous`` – The journal database disk synchronization is optimized for
|
||||
better performance at the expense of lower database durability in the case of
|
||||
a crash. This mode is recommended on slave nodes with many zones.
|
||||
a crash. This mode is recommended on secondary servers with many zones.
|
||||
|
||||
*Default:* robust
|
||||
|
||||
|
|
@ -827,7 +827,7 @@ A key name identifier.
|
|||
|
||||
.. NOTE::
|
||||
This value MUST be exactly the same as the name of the TSIG key on the
|
||||
opposite master/slave server(s).
|
||||
opposite primary/secondary server(s).
|
||||
|
||||
.. _key_algorithm:
|
||||
|
||||
|
|
@ -923,8 +923,8 @@ the communication with the remote server.
|
|||
block-notify-after-transfer
|
||||
---------------------------
|
||||
|
||||
When incoming AXFR/IXFR from this remote (as a master), suppress sending
|
||||
NOTIFY messages to all configured slaves.
|
||||
When incoming AXFR/IXFR from this remote (as a primary server), suppress
|
||||
sending NOTIFY messages to all configured secondary servers.
|
||||
|
||||
*Default:* off
|
||||
|
||||
|
|
@ -1342,7 +1342,8 @@ propagation-delay
|
|||
-----------------
|
||||
|
||||
An extra delay added for each key rollover step. This value should be high
|
||||
enough to cover propagation of data from the master server to all slaves.
|
||||
enough to cover propagation of data from the primary server to all
|
||||
secondary servers.
|
||||
|
||||
.. NOTE::
|
||||
Has infuence over ZSK key lifetime.
|
||||
|
|
@ -1368,7 +1369,7 @@ rrsig-refresh
|
|||
-------------
|
||||
|
||||
A period how long at least before a signature expiration the signature will be refreshed,
|
||||
in order to prevent expired RRSIGs on slaves or resolvers' caches.
|
||||
in order to prevent expired RRSIGs on secondary servers or resolvers' caches.
|
||||
|
||||
*Default:* 7 days
|
||||
|
||||
|
|
@ -1655,7 +1656,8 @@ It is also possible to use the following formatters:
|
|||
master
|
||||
------
|
||||
|
||||
An ordered list of :ref:`references<remote_id>` to zone master servers.
|
||||
An ordered list of :ref:`references<remote_id>` to zone primary servers
|
||||
(formerly known as master servers).
|
||||
|
||||
*Default:* not set
|
||||
|
||||
|
|
@ -1664,8 +1666,8 @@ An ordered list of :ref:`references<remote_id>` to zone master servers.
|
|||
ddns-master
|
||||
-----------
|
||||
|
||||
A :ref:`reference<remote_id>` to zone primary master server.
|
||||
If not specified, the first :ref:`master<zone_master>` server is used.
|
||||
A :ref:`reference<remote_id>` to zone primary master. If not specified,
|
||||
the first :ref:`master<zone_master>` server is used.
|
||||
|
||||
*Default:* not set
|
||||
|
||||
|
|
@ -1907,7 +1909,7 @@ Possible values:
|
|||
refresh-min-interval
|
||||
--------------------
|
||||
|
||||
Forced minimum zone refresh interval to avoid flooding master.
|
||||
Forced minimum zone refresh interval to avoid flooding primary server.
|
||||
|
||||
*Default:* 2
|
||||
|
||||
|
|
|
|||
|
|
@ -14,18 +14,18 @@ database:
|
|||
storage: "@storage_dir@"
|
||||
|
||||
remote:
|
||||
# - id: slave
|
||||
# - id: secondary
|
||||
# address: 192.168.1.1@53
|
||||
#
|
||||
# - id: master
|
||||
# - id: primary
|
||||
# address: 192.168.2.1@53
|
||||
|
||||
acl:
|
||||
# - id: acl_slave
|
||||
# - id: acl_secondary
|
||||
# address: 192.168.1.1
|
||||
# action: transfer
|
||||
|
||||
# - id: acl_master
|
||||
# - id: acl_primary
|
||||
# address: 192.168.2.1
|
||||
# action: notify
|
||||
|
||||
|
|
@ -35,12 +35,12 @@ template:
|
|||
file: "%s.zone"
|
||||
|
||||
zone:
|
||||
# # Master zone
|
||||
# # Primary zone
|
||||
# - domain: example.com
|
||||
# notify: slave
|
||||
# acl: acl_slave
|
||||
# notify: secondary
|
||||
# acl: acl_secondary
|
||||
|
||||
# # Slave zone
|
||||
# # Secondary zone
|
||||
# - domain: example.net
|
||||
# master: master
|
||||
# acl: acl_master
|
||||
# master: primary
|
||||
# acl: acl_primary
|
||||
|
|
|
|||
Loading…
Reference in a new issue