🔍 LIVE DNS LOOKUP INTERACTIVE
💥 Enter a domain name first!
ℹ️ Powered by Cloudflare DoH — queries go to cloudflare-dns.com/dns-query over HTTPS. No software needed — runs entirely in your browser!
📖 READING DIG OUTPUT — ANNOTATED REFERENCE

dig output has a consistent structure across all record types. Once you learn to read one, you can read them all. Click each section below to expand the annotated example.

🟢 Example 1 — dig devdunia.com (A record)
; <<>> DiG 9.18.1 <<>> devdunia.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31415 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;devdunia.com. IN A ;; ANSWER SECTION: devdunia.com. 3600 IN A 185.199.108.153 devdunia.com. 3600 IN A 185.199.109.153 devdunia.com. 3600 IN A 185.199.110.153 devdunia.com. 3600 IN A 185.199.111.153 ;; Query time: 18 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Sun Jun 15 10:00:00 UTC 2026 ;; MSG SIZE rcvd: 105
① HEADER LINE
status: NOERROR — the domain exists and DNS responded cleanly. Other values: NXDOMAIN (domain doesn't exist), SERVFAIL (resolver problem), REFUSED (server declined).
② FLAGSqr = this is a Query Response, rd = Recursion Desired (client asked for full recursion), ra = Recursion Available (server supports it).
③ ANSWER SECTION
Format: name TTL class type data
TTL = Time To Live in seconds — how long resolvers may cache this record. 3600 = 1 hour. GitHub Pages uses 4 IPs for load distribution.
④ STATS
Query time shows round-trip latency to your resolver. Low = cached answer, high = fresh recursive lookup. The SERVER line tells you which resolver answered (here, Cloudflare 1.1.1.1).
📧 Example 2 — dig devdunia.com MX (mail servers)
; <<>> DiG 9.18.1 <<>> devdunia.com MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27183 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;devdunia.com. IN MX ;; ANSWER SECTION: devdunia.com. 3600 IN MX 1 aspmx.l.google.com. devdunia.com. 3600 IN MX 5 alt1.aspmx.l.google.com. devdunia.com. 3600 IN MX 5 alt2.aspmx.l.google.com. devdunia.com. 3600 IN MX 10 alt3.aspmx.l.google.com. devdunia.com. 3600 IN MX 10 alt4.aspmx.l.google.com. ;; Query time: 24 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Sun Jun 15 10:00:00 UTC 2026 ;; MSG SIZE rcvd: 162
MX PRIORITY NUMBERS
The number before the mail server hostname is the priority — lower number = higher preference. Sending servers try priority 1 (aspmx.l.google.com) first, falling back to priority 5 and 10 servers only if the primary is unreachable.
WHY MULTIPLE MX RECORDS?
Redundancy! If Google's primary mail server is down, email bounces to the next-priority servers. Google Workspace (Gmail for business) always sets up multiple MX records for high availability.
📌 Example 3 — dig devdunia.com NS (nameservers)
; <<>> DiG 9.18.1 <<>> devdunia.com NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14142 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;devdunia.com. IN NS ;; ANSWER SECTION: devdunia.com. 86400 IN NS ns1.exampleregistrar.com. devdunia.com. 86400 IN NS ns2.exampleregistrar.com. ;; AUTHORITY SECTION: ; (omitted — shown when answer comes from a non-authoritative resolver) ;; Query time: 12 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Sun Jun 15 10:00:00 UTC 2026 ;; MSG SIZE rcvd: 90
NS RECORDS = WHO'S IN CHARGE?
Nameserver records tell the internet which servers hold the authoritative DNS records for this domain. When you change your domain's nameservers (e.g. moving from GoDaddy to Cloudflare), you update these. The TTL of 86400 = 24 hours — NS records are cached much longer than A records.
AUTHORITY SECTION
When dig queries a non-authoritative resolver (like 1.1.1.1) and the answer is cached, the AUTHORITY section is empty. If you query the authoritative server directly (dig @ns1.exampleregistrar.com devdunia.com NS), you'll see it populated with SOA records.
📋 DNS RECORD TYPES CHEAT SHEET REFERENCE

DNS has over 30 record types — here are the ones you'll encounter daily as a developer.

Type What it stores Example use dig command
A IPv4 address (32-bit) Map domain → IP (e.g. 185.199.108.153) dig example.com A
AAAA IPv6 address (128-bit) Map domain → IPv6 (e.g. 2606:50c0::153) dig example.com AAAA
CNAME Canonical name alias www → example.com, CDN aliases dig www.example.com CNAME
MX Mail server + priority Email routing, Google Workspace setup dig example.com MX
NS Authoritative nameservers Who controls DNS for this domain dig example.com NS
TXT Arbitrary text strings SPF, DKIM, domain verification, DMARC dig example.com TXT
SOA Start of Authority metadata Zone serial, refresh/retry times, admin email dig example.com SOA
PTR Reverse DNS (IP → hostname) Spam filtering, server identity checks dig -x 8.8.8.8
SRV Service location + port VoIP, Minecraft, service discovery dig _sip._tcp.example.com SRV
CAA Allowed SSL/TLS CAs Restrict which CAs can issue certs for domain dig example.com CAA
💡 Pro Tip — TXT records are the Swiss army knife! They're used for SPF (email auth), DKIM (signing keys), DMARC policies, Google Search Console verification, GitHub Pages domain verification, and even some creative hacks like storing JSON config.
🚩 COMMON DIG COMMANDS CHEAT SHEET

Click COPY on any card to copy the command to your clipboard. Replace example.com with your domain.

Basic A Lookup
dig example.com
Default query — returns the A (IPv4) record. The most common dig command.
Mail Servers
dig example.com MX
Lists all mail exchange servers and their priorities for the domain.
Nameservers
dig example.com NS
Shows which nameservers are authoritative for this domain.
TXT Records
dig example.com TXT
Reveals SPF, DKIM, DMARC policies, domain verification tokens and more.
Use Google DNS
dig @8.8.8.8 example.com
Force the query through Google's public resolver. Useful to bypass your ISP's DNS cache.
Use Cloudflare DNS
dig @1.1.1.1 example.com
Query via Cloudflare's ultra-fast resolver. Often faster and more privacy-respecting than ISP DNS.
Short Output
dig +short example.com
Strips all headers — just prints the bare record data. Great for scripting.
Answer Only
dig +noall +answer example.com
Suppresses all sections except ANSWER. Cleaner than +short — still shows TTL & type.
Reverse DNS (PTR)
dig -x 185.199.108.153
Reverse lookup — find the hostname for an IP. The -x flag handles the in-addr.arpa conversion automatically.
All Record Types
dig example.com ANY
Request all available record types in one query. Note: many resolvers now restrict ANY queries to prevent amplification attacks.
Trace Resolution Path
dig +trace example.com
Shows the full delegation chain: root → TLD → authoritative. Invaluable for debugging propagation issues.
Check DNSSEC
dig example.com +dnssec
Requests DNSSEC records (RRSIG, DNSKEY). Look for the ad flag in the response header to confirm validation.
🧠 HOW DNS RESOLUTION WORKS DEEP DIVE

When you type devdunia.com in your browser, up to 7 layers of caching and delegation fire before you get the IP — all in under 50ms. Here's how:

1

Browser Cache — The browser checks its own DNS cache first. If you visited devdunia.com recently and the TTL hasn't expired, you get the IP instantly. Chrome: chrome://net-internals/#dns to inspect.

2

OS Cache — Cache miss? The OS checks its own resolver cache (/etc/hosts on Linux/Mac, the hosts file on Windows, plus the system resolver cache). This is why sudo dscacheutil -flushcache helps after a DNS change on Mac.

3

Recursive Resolver — Still no cached answer? The OS sends the query to your configured DNS resolver (e.g. 1.1.1.1, 8.8.8.8, or your ISP's resolver). This server does the heavy lifting — it's called "recursive" because it recurses through the DNS hierarchy on your behalf.

4

Root Nameservers — If the recursive resolver doesn't have the answer cached, it queries one of the 13 root nameserver clusters (a.root-servers.net → m.root-servers.net). The root servers don't know the IP — but they know who does: the TLD nameservers.

5

TLD Nameservers — The root server replies: "I don't know, but ask the .com TLD nameservers." The resolver queries Verisign's .com nameservers which respond with the domain's authoritative nameservers (e.g. ns1.yourregistrar.com).

6

Authoritative Nameserver — The resolver now queries your domain's nameservers — the ones configured at your registrar (Cloudflare, Route 53, GoDaddy, etc.). These servers hold the actual DNS zone file and return the definitive answer.

7

Answer Returned & Cached — The IP is returned all the way back up the chain. The recursive resolver caches the answer for the record's TTL, so future queries skip steps 4–6. Your browser renders the page. Total time: ~10–50ms for a cached answer, ~100–400ms for a cold recursive lookup.

🧪 Test it yourself! Run dig +trace devdunia.com in your terminal to watch the full delegation chain live — root servers, TLD servers, and the authoritative answer, all in one command.

TTL (Time To Live)

Seconds a record may be cached. Low TTL = faster propagation when you change records, but more DNS queries. Set TTL low before migration, raise it after.

DNS Propagation

When you update a DNS record, old resolvers keep serving the cached version until TTL expires. "Propagation" just means waiting for caches worldwide to expire.

DNSSEC

DNS Security Extensions add cryptographic signatures to records, preventing cache poisoning attacks. Look for the ad (Authenticated Data) flag in dig output.

DoH / DoT

DNS-over-HTTPS and DNS-over-TLS encrypt DNS queries so your ISP can't see what domains you're visiting. This tool uses Cloudflare DoH for all live lookups!