☰

BIND9 не получает запросы по IPv6

tag-icon • tag-icon debian bind ipv6
BIND9 не получает запросы по IPv6

Я тестирую обновление сервера Debian 10 до Debian 11. На сервере в качестве основного авторитетного DNS для ряда доменов работает bind9, и на Debian 10 он работает нормально уже два года. (BIND v.9.11.5) На новом тестовом Debian 11 VPS (BIND 9.16.15) с скопированными файлами конфигурации для конкретного сайта (пока только для одного тестового домена) bind9 работает нормально, когда запросы (A, AAAA, MX) отправляются по IPv4, но при использовании IPv6 ответа нет.
У меня есть брандмауэр nftables, который разрешает входящие пакеты для порта 53, и если я включаю ведение журнала брандмауэра для UDP dport 53, отображаются все пакеты запросов IPv6 и IPv4.
Когда bind9 запускается, он сообщает в syslog, что он прослушивает адрес IPv6.
ss показывает процесс, прослушивающий IPv6.
Если я использую rndc querylogи просматриваю файл журнала, запросы IPv4 регистрируются, а запросы IPv6 — нет.
Это как если бы входящие пакеты UDP терялись между брандмауэром и bind9.
Никакие другие процессы не прослушивают порт 53, потому что если я останавливаю запуск bind9, ss ничего не выводит.
Другие службы (например, SSH) отлично работают на IPv6.
Мой named.conf.optionsвыглядит так:

options {
    directory "/var/cache/bind";

  allow-query-cache { none; };
  allow-query { any; };
  recursion no;

    //========================================================================
    // If BIND logs error messages about the root key being expired,
    // you will need to update your keys.  See https://www.isc.org/bind-keys
    //========================================================================

  dnssec-validation auto;

  listen-on-v6 port 53 { any; };

};

Какие еще тесты я могу провести, чтобы решить эту проблему?

(Существует вторая проблема с BIND, которая может быть не связана с предыдущей: ошибка «отказано в доступе» во время передачи зоны на вторичный DNS.)

решение1

Исправлено перезагрузкой!
Возможно, мне следовало это сделать после недавнего автоматического обновления ядра. Такое поведение определенно не имело никакого смысла.

ОБНОВЛЕНИЕ: Столкнувшись с похожими проблемами снова, я теперь подозреваю, что это произошло из-за того, что в моей системе iptables был ранее установлен каким-то другим программным обеспечением. Если iptables все еще установлен, его правила могут сохраняться в сетевой конфигурации ядра, невидимые для nftables. Чтобы исправить это, мне пришлось удалить пакет iptables и очистить все правила iptables в ядре; последнее произошло бы при перезагрузке.

Связанный контент