На одном из серверов была проблема: после ребута время устанавливалось на час вперёд. После синхронизации по NTP время исправлялось.
Временная зона правильная. Вероятно неправильное время указано в BIOS, но проверить всё не получалось — думал для этого надо перегружать сервер. Но оказалось, что можно проверить и исправить время в BIOS прямо из операционной системы.

Посмотрел время в BIOS и убедился, что время на час вперёд:
#hwclock
Wed 13 Nov 2019 07:49:18 PM +06 -0.250483 seconds

Поменял время:
#hwclock --set --date «Wed 13 Nov 2019 06:54 PM»

Проверил — всё нормально теперь:
#hwclock
Wed 13 Nov 2019 06:54:03 PM +06 -0.130003 seconds

Все команды, в том числе для просмотра, должны выполняться от пользователя root.

Запарила служба NetworkManager, с ней толком непонятно что и почему не работает. То фиг разберёшь где ДНС-серверы указать, то не перезапускаются нормально сетевые настройки, то аська не подключается…
Довольно часто встречается совет вырубить нафиг эту службу. А, действительно, работал же я под ФриБСД без неё.
Остановить службу можно вот так:

sudo service NetworkManager stop

И, о чудо, перезапуск сети работает без ошибок, аська подключилась без проблем.

Убедимся, что эта служба не запустится после ребута:

#chkconfig --list | grep NetworkManager
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off

Ставим нужные пакеты:
yum install fuse fuse-ntfs-3g

И система автоматически монтирует диск, а можно примонтировать вручную, очевидно как-то так:
mount -t ntfs-3g /dev/sXY /mnt/mydisk

Пипец, в CentOS 8 теперь нельзя установить ntpdate, чтобы синхронизировать время с NTP-серверов. Теперь, блин, надо, видите ли, запускать новый демон чтобы просто синхронизировать время.
А как без ntpdate проверить работает ли какой-либо NTP-сервер вообще непонятно. Это я чтоли должен настроить полноценную синхронизацию и ждать сообщения в логах? А мне, блин, не надо синхронизироваться, мне надо просто посмотреть отвечает ли сервер и прям в данный момент интерактивно!
Кроме матов больше слов нет…

Настройка NTP-клиента на CentOS 8.

Посмотреть настройки времени:
timedatectl

Задать часовой пояс:
timedatectl set-timezone Asia/Bishkek

В конфиге нового демона убрать строку с ненужными серверами и указать нужные серверы — источники времени:
#pool 2.centos.pool.ntp.org iburst
server ntp1.domain.tld.
server ntp2.domain.tld.

Запустить новый демон:
systemctl start chronyd

Включить синхронизацию времени:
timedatectl set-ntp true

Подождать какое-то время пока не обновится время в системе или смотреть за логами и ждать появится ли там запись о подстройке времени.

Посмотреть список обновлений для всего, в том числе ядро:
yum check-update

Обновить всё и без запроса подтверждения:
yum -y update

Посмотреть версию CentOS:
cat /etc/redhat-release

Посмотреть версию ядра:
uname -a

Краткая памятка для настройки superslave в powerdns.

Указываем следующие опции в файле /etc/powerdns/pdns.conf:

superslave=yes
launch=gmysql
gmysql-host=localhost
gmysql-user=pdns
gmysql-dbname=pdns
gmysql-password=123456

Создаём базу данных, пользователя и даём ему права на эту БД:

create database pdns DEFAULT CHARACTER SET = utf8 DEFAULT COLLATE = utf8_unicode_ci;
create user pdns@localhost IDENTIFIED BY '123456';
grant all on pdns.* to pdns@localhost;
flush privileges;

Создаём таблицы в БД из файла, который должен был быть установлен в комплекте с pdns:

mysql -u pdns -p pdns < /usr/share/pdns-backend-mysql/schema/schema.mysql.sql

Добавить первичные ДНС-серверы для ваших доменов в таблицу supermasters (один раз, а не для каждого домена):

INSERT INTO `supermasters` VALUES ('10.1.1.1','ns1.domain.tld','internal');
INSERT INTO `supermasters` VALUES ('10.1.1.2','ns2.domain.tld','internal');

На этих серверах должен быть разрешён трансфер доменов для вашего superslave-сервера. Проверить можно как-то так:

dig -t axfr @ns1.domain.tld domain2.tld

Superslave-сервер откачает домен после получения notify — уведомления про изменения в домене, так что первичный сервер должен отправлять эти самые уведомления. Обычно, это надо настроить явным образом, т.к. по-умолчанию ДНС-сервер отправляет уведомления только серверам, указанным как авторитетные серверы для этого домена. В bind указать кому ещё отправлять уведомления можно при помощи опции also-notify.
На сервере с bind можно вручную, не производя изменения в домене, отправить уведомления командой rndc:

rndc notify domain2.tld

Если доменов много, то можно отправить уведомления однострочным скриптом типа такого:

grep "^zone " bind-zones-file.conf | sed -e's/zone "//' -e's/" {//' | while read i;do echo $i;rndc notify $i;sleep 2;done

Это работает если домены в файле bind-zones-file.conf описаны как-то вот так:

zone "domain2.tld" {
...
};

К сожалению, логи pdns указывают на причину проблемы не прямо, а какими-то намёками. Например, вот это, если не ошибаюсь, говорит о том, что нет прав на трансфер домена с мастера:

pdns_server[282496]: Error resolving SOA or NS for domain2.tld at: 10.1.1.1: Query to '10.1.1.1' for SOA of 'domain2.tld' produced a NS record

А вот это говорит о том, что нет подходящего мастера в таблице supermasters:

pdns_server[284836]: Unable to find backend willing to host domain2.tld for potential supermaster 10.1.1.1. Remote nameservers:
pdns_server[284836]: ns1.domain.tld
pdns_server[284836]: ns2.domain.tld