# dig output explainer > Paste real dig output and get a decoded, explained breakdown: the header and flags, the EDNS OPT pseudo-section, every record in each section, and the query stats. Parsed entirely in your browser, nothing is resolved or sent anywhere. - Tool: https://ronutz.com/en/tools/dig-output-explainer - Family: Networking --- ## What it does Paste the output of a `dig` command and the tool reconstructs the DNS message it represents, section by section, and explains each part. It reads the header, the flags line and section counts, the EDNS OPT pseudo-section, the four record sections with every resource record broken into its fields, and the trailing query statistics. It parses the text only: nothing is resolved and nothing is sent anywhere. ## Why dig output needs decoding `dig` prints a faithful but terse rendering of a DNS message, and a lot of meaning is packed into short tokens. The **header** carries the operation, a status code, and a message id; the **flags** line carries single-word flags whose presence or absence changes everything. `aa` means the answer is authoritative, from a server responsible for the zone rather than a cache; `rd` means recursion was desired and `ra` that it is available; `ad` marks data validated by DNSSEC; `tc` means the reply was truncated and should be retried over TCP. The status code is the other thing to read first: `NOERROR`, `NXDOMAIN` for a name that does not exist, or `SERVFAIL` for a failure at the server. ## The sections and EDNS A DNS message has four sections, and dig labels them: **QUESTION** (what was asked), **ANSWER** (the records that answer it), **AUTHORITY** (the name servers responsible), and **ADDITIONAL** (extra helpful records). The tool breaks every resource record into its parts: the name, the TTL in seconds, the class (almost always `IN`), the type (`A`, `AAAA`, `MX`, and so on), and the record data. It also decodes the **OPT pseudo-section**, the EDNS(0) extension (RFC 6891) that advertises things like the largest UDP response the resolver will accept and DNSSEC support, and which is not a real record but metadata about the exchange. ## The statistics The footer dig prints is genuinely useful for diagnosis: the query time tells you how long the resolver took, the server line tells you which resolver answered, and the message size and timestamp round it out. Reading these together often explains a slow or surprising lookup faster than the records themselves. ## Using it Paste a complete `dig` response and read the decoded header, flags, sections, and stats. The parse is deterministic and entirely local; the tool never performs a lookup of its own. ## 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 - [dig Query Options and Output Control](https://ronutz.com/en/learn/dig-query-options.md): dig's real power is its options: choosing the server to ask, the record type, and exactly how much of the answer to print. This covers the handful you will actually use every day, from @server and -t to +short and the +noall +answer combination that trims dig down to just the records. - [DNSSEC Records in dig Output](https://ronutz.com/en/learn/dnssec-records-in-dig.md): Add +dnssec and a dig answer grows a new family of records: RRSIG, DNSKEY, DS, and the NSEC or NSEC3 denial records. This explains what each one is, how they chain from the root down to a zone, and what the ad flag really certifies. - [EDNS and the OPT Pseudo-Section](https://ronutz.com/en/learn/edns-and-the-opt-pseudosection.md): The OPT pseudo-section is not a record and not something you queried: it is EDNS(0) metadata that dig surfaces near the top of an answer. It carries the UDP payload size, the DO flag that requests DNSSEC, and options like COOKIE, and it quietly explains a whole class of resolution failures. - [Following Delegation with dig +trace](https://ronutz.com/en/learn/dig-trace-and-delegation.md): dig +trace resolves a name the way the internet actually does it: starting at the root, following the delegation to the TLD, and then to the domain's own authoritative servers, printing each hop. It is the single best way to see where resolution breaks and to understand how DNS is stitched together. - [nslookup vs dig: Which to Use](https://ronutz.com/en/learn/nslookup-vs-dig.md): nslookup and dig both query DNS, but nslookup is terser and hides the header flags and TTLs that dig shows in full. This maps one output onto the other and gives a simple rule for which to reach for. - [Reading dig Output From Top to Bottom](https://ronutz.com/en/learn/reading-dig-output.md): A dig answer has a fixed shape: a version line, the header, the flags line, the OPT pseudo-section, the four sections, and the query stats. Once you know what each block is, you can read any response at a glance and spot the one line that explains a resolution problem. - [Reading the Records in a dig Answer](https://ronutz.com/en/learn/dns-record-types-in-answers.md): Every record in a dig section is five columns: name, TTL, class, type, and rdata. This walks the columns and then the rdata of the record types you actually meet, from A and CNAME to MX, SOA, SRV, and CAA, so a wall of records reads as plain facts. - [The DNS Header: Opcode, Status, and Flags](https://ronutz.com/en/learn/dns-message-header-and-flags.md): The header line and the flags line hold the message-level facts: what kind of query this is, whether it succeeded, and seven single-bit flags (qr, aa, tc, rd, ra, ad, cd) that tell you who answered and how. Reading them correctly is the difference between a two-minute diagnosis and an hour of guessing.