Abaixo do header e da pergunta, cada linha que o dig imprime nas seções answer, authority e additional é um resource record (RR) em cinco colunas: nome do owner, time to live (), classe, tipo e dados, o formato de master file da (RFC) 1035. Este artigo lê as colunas e depois os dados dos tipos que você encontra; a resposta como um todo, seus blocos e seu header têm artigos próprios. Depois disso você consegue decodificar cada registro, distinguir a contagem regressiva de um cache da constante de uma zona e seguir uma cadeia de até o nome que mereceu o código de status.

Cinco colunas, seis campos na mensagem

Na mensagem, um registro tem seis campos (RFC 1035, seção 3.2.1): NAME, "an owner name, i.e., the name of the node to which this resource record pertains", o nome do nó a que o registro pertence; TYPE e CLASS, dois octetos cada; TTL; RDLENGTH; e RDATA, uma sequência de octetos de comprimento variável que descreve o recurso. O dig imprime cinco, porque os dados impressos já implicam o comprimento, na ordem do master file, em que "Since type and class mnemonics are disjoint, the parse is unique" (seção 5.1), a leitura é única porque tipo e classe não se confundem: o tipo é sempre a última palavra antes dos dados. A linha da pergunta tem três colunas e nenhum TTL (seção 4.1.2) e começa com ponto e vírgula porque o dig a imprime como comentário por padrão (manual do dig, +question).

Ilustrativo, composto no formato do dig (BIND 9.20.29 masterdump.c) com um endereço e o TTL que example.com respondeu em 2026-10-18:

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154

Na prática a classe de quase toda consulta é IN, a Internet (RFC 9499, seção 4); a Internet Assigned Numbers Authority () registra IN como 1 e Chaos (CH) como 3 (IANA DNS Parameters, DNS CLASSes), e CH sobrevive para perguntas sobre o próprio servidor, como id.server do tipo (RFC 4892, seção 2).

O TTL: contagem regressiva no cache, constante na zona

O TTL é "a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded" (RFC 1035, seção 4.1.3), o intervalo em segundos durante o qual o registro pode ficar em cache; a seção 3.2.1 dizia com sinal, o que a errata 2130 corrige (RFC 1035, errata 2130). Vai de 0 a 2147483647 como máximo, não como obrigação (RFC 2181, seção 8), com teto recomendado de 604.800 segundos, sete dias (RFC 8767, seção 4).

Quem respondeu decide o que você vê: "refresh timers and TTLs for cached data conceptually 'count down', while data in the zone stays with constant TTLs" (RFC 1035, seção 6.1.3), em cache o TTL conta para trás, na zona fica constante. Lido por um resolver público em 2026-10-18, o CNAME de www.iana.org mostrou TTL 2971 e, 305 segundos depois, 2666. Os registros A da mesma resposta foram de 216 a 300: expiraram, foram buscados de novo e recomeçaram nos 300 da zona. Perguntado ao servidor autoritativo, o número não se move. Um resolver público anycast é muitos caches (RFC 4892, seção 1).

Endereços e nomes: A, AAAA, NS e PTR

Os dados de um registro A são um endereço de 32 bits em decimal pontuado, e um host com vários endereços tem vários registros A (RFC 1035, seção 3.4.1). Um registro guarda um endereço IPv6 de 128 bits na ordem de bytes da rede (RFC 3596, seção 2.2).

Os dados de um registro NS (name server) nomeiam um host que deve ser autoritativo para a classe e o domínio (RFC 1035, seção 3.3.11); os registros NS ficam no topo da zona, ao lado do (RFC 1034, seção 4.2.1).

Os dados de um registro (domain name pointer) são um nome (RFC 1035, seção 3.3.12). Sob in-addr.arpa, cada label é um octeto do endereço, em ordem inversa (seção 3.5): 192.0.2.1 é consultado como 1.2.0.192.in-addr.arpa. O IPv6 inverte seus 32 dígitos hexadecimais, um label cada, sob ip6.arpa (RFC 3596, seção 2.5), então 2001:db8::1 vira 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, nome que o IPv6 Toolkit calcula.

CNAME: a cadeia que o servidor segue

Os dados de um registro CNAME (canonical name) "specifies the canonical or primary name for the owner. The owner name is an alias" (RFC 1035, seção 3.3.1), o owner é um alias do nome canônico. "If a CNAME RR is present at a node, no other data should be present" (RFC 1034, seção 3.6.2), nada mais onde há CNAME, exceto os registros RRSIG e NSEC de uma zona assinada (RFC 4035, seção 2.5). Perguntado por um registro A de um alias, o servidor copia o CNAME para a resposta e recomeça no nome canônico (RFC 1034, seção 4.3.2), de modo que a resposta carrega a cadeia em ordem, cada registro tendo como owner os dados do anterior (RFC 2308, seção 1). Ilustrativo, com endereços de documentação:

;; ANSWER SECTION:
www.example.com.		3600	IN	CNAME	www.example.com.cdn.example.net.
www.example.com.cdn.example.net. 300	IN	A	192.0.2.10
www.example.com.cdn.example.net. 300	IN	A	192.0.2.11

Quem respondeu decide se você vê a cadeia inteira. Um resolver recursivo a segue, guardando o CNAME em cache e recomeçando no nome canônico (RFC 1034, seção 5.3.3). Um servidor autoritativo cujo alvo está em outra zona devolve o CNAME e um referral na seção authority (RFC 2308, seção 2.1); a segunda consulta é sua.

O código de resposta () pertence ao fim da cadeia: "The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response" (RFC 6604, seção 3), o do último ciclo de consulta. Uma cadeia que termina em nome inexistente dá NXDOMAIN com os CNAMEs ainda na resposta (RFC 2308, seção 2.1); uma que termina em nome sem o tipo pedido dá NOERROR, só CNAMEs na resposta e um SOA na seção authority (seção 2.2).

SOA: sete campos, e o que MINIMUM significa hoje

Os dados do registro SOA (start of a zone of authority) são dois nomes e cinco números (RFC 1035, seção 3.3.13): MNAME, o servidor primário; RNAME, a caixa postal responsável escrita como nome, cujo primeiro label é a parte local (RFC 1912, seção 2.2); SERIAL, a versão da zona; REFRESH, RETRY e EXPIRE, os timers das transferências de zona; e MINIMUM. Ilustrativo, composto do SOA de example.com em 2026-10-18, no formato padrão e com +multiline +ttlunits (BIND 9.20.29 soa_6.c):

example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2416374680 10000 2400 604800 1800

example.com.		30m IN SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. (
				2416374680 ; serial
				10000      ; refresh (2 hours 46 minutes 40 seconds)
				2400       ; retry (40 minutes)
				604800     ; expire (1 week)
				1800       ; minimum (30 minutes)
				)

A RFC 2308 redefiniu MINIMUM: "The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field" (RFC 2308, seção 4), o TTL das respostas negativas. Um servidor que reporta NXDOMAIN, ou um nome sem dados do tipo pedido, põe o SOA da zona na seção authority, e "The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself" (seção 3), o menor entre MINIMUM e o TTL do próprio SOA. Em example.com ambos valem 1800, então uma resposta negativa vive no máximo 30 minutos em cache, e NXDOMAIN igualmente (seção 5).

Em 2026-10-18, um nome inexistente sob example.com voltou NOERROR com o SOA acima na seção authority: a negação compacta de existência responde NODATA em vez de NXDOMAIN (RFC 9824, seção 1); um nome inexistente sob .invalid voltou NXDOMAIN com o SOA da raiz, porque "Users MAY assume that queries for 'invalid' names will always return NXDOMAIN responses" (RFC 6761, seção 6.4), nomes sob invalid sempre devolvem NXDOMAIN.

MX e SRV: preferência, prioridade, peso e o ponto que significa nenhum

Os dados de um registro (mail exchange) são um PREFERENCE de 16 bits e um host EXCHANGE (RFC 1035, seção 3.3.9). O servidor de e-mail remetente ordena por preferência, menor primeiro, e sorteia entre iguais (RFC 5321, seção 5.1). Um único registro 0 . é o null MX, nenhum e-mail aceito, e "A domain that advertises a null MX MUST NOT advertise any other MX RR" (RFC 7505, seção 3), e nenhum outro MX.

Um registro (Server Selection), tipo 33, tem como owner um nome da forma _Service._Proto.Name e guarda Priority, Weight, Port e Target (RFC 2782, The format of the SRV RR). "A client MUST attempt to contact the target host with the lowest-numbered priority it can reach" (Usage rules), a menor prioridade alcançável primeiro, e entre prioridades iguais "Larger weights SHOULD be given a proportionately higher probability of being selected" (Usage rules), pesos maiores recebem probabilidade proporcionalmente maior. Um Target . significa que o serviço decididamente não está disponível (The format of the SRV RR). O exemplo da própria RFC:

_foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
                SRV 0 3 9 new-fast-box.example.com.
                SRV 1 0 9 sysadmins-box.example.com.

A terceira máquina só é tentada quando as duas de prioridade 0 falham, e os pesos 1 e 3 não dividem o tráfego 1 para 3: o sorteio é um número aleatório uniforme de 0 à soma, inclusive, então a máquina de peso 3 é escolhida 3 vezes em 5 nesta ordem e 4 vezes em 5 se listada primeiro (RFC 2782, errata 8120).

TXT: strings de no máximo 255 octetos

Os dados de um registro TXT (text) são uma ou mais character-strings, cada uma um octeto de comprimento seguido de tantos octetos, logo no máximo 255 octetos cada (RFC 1035, seções 3.3 e 3.3.14). O dig imprime cada string entre aspas duplas, separadas por um espaço, escapando aspas, barras invertidas e bytes não imprimíveis (BIND 9.20.29 rdata.c); as aspas são apresentação, não dados. Um valor longo chega como várias strings em um registro, e para o Sender Policy Framework () "the record MUST be treated as if those strings are concatenated together without adding spaces" (RFC 7208, seção 3.3), as strings são concatenadas sem espaço. A validação do Automatic Certificate Management Environment () põe seu token em um TXT sob _acme-challenge (RFC 8555, seção 8.4), o valor que o ACME dns-01 TXT computer calcula.

CAA: flags, tag, valor

Um registro (Certification Authority Authorization) é impresso como flags tag "value": um número de 0 a 255, letras minúsculas e dígitos, e um valor entre aspas (RFC 8659, seção 4.1.1; BIND 9.20.29 caa_257.c). Pela convenção de numeração, "the Flags value 1 means that bit 7 is set, while a value of 128 means that bit 0 is set" (seção 4.1), o valor 128 liga o bit 0: 128 marca uma propriedade que a certification authority () precisa entender, ou não emite. As tags são issue, issuewild para nomes curinga, que tem precedência, e iodef, um endereço mailto, http ou https para relatórios (seções 4.2 a 4.4). A busca "climbs the DNS name tree from the specified label up to, but not including, the DNS root" (seção 3), sobe a árvore de nomes até a raiz, sem incluí-la. Nos exemplos da RFC, o segundo proíbe qualquer emissor (seção 4.2) e o terceiro barra toda CA que não implementou tbs (seção 4.5):

certs.example.com         CAA 0 issue "ca1.example.net"
nocerts.example.com       CAA 0 issue ";"
new.example.com           CAA 128 tbs "Unknown"

Os tipos das DNS Security Extensions (), RRSIG, DNSKEY, DS, NSEC e parentes, aparecem nas mesmas cinco colunas quando você pergunta com +dnssec; os registros DNSSEC na saída do dig os lê.

Quando uma resposta aparentemente correta falha

CNAME no ápice. O ápice guarda o SOA e os NS (RFC 9499, seção 7), e "A CNAME record is not allowed to coexist with any other data" (RFC 1912, seção 2.4), nada coexiste com um CNAME. As saídas são registros de endereço no ápice ou um registro HTTPS com SvcPriority 0, cujo "primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed" (RFC 9460, seção 2.4.2), permitir alias no ápice, onde CNAME não é permitido.

Alias onde se exige um host. "The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias" (RFC 2181, seção 10.3), NS e MX não apontam para alias: nenhum endereço vem então na seção additional (seção 10.3), e NS apontando para CNAME conflita com servidores (RFC 1912, seção 2.4).

Registros velhos depois de uma mudança. Um cache guarda o registro antigo até o fim da contagem, então baixar o TTL depois não ajuda ninguém: "If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change" (RFC 1034, seção 3.6), reduza o TTL antes da mudança e restaure depois. Uma resposta negativa fica em cache do mesmo modo, por até min(MINIMUM, TTL do SOA).

TXT e SRV mal lidos. Um TXT de várias strings unido com espaços, ou pesos de SRV lidos entre prioridades diferentes, são erros de leitura, não de zona.

Como ver isso

# TTLs da zona em um servidor autoritativo (endereço ilustrativo), contagem do cache no seu resolver
dig @192.0.2.53 example.com A
dig example.com A
# Um tipo por vez; o SOA na forma verbosa com unidades
dig example.com MX
dig -t TXT example.com
dig +multiline +ttlunits example.com SOA
# Só as linhas de registro: nome, TTL, classe, tipo, dados
dig +noall +answer example.com NS
# Reverso: o dig monta 1.2.0.192.in-addr.arpa e pede PTR
dig -x 192.0.2.1
# Um NXDOMAIN de verdade, e a identidade de um servidor na classe CH
dig nonexistent.invalid A
dig @192.0.2.53 -c CH -t TXT id.server

dig @server name type é a invocação típica; sem tipo o dig pede A, sem servidor lê /etc/resolv.conf (manual do dig, Simple Usage). -x monta o nome reverso e define o tipo PTR (Options, -x); +noall +answer deixa só as linhas de registro (Examples); como o dig interpreta a linha de comando tem artigo próprio.

Cole a saída padrão de uma linha por registro no dig output explainer: ele separa cada registro em cinco colunas, nomeia os campos de dados de SOA, MX, SRV e CAA e sinaliza como NODATA uma resposta NOERROR sem registros. O dig command builder monta os comandos acima, classe CH e -x incluídos; o nslookup output explainer lê a forma rotulada do nslookup.

Para lembrar

  • Uma linha de registro são cinco colunas, nome do owner, TTL, classe, tipo e dados; o RDLENGTH da mensagem fica implícito, e o tipo é sempre a última palavra antes dos dados.
  • O TTL é uma contagem de segundos sem sinal, no máximo 2147483647; decresce no cache e fica constante na zona.
  • O owner de um CNAME não guarda outro dado; o servidor copia o CNAME para a resposta e recomeça no alvo, e o RCODE pertence ao último nome da cadeia.
  • O MINIMUM do SOA é o TTL de cache negativo, limitado pelo TTL do próprio SOA, para NXDOMAIN e NODATA igualmente.
  • Preferência MX e prioridade SRV: menor primeiro; o peso do SRV só se divide entre prioridades iguais, e um target . significa serviço nenhum.
  • Uma string TXT tem no máximo 255 octetos; várias strings em um registro se unem sem espaço, e as aspas são do dig, não dos dados.
  • Flags 128 em CAA significa crítico; as tags são issue, issuewild e iodef, e a busca sobe em direção à raiz.

Fontes