dig is a command-line DNS query tool that shows both answers and the context around them. It can ask for a specific record type, target a chosen DNS server, and follow the delegation path from root servers. Those are separate tests. Start with the lookup that failed and change one setting at a time so that a different name, record type, or resolver does not obscure the comparison.

These examples use the BIND 9 version of dig and the reserved documentation name example.com. Run them in a terminal where dig is available, substituting the hostname you need to check. The examples illustrate command syntax, not measured lookup results.

Query a Name and Record Type

Enter the hostname followed by the record type. The command below asks for A records, which contain IPv4 addresses. Use a hostname rather than a full web address with an HTTPS prefix or a path.

dig example.com A

For IPv6 address records, use dig example.com AAAA; for mail exchanger records, replace AAAA with MX; for text records, use TXT. A name can exist without the requested type. BIND dig normally asks for A when the type is omitted, but specifying it makes comparisons easier to interpret.

Without an explicit server, dig uses its resolver configuration. On typical Unix-like installations, that means consulting /etc/resolv.conf for DNS server addresses. This query path can differ from the one used by a browser or another application with its own DNS service. Check the responding server in the output instead of assuming that every application made the same lookup.

Choose a Resolver Explicitly

Put an at-sign and server address before the name to query that server. These commands compare the default resolver with Cloudflare's standard public resolver at 1.1.1.1 while keeping the name and type unchanged. Use only resolvers permitted on your network, and keep private company names on the organization's approved DNS service.

dig example.com AAAA
dig @1.1.1.1 example.com AAAA

The SERVER line in a completed response identifies the endpoint that replied. The explicit server option affects this command; it does not rewrite system DNS settings. If a local resolver knows a private zone or applies filtering, a public resolver may answer differently for legitimate reasons. Compare queries made on the same network at roughly the same time.

A timeout means dig did not receive a reply within the configured limits. The server or network path may be unavailable, or a firewall may be dropping the traffic. Silence does not prove that the domain has no record. A DNS response with status REFUSED is different: the server replied but declined the query.

If you query an authoritative server directly, check that the requested name belongs to a zone it serves. Such a query tests that server's zone data, whereas a query through a recursive resolver can involve cached data and additional lookups. Record which kind of server you contacted before interpreting a difference.

Read the Full Response

In ordinary output, the header contains a status such as NOERROR, NXDOMAIN, or SERVFAIL. NOERROR means the reply reports no DNS error, but it does not guarantee an address in the answer section. NXDOMAIN reports a nonexistent name; if the reply contains an alias, inspect its target as well. SERVFAIL means the server could not complete the query successfully and does not identify a single root cause.

The QUESTION SECTION shows the name, class, and type associated with the response. Use it to catch a typo or an accidental type mismatch. The ANSWER SECTION contains returned records, normally shown with their owner name, TTL, class, type, and value. Check the actual type on each line because an answer can include an alias as well as address records.

The AUTHORITY SECTION can help distinguish a missing record from a referral to other servers. For example, a NOERROR reply with no matching answer and an SOA record in the authority section can indicate that the requested type is absent. In a referral, NS records in the AUTHORITY SECTION identify the next name servers, and the ADDITIONAL SECTION may include their addresses. Read that context before treating an empty answer as a final result.

Keep the full output while diagnosing a failure. The +short option hides context, so a blank result alone cannot distinguish a missing name, missing type, or failed query. After interpreting the full response, +noall +answer provides a compact answer list that retains record names, TTLs, types, and values.

Check Flags and Timing

An aa flag indicates that the responding server is authoritative for the queried name. An ra flag advertises that recursion is available from that server; it does not prove that this answer required a fresh recursive lookup. Authority and recursion flags are different from a claim that DNSSEC signatures have been validated.

A recursive answer may show a remaining cache TTL rather than the original value set in the zone. A small TTL alone does not establish when the record changed or whether it is wrong. If you control the zone, compare the returned data with the authoritative configuration and the time of the change.

The query-time value measures the DNS exchange under the current test conditions. It is not a prediction of browsing speed or a check of the website's certificate and application. When comparing results, retain the full command, output, time, active network, and dig version, which dig -v displays.

Trace Delegation from the Root

The +trace option follows delegation referrals from root name servers toward the authoritative servers for the requested name. Use it when a normal lookup suggests a delegation problem. This example traces an NS query:

dig example.com NS +trace

After discovering the root servers, dig sends its own iterative queries along the referral path. If an explicit server is supplied, it is used only for the initial root-server discovery query. The later queries need direct access to other DNS servers, so a network that permits only its approved resolver can prevent the trace from completing.

Tracing enables the DNSSEC record request option, but requesting those records is not the same as validating their signatures. The trace also does not reproduce every cache, forwarding rule, internal DNS view, or policy used by a recursive resolver. A successful trace therefore does not rule out a problem in the normal resolution path.

For a direct comparison, trace the same name and record type as the failing recursive query. If a trace stops, check which server failed to answer and whether your network allows that contact before blaming the delegation. If the trace completes but the recursive query returns SERVFAIL, investigate the resolver's validation, cache, policy, and network access. Give the DNS administrator both outputs with the exact name and type tested, then repeat the original lookup after the identified problem is corrected.