Seguindo empresa Google sobre a intenção de realizar um experimento para verificar a implementação do 'DNS sobre HTTPS' (DoH, DNS over HTTPS) desenvolvida para o navegador Chrome. Na versão Chrome 78, agendada para 22 de outubro, algumas categorias de usuários serão, por padrão, de uso do DoH. No experimento de habilitação do DoH, participarão apenas os usuários cujas configurações do sistema especificam determinados provedores de DNS reconhecidos como compatíveis com o DoH.
Na lista de provedores de DNS, estão incluídos Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168, 185.228.169.168) e DNS.SB (185.222.222.222, 185.184.222.222). Se nas configurações de DNS do usuário estiver indicado um dos servidores de DNS mencionados, o DoH no Chrome será ativado por padrão. Para aqueles que utilizam servidores DNS fornecidos pelo provedor de internet local, tudo permanecerá inalterado e as consultas de DNS continuarão utilizando o resolvedor do sistema.
Uma diferença importante em relação à implementação do DoH no Firefox, onde a habilitação gradual do DoH por padrão já no final de setembro, é a ausência de um vínculo a um único serviço de DoH. Se no Firefox o servidor DNS padrão é o CloudFlare, no Chrome haverá apenas uma atualização no método de funcionamento com DNS para um serviço equivalente, sem mudança de provedor de DNS. Por exemplo, se o usuário tem configurado o DNS 8.8.8.8 nas configurações do sistema, no Chrome será o serviço DoH do Google ('https://dns.google.com/dns-query'), se o DNS é 1.1.1.1, então o serviço DoH do Cloudflare ('https://cloudflare-dns.com/dns-query'), e Se desejar, o usuário poderá habilitar ou desabilitar o DoH através da configuração 'chrome://flags/#dns-over-https'. Três modos de operação são suportados: 'secure', 'automatic' e 'off'. No modo 'secure', os hosts são determinados apenas com base em valores seguros previamente armazenados em cache (obtidos através de uma conexão segura) e consultas via DoH; o retorno ao DNS comum não é aplicado. No modo 'automatic', se o DoH e o cache seguro não estiverem disponíveis, é permitida a obtenção de dados do cache inseguro e a consulta através do DNS tradicional. No modo 'off', primeiro é verificado o cache geral e se não houver dados, a consulta é enviada através do DNS do sistema. O modo é definido através da
configuração kDnsOverHttpsMode, e o template de correspondência de servidores através de kDnsOverHttpsTemplates.
O experimento para ativar o DoH será realizado em todas as plataformas suportadas pelo Chrome, exceto Linux e iOS, devido à complexidade de analisar as configurações do resolvedor e às restrições de acesso às configurações do DNS. Caso ocorram falhas no envio de solicitações ao servidor DoH após a ativação (por exemplo, devido a bloqueio, interrupção da conectividade de rede ou falha), o navegador retornará automaticamente às configurações padrão do DNS.
O objetivo do experimento é a verificação final da implementação do DoH e a análise do impacto do uso do DoH no desempenho. Vale ressaltar que, na verdade, o suporte ao DoH foi adicionado ao código base do Chrome ainda em fevereiro, mas para configurar e ativar o DoH iniciar o Chrome com uma flag especial e um conjunto não óbvio de opções.
Lembramos que o DoH pode ser útil para evitar vazamentos de informações sobre os nomes de host solicitados através dos servidores DNS dos provedores, combater ataques MITM e a substituição do tráfego DNS (por exemplo, ao conectar-se a redes Wi-Fi públicas), enfrentar bloqueios no nível DNS (o DoH não pode substituir uma VPN para contornar bloqueios implementados no nível DPI) ou organizar a operação quando não é possível o acesso direto aos servidores DNS (por exemplo, ao usar um proxy). Em uma situação normal, as solicitações DNS são enviadas diretamente aos servidores DNS especificados na configuração do sistema; no caso do DoH, a solicitação para determinar o endereço IP do host é encapsulada no tráfego HTTPS e enviada a um servidor HTTP, onde o resolvedor processa as solicitações por meio da API Web. O padrão existente do DNSSEC utiliza criptografia apenas para autenticar o cliente e o servidor, mas não protege o tráfego de interceptação nem garante a privacidade das solicitações.
Fonte: opennet.ru
