O DNS público do Google fornece duas APIs de DoH distintas nestes endpoints:
A página Visão geral dos transportes seguros
tem exemplos de linha de comando curl para usar as duas APIs, além de detalhes de
TLS e outros recursos comuns ao DNS sobre TLS (DoT) e DoH.
O DoH também é compatível com o serviço DNS64 público do Google apenas para IPv6.
O DNS público do Google não é compatível com URLs http: não seguros para chamadas de API.
Métodos HTTP
- DOWNLOAD
- Use o método GET para reduzir a latência, já que ele é armazenado em cache com mais eficiência.
As solicitações GET RFC 8484 precisam ter um parâmetro de consulta
?dns=com uma mensagem DNS codificada em Base64Url. O método GET é o único compatível com a API JSON. - POST
- O método POST é compatível apenas com a API RFC 8484 e usa uma mensagem binária DNS com o content-Type application/dns-message no corpo da solicitação e na resposta HTTP do DoH.
- HEAD
- Atualmente, o HEAD não é suportado e retorna um erro 400 Solicitação inválida.
Outros métodos retornam erros 501 "Não implementado".
Códigos de status HTTP
O DoH do DNS público do Google retorna os seguintes códigos de status HTTP:
Sucesso
- 200 OK
- A análise e a comunicação HTTP com o resolvedor de DNS foram concluídas, e o conteúdo do corpo da resposta é uma resposta DNS em codificação binária ou JSON, dependendo do endpoint da consulta, da opção "Aceitar cabeçalho" e dos parâmetros "GET".
Direcionamentos
- 301 Movido permanentemente
- Os clientes precisam tentar novamente no URL fornecido no cabeçalho
Location:. Se a consulta original for uma solicitação POST, os clientes só poderão tentar novamente com GET se o novo URL especificar um argumento de parâmetro GETdns. Caso contrário, os clientes precisarão tentar novamente com POST.
Outros códigos como 302 encontrados, 307 redirecionamento temporário ou 308 redirecionamento permanente podem ser usados no futuro, e os clientes DoH devem lidar com todos os quatro códigos.
As respostas com os códigos 301 e 308 permanentes precisam ser armazenadas em cache indefinidamente. Se possível, os usuários podem receber uma solicitação para atualizar a configuração original usando o novo URL.
As solicitações POST que recebem respostas 307 ou 308 sempre precisam ser repetidas com POST.
Erros
As respostas de erro terão uma explicação do status HTTP no corpo, usando HTML ou texto simples.
- 400 Solicitação inválida
- Problemas ao analisar os parâmetros GET ou uma mensagem de solicitação DNS inválida. Para parâmetros GET ruins, o corpo HTTP deve explicar o erro. A maioria das mensagens DNS inválidas recebe uma permissão 200 OK com um FORMERR. O erro HTTP é retornado para mensagens distorcidas sem seção de pergunta, uma sinalização QR que indica uma resposta ou outras combinações de sinalização sem sentido com erros de análise de DNS binário.
- 413 payload muito grande
- Um corpo de solicitação POST RFC 8484 excedeu o tamanho máximo de mensagem de 512 bytes.
- 414 URI muito longo
- O cabeçalho de consulta GET era muito grande, ou o parâmetro
dnstinha uma mensagem DNS codificada em Base64Url excedendo o tamanho máximo de mensagem de 512 bytes. - 415 Tipo de mídia incompatível
- O corpo POST não tinha um cabeçalho
application/dns-messageContent-Type. - 429 número excessivo de solicitações
- O cliente enviou muitas solicitações em um determinado período. Os clientes precisam interromper o envio de solicitações até a hora especificada no cabeçalho"Tentar novamente" (um tempo relativo em segundos).
- 500 Internal Server Error
- Erros de DoH internos do DNS público do Google.
- 501 Não implementado
- Apenas os métodos GET e POST são implementados, outros métodos recebem esse erro.
- 502 Bad Gateway
- O serviço DoH não conseguiu entrar em contato com os resolvedores de DNS público do Google.
No caso de uma resposta 502, mesmo que tentar novamente em um endereço DNS público alternativo do Google possa ajudar, uma resposta substituta mais eficaz seria tentar outro serviço DoH ou alternar para o DNS UDP ou TCP tradicional em 8.8.8.8.
Benefícios do DoH
Usar HTTPS, não apenas a criptografia TLS, tem alguns benefícios práticos:
- As APIs HTTPS amplamente disponíveis e com bom suporte simplificam a implementação tanto para o DNS público do Google quanto para clientes em potencial.
- Um serviço HTTPS oferece a apps da Web acesso a todos os tipos de registro DNS, evitando as limitações das APIs DNS atuais do navegador e do SO, que geralmente aceitam apenas pesquisas de host para endereço.
- Os clientes que implementam o suporte a HTTPS baseado em UDP QUIC podem evitar problemas, como bloqueio de cabeçalho da linha, que pode ocorrer ao usar o transporte TCP.
Práticas recomendadas de privacidade para DoH
Os desenvolvedores de aplicativos da DoH devem considerar as práticas recomendadas de privacidade descritas em RFC 8484 e expandidas abaixo:
Limitar o uso de cabeçalhos HTTP
Os cabeçalhos HTTP revelam informações sobre a implementação de DoH do cliente e podem ser usados para anonimizar os clientes. Cabeçalhos como cookie, User-Agent e Accept-Language são os piores infratores, mas até mesmo o conjunto de cabeçalhos enviados pode ser revelador. Para minimizar esse risco, envie apenas os cabeçalhos HTTP necessários para DoH: Host, Content-Type (para POST) e, se necessário, "Accept". O user agent precisa ser incluído em qualquer versão de desenvolvimento ou teste.
Usar opções de preenchimento EDNS
Siga as orientações na RFC 8467 (em inglês) para usar as opções de preenchimento de EDNS para preencher as consultas de DoH com alguns tamanhos comuns para proteger contra análise de tráfego. O uso do padding HTTP/2 também é possível, mas, ao contrário do padding EDNS, o padding não extrairá o padding das respostas dos servidores DoH.
Use o POST do RFC 8484 somente para aplicativos confidenciais ou modos de navegador
O uso de POST para consultas de DoH reduz o cache de respostas e pode aumentar a latência do DNS. Por isso, geralmente não é recomendado. No entanto, reduzir o armazenamento em cache provavelmente é recomendado para aplicativos sensíveis à privacidade e pode proteger contra ataques de tempo de apps da Web que tentam determinar quais domínios o usuário visitou recentemente.
Issues
Para informar um bug ou solicitar um novo recurso, abra um problema do DoH (link em inglês).