DNS e resolução de nomes

DNS relaciona nomes a dados distribuídos

Aplicações são usadas com nomes como portal.example.com, mas a entrega IP precisa de endereços. O Domain Name System, ou DNS, oferece uma base distribuída e hierárquica de dados associados a nomes.

“Converter nome em IP” é o uso mais visível, não a definição completa. DNS também publica:

• servidores responsáveis por uma zona;
• destinos de correio;
• aliases;
• informações para resolução reversa;
• políticas representadas em registros textuais;
• parâmetros para acesso a serviços;
• material usado na validação DNSSEC.

Na aula anterior, DHCP entregou ao cliente o endereço de um resolvedor. Agora acompanharemos o que esse resolvedor faz quando a aplicação precisa localizar um serviço.

Um nome é uma sequência hierárquica de labels

Os componentes separados por pontos são labels. Em:

portal.example.com.

a leitura hierárquica acontece da direita para a esquerda:

1. . representa a raiz;
2. com está abaixo da raiz;
3. example está abaixo de com;
4. portal está abaixo de example.com.

O ponto final explícito indica um nome absoluto até a raiz. Interfaces normalmente omitem esse ponto na exibição, mas o modelo lógico permanece.

Um nome textual não implica automaticamente uma zona para cada label. portal, turma.portal e outros nomes podem estar dentro da mesma zona ou abaixo de novas delegações. Domínio descreve uma parte da árvore; zona descreve o conjunto administrado por uma autoridade entre seu topo e os cortes delegados.

Stub, recursivo e autoritativo são papéis diferentes

Três componentes aparecem na resolução comum:

• stub resolver: parte do sistema ou da aplicação que envia a pergunta a um resolvedor configurado;
• resolvedor recursivo: procura uma resposta final em nome do cliente e normalmente mantém cache;
• servidor autoritativo: responde com conhecimento local sobre uma ou mais zonas que serve.

O mesmo software pode oferecer mais de um papel, mas misturar os nomes prejudica o diagnóstico. Um servidor autoritativo não precisa “perguntar à Internet” para responder pelos dados de sua zona. Um recursivo não se torna autoridade apenas porque guardou uma resposta em cache.

O stub costuma enviar uma consulta com o bit RD, Recursion Desired, solicitando recursão. Se o serviço está disponível, a resposta indica essa capacidade com RA, Recursion Available. O resolvedor então responde pelo cache ou percorre outros servidores.

Nas etapas externas, o resolvedor normalmente realiza consultas não recursivas e recebe respostas ou referrals. Isso é resolução iterativa: cada autoridade aponta para uma parte mais próxima do nome procurado.

Uma resolução sem cache segue delegações

Suponha que o navegador peça um registro A para portal.example.com e o cache esteja vazio.

1. o stub envia a pergunta ao resolvedor recursivo;
2. o resolvedor consulta um servidor da raiz;
3. a raiz não entrega o endereço de portal; ela indica servidores de com;
4. um servidor de com indica os servidores autoritativos de example.com;
5. o autoritativo de example.com responde pelo registro solicitado;
6. o resolvedor valida o que for aplicável, armazena a resposta e a devolve ao stub.

O desenho mostra o caminho lógico, não exige uma consulta a cada nível em toda resolução. Informações de raiz, delegações e respostas anteriores podem estar em cache. Um resolvedor com cache aquecido começa do conhecimento mais próximo que ainda esteja válido.

Implementações com QNAME minimisation também evitam expor o nome completo a servidores que só precisam informar o próximo corte. Em vez de perguntar por portal.example.com à raiz, o resolvedor envia apenas o necessário para descobrir a delegação seguinte.

A raiz aponta caminhos; não guarda todos os endereços

Servidores autoritativos da zona raiz conhecem delegações para domínios de primeiro nível, como com. Eles não precisam armazenar o registro A de todo host existente.

Da mesma forma, servidores do TLD com publicam delegações para zonas abaixo dele. A resposta normalmente inclui NS no trecho de autoridade e, quando necessário, endereços auxiliares para alcançar esses servidores.

Essa distribuição oferece escala e autonomia:

• a raiz administra seu corte;
• o registro do TLD administra delegações abaixo dele;
• a autoridade de example.com administra os dados de sua zona;
• example.com pode delegar uma zona filha a outra equipe ou infraestrutura.

Uma consulta pode encontrar mais de um servidor em cada delegação. Redundância de autoridade reduz dependência de uma única instância, mas somente se rede, dados e operação realmente evitarem o mesmo ponto de falha.

Zona e delegação se encontram em um corte

Uma delegação cria uma zona separada abaixo de outra. O pai publica um RRset NS que aponta para servidores da zona filha. O filho serve seus próprios dados autoritativos, incluindo o SOA e o NS no ápice.

Considere a delegação de cursos.example.com para ns1.cursos.example.com. Surge um problema circular:

Para consultar cursos.example.com, preciso do endereço de ns1.cursos.example.com.
Para descobrir esse endereço, preciso consultar cursos.example.com.

O pai inclui então um registro de endereço auxiliar chamado glue. Esse A ou AAAA permite alcançar o servidor delegado. Glue no pai apoia a navegação, mas não transforma o pai em autoridade pelo conteúdo da zona filha.

Nem toda delegação precisa de glue. Se cursos.example.com usa ns1.provider.example.net, o endereço do servidor pode ser resolvido seguindo a hierarquia de provider.example.net. O pai deve fornecer glue quando ele é necessário para tornar a delegação alcançável, e pode haver regras de bailiwick para aceitar e armazenar dados adicionais com segurança.

Resource records formam conjuntos por nome e tipo

A unidade de dados é o resource record, RR. Registros com mesmo nome, classe e tipo formam um RRset. Uma consulta A pode retornar vários registros A do mesmo nome; a ordem observada não cria, por si, prioridade garantida.

Cada registro possui campos conceituais como:

nome | TTL | classe | tipo | dados

Exemplo didático:

portal.example.com.  300  IN  A  192.0.2.80

• portal.example.com. é o owner name;
• 300 é o TTL em segundos;
• IN é a classe Internet;
• A é o tipo;
• 192.0.2.80 é o dado específico do tipo.

O conteúdo de RDATA muda conforme o tipo. Não interprete todo registro como texto livre ou como endereço.

Tipos de registro respondem a perguntas diferentes

O registro AAAA pode ser consultado por uma conexão feita sobre IPv4, e um registro A pode ser consultado sobre IPv6. O transporte da consulta DNS e o tipo de endereço solicitado são dimensões independentes.

TXT tornou-se contêiner de dados para vários protocolos, mas não existe um significado universal para qualquer string TXT. SPF, verificação de domínio e outros usos definem sintaxes próprias.

SVCB e HTTPS são tipos modernos definidos para associar serviços a destinos e parâmetros. Eles não substituem automaticamente A e AAAA em todo cliente; o comportamento depende da especificação que consome esses registros.

CNAME é alias DNS, não redirecionamento web

Se aulas.example.com possui CNAME para portal.example.net, o resolvedor passa a procurar o tipo solicitado no nome canônico. A resposta pode trazer a cadeia e os dados finais quando disponíveis.

O navegador ainda usa a URL original de acordo com HTTP e TLS. CNAME não envia status 301 ou 302, não muda o caminho e não instrui sozinho a barra de endereço.

Cadeias longas acrescentam consultas e pontos de falha. Loops de alias não produzem um destino válido. Além disso, um nome com CNAME possui restrições de coexistência com outros dados DNS; não trate CNAME como um campo decorativo que pode ser somado livremente a qualquer conjunto.

TTL controla cache, não agenda uma propagação mundial

O Time to Live de um RR limita por quanto tempo ele pode permanecer em cache antes de ser descartado ou atualizado. O autoritativo fornece o TTL; o recursivo normalmente devolve o valor restante à medida que o tempo passa.

Considere um RRset com TTL 300:

1. às 10:00, um miss leva o recursivo à autoridade e inicia o cache;
2. às 10:02, outro cliente recebe a resposta em cache com cerca de 180 segundos restantes;
3. depois da expiração, a próxima necessidade provoca nova resolução;
4. se a autoridade mudou o RRset, o recursivo passa a obter o valor novo.

“Aguardar a propagação” costuma misturar fenômenos distintos:

• caches ainda válidos;
• servidores autoritativos com versões diferentes;
• delegação atualizada no pai;
• cache local de sistema, navegador ou aplicação;
• resolvedores que aplicam limites operacionais;
• respostas diferentes por localização ou política.

Reduzir TTL antes de uma mudança planejada pode diminuir o período de cache futuro, mas não apaga respostas já armazenadas com TTL anterior. TTL zero também não é uma ordem para que todas as camadas de aplicação esqueçam seus próprios estados.

Respostas negativas também podem ser armazenadas

Cache não guarda somente dados existentes. A RFC 2308 define cache negativo para evitar repetir consultas por nomes ou tipos ausentes durante um intervalo calculado a partir das informações da zona.

Duas situações precisam ser separadas:

• NXDOMAIN: o nome consultado não existe;
• NODATA: o nome existe, mas não possui RRset do tipo solicitado.

Se portal.example.com possui A, mas não AAAA, uma consulta AAAA pode receber NODATA. Isso é diferente de afirmar que portal.example.com não existe.

O diagrama inclui uma trilha negativa separada porque o tempo dessa resposta não deve ser inferido do TTL de um RRset positivo escolhido arbitrariamente. SOA e regras de cache negativo participam do cálculo.

SERVFAIL e REFUSED não significam nome inexistente

O campo RCODE resume o resultado da resposta. Alguns códigos comuns:

SERVFAIL pode surgir de timeout em autoridades, delegação quebrada, falha DNSSEC, limite interno ou outro erro. Trocar SERVFAIL por “domínio não existe” esconde a causa.

REFUSED pode indicar que o servidor não oferece recursão àquele cliente, não permite o tipo de operação ou aplica uma política. A existência do nome permanece uma pergunta separada.

DNS usa UDP e TCP

DNS clássico opera normalmente na porta 53 e possui transporte sobre UDP e TCP. A frase “DNS usa UDP, exceto transferência de zona” está incompleta.

UDP evita estabelecer conexão para cada troca e funciona bem para muitas consultas. EDNS(0) permite anunciar capacidade de mensagens UDP maiores e transportar extensões, mas tamanhos precisam considerar caminho, fragmentação e política.

Se uma resposta UDP não cabe no limite aplicável, o servidor pode marcar TC, Truncated. O cliente então tenta novamente por TCP. Uma implementação DNS completa precisa suportar TCP, e resolvers podem escolher TCP em outras situações; ele não é exclusivo de AXFR ou IXFR.

O conteúdo sobre TCP, UDP, portas e sockets explica os serviços de transporte. Aqui, a decisão pertence ao DNS: protocolo de aplicação, tamanho, privacidade, estado e política influenciam o transporte usado.

Perder UDP não significa que o DNS enviará automaticamente a mesma consulta por TCP em toda situação. Retransmissões, servidores alternativos, timeout e fallback dependem das regras e da implementação.

DNSSEC valida dados; não esconde consultas

DNSSEC acrescenta assinaturas e uma cadeia de confiança para permitir que um resolvedor validador verifique origem e integridade dos dados DNS.

De forma resumida:

• a zona assina RRsets e publica chaves em DNSKEY;
• o pai publica DS para estabelecer ligação com a chave da zona filha;
• a validação pode seguir uma âncora de confiança até o RRset;
• respostas negativas autenticadas usam registros próprios, como NSEC ou NSEC3;
• falha na cadeia pode produzir SERVFAIL para um cliente que depende do validador.

DNSSEC não criptografa o conteúdo. Quem observa o transporte clássico ainda pode ver nomes e respostas, e o resolvedor continua conhecendo a pergunta.

DoT, DoH e DoQ protegem transporte DNS com TLS, HTTPS ou QUIC conforme suas especificações. Eles podem oferecer confidencialidade entre participantes daquele trecho, mas não provam sozinhos que o dado da zona foi assinado corretamente.

Os mecanismos se complementam. Um canal criptografado até um resolvedor mal configurado entrega a consulta com privacidade no caminho, mas não corrige dados autoritativos errados. DNSSEC valida dados, mas não oculta o nome do resolvedor que os consulta.

Cache melhora desempenho e amplia a responsabilidade

Responder do cache reduz latência e carga sobre a hierarquia. Ao mesmo tempo, um cache precisa aceitar apenas respostas relacionadas às consultas, respeitar bailiwick e aplicar regras de validação e expiração.

Ataques de envenenamento tentam inserir dados falsos para que clientes sejam conduzidos ao destino errado. Identificadores de transação, imprevisibilidade de origem, validação de contexto e DNSSEC fazem parte de camadas de defesa, sem substituir operação segura do resolvedor.

Resolvedores abertos à Internet também podem ser abusados em reflexão e amplificação. Recursão deve ser oferecida ao público pretendido, e autoridades devem responder somente pelos papéis necessários.

Privacidade merece o mesmo cuidado: consultas revelam interesses e serviços usados. Criptografia de transporte, minimização do QNAME, retenção controlada de logs e escolha consciente do resolvedor reduzem exposições diferentes.

Diagnostique do cliente até a autoridade

Quando nomes falham, investigue por camadas:

1. confirme o nome exato e o tipo solicitado;
2. verifique arquivo hosts, cache da aplicação e sufixos de pesquisa locais;
3. identifique qual resolvedor o cliente realmente usa;
4. teste conectividade IPv4 e IPv6 até esse resolvedor;
5. observe RCODE, flags RD, RA, AA e, quando aplicável, AD;
6. examine Answer, Authority e Additional;
7. consulte o mesmo recursivo com A, AAAA ou outro tipo necessário;
8. compare com servidores autoritativos sem confundir cache e autoridade;
9. verifique delegação NS e glue a partir do pai;
10. confira SOA, serial, TTLs e consistência entre autoridades;
11. teste UDP e TCP quando houver timeout, truncamento ou resposta grande;
12. valide cadeia DNSSEC, DS, DNSKEY, assinaturas e relógio;
13. compare NXDOMAIN, NODATA, SERVFAIL e REFUSED antes de concluir.

Uma ferramenta em modo “trace” reproduz parte da caminhada iterativa e ajuda a encontrar uma delegação quebrada. Ela não imita necessariamente cache, política, encaminhadores, criptografia e validação do resolvedor usado pela aplicação.

Se a resolução retorna A e AAAA corretos, mas o site falha, o problema pode estar depois do DNS: seleção de endereço, rota, transporte, TLS, HTTP ou aplicação. DNS informa dados; não confirma que o serviço aceita conexões.

Erros comuns sobre DNS

• “DNS é uma lista mundial de nomes e IPs”: é uma árvore distribuída de registros e autoridades;
• “o servidor raiz conhece todo endereço final”: ele aponta para delegações mais próximas;
• “recursivo e autoritativo são iguais”: um busca e guarda respostas; o outro serve dados de zonas;
• “cada subdomínio é uma zona”: somente uma delegação cria um novo corte de autoridade;
• “glue é o registro autoritativo do filho”: ele auxilia a alcançar a delegação a partir do pai;
• “CNAME redireciona o navegador”: alias DNS não é resposta HTTP;
• “A consulta AAAA precisa viajar por IPv6”: tipo de RR e transporte IP são independentes;
• “TXT tem um significado universal”: protocolos atribuem semânticas específicas às strings;
• “TTL é tempo de propagação”: caches começam e expiram em momentos diferentes;
• “NXDOMAIN e NODATA são iguais”: um nega o nome; o outro não encontra o tipo no nome existente;
• “SERVFAIL significa domínio inexistente”: é falha de processamento ou resolução;
• “DNS usa somente UDP”: suporte a TCP é obrigatório em implementações completas;
• “TCP aparece apenas em transferências”: respostas e consultas comuns também podem usar TCP;
• “DNSSEC criptografa consultas”: ele valida autenticidade e integridade dos dados;
• “DoH torna o dado autoritativo correto”: ele protege o transporte HTTPS daquele trecho;
• “se resolveu, o serviço está no ar”: DNS não testa rota, porta nem aplicação.

O que você deve guardar

DNS organiza nomes em uma árvore e distribui autoridade por zonas. O stub pede uma resposta final a um resolvedor recursivo; sem cache, o recursivo segue referências de raiz, TLD e zona autoritativa.

Delegações usam NS no pai e podem precisar de glue para quebrar dependências circulares. Resource records possuem tipos e significados distintos: A e AAAA publicam endereços, CNAME cria alias, MX aponta correio, NS e SOA descrevem autoridade e outros tipos atendem protocolos específicos.

TTL limita cache; caches diferentes expiram em momentos diferentes. Respostas negativas também podem ser armazenadas. NXDOMAIN, NODATA, SERVFAIL e REFUSED precisam ser interpretados separadamente.

DNS clássico usa UDP e TCP, com EDNS e truncamento influenciando o transporte. DNSSEC valida dados, enquanto DoT, DoH e DoQ protegem trechos do transporte. QNAME minimisation reduz o nome revelado a autoridades intermediárias.

Referências

• IETF — RFC 1034: Domain Names — Concepts and Facilities. Acesso em 29 ago. 2026.
• IETF — RFC 1035: Domain Names — Implementation and Specification. Acesso em 29 ago. 2026.
• IETF — RFC 9499: DNS Terminology. Acesso em 29 ago. 2026.
• IETF — RFC 2308: Negative Caching of DNS Queries. Acesso em 29 ago. 2026.
• IETF — RFC 3596: DNS Extensions to Support IPv6. Acesso em 29 ago. 2026.
• IETF — RFC 6891: Extension Mechanisms for DNS — EDNS(0). Acesso em 29 ago. 2026.
• IETF — RFC 7766: DNS Transport over TCP. Acesso em 29 ago. 2026.
• IETF — RFC 4033: DNS Security Introduction and Requirements. Acesso em 29 ago. 2026.
• IETF — RFC 9156: DNS Query Name Minimisation. Acesso em 29 ago. 2026.
• IANA — Domain Name System Parameters. Acesso em 29 ago. 2026.