Os desenvolvedores do servidor DNS BIND anunciaram a adição de suporte de servidor para as tecnologias DNS sobre HTTPS (DoH, DNS sobre HTTPS) e DNS sobre TLS (DoT, DNS sobre TLS), bem como o mecanismo XFR-over-TLS para segurança transferir o conteúdo das zonas DNS entre servidores. DoH está disponível para teste na versão 9.17, e o suporte DoT está presente desde a versão 9.17.10. Após a estabilização, o suporte DoT e DoH será portado para o branch estável 9.17.7.
A implementação do protocolo HTTP/2 utilizado no DoH é baseada no uso da biblioteca nghttp2, que está incluída entre as dependências assembly (no futuro, a biblioteca está prevista para ser transferida para o número de dependências opcionais). São suportadas conexões HTTP/2 criptografadas (TLS) e não criptografadas. Com as configurações apropriadas, um único processo nomeado agora pode atender não apenas consultas DNS tradicionais, mas também consultas enviadas usando DoH (DNS sobre HTTPS) e DoT (DNS sobre TLS). O suporte HTTPS no lado do cliente (dig) ainda não foi implementado. O suporte XFR sobre TLS está disponível para solicitações de entrada e saída.
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;}; }
Dentre as características da implementação do DoH no BIND, destaca-se a integração como um transporte geral, que pode ser utilizado não apenas para processar solicitações de clientes ao resolvedor, mas também na troca de dados entre servidores, na transferência de zonas por um servidor DNS autoritativo, e ao processar quaisquer solicitações suportadas por outros transportes DNS.
Outro recurso é a capacidade de mover operações de criptografia de 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 outras pessoas. O suporte para DNS sobre HTTP não criptografado é implementado para simplificar a depuração e como uma camada de encaminhamento na rede interna, com base na qual a criptografia pode ser organizada em outro servidor. Em um servidor remoto, o nginx pode ser usado para gerar tráfego TLS, semelhante à forma como a ligação HTTPS é organizada para sites.
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.
Fonte: opennet.ru