Resumo

  • DoH protege o canal entre cliente e resolvedor, mas não determina qual resolvedor pertence ao contexto do usuário.
  • A descoberta permite ao cliente trocar o resolvedor conhecido da rede por seu serviço criptografado correspondente; a seleção continua sendo uma decisão do cliente.
  • Espaço de nomes, filtragem, fallback e jurisdição dos registros acompanham a escolha do resolvedor.
  • Um mapa de política deve ligar designação, autenticação, seleção, contexto de nomes e práticas de dados.

Considere um cenário hipotético. Dois notebooks gerenciados entram na mesma rede do escritório. O sistema operacional do primeiro descobre e valida o serviço criptografado do resolvedor designado pela rede; um nome interno continua funcionando. No segundo, o navegador seleciona um serviço DoH público. A conexão TLS está saudável, mas o nome privado desaparece e o controle DNS da rede fica fora do caminho. A diferença não está na criptografia. Está em quem escolheu a autoridade de resolução e na política que veio com ela.

A RFC 8484 transporta cada par de consulta e resposta DNS em uma troca HTTPS. O TLS fornece confidencialidade e integridade. A mesma RFC observa que política local e DNS dividido podem fazer servidores distintos responderem de maneira diferente à mesma consulta. Sistemas de inspeção dependentes de DNS sem proteção também deixam de funcionar para o tráfego DoH. A proteção do canal, portanto, torna mais visível uma escolha de governança antes implícita.

A RFC 9462 disciplina a descoberta. O DDR permite passar de um resolvedor conhecido e não criptografado para um serviço criptografado do mesmo operador ou de uma entidade cooperante. Verified Discovery exige cadeia de certificados válida e um subjectAltName de endereço IP que cubra o resolvedor de origem. Opportunistic Discovery permite o serviço criptografado quando ele usa o mesmo endereço IP do serviço não criptografado e recomenda esse modo apenas para endereços privados ou locais. O transporte fica protegido, mas a identidade do resolvedor não é autenticada pelo nome do certificado.

Os dois métodos oferecem garantias diferentes e não eliminam a política de seleção do cliente.

A RFC 9463 permite que a rede designe resolvedores criptografados por DHCPv4, DHCPv6 ou Router Advertisement IPv6. A oferta pode trazer domínio de autenticação, endereços, protocolos e prioridade. Designar, porém, não significa obrigar. Sistema e aplicativo podem aceitar, comparar ou recusar. A responsabilidade passa a atravessar rede de acesso, plataforma, aplicativo e operador do serviço.

A governança dos dados também muda. A RFC 8932 recomenda minimizar a coleta, manter registros operacionais pelo menor período viável, limitar o acesso de pessoas e explicar as práticas. Trocar o resolvedor pode alterar local de processamento, retenção, jurisdição e as evidências disponíveis durante um incidente.

O controle prático é um mapa de política do resolvedor. Para cada grupo de clientes e contexto de rede, registrar o responsável pela política e o momento da decisão, quem fez a indicação, como a identidade foi autenticada, qual componente escolheu o serviço, quais nomes são atendidos, quais controles se aplicam e qual fallback é permitido. O mapa também identifica o responsável por consultas e logs, o prazo de retenção e a jurisdição aplicável. É preciso testar nomes públicos e privados e repetir a validação após mudanças em navegador, sistema, DHCP, certificado ou endpoint.

Fontes