Os desenvolvedores do servidor DNS BIND anunciaram a adição ao ramo experimental 9.17 da implementação de suporte ao servidor para as tecnologias 'DNS sobre HTTPS' (DoH, DNS over HTTPS) e DNS sobre TLS (DoT, DNS over TLS), assim como um mecanismo XFR-over-TLS para transmissão segura do conteúdo das zonas DNS entre servidores. O DoH está disponível para testes na versão 9.17.10, enquanto o suporte ao DoT está presente desde a versão 9.17.7. Após a estabilização, o suporte ao DoT e DoH será retroportado para o ramo estável 9.16.
A implementação do protocolo HTTP/2, utilizado no DoH, baseia-se na aplicação da biblioteca nghttp2, que está entre as dependências de compilação (posteriormente, a biblioteca deve ser transferida para as dependências opcionais). Conexões tanto criptografadas (TLS) quanto não criptografadas via HTTP/2 são suportadas. Com as configurações adequadas, um processo named agora pode atender não apenas às solicitações DNS tradicionais, mas também às solicitações enviadas usando DoH (DNS-over-HTTPS) e DoT (DNS-over-TLS). O suporte a HTTPS no lado do cliente (dig) ainda não foi implementado. O suporte ao XFR-over-TLS está disponível tanto para solicitações de entrada quanto para solicitações de saída.
O processamento de solicitações usando DoH e DoT é ativado ao adicionar opções http e tls na diretiva listen-on. Para suportar DNS-over-HTTP não criptografado, deve-se 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-over-HTTP podem ser redefinidas através das opções 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 integração como um transporte comum, que pode ser aplicado não apenas para o tratamento de solicitações dos clientes ao resolvedor, mas também na troca de dados entre servidores, na transmissão de zonas pelo servidor DNS autoritativo e ao processar quaisquer solicitações suportadas por outros transportes DNS.
Outra característica é a possibilidade de transferir 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 gerenciados por outra equipe. O suporte a DNS não criptografado sobre HTTP foi implementado para simplificar a depuração e como um nível para encaminhamento em uma rede interna, baseado no qual a criptografia pode ser organizada em outro servidor. No servidor externo, o nginx pode ser usado para formar o tráfego TLS, de maneira semelhante à forma como a ligação HTTPS é organizada para sites.
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.
Fonte: opennet.ru
