Depois de dois anos de desenvolvimento, o consórcio ISC apresentou o primeiro lançamento estável da nova e significativa versão do servidor DNS BIND 9.18. O suporte para a versão 9.18 será mantido por três anos até o segundo trimestre de 2025, como parte de um ciclo de suporte expandido. O suporte para a versão 9.11 será encerrado em março, e para a versão 9.16, em meados de 2023. Para o desenvolvimento de funcionalidade na próxima versão estável do BIND, foi formada a versão experimental BIND 9.19.0.
O lançamento do BIND 9.18.0 é notável pela implementação do suporte às tecnologias 'DNS sobre HTTPS' (DoH, DNS over HTTPS) e DNS sobre TLS (DoT, DNS over TLS), bem como o mecanismo XoT (XFR-over-TLS) para transmissão segura de conteúdos de zonas DNS entre servidores (suportado tanto para envio quanto para recepção de zonas via XoT). Com as configurações apropriadas, um único processo named pode agora lidar não apenas com consultas DNS tradicionais, mas também com consultas enviadas usando DNS-over-HTTPS e DNS-over-TLS. O suporte do cliente para DNS-over-TLS está embutido na ferramenta dig, que pode ser usada para enviar consultas sobre TLS ao especificar a flag '+tls'.
A implementação do protocolo HTTP/2, utilizado no DoH, é baseada na biblioteca nghttp2, que está entre as dependências opcionais para compilação. Certificados para DoH e DoT podem ser fornecidos pelo usuário ou gerados automaticamente durante a inicialização.
O processamento de consultas usando DoH e DoT é habilitado através da adição das opções 'http' e 'tls' na diretiva listen-on. Para suportar DNS não criptografado sobre HTTP, as configurações devem especificar 'tls none'. As chaves são definidas na seção 'tls'. As portas padrão de rede 853 para DoT, 443 para DoH e 80 para DNS-over-HTTP podem ser sobrescritas através dos parâmetros tls-port, https-port e http-port. Por exemplo:
tls local-tls { key-file '/path/to/priv_key.pem'; cert-file '/path/to/cert_chain.pem'; }; http local-http-server { endpoints { '/dns-query'; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
Entre as características da implementação do DoH no BIND destaca-se a possibilidade de mover as operações de criptografia para TLS para outro servidor, o que pode ser necessário em situações onde os certificados TLS são armazenados em outro sistema (por exemplo, em uma infraestrutura com servidores web) e são geridos por outra equipe. O suporte para DNS-over-HTTP não criptografado é implementado para facilitar a depuração e servir como um nível para encaminhamento para outro servidor na rede interna (para mover a criptografia para um servidor separado). No servidor externo, o nginx pode ser utilizado para formar o tráfego TLS, semelhante à forma como a ligação HTTPS é organizada para sites.
Outra característica é a integração do DoH como um transporte comum, que pode ser aplicado não apenas para o processamento das solicitações dos clientes para o resolvedor, mas também na troca de dados entre servidores, na transmissão de zonas por um servidor DNS autoritativo e no processamento de quaisquer solicitações suportadas por outros transportes DNS.
Entre as desvantagens, que podem ser compensadas pela desativação da construção com DoH/DoT ou pelo deslocamento da criptografia para outro servidor, destaca-se a complexidade geral da base de código — um servidor HTTP embutido e uma biblioteca TLS são adicionados, os quais podem potencialmente conter vulnerabilidades e atuar como vetores adicionais para ataques. Além disso, o uso do DoH aumenta o tráfego.
Vale lembrar que o DNS-over-HTTPS pode ser útil para eliminar vazamentos de informações sobre os nomes de hosts solicitados através dos servidores DNS dos provedores, combater ataques MITM e a substituição do tráfego DNS (por exemplo, ao se conectar a Wi-Fi público), e enfrentar bloqueios a nível de DNS (o DNS-over-HTTPS não pode substituir VPN no âmbito da superação de bloqueios implementados a nível de DPI) ou para possibilitar o funcionamento em caso de impossibilidade de conexão direta aos servidores DNS (por exemplo, ao operar através de um proxy). Se em uma situação comum as solicitações DNS são enviadas diretamente para os servidores DNS especificados na configuração do sistema, no caso do DNS-over-HTTPS a solicitação para determinar endereços IP o host é encapsulada no tráfego HTTPS e enviada para o servidor HTTP, onde o resolvedor processa as solicitações através da API Web.
«DNS over TLS» difere de «DNS over HTTPS» pela utilização do protocolo padrão DNS (geralmente utilizando a porta de rede 853), encapsulado em um canal de comunicação criptografado, estabelecido por meio do protocolo TLS, com validação do host através de certificados TLS/SSL, assinados por uma autoridade certificadora. O padrão existente DNSSEC utiliza criptografia apenas para autenticação do cliente e do servidor, mas não protege o tráfego contra interceptação e não garante a confidencialidade das consultas.
Algumas outras inovações:
- Adicionadas as configurações tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer para definir os tamanhos dos buffers utilizados no envio e recebimento de consultas via TCP e UDP. Em servidores sobrecarregados, o aumento dos buffers de entrada permitirá evitar a perda de pacotes durante picos de tráfego, enquanto a diminuição ajudará a eliminar a saturação da memória com consultas antigas.
- Adicionada uma nova categoria de logs «rpz-passthru», permitindo registrar separadamente as ações de passagem do RPZ (Response Policy Zones).
- Na seção response-policy, foi adicionada a opção «nsdname-wait-recurse», onde, ao definir como «no», as regras RPZ NSDNAME são aplicadas apenas se, para a consulta, forem encontrados servidores de nomes autorizados presentes no cache; caso contrário, a regra RPZ NSDNAME é ignorada, mas as informações são extraídas em segundo plano e aplicadas a consultas subsequentes.
- Para registros dos tipos HTTPS e SVCB, foi implementado o processamento da seção «ADDITIONAL».
- Adicionados tipos de regras customizáveis update-policy — krb5-subdomain-self-rhs e ms-subdomain-self-rhs, permitindo restringir a atualização de registros SRV e PTR. Nos blocos update-policy, também foi adicionada a possibilidade de definir restrições no número de registros, específicas para cada tipo.
- A saída da ferramenta dig foi ampliada com informações sobre o protocolo de transporte (UDP, TCP, TLS, HTTPS) e prefixos DNS64. Para fins de depuração, a ferramenta dig agora permite especificar um identificador de consulta específico (dig +qid=).
- Suporte adicionado para a biblioteca OpenSSL 3.0.
- Para resolver problemas de fragmentação de IP ao processar mensagens DNS grandes, conforme a iniciativa DNS Flag Day 2020, o código que realizava ajustes no tamanho do buffer EDNS em caso de ausência de resposta às consultas foi removido do resolvedor. O tamanho do buffer EDNS agora é definido como fixo (edns-udp-size) para todas as consultas de saída.
- O sistema de construção foi migrado para uma combinação de autoconf, automake e libtool.
- O suporte para arquivos de zona no formato «map» (masterfile-format map) foi interrompido. Os usuários deste formato são aconselhados a converter as zonas para o formato raw usando a ferramenta named-compilezone.
- O suporte para os antigos drivers DLZ (Dynamically Loadable Zones) foi descontinuado, sendo substituído pelos módulos DLZ.
- O suporte para compilação e execução na plataforma Windows foi encerrado. A última versão que pode ser instalada no Windows é o BIND 9.16.
Fonte: opennet.ru
