Uma consulta DNS recursiva, um salto de cada vez
Navegador
quer example.com
Resolvedor
seu provedor / 1.1.1.1
Raiz + TLD
quem opera o .com?
Autoritativo
a resposta real
Cada salto desta cadeia é em si uma consulta DNS, depois armazenada em cache
DNS sobre HTTPS explicado: o que ele faz e o que não protege
O DNS clássico tem uma peculiaridade de privacidade que surpreende as pessoas: suas consultas viajam como texto simples e legível. Qualquer rede entre você e o resolvedor (o roteador da cafeteria, seu provedor, um hotspot comprometido) pode ver quais nomes você pergunta e, em princípio, alterar as respostas. DNS sobre HTTPS, normalmente abreviado como DoH, envolve essas consultas na mesma criptografia que o seu navegador já usa para sites.
O DoH é genuinamente útil, mas também é amplamente supervalorizado. Ele protege um segmento específico de uma conversa específica. Entender exatamente qual segmento lhe diz tanto o que ele vale quanto o que ele nunca faria por você.
As três maneiras como uma consulta pode viajar
Seu dispositivo normalmente não fala diretamente com o DNS da internet. Um aplicativo pergunta ao resolvedor stub do sistema operacional, e o stub pergunta a um resolvedor recursivo, o serviço que a sua rede atribuiu ou um que você escolheu. Como funciona a resolução DNS percorre essa cadeia por inteiro. O DoH muda como o stub fala com o resolvedor:
| DNS clássico | DNS sobre TLS (DoT) | DNS sobre HTTPS (DoH) | |
|---|---|---|---|
| Transporte | UDP simples, normalmente porta 53 | TLS em sua própria porta, 853 | HTTPS, compartilhando a porta 443 com o tráfego web |
| Criptografado | Não | Sim | Sim |
| Visível para a rede local | Os nomes que você consulta | Que você está usando DNS, não quais nomes | Difícil de distinguir de requisições web comuns |
| Respostas autenticadas | Não | Pela conexão TLS | Pela conexão HTTPS |
A diferença prática entre DoT e DoH é sobretudo sobre se misturar e sobre quem controla a configuração. O DoT se anuncia em uma porta dedicada, então uma rede pode permiti-lo ou bloqueá-lo deliberadamente. O DoH trafega dentro do tráfego web normal, o que torna mais difícil para uma rede destacá-lo, e ele é comumente configurado por aplicativo (um navegador pode usar DoH enquanto o resto do sistema não) em vez de apenas no sistema inteiro.
O que o DoH protege
Com o DoH ligado, o trecho entre o seu dispositivo e o resolvedor é criptografado e autenticado: a rede local não pode mais ler os nomes que você consulta, nem reescrever silenciosamente as respostas no caminho de volta. Em uma rede em que você não confia (o Wi-Fi público é o caso dos livros), isso é uma melhoria real, porque a rede local era antes o lugar mais fácil para observar ou adulterar consultas.
O DoH também autentica o próprio resolvedor, do mesmo jeito que o HTTPS autentica um site. Seu stub sabe que está realmente falando com o resolvedor que pretendia, e não com um impostor que a rede local inseriu. Com o DNS clássico, essa garantia simplesmente não existe; uma resposta falsificada que chega primeiro é aceita.
O que o DoH não protege
Três limites importam, e nenhuma explicação honesta deveria pulá-los:
- O resolvedor ainda vê tudo. A criptografia corre entre você e o resolvedor, então o resolvedor necessariamente lê cada consulta para respondê-la. O DoH move a sua confiança da rede local e do seu provedor para o operador do resolvedor; ele não remove a necessidade de confiança.
- O destino continua visível. Depois da consulta, seu dispositivo se conecta ao endereço IP do site, e as redes podem observar a quais endereços você se conecta mesmo quando não podem ver os nomes. O DNS criptografado esconde a pergunta, não a jornada que se segue.
- Apenas esse trecho é coberto. Assim que o resolvedor tem a sua consulta, ele busca a resposta nos servidores autoritativos em seu nome. O DoH não diz nada sobre esse lado da conversa, e não criptografa o próprio tráfego web: esse continua sendo o trabalho do HTTPS e do TLS na conexão com o site.
DoH não é DNSSEC, e nenhum substitui o outro
Essas duas tecnologias são confundidas o tempo todo porque ambas envolvem DNS e segurança, mas resolvem problemas opostos. O DoH fornece confidencialidade: mantém a conversa entre você e o resolvedor privada. O DNSSEC fornece autenticidade: permite que um resolvedor verifique que uma resposta realmente veio do dono do domínio e não foi alterada em nenhum ponto do caminho, usando assinaturas digitais publicadas no próprio DNS.
Um canal criptografado carregando uma resposta falsificada continua sendo uma resposta falsificada, e é por isso que o DoH sozinho não pode provar que uma resposta é verdadeira. E uma resposta assinada e verificável ainda pode viajar à vista de todos, e é por isso que o DNSSEC sozinho não mantém nada privado. Usados juntos, eles cobrem as lacunas um do outro; como o DNSSEC funciona cobre em detalhe o lado das assinaturas.
| DoH / DoT | DNSSEC | |
|---|---|---|
| Protege | A privacidade das suas consultas | A verdade das respostas |
| Funciona entre | Seu dispositivo e o resolvedor | O dono do domínio e o resolvedor que valida |
| Se faltar | Redes podem observar ou adulterar consultas | Respostas falsificadas podem ser aceitas como reais |
| Analogia | Um envelope lacrado | Uma assinatura na carta dentro dele |
Um detalhe silencioso: o que acontece quando o DoH falha
As implementações de DNS criptografado geralmente escolhem entre dois comportamentos quando o caminho criptografado falha. Em um modo oportunista, o dispositivo volta discretamente ao DNS clássico, então as consultas continuam funcionando, mas perdem a proteção sem nenhuma reclamação visível. Em um modo estrito, o dispositivo se recusa a voltar, e os nomes simplesmente param de resolver até o serviço criptografado ficar acessível de novo. Nenhum dos dois é um defeito: o primeiro troca privacidade por confiabilidade, o segundo faz a troca oposta. Mas vale a pena saber qual comportamento o seu navegador ou sistema usa, porque uma volta oportunista significa que a sua proteção pode sumir justamente nas redes hostis onde você mais a queria, e ninguém lhe diria.
Onde o DoH é configurado
O DoH vive onde o resolvedor stub é configurado, o que na prática significa o navegador e o sistema operacional. Muitos navegadores têm a própria configuração de DNS criptografado e podem ligá-la por padrão, usando um resolvedor que o navegador escolheu; os sistemas operacionais também oferecem cada vez mais uma opção de DNS criptografado para todo o sistema. Essa divisão explica uma confusão comum: um navegador pode estar usando DoH enquanto outros aplicativos na mesma máquina ainda usam DNS clássico, então uma verificação em nível de rede pode mostrar os dois ao mesmo tempo.
Depois da troca: quem ainda pode ver o quê
Uma forma compacta de manter o quadro inteiro claro é percorrer o elenco de observadores e perguntar o que cada um descobre depois que o DoH está ativo:
| Observador | Com DNS clássico | Com DoH |
|---|---|---|
| Rede local e hotspot | Todos os nomes que você consulta, em texto simples | Uma conexão criptografada com um resolvedor; não os nomes dentro dela |
| Seu provedor de internet | As mesmas consultas em texto simples, enquanto atravessam a rede dele | A conexão com o resolvedor e os endereços IP aos quais você se conecta depois |
| O operador do resolvedor | Todas as consultas que ele responde para você | Sem mudança: ele continua lendo todas as consultas que responde |
| Os sites que você visita | Sua conexão com o endereço deles | Sem mudança: eles veem a mesma conexão de antes |
A tabela também explica o debate que acompanha o DoH por toda parte. Tirar as consultas da rede local as concentra em resolvedores em menor número e maiores, o que é bom para escapar de um hotspot hostil e menos obviamente bom como formato geral para a internet. Nenhum dos lados desse debate muda a mecânica acima; ele muda qual resolvedor você decide que merece a confiança que a rede local recebia por padrão.
Um exemplo prático: uma consulta, de duas formas
Acompanhe uma única consulta por shop.example.com a partir de um laptop no Wi-Fi de uma cafeteria. O nome precisa ser resolvido antes que qualquer outra coisa possa acontecer, e a busca de IP do domínio mostraria os endereços que o resolvedor acaba retornando. O que difere entre os dois caminhos abaixo é apenas o tubo pelo qual a pergunta viaja.
Com DNS clássico, o laptop envia a pergunta como UDP simples para o resolvedor da cafeteria. O ponto de acesso, o firmware do roteador da cafeteria e qualquer coisa que registre o tráfego nessa rede podem ler a pergunta por completo: este dispositivo acabou de pedir shop.example.com. Se algum dispositivo no caminho reescrever a resposta, apontando o nome para 198.51.100.20 em vez do real 203.0.113.44, o laptop a aceita sem nenhuma forma de perceber a diferença.
Com DoH, o laptop abre uma conexão HTTPS com o resolvedor que escolheu e envia a mesma pergunta dentro dela. A rede da cafeteria vê uma conexão criptografada com o endereço de um resolvedor na porta 443, indistinguível em formato do tráfego web comum; o nome dentro dela nunca aparece. A resposta que volta viaja dentro dessa conexão autenticada, então um middlebox na rede local não pode encaixar 198.51.100.20 sem romper a conexão por inteiro, o que o laptop perceberia.
Observe o que não mudou no segundo caminho. O próprio resolvedor continuou lendo a pergunta, porque precisava. E, assim que o laptop tem a resposta, ele abre uma conexão para 203.0.113.44 à vista plena da mesma rede da cafeteria: a pergunta se tornou privada, a jornada depois dela, não. Esse par de fatos é toda a história do DoH em miniatura.
Você deveria ligá-lo?
Para a maioria das pessoas, sim, de olhos abertos. Em redes que você não controla, consultas criptografadas removem o ponto mais fácil de escuta e adulteração por quase custo nenhum. Apenas mantenha as contas claras: você está escolhendo um operador de resolvedor em quem confiar suas consultas, e a privacidade do resto do seu tráfego continua dependendo de os próprios sites usarem HTTPS. O DoH é uma melhoria sólida em um trecho da cadeia de resolução, e isso, nem mais nem menos, é o que ele promete.
Precisa conferir os endereços DNS públicos de um domínio? Use a ferramenta Domain IP Lookup.
Perguntas frequentes
Leitura relacionada
Três camadas dividem o nome “servidor DNS”
Resolvedor stub
seu próprio dispositivo
Resolvedor recursivo
provedor, roteador ou 1.1.1.1
Autoritativo
o DNS do próprio domínio
O que é 1.1.1.1? Um guia simples sobre resolvedores DNS públicos
Em algum momento, «é só usar 1.1.1.1» virou a fita adesiva dos conselhos de rede doméstica. Às vezes ajuda. Às vezes só muda quem responde às suas perguntas. Eis o que ele realmente faz.
Uma consulta DNS recursiva, um salto de cada vez
Navegador
quer example.com
Resolvedor
seu provedor / 1.1.1.1
Raiz + TLD
quem opera o .com?
Autoritativo
a resposta real
Cada salto desta cadeia é em si uma consulta DNS, depois armazenada em cache
Resolução DNS explicada: como os domínios se resolvem em IPs
Siga uma consulta DNS do início ao fim: cache do navegador, resolvedor recursivo, referências de raiz e TLD, resposta autoritativa e os caches na volta.
Três camadas dividem o nome “servidor DNS”
Resolvedor stub
seu próprio dispositivo
Resolvedor recursivo
provedor, roteador ou 1.1.1.1
Autoritativo
o DNS do próprio domínio
O que é um servidor DNS? Tipos e como funciona
O que é um servidor DNS? Conheça os papéis por trás do nome: resolvers recursivos, servidores autoritativos, raiz e TLD, e o que cada um responde.