Quando o dig ou o nslookup mostra uma resposta de DNS, o endereço que você queria é uma linha só. O resto é a mensagem devolvida, "divided into 5 sections (some of which are empty in certain cases)", cinco seções, algumas às vezes vazias, segundo a (RFC) 1035 (RFC 1035, seção 4.1): header, pergunta, resposta, autoridade e adicional. Juntas, dizem quem respondeu, com que autoridade e por que a consulta falhou; cada parte abaixo leva ao artigo da série que se aprofunda nela. Depois da leitura, você consegue dizer quem respondeu, ler as flags, a linha e o time to live () de cada registro, separar as falhas e perguntar direto à autoridade.

Uma resposta, de cima para baixo

Ilustrativa: montada no formato de saída do dig do 9.20.29, com endereços de documentação; nenhum servidor real a produziu.

; <<>> DiG 9.20.29 <<>> @192.0.2.53 www.example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 00112233445566770102030405060708090a0b0c0d0e0f10 (good)
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	3600	IN	A	203.0.113.10

;; Query time: 12 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Sun Oct 18 19:00:00 -03 2026
;; MSG SIZE  rcvd: 88

As linhas ->>HEADER<<- e flags: são o header; depois vêm a pseudosseção OPT, um bloco por seção com registros (BIND 9.20.29 message.c) e quatro linhas de estatística (BIND 9.20.29 dig.c). O explicador de saída do dig decodifica uma saída assim; a leitura bloco a bloco abre a série.

Quem respondeu

Embaixo, ;; SERVER: traz o endereço e a porta de onde veio a resposta, o servidor como digitado e o transporte (BIND 9.20.29 dig.c). Sem indicação, o dig consulta os servidores de /etc/resolv.conf (manual do dig, Description), então costuma ser o seu resolver, não o servidor da zona; o nslookup mostra isso primeiro, em Server: e Address: (BIND 9.20.29 nslookup.c). Com recursion desired (RD), copiada da sua consulta, e recursion available (RA) ligadas na resposta, o servidor fez a recursão (RFC 1034, seção 4.3.1). Mais sobre o layout do nslookup e a escolha do resolver.

Autoridade, cache ou referral

O bit authoritative answer (AA) "specifies that the responding name server is an authority for the domain name in question section", quem respondeu é autoridade para o nome (RFC 1035, seção 4.1.1). O nslookup do BIND imprime Non-authoritative answer: quando o bit está desligado (BIND 9.20.29 nslookup.c). Desligado, o bit diz só que quem respondeu não é autoridade: um resolver respondendo do cache ou com dado recém-buscado, ou um servidor dando um referral (indicação de outro servidor), já que "these referrals have the AA bit set to 0", com AA zerado (RFC 9499, seção 6). Os dados da zona mantêm TTLs constantes, e os TTLs em cache diminuem (RFC 1035, seção 6.1.3), então um TTL que cai a cada consulta denuncia um cache. Mais sobre autoridade.

O header e as flags

A linha ->>HEADER<<- traz o operation code (opcode), o response code () como status e o identificador (ID). A Internet Assigned Numbers Authority () registra o opcode 0 como Query e os RCODEs 0 NoError, 1 FormErr, 2 ServFail, 3 NXDomain, 4 NotImp e 5 Refused (IANA, DNS Parameters). O ID é um número de 16 bits que quem pergunta define e a resposta copia (RFC 1035, seção 4.1.1; RFC 1035, errata 7587). A linha de flags lista os bits ligados (seção 4.1.1; RFC 4035, seções 3.2.2 e 3.2.3):

FlagLigada numa resposta
qr: é resposta, não consulta
aaAuthoritative Answer: vem de uma autoridade para o nome
tcTrunCation: cortada para caber no canal
rdRecursion Desired: a recursão foi pedida
raRecursion Available: o servidor oferece recursão
adAuthentic Data: seções answer e authority julgadas autênticas
cdChecking Disabled: a consulta dispensou a validação

Sem as Extension Mechanisms for DNS ((0)), mensagens UDP param em 512 bytes, e "Longer messages are truncated and the TC bit is set in the header", com truncamento e TC ligada (RFC 1035, seção 4.2.1). O cliente então repete por TCP (RFC 2181, seção 9), que toda implementação de uso geral é obrigada (MUST) a suportar (RFC 7766, seção 5); com a porta TCP 53 bloqueada, a nova tentativa falha. Mais sobre o header.

A linha OPT

O EDNS(0) permite mensagens acima de 512 octetos, amplia o response code e transporta opções (RFC 9499, seção 5). Ele viaja na seção adicional como um pseudorregistro OPT, um resource record (RR) do tipo 41, e "OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files", nunca vai para cache nem para arquivos de zona (RFC 6891, seção 6.1.1). O dig o imprime à parte, por isso ADDITIONAL: 1 sem seção adicional na tela é o OPT (BIND 9.20.29 message.c).

Você pediu: no dig, "EDNS is set to 0 by default", o EDNS vem ligado (manual do dig, +edns), e quem responde só inclui OPT quando a consulta trouxe um (RFC 6891, seções 6.1.1 e 7). Sua oferta, 1232 octetos no dig 9.20.29 (BIND 9.20.29 dighost.c), aparece com +qr, e a flag do diz que você aceita registros das DNS Security Extensions (), daí o nome DNSSEC OK (DO) (RFC 3225, seção 3). Numa resposta, udp: é o tamanho de payload do servidor que respondeu: o dig imprime o campo CLASS da mensagem recebida (BIND 9.20.29 message.c), que a errata 8348, com status held for document update, descreve como o tamanho de quem envia, porque "The requestor is not the same as the sender", quem pergunta não é quem envia (RFC 6891, errata 8348). Seguem opções como COOKIE e Extended DNS Error (EDE) (IANA, DNS Parameters). Mais sobre o EDNS.

A linha de um registro

Cada registro aparece como nome, TTL, classe, tipo e dados; o comprimento dos dados viaja sem ser impresso (RFC 1035, seção 3.2.1). Um TTL vai de 0 a 2147483647, e "The TTL specifies a maximum time to live, not a mandatory time to live", é um teto, não uma obrigação (RFC 2181, seção 8). Os 88 octetos do exemplo fecham exatamente (RFC 1035, seção 4.1):

header     parte fixa                     12   seis palavras de 16 bits
question   www.example.com. IN A          21   nome 1+3 + 1+7 + 1+3 + 1 = 17, QTYPE 2, QCLASS 2
answer     A 203.0.113.10                 16   ponteiro para o nome 2, TYPE 2, CLASS 2, TTL 4, RDLENGTH 2, endereço 4
OPT        parte fixa, nome raiz          11   nome 1, TYPE 2, CLASS 2, TTL 4, RDLEN 2
COOKIE     opção nos dados do OPT         28   código 2, tamanho 2, cliente 8 + servidor 16
total                                     88   60 sem o cookie

Mais sobre os dados dos registros e os rótulos do nslookup.

Quando a resposta é uma falha

não tem código próprio; é "an answer with the RCODE set to NOERROR and no relevant answers in the answer section", um NOERROR sem respostas relevantes (RFC 2308, seção 2.2). NXDOMAIN, de um servidor autoritativo, diz que "the domain name referenced in the query does not exist", o nome não existe (RFC 1035, seção 4.1.1). SERVFAIL diz que o servidor não conseguiu processar a consulta: um autoritativo sem dados válidos da zona ou um resolver, por vários motivos (RFC 9520, seção 2.1). REFUSED é política: uma zona que o servidor não atende, ou um cliente fora das listas de controle de acesso de um resolver (seção 2.2). Silêncio não é código de resposta: o dig imprime timed out e no servers could be reached (BIND 9.20.29 dighost.c) e sai com status 9 (manual do dig, Return Codes).

Negativas também ficam em cache. O servidor autoritativo inclui o registro (start of a zone of authority) da zona, cujo TTL, o menor entre o campo MINIMUM do SOA e o TTL do próprio SOA, "indicates how long a resolver may cache the negative answer", o prazo da negativa no cache (RFC 2308, seção 3). Com MINIMUM 300 e TTL do SOA 3600 (valores ilustrativos), um NXDOMAIN em cache dura 300 segundos, mesmo se o nome surgir um minuto depois. Isso, mais os registros positivos cumprindo seus TTLs, explica quase toda mudança lenta; perguntar à autoridade mostra o dado novo, mas não esvazia cache nenhum. Como o nslookup descreve cada falha tem uma parte própria.

Como perguntar com precisão

# Pergunte a um servidor escolhido, e não ao de /etc/resolv.conf (endereços ilustrativos)
dig @192.0.2.53 www.example.com A
# Pergunte ao servidor autoritativo da zona sem recursão e procure aa
dig @198.51.100.53 +norecurse www.example.com A
# Mostre também a sua consulta: o bit RD, o registro OPT e o tamanho udp: oferecido
dig +qr www.example.com
# Só a seção answer, ou só os dados
dig +noall +answer www.example.com
dig +short www.example.com

@server escolhe o servidor, e +norecurse desliga o RD, que o dig liga por padrão (manual do dig, +recurse). Feita ao autoritativo da zona, a consulta recebe a resposta da própria zona, com aa.

Perguntar assim a cada servidor dos registros NS (name server) da zona também revela uma lame delegation (delegação manca), um servidor que recebeu a zona "but is not performing nameservice for that zone", que não a atende (RFC 1912, seção 2.8): a resposta dele vem sem aa.

O montador de comandos dig gera comandos assim e explica cada token; o prompt do nslookup tem server, set type= e set debug (manual do nslookup). Mais sobre como o dig lê um comando, as opções e o prompt do nslookup.

Como seguir a delegação

Com +trace, o dig faz consultas iterativas, seguindo os referrals desde os servidores raiz (manual do dig, +trace). @server só escolhe a quem pedir os servidores da raiz, e o +dnssec liga junto (+trace). Um resolver, ao contrário, parte dos registros NS mais próximos que já tem, e "If the data is in the cache, it is assumed to be good enough for normal use", o que está no cache vale (RFC 1034, seção 5.3.3). Um trace pode, então, mostrar uma delegação que o cache do resolver ainda não acompanhou. Mais sobre o trace e a própria raiz.

Nomes reversos e respostas assinadas

dig -x 192.0.2.1 pede o registro (domain name pointer) de 1.2.0.192.in-addr.arpa, com os octetos invertidos (manual do dig, -x; RFC 1035, seção 3.5); o IPv6 escreve seus 32 dígitos hexadecimais ao contrário, um rótulo cada, sob ip6.arpa (RFC 3596, seção 2.5), como mostra o Kit de ferramentas IPv6. Os dados reversos e os diretos ficam em zonas diferentes e podem divergir (RFC 1035, seção 3.5).

+dnssec liga o DO (manual do dig, +dnssec), e o servidor de uma zona assinada junta registros Resource Record Signature (RRSIG) aos dados, Next Secure () às negativas e Delegation Signer (DS) aos referrals; os DNS Public Key () vêm quando pedidos (RFC 4034, seção 1; RFC 4035, seção 3.1).

Um resolver que valida responde SERVFAIL para dados bogus (inválidos), mas "it MUST return the full response if and only if the original query had the CD bit set", completa só se a consulta tiver CD (RFC 4035, seção 5.5): se o +cd transforma um SERVFAIL em dados, desconfie da validação. Mais sobre consultas reversas, registros DNSSEC e a cadeia de confiança.

A mesma resposta no nslookup

Server:		192.0.2.53
Address:	192.0.2.53#53

Non-authoritative answer:
Name:	www.example.com
Address: 203.0.113.10

Ilustrativa, no formato do nslookup do BIND 9.20.29; o Windows tem o próprio nslookup, cuja saída exata não aparece aqui. O do BIND mostra o servidor, Non-authoritative answer: quando o AA está desligado e depois os registros com rótulos; TTLs só aparecem no debug, flags nunca, e uma falha sai como ** server can't find seguido do nome e do código (BIND 9.20.29 nslookup.c). A documentação da Microsoft chama as mensagens de erro de Nonexistent domain, Server failure, Refused, No records e timed out (Microsoft Learn, nslookup). O explicador de saída do nslookup decodifica essa saída, e qual ferramenta usar tem uma parte própria.

Respostas forjadas e a correção de 2008

O envenenamento de cache (cache poisoning) planta dados de DNS forjados no cache de um resolver (VU#800113, Description). O resolver aceita a primeira resposta cuja pergunta, ID, endereço e porta batem com a consulta (RFC 5452, seção 3), e em 2008 forjar uma era viável: o ID tem 16 bits, e algumas implementações usavam a mesma porta de origem em todas as consultas (VU#800113, Description). A correção mudou como as consultas saem do resolver, não o que as respostas mostram: "A number of vendors have released patches to implement source port randomization in the nameserver", patches que sorteiam a porta de origem (VU#800113, Solution). Sem mudanças no protocolo como as do DNSSEC, "these mitigations cannot completely prevent cache poisoning", não eliminam o envenenamento (VU#800113, Description). Em cache, respostas forjadas e legítimas são igualmente não autoritativas; só a validação DNSSEC as distingue. Mais sobre a falha de Kaminsky e a pergunta criptografada.

Para lembrar

  • As primeiras linhas do nslookup e a ;; SERVER: do dig dizem quem respondeu: por padrão, o seu resolver, não o da zona.
  • aa marca uma autoridade para o nome; sem ele, a resposta pode ser de cache, de busca recente ou um referral.
  • Numa resposta, o udp: da linha OPT é o tamanho de payload do servidor que respondeu; o dig 9.20.29 oferece 1232 octetos, visíveis com +qr.
  • NODATA é NOERROR sem respostas; NXDOMAIN, nome inexistente; SERVFAIL, servidor incapaz de processar a consulta; REFUSED, política; timeout, nenhuma resposta.
  • Negativas ficam em cache pelo menor entre o MINIMUM e o TTL do SOA, e TTLs em cache diminuem: mudança lenta quase sempre é cache.
  • Os patches de 2008 sortearam a porta de origem; só a validação DNSSEC, nunca uma linha da saída, separa resposta forjada de legítima no cache.

Esta série, em ordem

Este artigo abre a série DNS, lido a partir da resposta. Ele lê uma resposta de cima para baixo, linha por linha, e aponta o artigo que explica cada linha; as partes abaixo são esses artigos, na mesma ordem: a saída das duas ferramentas, quem respondeu, o header e a seção OPT, os registros, as falhas e, depois, como perguntar com precisão, como seguir a delegação, as consultas reversas, o DNSSEC e a escolha entre as duas ferramentas.

  1. Como ler a saída do dig, de cima a baixo. O formato fixo da saída do dig, da linha de versão às estatísticas da consulta, bloco por bloco.
  2. Como ler a saída do nslookup. O header com Server e Address, o aviso Non-authoritative e o texto que vem depois, diferente para cada tipo de registro.
  3. Respostas autoritativas e não autoritativas. O que significa o aviso Non-authoritative answer, por que ele geralmente não é um problema e como obter uma resposta autoritativa.
  4. O header do DNS: opcode, status e flags. O opcode, o status e as sete flags de um bit (qr, aa, tc, rd, ra, ad, cd), que dizem quem respondeu e como.
  5. O EDNS e a pseudosseção OPT. A pseudosseção OPT: o tamanho do payload UDP, o bit DO, que pede DNSSEC, e opções como os cookies.
  6. Como ler os registros numa resposta do dig. As cinco colunas de todo registro e, depois, o rdata de A, , , SOA, , e dos outros tipos que você vai encontrar.
  7. Como o nslookup mostra cada tipo de registro. Como o nslookup identifica cada registro com rótulos em texto, e não em colunas, incluindo o bloco de várias linhas do SOA.
  8. Os erros do nslookup e o que eles significam. NXDOMAIN, SERVFAIL, REFUSED e timeouts: o código depois de ** server can't find é o diagnóstico.
  9. Anatomia de uma linha de comando do dig: como o dig lê o que você digita. Como o dig entende um servidor, flags, um nome, um tipo, uma classe e as opções iniciadas por + em quase qualquer ordem, e os valores padrão que ele preenche.
  10. Opções de consulta e controle da saída do dig. As opções do dia a dia, de @servidor e -t a +short, e as que enxugam a saída.
  11. O modo interativo do nslookup. O prompt interativo: trocar de resolver, mudar o tipo de registro, ligar a saída de debug.
  12. Como seguir a delegação com dig +trace. A resolução a partir da raiz, hop a hop, do jeito que a internet faz de verdade.
  13. Consultas DNS reversas com o nslookup. Registros PTR sob in-addr.arpa e ip6.arpa, e como o nslookup monta o nome reverso para você.
  14. Registros DNSSEC na saída do dig. RRSIG, DNSKEY, DS e NSEC: como eles se encadeiam da raiz até uma zona e o que a flag ad atesta.
  15. nslookup ou dig: qual usar. A mesma resposta nas duas ferramentas e uma regra simples para escolher entre elas.

Fontes