Domain IP Lookup

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

Fundamentos de DNS

DNS sobre HTTPS explicado: o que ele faz e o que não protege

7 min de leituraPor Domain IP Lookup Team

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ássicoDNS sobre TLS (DoT)DNS sobre HTTPS (DoH)
TransporteUDP simples, normalmente porta 53TLS em sua própria porta, 853HTTPS, compartilhando a porta 443 com o tráfego web
CriptografadoNãoSimSim
Visível para a rede localOs nomes que você consultaQue você está usando DNS, não quais nomesDifícil de distinguir de requisições web comuns
Respostas autenticadasNãoPela conexão TLSPela 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 / DoTDNSSEC
ProtegeA privacidade das suas consultasA verdade das respostas
Funciona entreSeu dispositivo e o resolvedorO dono do domínio e o resolvedor que valida
Se faltarRedes podem observar ou adulterar consultasRespostas falsificadas podem ser aceitas como reais
AnalogiaUm envelope lacradoUma 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:

ObservadorCom DNS clássicoCom DoH
Rede local e hotspotTodos os nomes que você consulta, em texto simplesUma conexão criptografada com um resolvedor; não os nomes dentro dela
Seu provedor de internetAs mesmas consultas em texto simples, enquanto atravessam a rede deleA conexão com o resolvedor e os endereços IP aos quais você se conecta depois
O operador do resolvedorTodas as consultas que ele responde para vocêSem mudança: ele continua lendo todas as consultas que responde
Os sites que você visitaSua conexão com o endereço delesSem 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