diff options
| -rw-r--r-- | doc/configuration.rst | 74 | ||||
| -rw-r--r-- | doc/introduction.rst | 2 | ||||
| -rw-r--r-- | doc/man/keymgr.8in | 7 | ||||
| -rw-r--r-- | doc/man/knot.conf.5in | 24 | ||||
| -rw-r--r-- | doc/man/knotc.8in | 23 | ||||
| -rw-r--r-- | doc/man_keymgr.rst | 7 | ||||
| -rw-r--r-- | doc/man_knotc.rst | 25 | ||||
| -rw-r--r-- | doc/operation.rst | 26 | ||||
| -rw-r--r-- | doc/reference.rst | 24 | ||||
| -rw-r--r-- | samples/knot.sample.conf.in | 20 |
10 files changed, 122 insertions, 110 deletions
diff --git a/doc/configuration.rst b/doc/configuration.rst index ba8691d1d..3655399f7 100644 --- a/doc/configuration.rst +++ b/doc/configuration.rst @@ -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, diff --git a/doc/introduction.rst b/doc/introduction.rst index f15717074..1f167d1f6 100644 --- a/doc/introduction.rst +++ b/doc/introduction.rst @@ -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 diff --git a/doc/man/keymgr.8in b/doc/man/keymgr.8in index bd574be2a..184e1a530 100644 --- a/doc/man/keymgr.8in +++ b/doc/man/keymgr.8in @@ -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 diff --git a/doc/man/knot.conf.5in b/doc/man/knot.conf.5in index 3d7f2098e..bf75c801a 100644 --- a/doc/man/knot.conf.5in +++ b/doc/man/knot.conf.5in @@ -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 diff --git a/doc/man/knotc.8in b/doc/man/knotc.8in index 1deeb9a4b..33fb6e41f 100644 --- a/doc/man/knotc.8in +++ b/doc/man/knotc.8in @@ -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 diff --git a/doc/man_keymgr.rst b/doc/man_keymgr.rst index a297f7a36..e87d3e49f 100644 --- a/doc/man_keymgr.rst +++ b/doc/man_keymgr.rst @@ -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 diff --git a/doc/man_knotc.rst b/doc/man_knotc.rst index dc872ee8d..cef5cd7fa 100644 --- a/doc/man_knotc.rst +++ b/doc/man_knotc.rst @@ -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 +................................................ :: diff --git a/doc/operation.rst b/doc/operation.rst index ee2160832..03d189401 100644 --- a/doc/operation.rst +++ b/doc/operation.rst @@ -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. diff --git a/doc/reference.rst b/doc/reference.rst index 9e06d31d2..32d2fc8df 100644 --- a/doc/reference.rst +++ b/doc/reference.rst @@ -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 diff --git a/samples/knot.sample.conf.in b/samples/knot.sample.conf.in index 6df291b7d..e53575709 100644 --- a/samples/knot.sample.conf.in +++ b/samples/knot.sample.conf.in @@ -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 |