
Tenho um servidor DNS rodando dentro de nossa rede privada no IP 10.10.0.10. Os servidores DNS resolvem URLs para IPs privados também dentro de nossa rede. SSL para todos os URLs é tratado por um certificado curinga para um domínio .BIZ. Mas recentemente o Chrome e o Firefox começaram a ativar DNS sobre HTTPS durante atualizações recentes. Como nosso servidor DNS não é compatível com DOH, os usuários não podem navegar para nossos URLs, a menos que desabilitem o recurso DOH em seus navegadores.
Idealmente, gostaria que nossos usuários mantivessem o DOH habilitado em seus navegadores e ainda confiassem no servidor DNS local para resolver URLs para nossos IPs privados. Na tentativa de conseguir isso, olhei paradoh-proxy. Ativei uma VM Centos-7 no IP 10.10.0.20, instalei o doh-proxy e abri a porta 443. Em seguida, executei:
/usr/local/bin/doh-proxy --upstream-resolver=10.10.0.10 --certfile=/etc/pki/public/mycompany.bundle.biz.crt --keyfile=/etc/pki/private/mycompany.biz.pem
Usando o netstat, verifiquei que a porta 443 estava escutando. Em seguida, modifiquei minha configuração de VPN para alterar a configuração de DNS de 10.10.0.10 para 10.10.0.20 (o novo servidor doh-proxy). Porém ainda não consegui navegar para nossos URLs com o DOH habilitado no navegador.
Estou entendendo mal a intenção por trás do doh-proxy?
Responder1
Não acho que você tenha entendido mal a intenção por trás doh-proxy
, parece ser um frontend DoH para um servidor resolvedor DNS regular, criando uma maneira para os clientes DoH consultarem o referido servidor resolvedor.
Existem várias outras soluções de proxy, caso esta implementação específica não seja adequada por qualquer motivo.
O que acredito que você pode ter entendido mal/esquecido, entretanto, é que para configurar o DoH, o cliente precisa saber a URL do servidor DoH (por exemplo https://dns.quad9.net/dns-query
, https://dns.google/dns-query
, , etc), ter apenas um endereço IP não faz nada para configurar o DoH.
E, para dificultar as coisas, o DoH não possui atualmente nenhum mecanismo de descoberta adequado. (Qual é a causa raiz de muita controvérsia em torno do DoH, especialmente com a abordagem da Mozilla.)
Exemplos de como "DoH habilitado por padrão" funciona neste momento:
- O Firefox está configurado para saber qual servidor DoH usar (a Mozilla escolhe um serviço DoH em nome de seus usuários, desconsiderando a configuração do sistema operacional).
- O Chrome atualiza seletivamente de DNS simples para DoH com base em uma tabela de mapeamento com endereços IP conhecidos de serviços DNS como chave, por exemplo
8.8.8.8 -> https://dns.google/dns-query
(o Google mantém uma tabela de mapeamento para serviços DNS conhecidos e a atualização do DoH só ocorre quando a tabela de mapeamento facilita consultando o mesmo serviço DNS que a configuração do sistema operacional indica para DNS simples).
Resumindo, é fácil executar seu próprio serviço DoH, mas não necessariamente fácil fazer com que os clientes o utilizem.
O que você precisa fazer é, de alguma forma, dizer aos clientes para usarem https://dns.example.com/dns-query
(se assumirmos que este é o URL adequado para o seu proxy) como seu endpoint DoH, o que em sua forma mais simples provavelmente significa configuração manual nos clientes (por aplicativo, nada menos) .
Certamente você pode encontrar maneiras de automatizar a configuração de um conjunto de aplicativos conhecidos, mas neste momento não existe um método de descoberta estabelecido comparável a como, por exemplo, o DHCP pode fornecer os endereços para DNS simples.