# explicador de saída do dig > Cole a saída real do dig e obtenha um detalhamento decodificado e explicado: o cabeçalho e as flags, a pseudo-seção OPT do EDNS, cada registro em cada seção e as estatísticas da consulta. Analisado inteiramente no seu navegador, nada é resolvido nem enviado a lugar algum. - Tool: https://ronutz.com/pt-BR/tools/dig-output-explainer - Family: Redes --- ## O que faz Cole a saída de um comando `dig` e a ferramenta reconstrói a mensagem DNS que ela representa, seção por seção, e explica cada parte. Ela lê o cabeçalho, a linha de flags e as contagens de seção, a pseudo-seção OPT do EDNS, as quatro seções de registros com cada resource record dividido em seus campos, e as estatísticas finais da consulta. Ela analisa apenas o texto: nada é resolvido e nada é enviado a lugar algum. ## Por que a saída do dig precisa ser decodificada O `dig` imprime uma representação fiel, mas concisa, de uma mensagem DNS, e muito significado fica compactado em tokens curtos. O **cabeçalho** carrega a operação, um código de status e um id de mensagem; a linha de **flags** carrega flags de uma palavra cuja presença ou ausência muda tudo. `aa` significa que a resposta é autoritativa, vinda de um servidor responsável pela zona e não de um cache; `rd` significa que a recursão foi desejada e `ra` que ela está disponível; `ad` marca dados validados por DNSSEC; `tc` significa que a resposta foi truncada e deve ser repetida por TCP. O código de status é a outra coisa a ler primeiro: `NOERROR`, `NXDOMAIN` para um nome que não existe, ou `SERVFAIL` para uma falha no servidor. ## As seções e o EDNS Uma mensagem DNS tem quatro seções, e o dig as rotula: **QUESTION** (o que foi perguntado), **ANSWER** (os registros que respondem), **AUTHORITY** (os servidores de nomes responsáveis) e **ADDITIONAL** (registros extras úteis). A ferramenta divide cada resource record em suas partes: o nome, o TTL em segundos, a classe (quase sempre `IN`), o tipo (`A`, `AAAA`, `MX` e assim por diante) e os dados do registro. Ela também decodifica a **pseudo-seção OPT**, a extensão EDNS(0) (RFC 6891) que anuncia coisas como a maior resposta UDP que o resolvedor aceita e o suporte a DNSSEC, e que não é um registro real, mas metadados sobre a troca. ## As estatísticas O rodapé que o dig imprime é realmente útil para diagnóstico: o tempo de consulta diz quanto o resolvedor levou, a linha do servidor diz qual resolvedor respondeu, e o tamanho da mensagem e o horário completam. Ler isso em conjunto muitas vezes explica uma consulta lenta ou surpreendente mais rápido do que os próprios registros. ## Como usar Cole uma resposta completa do `dig` e leia o cabeçalho, as flags, as seções e as estatísticas decodificadas. A análise é determinística e inteiramente local; a ferramenta nunca faz uma consulta própria. ## Standards and references - [RFC 1035 - Domain Names (Implementation and Specification)](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 6891 - Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891) - [RFC 2308 - Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308) - [RFC 4034 - Resource Records for the DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4034) - [RFC 8499 - DNS Terminology](https://www.rfc-editor.org/rfc/rfc8499) ## Related reading - [Lendo a saída do dig de cima a baixo](https://ronutz.com/pt-BR/learn/reading-dig-output.md): Uma resposta do dig tem uma forma fixa: uma linha de versão, o cabeçalho, a linha de flags, a pseudo-seção OPT, as quatro seções e as estatísticas da consulta. Depois que você conhece cada bloco, consegue ler qualquer resposta num relance e identificar a única linha que explica um problema de resolução. - [Lendo os registros em uma resposta do dig](https://ronutz.com/pt-BR/learn/dns-record-types-in-answers.md): Todo registro em uma seção do dig são cinco colunas: nome, TTL, classe, tipo e rdata. Este artigo percorre as colunas e depois o rdata dos tipos de registro que você realmente encontra, de A e CNAME a MX, SOA, SRV e CAA, para que uma parede de registros se leia como fatos simples. - [nslookup vs dig: qual usar](https://ronutz.com/pt-BR/learn/nslookup-vs-dig.md): O nslookup e o dig ambos consultam DNS, mas o nslookup é mais enxuto e esconde as flags do cabeçalho e os TTLs que o dig mostra por completo. Este artigo mapeia uma saída sobre a outra e dá uma regra simples para saber qual usar. - [O cabeçalho DNS: opcode, status e flags](https://ronutz.com/pt-BR/learn/dns-message-header-and-flags.md): Duas linhas carregam todo o estado de uma mensagem DNS: que tipo de consulta é, se ela teve sucesso e sete flags de um único bit (qr, aa, tc, rd, ra, ad, cd) que dizem quem respondeu e como. Lê-las corretamente é a diferença entre um diagnóstico de dois minutos e uma hora de adivinhação. - [O EDNS e a pseudo-seção OPT](https://ronutz.com/pt-BR/learn/edns-and-the-opt-pseudosection.md): A pseudo-seção OPT não é um registro e não é algo que você consultou: é metadado do EDNS(0) que o dig mostra perto do topo de uma resposta. Ela carrega o tamanho do payload UDP, a flag DO que solicita DNSSEC e opções como COOKIE, e explica silenciosamente toda uma classe de falhas de resolução. - [Opções de consulta e controle de saída do dig](https://ronutz.com/pt-BR/learn/dig-query-options.md): O verdadeiro poder do dig está em suas opções: escolher qual servidor perguntar, o tipo de registro e exatamente quanto da resposta imprimir. Este artigo cobre o punhado que você realmente usará todo dia, de @servidor e -t a +short e a combinação +noall +answer que reduz o dig a apenas os registros. - [Registros DNSSEC na saída do dig](https://ronutz.com/pt-BR/learn/dnssec-records-in-dig.md): Adicione +dnssec e uma resposta do dig ganha uma nova família de registros: RRSIG, DNSKEY, DS e os registros de negação NSEC ou NSEC3. Este artigo explica o que é cada um, como eles se encadeiam da raiz até uma zona, e o que a flag ad realmente certifica. - [Seguindo a delegação com dig +trace](https://ronutz.com/pt-BR/learn/dig-trace-and-delegation.md): O dig +trace resolve um nome da forma como a internet de fato faz: começando na raiz, seguindo a delegação para o TLD e então para os próprios servidores autoritativos do domínio, imprimindo cada salto. É a melhor forma de ver onde a resolução quebra e de entender como o DNS é costurado.