O que o DNS faz antes de um site abrir

Digitar um nome no navegador parece abrir uma porta única. Na prática, o navegador primeiro precisa de informações sobre onde se conectar. DNS — Sistema de Nomes de Domínio — participa dessa descoberta; ele não é o próprio site. Este artigo amplia a explicação do nosso vídeo sobre DNS.

Um nome é uma pergunta, não um endereço

Considere o nome ilustrativo example.org. Um aparelho pede dados DNS relevantes a um resolvedor. Conforme o tipo de registro solicitado e a configuração, a resposta pode indicar um endereço IP ou apontar para outro nome. O aparelho usa essa resposta como um dos dados necessários para tentar a conexão. A estrutura do DNS e seus registros estão em RFC 1034 e RFC 1035.

Um nome pode ter várias respostas válidas, que também podem mudar com o tempo. O cache importa: o resolvedor ou aparelho pode reutilizar uma resposta temporariamente, conforme seu prazo de validade. Assim, dois aparelhos podem se comportar de modo diferente sem que isso prove invasão. A resposta DNS, sozinha, não revela se o site respondeu, se a conexão segura terminou ou se a página carregou.

Falha no DNS não explica toda falha de conexão

Se o nome não for resolvido, o site pode não abrir mesmo que o aparelho esteja no Wi-Fi e alcance outros destinos. No sentido oposto, uma consulta DNS bem-sucedida não garante a conexão posterior. O caminho passa pela rede local, resolução do nome, rota e resposta do serviço. Verifique uma etapa por vez; não troque todas as configurações após um erro do navegador.

O que DNSSEC e HTTPS protegem

O DNSSEC foi criado para autenticar dados DNS e detectar certas alterações em respostas assinadas. Ele não cifra consultas DNS nem torna a navegação confidencial; RFC 4033 explicita esses limites. HTTPS oferece uma conexão protegida separada com o serviço quando a validação do certificado funciona. Uma resposta DNS correta não substitui essa validação. RFC 8446 especifica o TLS 1.3, protocolo normalmente usado sob HTTPS.

Para investigar, anote o nome exato, o aparelho afetado, se outro nome funciona e se outro aparelho na mesma rede vê o mesmo erro. Não publique IPs privados, senhas ou capturas com dados de conta. Essas observações reduzem hipóteses sem fingir que um sintoma isolado prova a causa.

Um modelo de ameaça para DNS

Ativo: integridade da resposta que liga nome e serviço e privacidade da consulta. Fronteiras de confiança: aparelho, resolvedor configurado, dados DNS autoritativos e conexão HTTPS posterior. Falhas possíveis: resposta falsa pode desviar o cliente; consulta visível pode revelar nomes pesquisados. São riscos distintos com controles distintos. A RFC 4033 descreve autenticação, integridade e falta de confidencialidade do DNSSEC; a RFC 9076 trata da privacidade.

DNSSEC ajuda quando o resolvedor verifica uma cadeia assinada; um rótulo de produto não prova que a consulta foi validada. Transporte DNS cifrado pode reduzir a exposição da consulta em um trecho, mas não autentica o site. Mantenha a validação de certificados do navegador, use um resolvedor confiável e investigue redirecionamentos ou alertas. Trocar o DNS não é reparo universal nem prova de invasão.

Experimente: quando uma página falhar, separe duas perguntas: “O nome foi resolvido?” e “A conexão com o serviço se completou?”. Isso ajuda mais do que concluir de imediato que “o Wi-Fi quebrou”.

Fontes conferidas em 15 de outubro de 2026: RFC 1034, RFC 1035, RFC 4033, RFC 8446.