We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Professional tool to query domain DNS records. Supports A, AAAA, MX, NS, and custom DNS servers.
Dig (Domain Information Groper) is a powerful administrative tool used for network troubleshooting and educational purposes. It queries Domain Name System (DNS) servers to retrieve record information such as host addresses (A), mail exchange (MX), and name servers (NS). This tool provides a web-based interface to perform these queries directly without using the command line.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
DNS associates names with records used by internet services. This lookup asks for one name and one selected record type at a time, with an optional DNS server. Enter a hostname or DNS name such as www.example.com, without a scheme, path, port, or query string. The result is a structured view of returned data, rather than a complete raw dig message.
Choose from A, AAAA, CNAME, MX, NS, TXT, SOA, PTR, CAA, and SRV. A returns IPv4 address data; AAAA returns IPv6; MX includes mail exchanger and preference; NS identifies name servers; and TXT returns text data. CNAME indicates an alias, while SOA and SRV expose structured fields for zone authority and service location. RFC 1035 defines the core DNS message and records, with later RFCs specifying AAAA, SRV, and CAA. See RFC 1035, RFC 3596, RFC 2782, and RFC 8659.
Use A or AAAA to ask for an address record. Use CNAME to check for an alias; resolving its target address is a separate lookup.
MX records list mail exchangers with a preference value. TXT records carry text strings used for different domain purposes; interpretation depends on the owner name and the record’s purpose.
NS and SOA expose name-server and zone information. SRV records describe a service target and its connection parameters. CAA records express certificate-authority authorization policy.
PTR looks up a reverse-DNS name. Enter the reverse name itself; this form does not turn a bare IP address into that name for you.
The query result is a snapshot of what the selected resolver returned for that request. It does not by itself establish whether a website is reachable or mail will be delivered.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use a hostname or a service name, for example _sip._tcp.example.com. Do not paste https:// or a URL path.
Choose one of the ten available types. If you are checking both IPv4 and IPv6, run A and AAAA as separate queries.
Leave the server field empty to use the default system DNS selection, or enter a DNS server to compare its response with another resolver.
Review the returned value and record type. MX shows preference alongside its host; TXT values are grouped as text; SOA shows zone fields; other complex records appear as structured data.
Use cases
See how the tool fits into real work and everyday tasks.
When an app cannot reach a hostname, query A or AAAA to see whether that resolver returns an address, then investigate routing and service health separately.
Query MX to inspect listed mail exchangers and their preference values. Use TXT when checking a known policy or verification name, and interpret the text according to the service that uses it.
Run the same name and type against a selected resolver and the default one to identify a difference in returned answers; the comparison is limited to those responses.
Q&A
Find concise answers to common questions and confusing cases.
No. It displays structured record data rather than the full raw message, flags, sections, or command-line options.
One response cannot establish global propagation. Different resolvers may return different cached answers; compare selected resolvers and consult the authoritative DNS configuration for a fuller investigation.
No. DNS data is only one part of service delivery. A returned address does not test the web server, and an MX record does not verify mailbox acceptance or delivery.
Enter the reverse-DNS name, rather than expecting the form to build it from a bare IP address. For IPv4, that name uses the reversed octets under in-addr.arpa.
Notes
Review scope, result limitations, and important precautions before use.
The displayed answer reflects the resolver used for that lookup and may differ from another resolver because DNS data can be cached and updated over time. A single query does not perform a propagation test, DNSSEC validation, full trace, zone transfer, or service availability check. The display is structured record data and does not include the full raw response details needed for those diagnostics.
For changes to production DNS, compare the answer with the authoritative provider’s zone settings and verify the intended record name and type. Do not treat a record lookup alone as proof that a domain, mail system, or certificate configuration is correctly deployed.
Related
Discover related tools, collections, and available API capabilities.