O DNS público do Google fornece duas APIs do DoH distintas nestes endpoints:
A página Visão geral dos transportes seguros tem exemplos de linha de comando curl para usar APIs, detalhes de TLS e outros recursos comuns a DNS sobre TLS (DoT) e DoH.
O DoH também é compatível com o serviço DNS64 público do Google somente 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
- GET
- O uso do método GET pode 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 só é compatível com a API RFC 8484 e usa uma mensagem DNS binária com o aplicativo Content-Type/dns-message no corpo da solicitação e na resposta HTTP do DoH.
- HEAD
- No momento, HEAD não é compatível e retorna um erro 400 Bad Request.
Outros métodos retornam erros 501 Not Implemented.
Códigos de status HTTP
O DoH do DNS público do Google retorna os seguintes códigos de status HTTP:
Concluído
- 200 OK
- A análise HTTP e a comunicação com o resolvedor de DNS foram bem-sucedidas, e o conteúdo do corpo da resposta é uma resposta DNS em codificação binária ou JSON, dependendo do endpoint de consulta, no cabeçalho Accept e nos parâmetros GET.
Redirecionamentos
- 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ó precisarão tentar novamente com GET se o novo URL especificar um argumento de parâmetrodnsGET. Caso contrário, os clientes precisarão tentar novamente com POST.
Outros códigos, como 302 encontrado, redirecionamento temporário 307 ou redirecionamento permanente 308, podem ser usados no futuro, e os clientes do DoH precisam lidar com todos os quatro códigos.
As respostas com os códigos permanentes 301 e 308 precisam ser armazenadas em cache indefinidamente. Se for prático, 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 devem 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 incorretos, o corpo do HTTP deve explicar o erro. A maioria das mensagens DNS inválidas recebe um erro "200 OK" com um FORMERR. O erro HTTP é retornado para mensagens ilegíveis sem seção de pergunta, uma sinalização QR indicando uma resposta ou outras combinações de sinalizações 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 da mensagem de 512 bytes.
- URI 414 muito longo
- O cabeçalho da consulta GET era muito grande ou o parâmetro
dnstinha uma mensagem DNS codificada em Base64Url que excedeva 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 Content-Type
application/dns-message. - 429 número excessivo de solicitações
- O cliente enviou muitas solicitações em um determinado período. Os clientes precisam parar de enviar solicitações até o momento especificado no cabeçalho "Tentar novamente depois" (um tempo relativo em segundos).
- 500 Internal Server Error
- Erros de DoH internos de DNS público do Google.
- 501 Não implementado
- Somente 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, embora uma nova tentativa 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
O uso de HTTPS, e não apenas a criptografia TLS, tem alguns benefícios práticos:
- As APIs HTTPS com ampla disponibilidade e suporte simplificam a implementação do DNS público do Google e de clientes em potencial.
- Um serviço HTTPS fornece aos apps da Web acesso a todos os tipos de registro DNS, evitando as limitações das APIs DNS e do navegador atuais, que geralmente oferecem suporte apenas para pesquisas de host para endereço.
- Os clientes que implementam o suporte a HTTPS baseado em QUIC com UDP podem evitar problemas como o bloqueio "head-of-line" que pode ocorrer ao usar o transporte TCP.
Práticas recomendadas de privacidade para DoH
Os desenvolvedores de aplicativos de DoH precisam considerar as práticas recomendadas de privacidade descritas na RFC 8484 e ampliadas 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 tornar os clientes anônimos. 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 padding do EDNS
Siga as orientações no RFC 8467 (link em inglês) para usar as opções de preenchimento EDNS a fim de preencher consultas DoH em alguns tamanhos comuns para proteger contra a análise de tráfego. O uso do padding HTTP/2 também é possível, mas, ao contrário do preenchimento EDNS, não obterá padding nas respostas dos servidores DoH.
Use POST RFC 8484 somente para aplicativos ou modos de navegador que exigem privacidade
O uso de POST para consultas de DoH reduz a capacidade de cache das respostas e pode aumentar a latência do DNS. Portanto, em geral, ele não é recomendado. No entanto, reduzir o armazenamento em cache é provavelmente desejável 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 no DoH.