codynet

DNS

Online DIG Tool

Run dig online — a free, web-based dig command that returns full packet output with sections, flags, status codes, and TTLs, straight from your browser. No install, no signup.

Run DIG query

Send a packet-level DNS query and inspect sections, flags, rcodes, and TTLs.

Results come from deterministic DNS APIs or HTTPS RDAP endpoints.

Results

Sample Live example: dig codynet.com A. Run your own lookup above to replace it.

codynet.com.A1.1.1.1NOERROR72 ms
id 12225
opcode QUERY
rcode NOERROR
flags QR RD RA

;QUESTION

codynet.com.INA

;ANSWER

codynet.com.300INA20.118.138.147

;AUTHORITY

No records in this section.

;ADDITIONAL

No records in this section.

Continue investigating

Hand a value from this result to another tool — the lookup is prefilled for you.

Practical guide

How to use the DIG tool

dig is the standard DNS troubleshooting tool because it shows the actual DNS response — not a polished summary. This page runs the same query against a public resolver and gives you the full answer to read or share.

What this tool checks

DIG sends a single DNS query to a recursive resolver and returns the full response: header flags, the question section, the answer, any authority and additional records, and a TTL for each row. Unlike a plain lookup, it shows you exactly what came back on the wire, which is what you need when something is wrong.

When to use it

Use DIG when a lookup looks fine but mail still bounces, when DNSSEC validation fails, when you need to read TTLs before a cutover, when a resolver returns a different answer than expected, or when you want a clean output to paste into a ticket. It shows the full wire response — header flags, response codes, sections, and per-record TTLs — for any of the supported types, including SOA and large TXT bundles.

How to read the result

The header line shows the status (NOERROR, NXDOMAIN, SERVFAIL, REFUSED) and the flags (qr, aa, rd, ra, ad). The ANSWER SECTION holds the records the resolver returned. The TTL column is in seconds. The AUTHORITY and ADDITIONAL sections are not always present but show the nameservers and glue records the resolver used. If the answer is empty but the status is NOERROR, the record type does not exist for that name.

Common errors and what they mean

NXDOMAIN means the resolver was authoritatively told the name does not exist. SERVFAIL almost always points to a broken DNSSEC chain or an unreachable authoritative server. A correct NOERROR with zero answers means the record type is missing for an existing name. If the AD flag is missing on a domain you expect to be signed, DNSSEC validation is failing somewhere upstream.

DIG status codes and header flags

The header line is the first thing to read. These are the values you will see most often and what each one tells you.

FieldValueMeaning
statusNOERRORQuery succeeded (the answer set may still be empty)
statusNXDOMAINThe name does not exist
statusSERVFAILResolver could not complete — often DNSSEC or an unreachable authority
statusREFUSEDThe resolver will not answer this query from your network
flagaaAuthoritative answer — came straight from the authoritative nameserver
flagrd / raRecursion desired / recursion available
flagadAuthenticated data — DNSSEC validation succeeded

Field notes

When an answer looks wrong, check the status and the aa flag before anything else — a cached NOERROR with no records sends more people down the wrong path than any other DNS result. If you expect a signed zone, confirm the ad flag is present; its absence is usually the first visible sign that DNSSEC validation is breaking upstream rather than at the authoritative server.

Example DIG query

Example input
dig example.com A @1.1.1.1
Example result
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1

;; ANSWER SECTION:
example.com.   3600   IN   A   93.184.216.34

Status NOERROR plus a populated ANSWER section is the success case. The TTL (3600) tells you how long Cloudflare will cache this answer before re-asking the authoritative servers.

Related tools

DNS Lookup

Plain structured output when you do not need packet detail.

Open tool

Multi-Resolver Compare

Run the same query against Cloudflare, Google, Quad9, and OpenDNS at once.

Open tool

NSLookup

A simpler interactive-style lookup for quick A, AAAA, CNAME, and NS checks.

Open tool

Related guides

Reading A Full dig +trace Response

Follow a trace from the root servers to your authoritative nameservers, and spot delegation problems a normal lookup hides.

Read guide

nslookup vs dig

When to reach for dig's full packet output versus nslookup's quick summary.

Read guide

DNS Records Explained

What A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, and CAA records are for, and how to read them in dig output.

Read guide

DNS TTL Explained

How to read the TTL column and how to pick a value that ages well during a migration.

Read guide

NXDOMAIN vs SERVFAIL

Two DNS error codes that look similar but mean very different things. Decode them from dig's status field.

Read guide

FAQ

What is the difference between dig and nslookup?
dig is the modern UNIX tool for DNS troubleshooting. It exposes the full DNS response — flags, response codes, all sections, and TTLs — in a stable, scriptable format. nslookup is older, interactive, and hides much of the protocol detail. Use dig (or this tool) whenever you need the raw answer or want to share output with someone for diagnosis.
How do I read the status field in a dig answer?
Look for the line that starts with ';; ->>HEADER<<-'. The status code is right after status:. NOERROR means the resolver returned an answer (which may be an empty answer set). NXDOMAIN means the name does not exist. SERVFAIL means the resolver failed to complete the query — often a DNSSEC issue or an upstream timeout. REFUSED usually means the resolver will not answer that query from your network.
What does the TTL column mean?
TTL is the number of seconds the resolver is allowed to cache the answer before re-asking the authoritative server. A small TTL like 60 makes record changes propagate quickly but means more lookups. A large TTL like 86400 (one day) is cheaper but slower to roll out changes. Read 'DNS TTL Explained' for the full picture.
Why does this tool show different answers than my command-line dig?
The two queries are going through different resolvers and possibly different networks. This tool uses public recursive resolvers (Cloudflare, Google, Quad9, OpenDNS). Your local dig probably uses your ISP, corporate, or local DNS, which may have a different cache state, split-horizon view, or filtering. Use Multi-Resolver Compare to see all of them side by side.
Can I query DNSSEC records with this tool?
Not yet — this tool queries A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA. DNSSEC types such as DNSKEY, DS, RRSIG, and NSEC are not supported here. For full chain-of-trust validation, run dig +dnssec locally or use a DNSSEC-specific debugger such as dnsviz.net.
How do I query a specific record type with the DIG tool?
Add the type the same way you would on the command line — for example dig example.com MX or dig example.com TXT. In this tool, set the record type in the form before you submit. The supported types are A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA.
What is the difference between the ANSWER, AUTHORITY, and ADDITIONAL sections?
The ANSWER section holds the records that answer your question. The AUTHORITY section lists the nameservers responsible for the zone, which you often see on a delegation or an NXDOMAIN. The ADDITIONAL section carries supporting records the resolver included to save a round trip — typically the A or AAAA glue for the nameservers in the AUTHORITY section.

Last reviewed: 2026-06-25.