BIND9 no recibe consultas sobre IPv6

Question

Estoy probando la actualización de un servidor Debian 10 a Debian 11. El servidor ejecuta bind9 como DNS autorizado principal para varios dominios y en Debian 10 ha estado funcionando bien durante dos años. (BIND v.9.11.5) En un nuevo VPS Debian 11 de prueba (BIND 9.16.15), con archivos de configuración específicos del sitio copiados (solo para 1 dominio de prueba por ahora), bind9 funciona normalmente cuando se realizan consultas (A, AAAA, MX) se envían a través de IPv4, pero no hay respuesta cuando se usa IPv6.
Tengo un firewall nftables que permite paquetes entrantes para el puerto 53, y si activo el registro del firewall para el puerto UDP 53, se muestran todos los paquetes de consulta IPv6 e IPv4.
Cuando se inicia bind9, informa en syslog que está escuchando en la dirección IPv6.
ss muestra el proceso de escucha en IPv6.
Si uso rndc querylogy miro el archivo de registro, las consultas de IPv4 se registran, pero las consultas de IPv6 no.
Es como si los paquetes UDP entrantes se perdieran entre el firewall y bind9.
Ningún otro proceso está escuchando en el puerto 53, porque si detengo la ejecución de bind9, ss no muestra nada.
Otros servicios (por ejemplo, SSH) funcionan perfectamente en IPv6.
Mi named.conf.optionsaspecto es este:

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; };

};

Entonces, ¿qué otras pruebas puedo hacer para resolver esto?

(Hay un segundo problema con BIND que puede no estar relacionado: un error de "permiso denegado" durante una transferencia de zona a un DNS secundario).

Answer 1

¡Se solucionó reiniciando!
Es posible que debería haber hecho esto después de que se realizó recientemente una actualización automática del kernel. El comportamiento ciertamente no tenía ningún sentido.

ACTUALIZACIÓN: Habiendo tenido problemas similares nuevamente, ahora sospecho que esto sucedió porque mi sistema tenía iptables previamente instalado por algún otro software. Si iptables todavía está instalado, sus reglas pueden persistir en la configuración de red del kernel, de manera invisible para nftables. Para solucionarlo, tuve que eliminar el paquete iptables y borrar todas las reglas de iptables en el kernel; esto último habría sucedido cuando reinicié.