Получение SERVFAIL/NOTAUTH при передаче зоны — ISC BIND 9

У меня есть два сервера BIND, на которых работает BIND 9:

BIND 9.11.36-RedHat-9.11.36-3.el8 (версия с расширенной поддержкой) <id:68dbd5b>
работает в Linux x86_64 4.18.0-372.9.1.el8.x86_64 #1 SMP Вт, 10 мая, 08:57:35 по восточному поясному времени 2022 г.
собрано make с помощью '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '-- prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr /share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr /share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '- -enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '-- with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/ pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '- -with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=no' '-- с-libjson' ' --enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full -report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 - Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin -cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/ rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
скомпилировано GCC 8.5.0 20210514 (Red Hat 8.5.0-10)
скомпилировано с версией OpenSSL: OpenSSL 1.1.1k FIPS 25 марта 2021 г.
ссылка на версию OpenSSL: OpenSSL 1.1.1k FIPS 25 марта 2021 г.
скомпилировано с версией libxml2: 2.9.7
связана с версией libxml2: 20907
скомпилировано с версией libjson-c: 0.13.1
связано с версией libjson-c: 0.13.1
скомпилировано с версией zlib: 1.2.11
связано с версией zlib: 1.2.11
связана с версией maxminddb: 1.2.0
скомпилировано с версией protobuf-c: 1.3.0
связано с версией protobuf-c: 1.3.0
поддержка потоков включена

пути по умолчанию:
  именованная конфигурация: /etc/named.conf
  Конфигурация rndc: /etc/rndc.conf
  Корневой ключ DNSSEC: /etc/bind.keys
  Ключ сеанса nsupdate: /var/run/named/session.key
  именованный файл PID: /var/run/named/named.pid
  именованный файл блокировки: /var/run/named/named.lock
  геоIP-каталог: /usr/share/GeoIP

Главный сервер находится по адресу 172.16.19.243, а дополнительный — по адресу 172.16.19.251. Они могут пинговать друг друга, и порт 53 (UDP и TCP) открыт на обоих. Раньше оба работали, но в нашу автоматизацию ввели новый код, и оба потеряли доступ к сети примерно на два часа. Возможно конфигурация была изменена.

Вторичный не показывает файлы зон в /etc/named/. Передача зоны не удалась:

Вторичный DNS-сервер с именем [546308]: общее: информация: зона 19.16.172.in-addr.arpa/IN: обновление: неожиданный rcode (SERVFAIL) от мастера 172.16.19.251#53 (источник 0.0.0.0#0)

/var/log/named/zone_transfers на основном шоу:

xfer-out: информация: клиент @0x7f48600ebf90 69.61.12.108#47302 (ns4.mydomain.example): неверный запрос на передачу зоны: 'ns4.mydomain.example/IN': неавторизованная зона (NOTAUTH)
... через 3 дня происходит отключение, но логи не появляются...
...через несколько часов после отключения и повторяющееся по сей день...
notify: info: zone mydomain.example/IN: отправка уведомлений (серийный номер 2022051909)
уведомление: информация: зона 19.16.172.in-addr.arpa/IN: отправка уведомлений (серийный номер 2022051909)
уведомление: информация: зона 16.16.172.in-addr.arpa/IN: отправка уведомлений (серийный номер 2022051909)
уведомление: информация: зона 17.16.172.in-addr.arpa/IN: отправка уведомлений (серийный номер 2022051909)
уведомление: информация: зона 18.16.172.in-addr.arpa/IN: отправка уведомлений (серийный номер 2022051909)

Проблема не решается запуском rndc ретрансфер mydomain.example. Запрос AXFR с помощью dig также завершается ошибкой:

копать -t axfr mydomain.example 172.16.19.243

; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> -t axfr mydomain.example 172.16.19.243
;; глобальные параметры: +cmd
; Передача не удалась.
; Передача не удалась.

Запрос записей A и PTR из Интернета для мастер-работ. Делать то же самое со вторичным теперь не удается:

копать @172.16.19.251 191.19.16.172.in-addr.arpa ptr

; <<>> DiG 9.18.2 <<>> @172.16.19.251 191.19.16.172.in-addr.arpa ptr
; (найден 1 сервер)
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: SERVFAIL, id: 57626
;; флаги: qr rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 0, ДОПОЛНИТЕЛЬНО: 1
;; ВНИМАНИЕ: рекурсия запрошена, но недоступна

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; УДП: 1232
; COOKIE: 204e72e23787aef415f9ec7562866219e93a158c23f1f323 (хорошо)
;; РАЗДЕЛ ВОПРОСОВ:
;191.19.16.172.in-addr.arpa. В ПТР

;; Время запроса: 48 мс
;; СЕРВЕР: 172.16.19.251#53(172.16.19.251) (UDP)
;; КОГДА: Чт, 19 мая, 10:28:39 CDT 2022 г.
;; РАЗМЕР MSG rcvd: 83

Файл /etc/named.conf мастера показан ниже:

параметры {
        разрешить запрос {
          никто;
        };
        разрешить передачу {
          никто;
        };
        рекурсия нет;

        auth-nxdomain нет; # соответствует RFC1035
        минимальные ответы да;
        минимальный-любой да;
        dnssec-включить да;
        dnssec-валидация да;
};

зона "." В {
        тип подсказки;
        файл "named.ca";
};

включить "/etc/named.rfc1912.zones";
включить "/etc/named.root.key";

//Системные зоны
зона "mydomain.example" В {
  тип мастер;
  файл "/etc/named/mydomain.example.db";
  разрешить запрос {любой;
  };
  разрешить передачу {
    локальный хост;
    172.16.19.243;
  };
  уведомлять да;
};

зона "16.16.172.in-addr.arpa" IN {
  тип мастер;
  файл "/etc/named/16.16.172.in-addr.arpa.rev";
  разрешить запрос {любой;
  };
  разрешить передачу {
    локальный хост;
    172.16.19.243;
  };
  уведомлять да;
};
// Зоны для 17 - 19 включены в конфиг *точно* такого же формата. Генерируется программно - если есть
// здесь опечатка, значит есть во всех. Передача зон не работает.

/etc/named/16.16.172.in-addr.arpa.rev на мастере выглядит следующим образом:

86400 долларов США

@ В SOA ns3.mydomain.example. admin.mydomain.example. (
                                                2022051917 ;Серийный номер
                                                3600 ;Обновить
                                                1800 ;Повторить
                                                604800 ;Срок действия
                                                86400 ;Минимальный TTL
)

;; Все записи зоны NS
@ В NS ns3.mydomain.example.
@ В NS ns4.mydomain.example.

;; Все записи PTR зоны

* В PTR HDN-UIDO

Опять же, поиск DNS для любой записи не работает на вторичном сервере, но все работает на главном. Перенос зон с главного на вторичный невозможен. Все зоны и конфигурации генерируются программно, поэтому если ошибка в одной зоне, то она будет присутствовать во всех. Других заметных ошибок в логах не обнаружено. Нет отказов SELinux ни на одном из серверов. Права доступа /etc/named/ равны 0770 root:named system_u:object_r:named_conf_t:s0 на обоих серверах. Удаление всех файлов .jnl не помогло (на мастере был только один, а не в /etc/named).

Что может быть причиной? Спасибо.

РЕДАКТИРОВАТЬ 5/19
Я подтвердил, что оба сервера имеют 53/UDP и 53/TCP, открытые друг для друга.

Из вторичного:

dig @172.16.19.243 +tcp 200.18.16.172.in-addr.arpa ptr

; <<>> DiG 9.11.36-RedHat-9.11.36-3.el8 <<>> @172.16.19.243 +tcp 200.18.16.172.in-addr.arpa ptr
; (найден 1 сервер)
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 6246
;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 0, ДОПОЛНИТЕЛЬНО: 1
;; ВНИМАНИЕ: рекурсия запрошена, но недоступна

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; УДП: 1232
; КУКИ: a9c777930fc7d210a2b794de6286b88d1d5f01b2a729a2f5 (хорошо)
;; РАЗДЕЛ ВОПРОСОВ:
;200.18.16.172.in-addr.arpa. В ПТР

;; РАЗДЕЛ ОТВЕТОВ:
200.18.16.172.in-addr.arpa. 86400 IN PTR EHB-DYN.18.16.172.in-addr.arpa.

;; Время запроса: 0 мс
;; СЕРВЕР: 172.16.19.243#53(172.16.19.243)
;; КОГДА: Чт, 19 мая, 16:37:15 CDT 2022 г.
;; РАЗМЕР MSG rcvd: 110

именованная контрольная зона использовался для проверки всех зон. Единственная проблема, о которой сообщалось, заключалась в отсутствии записи для NS4, на что также указывалось в комментариях. Я обратил на это внимание и изменил его на серверах, но это изменение не попало в этот вопрос, когда я его писал. В любом случае это не решило проблему. named-checkconf был запущен на обоих серверах, и оба вернули статус 0.

Подчиненный сервер имеет несколько адресов, но он использует правильный (показанный) адрес для запроса ведущего, что подтверждается перехватом пакетов на ведущем.

Запись A удалена из файла конфигурации обратной зоны. Фрагмент файла выше является точным.