DNS Lookup Explained: How to Check Records Instantly

Why You Are Searching for This

You are either debugging a domain that is not resolving, trying to verify that your DNS changes have propagated, investigating email delivery failures, or simply trying to understand what dig output actually means. All of these come down to the same need: reading and interpreting DNS records correctly.

DNS failures are silent and slow. Unlike a crashed server that returns an immediate error, a misconfigured DNS record can cause intermittent failures that vary by geographic location, appear and disappear as caches expire, and produce different symptoms for different users. Knowing how to check DNS records directly — bypassing caches and looking at authoritative sources — is a skill that saves significant debugging time.

What Is DNS?

DNS (Domain Name System) is a distributed, hierarchical database that maps human-readable domain names to IP addresses and other machine-readable information. When you type example.com into a browser, your computer has no idea what IP address to connect to. DNS resolves that name to an IP so TCP/IP can do its job.

The DNS namespace is organized as a tree:

• The root is represented by a dot (.) and is managed by ICANN
• TLDs (Top-Level Domains) sit below the root: .com, .org, .net, .uk
• Second-level domains sit below TLDs: example.com, google.com
• Subdomains sit below second-level domains: www.example.com, mail.example.com

Each level of this hierarchy is managed by a different set of nameservers, and DNS resolution walks down this tree to find the answer.

How DNS Resolution Works: Step by Step

When you browse to www.example.com for the first time, here is exactly what happens:

Step 1: Local Cache Check

Your operating system first checks its local DNS cache. If you resolved this domain recently and the TTL (Time to Live) has not expired, the cached answer is returned immediately without any network query. On Linux/macOS, you can see the resolver config at /etc/resolv.conf. On Windows, ipconfig /displaydns shows the cache.

Step 2: Recursive Resolver

If not cached, your OS sends a query to the recursive resolver (also called the recursive nameserver or full-service resolver). This is typically provided by your ISP or a public resolver like Google (8.8.8.8), Cloudflare (1.1.1.1), or Quad9 (9.9.9.9). The recursive resolver does the heavy lifting of walking the DNS tree on your behalf.

Step 3: Root Nameservers

The recursive resolver first queries one of the 13 root nameserver clusters (a.root-servers.net through m.root-servers.net). These do not know the answer for www.example.com directly, but they know which nameservers are authoritative for .com. They respond with a referral to the TLD nameservers.

Step 4: TLD Nameservers

The recursive resolver queries the .com TLD nameservers (operated by Verisign). These do not know the answer either, but they know which nameservers are authoritative for example.com. They respond with another referral to the authoritative nameservers for that domain.

Step 5: Authoritative Nameserver

The recursive resolver finally queries the authoritative nameserver for example.com. This server holds the actual DNS zone file with all records for that domain. It returns the authoritative answer — for example, the A record mapping www.example.com to 93.184.216.34.

Step 6: Caching and Response

The recursive resolver caches the answer according to its TTL value, then returns it to your OS, which caches it too. Subsequent queries for the same name within the TTL window are answered from cache without any network round-trips.

The entire recursive resolution process — root, TLD, authoritative — typically completes in 50–200ms for a cold lookup. Cached responses are returned in under 1ms.

DNS Record Types Explained

A Record (Address)

Maps a hostname to an IPv4 address. The most fundamental DNS record type. A domain can have multiple A records for load balancing or redundancy.

example.com.    300    IN    A    93.184.216.34
www.example.com. 300   IN    A    93.184.216.34

AAAA Record (IPv6 Address)

Maps a hostname to an IPv6 address. The name comes from IPv6 being four times the size of IPv4 (128 bits vs 32 bits).

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME Record (Canonical Name)

An alias that points one hostname to another. When a resolver sees a CNAME, it follows the chain until it reaches an A or AAAA record. CNAMEs cannot coexist with other records at the same name — you cannot have both a CNAME and an MX record for example.com (though you can at www.example.com). Many DNS providers offer ALIAS or ANAME records as a workaround for root domain aliases.

www.example.com.    300    IN    CNAME    example.com.
blog.example.com.   300    IN    CNAME    example.ghost.io.

MX Record (Mail Exchange)

Specifies the mail server(s) responsible for accepting email for a domain. MX records include a priority value — lower numbers are tried first, enabling failover. The value must point to a hostname, not an IP address.

example.com.    300    IN    MX    10    mail1.example.com.
example.com.    300    IN    MX    20    mail2.example.com.

TXT Record (Text)

Stores arbitrary text data. Used for domain verification, email authentication, and many other purposes. Common TXT records:

• SPF: "v=spf1 include:_spf.google.com ~all" — specifies which servers may send email for the domain
• DKIM: Public key used to verify email signatures (lives at selector._domainkey.example.com)
• DMARC: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" — email authentication policy
• Google/AWS/GitHub verification: Strings like "google-site-verification=abc123"

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com. 300 IN  TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

NS Record (Name Server)

Specifies the authoritative nameservers for a domain. These are set at the domain registrar and delegate DNS authority to a specific DNS provider. Changing NS records requires a registrar-level change and can take up to 48 hours to propagate globally.

example.com.    172800    IN    NS    ns1.exampledns.com.
example.com.    172800    IN    NS    ns2.exampledns.com.

SOA Record (Start of Authority)

Contains administrative information about a DNS zone: the primary nameserver, the responsible email address (the @ is replaced with a dot), and several timing parameters used by secondary nameservers for zone transfer synchronization.

example.com.    3600    IN    SOA    ns1.exampledns.com. admin.example.com. (
                    2026032601  ; Serial (YYYYMMDDnn)
                    3600        ; Refresh (1 hour)
                    900         ; Retry (15 min)
                    604800      ; Expire (1 week)
                    300         ; Negative cache TTL (5 min)
                )

SRV Record (Service)

Specifies the location of services using a standardized format. Used by SIP (VoIP), XMPP (chat), and many other protocols to locate service endpoints without hardcoding IPs or hostnames.

_sip._tcp.example.com.  300  IN  SRV  10 20 5060 sip.example.com.
; Priority Weight Port Target

CAA Record (Certification Authority Authorization)

Specifies which Certificate Authorities are allowed to issue TLS certificates for a domain. Prevents unauthorized certificate issuance. Any CA not listed in a CAA record must refuse to issue a certificate for that domain.

example.com.    300    IN    CAA    0 issue "letsencrypt.org"
example.com.    300    IN    CAA    0 issue "digicert.com"
example.com.    300    IN    CAA    0 issuewild ";"  ; no wildcard certs

Using dig: The Definitive DNS Debugging Tool

dig (Domain Information Groper) is the standard command-line DNS lookup tool. It queries DNS servers directly and shows the full response including TTL, record class, and server metadata. Available on Linux and macOS by default; install via winget install ISC.BIND on Windows.

Basic A Record Lookup

$ dig example.com

; <<>> DiG 9.18.1 <<>> example.com
;; QUESTION SECTION:
;example.com.                   IN      A

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

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 26 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 56

The ANSWER SECTION shows the record type (A), TTL in seconds (3018), class (IN for Internet), and the value (93.184.216.34). The SERVER line shows which resolver answered the query.

Query a Specific Record Type

# MX records
dig example.com MX

# TXT records (SPF, DKIM, DMARC)
dig example.com TXT
dig _dmarc.example.com TXT
dig google._domainkey.example.com TXT

# NS records
dig example.com NS

# All records (ANY query — may not work on all resolvers)
dig example.com ANY

Query the Authoritative Nameserver Directly (Bypass Cache)

# First, find the authoritative NS
dig example.com NS +short
# Output: ns1.exampledns.com.

# Then query it directly — @server syntax
dig @ns1.exampledns.com example.com A

# Short output only
dig example.com A +short
# Output: 93.184.216.34

Trace the Full Resolution Path

# +trace follows the delegation chain from root to authoritative
dig example.com +trace

The +trace flag makes dig perform iterative resolution itself, querying each level of the hierarchy in sequence. This is invaluable for debugging delegation issues, where a domain's NS records at the registrar and the records in the zone file are inconsistent.

Reverse DNS Lookup (PTR Records)

# Reverse lookup: IP to hostname
dig -x 93.184.216.34

# Or using the arpa format directly
dig 34.216.184.93.in-addr.arpa PTR

Using nslookup and host

nslookup is available on all platforms including Windows and provides a simpler interface than dig:

# Basic lookup
nslookup example.com

# Query specific record type
nslookup -type=MX example.com

# Query specific server
nslookup example.com 8.8.8.8

# Interactive mode
nslookup
> set type=TXT
> example.com
> exit

The host command is even simpler and good for quick checks:

host example.com           # A record
host -t MX example.com    # MX records
host -t TXT example.com   # TXT records
host 93.184.216.34         # Reverse lookup

TTL Explained: Why Changes Take Time

Every DNS record has a TTL (Time to Live) value in seconds. This tells resolvers and caches how long to keep the answer before querying again. A TTL of 300 means any cached answer is valid for 5 minutes before it must be refreshed.

TTL has direct implications for DNS changes:

• If your A record has TTL 86400 (24 hours) and you change the IP, some resolvers will continue sending traffic to the old IP for up to 24 hours
• To minimize downtime during IP changes, lower your TTL to 300 (5 minutes) at least 24 hours before making the change, make the change, then raise the TTL back after confirming everything works
• Root and TLD nameserver TTLs are typically 172800 (48 hours) for NS record changes — this is why domain registrar changes can take up to 48 hours
• Negative cache TTL (from the SOA record) controls how long NXDOMAIN responses are cached — important for newly created domains that were queried before the record existed

DNS Propagation

When you change a DNS record, the change is immediately visible on the authoritative nameserver. But resolvers around the world that have the old answer cached will not see the change until their cached TTL expires. This is what people mean by "DNS propagation" — it is not the DNS system broadcasting changes, it is resolvers' caches expiring at different times.

Practical notes:

• Different resolvers cache for different durations. Some ignore TTL and cache for longer. Google (8.8.8.8) and Cloudflare (1.1.1.1) generally respect TTL closely.
• You can check propagation from multiple geographic locations using tools like SecureBin's DNS Lookup, which queries multiple resolvers simultaneously
• ISP resolvers may cache aggressively for hours regardless of TTL — users on those networks will see the old record longest
• To check the authoritative answer (not cached), always query the NS directly using dig @ns1.yourdns.com yourname.com

Common DNS Errors and What They Mean

NXDOMAIN (Non-Existent Domain)

NXDOMAIN means the queried name does not exist in DNS. The authoritative nameserver explicitly confirmed it does not have a record for that name. Common causes:

• Typo in the domain name
• The record was deleted
• The domain registration expired
• A subdomain was queried before its record was created (check authoritative NS directly — it may exist there but your resolver cached the NXDOMAIN)

SERVFAIL (Server Failure)

SERVFAIL means the recursive resolver failed to get an answer. Unlike NXDOMAIN (which is a definitive "does not exist"), SERVFAIL is an operational error. Common causes:

• The authoritative nameserver is unreachable or down
• DNSSEC validation failure — the signature on the record is invalid or expired
• The nameserver returned a malformed response
• Zone transfer failure between primary and secondary NS

REFUSED

The nameserver explicitly refused to answer the query. Usually because you are querying a nameserver that is not authoritative for the domain and it does not allow recursive queries from your IP. This is common when you query a corporate internal DNS server for an external name.

NOERROR with Empty Answer (NODATA)

The domain exists but there is no record of the requested type. For example, querying AAAA for a domain that only has an A record returns NOERROR with an empty answer section. This is technically called NODATA and is different from NXDOMAIN.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on the network path — your ISP, coffee shop Wi-Fi operator, or a man-in-the-middle — can see every domain name you look up. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt DNS queries to prevent this.

DNS over HTTPS (DoH) sends queries over HTTPS (port 443), making them indistinguishable from regular web traffic. Major providers:

# Cloudflare DoH
curl "https://1.1.1.1/dns-query?name=example.com&type=A" \
  -H "accept: application/dns-json"

# Google DoH
curl "https://dns.google/resolve?name=example.com&type=A"

DNS over TLS (DoT) uses TLS on port 853. Less common for end-users but used between DNS resolvers and forwarders. You can test it with kdig from the knot-dns package:

kdig -d @1.1.1.1 +tls-ca +tls-hostname=cloudflare-dns.com example.com

Both protocols protect query confidentiality. They do not change what answers you receive — only how securely the query travels. If you are concerned about DNS privacy, enable DoH in your browser settings (Firefox and Chrome both support it natively) or use a DoH-capable resolver on your router.

Real Lookup Examples

Here is a complete diagnostic sequence for investigating an email delivery problem. The domain is not receiving email, and you need to check the full mail DNS configuration:

# 1. Check MX records
dig example.com MX +short
# 10 mail.example.com.

# 2. Check that the MX target resolves
dig mail.example.com A +short
# 203.0.113.10

# 3. Check SPF (TXT at apex)
dig example.com TXT +short
# "v=spf1 include:_spf.google.com ~all"

# 4. Check DMARC
dig _dmarc.example.com TXT +short
# "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

# 5. Check DKIM (replace 'google' with your selector)
dig google._domainkey.example.com TXT +short
# "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

# 6. Verify authoritative NS agrees (bypass cache)
dig example.com NS +short
# ns1.exampledns.com.
dig @ns1.exampledns.com example.com MX +short
# Same result = cache and authoritative agree

Frequently Asked Questions

What is the difference between dig and nslookup?

dig is the modern standard and is preferred by DNS professionals. It shows the full DNS response including TTL, flags, and server metadata, and its output format is scriptable and consistent across versions. nslookup is older, available on Windows by default, and suitable for quick interactive lookups. For scripting and precise debugging, use dig. For a quick check on a Windows machine without additional tools installed, nslookup is adequate. The host command is useful for its concise output when you just need a quick answer.

Why do I get different DNS results from different locations?

There are two common reasons. First, if you changed a DNS record recently, different resolvers around the world have different cached values depending on whether their cached copy has expired yet — this is DNS propagation in action. Second, some DNS providers use GeoDNS (also called latency-based routing or Anycast routing) to return different IP addresses based on the querier's location, directing users to the nearest server. A GeoDNS-enabled domain intentionally returns different A records to users in different regions.

How long does DNS propagation take?

It depends entirely on the TTL of the record being changed. If your A record has TTL 300 (5 minutes), propagation effectively completes within 5 minutes because all resolvers' cached copies expire within that window. If the TTL is 86400 (24 hours), it can take up to 24 hours. NS record changes (registrar-level) are governed by the TLD registry's TTL, typically 172800 (48 hours). The phrase "DNS propagation takes 24-48 hours" refers specifically to NS record changes — for a standard A or MX record with a short TTL, changes can be live worldwide in minutes.

What does DNSSEC do and should I use it?

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that the answer they receive is authentic and has not been tampered with in transit. Without DNSSEC, a man-in-the-middle can forge DNS responses and redirect your traffic to malicious servers (DNS spoofing / cache poisoning). With DNSSEC, any tampered response will fail signature verification and be rejected. You should enable DNSSEC if your DNS provider and registrar support it (most major providers do). It is especially important for high-value domains. Note: DNSSEC protects authenticity, not confidentiality — queries are still plaintext without DoH/DoT.

What is a DNS flush and when do I need it?

Flushing the DNS cache forces your OS to discard all cached DNS answers and make fresh queries. This is useful when you have changed DNS records and need to see the new values immediately without waiting for the cache TTL to expire. Commands by platform:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Windows
ipconfig /flushdns

Note that flushing your local cache only helps if the resolver you use (e.g., 8.8.8.8 or 1.1.1.1) has also expired its cache. If the upstream resolver still has the old answer cached, your request will get the old answer again immediately.

Why does my A record show the correct IP but the site still doesn't load?

DNS resolution is only one step in connecting to a server. If the A record resolves correctly but the site does not load, the problem lies elsewhere. Check: (1) Is the server running and listening on port 80/443? Use curl -v http://ip-address to test directly. (2) Is there a firewall rule blocking traffic? Check your cloud security groups or local firewall. (3) Is the TLS certificate valid for the domain? (4) Is there a web server (nginx, Apache) actually serving requests? (5) If you are behind a CDN like Cloudflare, is the origin server healthy? DNS is often blamed for problems that are actually server-side or network-side.

What is the difference between a CNAME and an ALIAS/ANAME record?

A CNAME record cannot be placed at the zone apex (the root domain, e.g., example.com) because the RFC prohibits coexistence of a CNAME with other record types, and the apex always needs NS and SOA records. However, many services (GitHub Pages, Heroku, Netlify, etc.) require you to point your root domain to their hostname. DNS providers like Cloudflare, Route 53, and Netlify DNS offer an ALIAS or ANAME record as a vendor extension. It works like a CNAME (follows the chain to an IP) but is resolved server-side at the authoritative nameserver, returning an A record to the client. This allows CDN-style features at the root domain without violating the CNAME-at-apex rule.

Use our free tool here → SecureBin DNS Lookup Tool