☰

BIND9 não está recebendo consultas via IPv6

tag-icon • tag-icon debian bind ipv6
BIND9 não está recebendo consultas via IPv6

Estou testando a atualização de um servidor Debian 10 para Debian 11. O servidor executa bind9 como um DNS autoritativo primário para vários domínios e no Debian 10 está funcionando bem há dois anos. (BIND v.9.11.5) Em um novo teste Debian 11 VPS (BIND 9.16.15), com arquivos de configuração específicos do site copiados (apenas para 1 domínio de teste por enquanto), o bind9 está funcionando normalmente quando consultas (A, AAAA, MX) são enviados por IPv4, mas não há resposta ao usar IPv6.
Eu tenho um firewall nftables que permite a entrada de pacotes para a porta 53, e se eu ativar o log do firewall para UDP dport 53, todos os pacotes de consulta IPv6 e IPv4 serão mostrados.
Quando o bind9 é iniciado, ele informa no syslog que está escutando o endereço IPv6.
ss mostra o processo escutando em IPv6.
Se eu usar rndc queryloge observar o arquivo de log, as consultas IPv4 serão registradas, mas as consultas IPv6 não.
É como se os pacotes UDP recebidos estivessem sendo perdidos entre o firewall e o bind9.
Nenhum outro processo está escutando na porta 53, porque se eu interromper a execução do bind9, ss não listará nada.
Outros serviços (por exemplo, SSH) funcionam perfeitamente em IPv6.
Meu named.conf.optionsfica assim:

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

};

Então, que outros testes posso fazer para resolver isso?

(Há um segundo problema com o BIND que pode não estar relacionado: um erro de “permissão negada” durante uma transferência de zona para um DNS secundário.)

Responder1

Corrigido pela reinicialização!
É possível que eu devesse ter feito isso depois que uma atualização automática do kernel foi feita recentemente. O comportamento certamente não fazia sentido.

ATUALIZAÇÃO: Tendo enfrentado problemas semelhantes novamente, agora suspeito que isso aconteceu porque meu sistema tinha iptables instalado anteriormente por algum outro software. Se o iptables ainda estiver instalado, suas regras poderão persistir na configuração de rede do kernel, de forma invisível para o nftables. Para consertar, tive que remover o pacote iptables e limpar todas as regras de iptables no kernel; o último teria acontecido quando eu reiniciei.

informação relacionada