Я тестирую обновление сервера Debian 10 до Debian 11.
На сервере работает bind9 в качестве основного авторитетного DNS для ряда доменов, и на Debian 10 он отлично работает уже два года. (СВЯЗАТЬ v.9.11.5)
На новом тестовом Debian 11 VPS (BIND 9.16.15) с скопированными специфичными для сайта файлами конфигурации (пока только для 1 тестового домена) bind9 работает нормально, когда запросы (A, AAAA, MX) отправляются по IPv4, но нет ответа при использовании IPv6.
У меня есть брандмауэр nftables, который разрешает входящие пакеты для порта 53, и если я включу ведение журнала брандмауэра для UDP dport 53, будут показаны все пакеты запросов IPv6 и IPv4.
Когда bind9 запускается, он сообщает в системном журнале, что прослушивает адрес IPv6.
ss показывает, как процесс прослушивает IPv6.
Если я использую журнал запросов rndc и посмотрите файл журнала, запросы IPv4 регистрируются, а запросы IPv6 - нет.
Как будто входящие пакеты UDP теряются между брандмауэром и bind9.
Ни один другой процесс не прослушивает порт 53, потому что, если я остановлю запуск bind9, ss ничего не выдаст.
Другие сервисы (например, SSH) отлично работают на IPv6.
Мой named.conf.options выглядит так:
параметры {
директория "/var/cache/bind";
разрешить-запрос-кэш {нет; };
разрешить запрос { любой; };
рекурсия нет;
//=============================================== ========================
// Если BIND регистрирует сообщения об ошибках об истечении срока действия корневого ключа,
// вам нужно будет обновить ваши ключи. См. https://www.isc.org/bind-keys
//=============================================== ========================
автоматическая проверка dnssec;
слушать на v6 порт 53 { любой; };
};
Итак, какие еще тесты я могу сделать, чтобы решить эту проблему?
(Существует вторая проблема с BIND, которая может быть несвязанной: ошибка «Отказано в доступе» во время передачи зоны на вторичный DNS.)
