Após dois anos de desenvolvimento, o consórcio ISC lançou a primeira versão estável de uma nova ramificação importante do servidor DNS BIND 9.18. O suporte para a filial 9.18 será fornecido por três anos até o 2º trimestre de 2025 como parte de um ciclo de suporte estendido. O suporte para a ramificação 9.11 terminará em março e o suporte para a ramificação 9.16 em meados de 2023. Para desenvolver a funcionalidade da próxima versão estável do BIND, um ramo experimental BIND 9.19.0 foi formado.
O lançamento do BIND 9.18.0 é notável pela implementação de suporte para DNS sobre HTTPS (DoH, DNS sobre HTTPS) e DNS sobre TLS (DoT, DNS sobre TLS), bem como o mecanismo XoT (XFR-over-TLS) para transferência segura de conteúdo DNS entre servidores (são suportadas zonas de envio e recebimento via XoT). Com as configurações apropriadas, um único processo nomeado agora pode atender não apenas consultas DNS tradicionais, mas também consultas enviadas usando DNS sobre HTTPS e DNS sobre TLS. O suporte do cliente para DNS sobre TLS está integrado no utilitário dig, que pode ser usado para enviar solicitações por TLS quando o sinalizador "+tls" é especificado.
A implementação do protocolo HTTP/2 usado no DoH é baseada no uso da biblioteca nghttp2, que está incluída como uma dependência opcional do assembly. Certificados para DoH e DoT podem ser fornecidos pelo usuário ou gerados automaticamente no momento da inicialização.
O processamento de solicitações usando DoH e DoT é habilitado adicionando as opções "http" e "tls" à diretiva listen-on. Para oferecer suporte a DNS sobre HTTP não criptografado, você deve especificar “tls none” nas configurações. As chaves são definidas na seção "tls". As portas de rede padrão 853 para DoT, 443 para DoH e 80 para DNS sobre HTTP podem ser substituídas por meio dos parâmetros tls-port, https-port e http-port. Por exemplo:
tls local-tls { arquivo-chave "/caminho/para/priv_key.pem"; arquivo cert "/caminho/para/cert_chain.pem"; }; http local-http-servidor { endpoints { "/dns-query"; }; }; opções { https-porta 443; porta de escuta 443 tls local-tls http meuservidor {qualquer;}; }
Uma das características da implementação do DoH no BIND é a capacidade de mover operações de criptografia para TLS para outro servidor, o que pode ser necessário em condições onde os certificados TLS são armazenados em outro sistema (por exemplo, em uma infraestrutura com servidores web) e mantidos por outro pessoal. O suporte para DNS sobre HTTP não criptografado é implementado para simplificar a depuração e como uma camada para encaminhamento para outro servidor na rede interna (para mover a criptografia para um servidor separado). Em um servidor remoto, o nginx pode ser usado para gerar tráfego TLS, semelhante à forma como a ligação HTTPS é organizada para sites.
Outra característica é a integração do DoH como um transporte geral que pode ser usado não apenas para lidar com solicitações de clientes ao resolvedor, mas também na comunicação entre servidores, na transferência de zonas por um servidor DNS autoritativo e no processamento de quaisquer consultas suportadas por outro DNS. transportes.
Entre as deficiências que podem ser compensadas desabilitando a construção com DoH/DoT ou movendo a criptografia para outro servidor, destaca-se a complicação geral da base de código - são adicionados um servidor HTTP integrado e uma biblioteca TLS, que poderia potencialmente conter vulnerabilidades e atuam como vetores adicionais para ataques. Além disso, ao usar DoH, o tráfego aumenta.
Lembremos que DNS-over-HTTPS pode ser útil para prevenir vazamentos de informações sobre os nomes de host solicitados através dos servidores DNS dos provedores, combater ataques MITM e falsificação de tráfego DNS (por exemplo, ao conectar-se a uma rede Wi-Fi pública), combater bloqueio no nível DNS (DNS sobre HTTPS não pode substituir uma VPN ao contornar o bloqueio implementado no nível DPI) ou para organizar o trabalho quando é impossível acessar diretamente os servidores DNS (por exemplo, ao trabalhar através de um proxy). Se em uma situação normal as solicitações DNS são enviadas diretamente para servidores DNS definidos na configuração do sistema, então no caso de DNS sobre HTTPS a solicitação para determinar o endereço IP do host é encapsulada no tráfego HTTPS e enviada ao servidor HTTP, onde o resolvedor processa solicitações por meio da API da Web.
“DNS sobre TLS” difere de “DNS sobre HTTPS” no uso do protocolo DNS padrão (geralmente é usada a porta de rede 853), envolto em um canal de comunicação criptografado organizado usando o protocolo TLS com verificação de validade do host por meio de certificados TLS/SSL certificados por uma autoridade de certificação. O padrão DNSSEC existente utiliza criptografia apenas para autenticar o cliente e o servidor, mas não protege o tráfego contra interceptação e não garante a confidencialidade das solicitações.
Algumas outras inovações:
- Adicionadas configurações tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer para definir os tamanhos dos buffers usados ao enviar e receber solicitações por TCP e UDP. Em servidores ocupados, aumentar os buffers de entrada ajudará a evitar que os pacotes sejam descartados durante picos de tráfego, e diminuí-los ajudará a eliminar o entupimento da memória com solicitações antigas.
- Uma nova categoria de log “rpz-passthru” foi adicionada, que permite registrar separadamente ações de encaminhamento de RPZ (Zonas de Política de Resposta).
- Na seção de política de resposta foi adicionada a opção “nsdname-wait-recurse”, quando definida como “no”, as regras RPZ NSDNAME são aplicadas somente se servidores de nomes autoritativos presentes no cache forem encontrados para a solicitação, caso contrário o A regra RPZ NSDNAME é ignorada, mas as informações são recuperadas em segundo plano e aplicadas a solicitações subsequentes.
- Para registros com tipos HTTPS e SVCB, foi implementado o processamento da seção “ADDICIONAL”.
- Adicionados tipos de regras de política de atualização personalizadas - krb5-subdomain-self-rhs e ms-subdomain-self-rhs, que permitem limitar a atualização de registros SRV e PTR. Os blocos de política de atualização também adicionam a capacidade de definir limites no número de registros, individuais para cada tipo.
- Adicionadas informações sobre o protocolo de transporte (UDP, TCP, TLS, HTTPS) e prefixos DNS64 à saída do utilitário dig. Para fins de depuração, dig adicionou a capacidade de especificar um identificador de solicitação específico (dig +qid= ).
- Adicionado suporte para biblioteca OpenSSL 3.0.
- Para resolver problemas de fragmentação de IP ao processar grandes mensagens DNS identificadas pelo DNS Flag Day 2020, o código que ajusta o tamanho do buffer EDNS quando não há resposta a uma solicitação foi removido do resolvedor. O tamanho do buffer EDNS agora está definido como constante (edns-udp-size) para todas as solicitações de saída.
- O sistema de compilação passou a usar uma combinação de autoconf, automake e libtool.
- O suporte para arquivos de zona no formato “mapa” (mapa em formato masterfile) foi descontinuado. Recomenda-se que os usuários deste formato convertam zonas em formato bruto usando o utilitário nomeado-compilezone.
- O suporte para drivers DLZ (zonas dinamicamente carregáveis) mais antigos foi descontinuado e substituído por módulos DLZ.
- O suporte de compilação e execução para a plataforma Windows foi descontinuado. O último branch que pode ser instalado no Windows é o BIND 9.16.
Fonte: opennet.ru