DNS lookup examples and record types explained for developers

Quick answer

💡Use dig hostname A to look up the IPv4 address for a hostname, dig hostname AAAA for IPv6, and dig hostname MX to find mail servers. Add @8.8.8.8 before the hostname to bypass your local resolver and query Google's public DNS directly. For troubleshooting propagation, compare results from multiple resolvers: dig @1.1.1.1 hostname A and dig @8.8.8.8 hostname A. NXDOMAIN means no record exists; SERVFAIL means the authoritative nameserver failed to respond.

Run DNS lookup →

Error symptoms

  • ✕DNS_PROBE_FINISHED_NXDOMAIN in Chrome — domain not found
  • ✕getaddrinfo ENOTFOUND hostname in Node.js
  • ✕SERVFAIL response from the resolver
  • ✕Domain resolves on one computer but not another
  • ✕Email delivery fails — MX record lookup returns nothing
  • ✕New DNS record not taking effect hours after publishing

Common causes

  • •Querying the wrong hostname or missing subdomain
  • •Missing or incorrect A, AAAA, CNAME, MX, or TXT record
  • •Old TTL still in effect at recursive resolvers
  • •VPN or corporate DNS returns different results than public resolvers
  • •Authoritative nameserver is misconfigured and returns SERVFAIL
  • •Firewall blocking DNS traffic on UDP port 53

When it happens

  • •Setting up custom domains for web applications
  • •Configuring email delivery with MX and SPF records
  • •Verifying domain ownership with TXT records
  • •Debugging container networking in Kubernetes or Docker
  • •Migrating DNS to a new hosting provider

DNS record types: A, AAAA, CNAME, MX, TXT, and NS explained

DNS stores different types of information for each domain in separate record types. Understanding which record type answers which question is the foundation of DNS troubleshooting.

A (Address) records map a hostname to an IPv4 address. This is the most fundamental DNS record — when a browser needs to connect to www.example.com, it queries for an A record and uses the returned IP address to open a TCP connection. A single hostname can have multiple A records (multiple IP addresses), and DNS will return them in a round-robin order for basic load balancing. A records are also used by HTTP to HTTPS redirect services, CDN edge nodes, and hosting platforms.

AAAA (Quad-A) records map a hostname to an IPv6 address. The modern internet supports both IPv4 and IPv6, and most operating systems follow a 'Happy Eyeballs' algorithm that queries for both A and AAAA records simultaneously and connects using whichever responds first. If your application does not respond on IPv6 but has an AAAA record published, IPv6-preferring clients may experience slow connections or timeouts as they fall back to IPv4.

CNAME (Canonical Name) records create an alias from one hostname to another. When a resolver encounters a CNAME, it follows the chain to the target hostname and resolves that instead. For example, www.example.com CNAME example.com means querying www.example.com produces the same A record as example.com. CNAME records cannot coexist with other record types for the same name — you cannot have both a CNAME and an MX record for www.example.com. Crucially, CNAME records cannot be used at the apex domain (example.com itself, also called the zone root) in standard DNS — only at subdomains. Some DNS providers work around this with proprietary ALIAS or ANAME record types that behave like CNAMEs at the apex.

MX (Mail Exchanger) records specify which mail servers should receive email for a domain. MX records have a priority value — lower numbers indicate higher priority. When email is sent to [email protected], the sending mail server queries for example.com MX records, sorts them by priority, and attempts delivery to the highest-priority server first. SPF (Sender Policy Framework) records are stored in TXT records and specify which IP addresses and domains are authorized to send email on behalf of the domain.

TXT (Text) records store arbitrary text data and are used for domain verification, SPF, DKIM signatures, DMARC policies, and custom application metadata. A single domain can have multiple TXT records, and each TXT record can contain multiple quoted strings. NS (Name Server) records specify the authoritative nameservers for a domain — these are the servers that hold the definitive answers for all DNS records in the zone. SOA (Start of Authority) records contain administrative information about the zone including the primary nameserver, the zone administrator's email address, and several timing parameters including the default TTL.

Example 1

DNS resolution and HTTP status codes are separate — confirm name resolution before blaming the application.

Diagnosing a missing A record vs an HTTP error

❌ Wrong

# Broken approach: HTTP 404 mistakenly blamed on DNS
$ curl -I https://www.example.com
HTTP/2 404
# Conclusion: DNS is broken
# Wrong — if curl gets a 404, DNS resolved successfully
# The 404 is an application-level response, not a DNS error
$ dig example.com  # Missing record type filter

✅ Fixed

# Fixed: separate DNS, TLS, and HTTP layers
$ dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34

$ dig www.example.com CNAME
;; ANSWER SECTION:
www.example.com. 3600 IN CNAME example.com.

$ curl -v https://www.example.com/ 2>&1 | grep -E 'Connected|HTTP'
# Connected to example.com (93.184.216.34) port 443
# HTTP/2 404
# DNS resolved correctly. The 404 is from the web server.

If curl receives any HTTP status code (200, 404, 500), DNS resolution already succeeded — the name was resolved to an IP address and a TCP connection was established. A DNS error would prevent curl from connecting at all and would produce 'Could not resolve host.' Always check DNS, TLS, and HTTP as separate layers before concluding which one is broken.

Using dig, nslookup, and host to query DNS records

dig (Domain Information Groper) is the most powerful and precise DNS query tool available on macOS and Linux. Unlike nslookup, dig does not modify your query or interpret the response — it shows exactly what the DNS protocol exchanged, including TTL values, query times, and the responding server's address. Learning to read dig output is an essential skill for any developer who works with DNS.

The basic dig syntax is: dig [options] [hostname] [type]. The type defaults to A if omitted. Common examples: dig example.com A for IPv4 address, dig example.com AAAA for IPv6, dig example.com MX for mail servers, dig example.com TXT for text records, dig example.com NS for nameservers, dig example.com CNAME to check for aliases. Add @resolver before the hostname to specify a DNS resolver: dig @8.8.8.8 example.com A queries Google's public DNS, while dig @1.1.1.1 example.com A queries Cloudflare. This bypasses your operating system's resolver configuration and lets you directly compare results from different resolvers.

Useful dig flags include: +short to print only the answer (no headers), +trace to show the full resolution chain from root nameservers down to the authoritative nameserver, +nocmd +noall +answer to print only the answer section without noise, and -x for reverse lookups (covered later). The +trace flag is invaluable for diagnosing delegation problems — it shows exactly which nameserver at each level is authoritative and what it returned, letting you pinpoint where the resolution chain breaks.

nslookup is available on both Unix systems and Windows and is useful for quick lookups. Its interactive mode lets you change the record type with the type command: nslookup, then set type=MX, then example.com. On Windows, nslookup is often the only DNS tool available in the default installation. However, nslookup's output format is less precise than dig's, and it sometimes performs additional lookups that add noise to the output.

The host command is a simpler alternative to dig that is easier to read for basic lookups. host example.com returns A, AAAA, and MX records simultaneously. host -t TXT example.com limits the query to TXT records. host does not display TTL values by default. On macOS, be aware that macOS performs DNS lookups through its mDNSResponder service, which may cache results differently from what dig and nslookup report — always test with both dig and the application that is having the DNS problem.

✦

Always specify the record type in dig

dig example.com without a type queries for A records only, hiding MX, TXT, CNAME, and other records. Use dig example.com ANY to request all record types (some resolvers restrict this), or query each type separately. For email troubleshooting, always check MX, TXT (SPF), and TXT at _dmarc.example.com explicitly.

Example 2

Domain verification records are often at a specific subdomain, not at the apex.

Querying the correct subdomain for TXT verification

❌ Wrong

# Broken: querying the wrong hostname for verification
$ dig example.com TXT
;; ANSWER SECTION:
example.com. 3600 IN TXT "v=spf1 include:mail.example ~all"
# Provider dashboard shows: verification failed
# Reason: the verification record is at a different host

✅ Fixed

# Fixed: query the exact subdomain the provider specified
$ dig _acme-challenge.example.com TXT
;; ANSWER SECTION:
_acme-challenge.example.com. 120 IN TXT "abc123xyz"

# Cross-check with multiple public resolvers
$ dig @1.1.1.1 _acme-challenge.example.com TXT
$ dig @8.8.8.8 _acme-challenge.example.com TXT

# Both should return the same value after propagation
# If they differ, the record is still propagating

Domain verification TXT records are almost always placed at a specific subdomain (like _acme-challenge, _github-challenge-, _tooldock-verify) rather than at the apex domain. Querying the apex returns existing SPF or DMARC records, not the verification token. Always copy the exact hostname from the provider's verification instructions and use it verbatim in your dig command.

TTL, caching, and why changes take time to propagate

TTL (Time To Live) is a value, in seconds, that a DNS record publisher attaches to each record. It instructs caching resolvers (recursive DNS servers, operating system caches, and browser caches) how long they may cache and reuse the answer before they must query the authoritative nameserver again. A TTL of 300 means resolvers may cache the answer for up to five minutes. A TTL of 86400 means resolvers may cache it for up to 24 hours.

When you change a DNS record — updating an A record to a new IP address, adding a TXT verification record, or switching MX records to a new mail provider — the change takes effect immediately at your authoritative nameserver. However, every resolver that previously queried that record will continue using its cached version until that cache entry expires. This is why DNS changes appear to take effect instantly for some users (those whose resolvers had already expired their cache, or those who use a different resolver that had not cached the old value) while other users see the old value for much longer.

The propagation time for a DNS change is bounded by the old TTL value at the time of the change, not the new TTL. If your A record had a TTL of 86400 (24 hours) when you changed it, some resolvers may cache the old IP address for up to 24 more hours after your change. A best practice before making DNS changes is to lower the TTL of the records you plan to change well in advance — typically to 300 seconds (5 minutes) — wait at least 24-48 hours for the lower TTL to propagate and for caches to expire, make your change, verify it is taking effect quickly, and then raise the TTL back to a higher value once you are confident the change is stable.

Dig shows you the current TTL of each record in the answer section. The first number after the hostname is the TTL: example.com. 247 IN A 93.184.216.34 means this record will expire from the resolver's cache in 247 seconds. When you run the same dig command again from the same resolver a minute later, you should see the TTL decrement — this confirms the resolver is caching the record. If the TTL resets to the full original value on every query, the resolver is not caching, which can indicate a misconfigured local resolver or a VPN that intercepts DNS traffic.

Note-worthy caches include: the browser DNS cache (chrome://net-internals/#dns to flush in Chrome), the operating system DNS cache (sudo dscacheutil -flushcache on macOS, sudo systemd-resolve --flush-caches on Linux), and the ISP's recursive resolver. Flushing all three layers and then querying with dig @8.8.8.8 will show you what a fresh resolver would see, which is usually the most reliable way to verify your DNS change is live.

Diagnosing DNS problems: NXDOMAIN, SERVFAIL, and timeouts

DNS errors have specific response codes (RCODE) that identify what went wrong. Understanding these codes is the first step in efficient DNS troubleshooting.

NXDOMAIN (Non-Existent Domain, RCODE 3) means the authoritative nameserver confirmed that the queried name does not exist in the DNS zone. This is a definitive negative answer — unlike a caching result, NXDOMAIN comes from the authoritative nameserver itself. In browsers, Chrome displays DNS_PROBE_FINISHED_NXDOMAIN. In Node.js applications, you see getaddrinfo ENOTFOUND hostname. In Python, socket.gaierror: [Errno -2] Name or service not known. The most common causes of NXDOMAIN are: a typo in the hostname, a missing DNS record (you forgot to create it), a deleted record, or querying for a subdomain that was never configured. To diagnose: run dig hostname A and look for the status line — Status: NXDOMAIN confirms the server responded but found nothing. Then check your DNS provider's dashboard to verify the record exists.

SERVFAIL (Server Failure, RCODE 2) means a resolver tried to look up the record but the authoritative nameserver failed to respond or returned an error. Unlike NXDOMAIN, SERVFAIL does not definitively mean the record doesn't exist — it means the query process broke down somewhere in the resolution chain. Common causes: the nameserver listed in NS records is unreachable or misconfigured, DNSSEC signature validation failed, the zone is not properly delegated, or the authoritative nameserver returned a malformed response. To diagnose: run dig +trace hostname A to trace the full resolution path and identify which step fails. DNSSEC-related SERVFAILs can be confirmed with dig hostname A +cd (disable checking) — if the query succeeds with checking disabled, the issue is in the DNSSEC signatures.

Timeout means the resolver sent a query but received no response before the timeout expired. In dig, this appears as a semicolon-prefixed ;; connection timed out; no servers could be reached. Common causes: UDP port 53 is blocked by a firewall, the resolver is down, or the authoritative nameserver is unreachable. Test connectivity to the resolver: dig @8.8.8.8 example.com A will confirm whether the problem is with your local resolver or with the authoritative nameserver. If @8.8.8.8 works but your default resolver times out, the problem is with your ISP or corporate DNS configuration.

Refused (RCODE 5) means the server received the query but chose not to answer it, often due to access control lists on the nameserver. This is common in corporate environments where internal DNS servers refuse queries from unknown sources. NOERROR with an empty answer section is different from NXDOMAIN — it means the name exists (or at least a parent zone does) but there are no records of the requested type for that name. For example, querying example.com CNAME might return NOERROR with no answer if example.com has A records but no CNAME record.

⚠

Lower your TTL before making DNS changes

If your A record has a TTL of 86400 (24 hours) and you change the IP address, resolvers that cached the old record may continue using it for up to 24 more hours. Reduce the TTL to 300 seconds at least 24-48 hours before making a planned DNS change to minimize the propagation window.

DNS-over-HTTPS and DNS-over-TLS: encrypted resolver queries

Traditional DNS queries are sent in plaintext over UDP or TCP on port 53. This means any observer on the network path — your ISP, a corporate network firewall, or a malicious party on a shared WiFi network — can see every hostname you resolve. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) address this by encrypting DNS queries, preventing network observers from seeing which domains you are looking up.

DNS-over-HTTPS (RFC 8484) tunnels DNS queries inside HTTPS requests. The DNS query is formatted as a binary DNS wire format payload and sent as an HTTP POST (or GET with Base64url-encoded query) to an HTTPS endpoint. From the perspective of network monitoring tools, DoH traffic is indistinguishable from regular HTTPS traffic to the resolver's IP address. All major browsers now support DoH, typically using it for their own internal DNS resolution even while the operating system continues to use plain DNS. Firefox routes all its DNS queries through Cloudflare's 1.1.1.1 DoH endpoint by default in some regions (configurable in Network Settings). Chrome uses the user's configured resolver in DoH mode if the resolver supports it.

DNS-over-TLS (RFC 7858) wraps DNS queries in a TLS session on a dedicated port (853 by default), rather than tunneling through HTTPS. DoT is more transparent than DoH to network administrators — a firewall can block or monitor port 853 as a distinct protocol. From a security perspective, both DoH and DoT provide equivalent privacy against passive eavesdropping. DoH provides stronger resistance against active blocking because blocking HTTPS traffic is more disruptive than blocking port 853.

For developers, the practical implications are: if your application does DNS lookups and you want to ensure they are encrypted, use a DNS library that supports DoH or DoT. In Node.js, the native dns module uses the operating system's resolver (which may or may not be encrypted depending on configuration). For encrypted lookups in Node.js, use a library like dns-over-http-resolver or make direct HTTPS requests to a DoH endpoint. Python has the dnspython library which supports DoT. curl supports DoH natively since version 7.62: curl --doh-url https://1.1.1.1/dns-query https://example.com.

Testing DoH from the command line can be done with curl: curl -s -H 'accept: application/dns-json' 'https://dns.google/resolve?name=example.com&type=A' | python3 -m json.tool. This queries Google's DoH endpoint and returns the DNS answer as JSON, which is easier to parse programmatically than the standard DNS wire format. Cloudflare's DoH endpoint is https://1.1.1.1/dns-query and supports both the JSON format and the DNS wire format.

Reverse DNS lookups and PTR records

A forward DNS lookup resolves a hostname to an IP address. A reverse DNS lookup does the opposite: it resolves an IP address to a hostname. Reverse DNS is stored in PTR (Pointer) records and is used for email server authentication, logging, network diagnostics, and some security systems.

To perform a reverse lookup with dig, use the -x flag: dig -x 93.184.216.34. This automatically constructs the special reverse DNS query format and returns the PTR record if one exists. The special format works by reversing the octets of the IPv4 address and appending .in-addr.arpa: the reverse query for 93.184.216.34 is 34.216.184.93.in-addr.arpa. For IPv6 addresses, each nibble is reversed and the .ip6.arpa suffix is used. dig -x 2001:db8::1 handles this automatically.

PTR records are set by the owner of the IP address block, not the owner of the domain. This creates an important asymmetry: forward DNS (example.com → 93.184.216.34) is controlled by the domain registrar and DNS hosting provider, but reverse DNS (93.184.216.34 → hostname) is controlled by whoever the IP address was allocated to — typically the hosting provider or ISP. If you host a server at a cloud provider and want reverse DNS for your IP address, you must configure it through the cloud provider's control panel, not through your domain's DNS settings.

Email deliverability depends heavily on reverse DNS. Most mail servers perform a reverse lookup on the connecting server's IP address and check that the hostname returned by the PTR record also has a forward A record pointing back to the original IP. This is called a forward-confirmed reverse DNS (FCrDNS) check. If your mail server's IP address has no PTR record, or the PTR record does not match a forward A record, many mail servers will reject your email or classify it as spam. For transactional email, confirm with your hosting provider that the PTR record for your mail server's IP matches the hostname you configured in your SMTP server's EHLO/HELO message.

nslookup also performs reverse lookups: nslookup 93.184.216.34 will return the PTR record. On Windows, this is often more convenient than installing dig. For a quick check without a command-line tool, the ToolDock DNS lookup tool at /tools/dns-lookup supports both forward and reverse lookups with results from multiple resolvers, and displays the PTR record alongside the forward A record for cross-verification.

DNS lookup checklist

  • ✓Use dig @8.8.8.8 hostname TYPE to bypass local resolver cache and query public DNS directly.
  • ✓Always specify the record type in dig (A, AAAA, MX, TXT) — the default A-only query hides other records.
  • ✓Compare results from @1.1.1.1 and @8.8.8.8 to detect resolver-specific caching differences.
  • ✓For propagation issues, check the TTL in dig output — wait for the old TTL to expire before expecting the new value.
  • ✓If NXDOMAIN: verify the exact hostname in your DNS provider's dashboard including the subdomain.
  • ✓If SERVFAIL: run dig +trace to find which nameserver in the resolution chain is failing.
  • ✓For email delivery problems, check MX, SPF (TXT), DKIM (TXT), and DMARC (TXT _dmarc.example.com) records.
  • ✓For mail server IPs, verify reverse DNS: dig -x IP_ADDRESS should return a PTR matching your SMTP hostname.

Frequently asked questions

What is the difference between NXDOMAIN and SERVFAIL?

NXDOMAIN (Non-Existent Domain) is a definitive answer from the authoritative nameserver: the name does not exist in DNS. SERVFAIL (Server Failure) means the resolver could not get an answer — the authoritative server was unreachable, returned an error, or failed DNSSEC validation. NXDOMAIN points to a missing record; SERVFAIL points to a server or delegation configuration problem.

How long does DNS propagation take?

Propagation time is bounded by the old TTL value at the time of the change. If the old A record had a TTL of 86400 (24 hours), some resolvers may cache the old IP for up to 24 more hours. To minimize downtime, lower your TTL to 300 seconds at least 24-48 hours before making a DNS change, then raise it again after confirming the change is live.

What does dig +trace do?

dig +trace follows the full DNS resolution chain from root nameservers down to the authoritative nameserver for your domain. It shows which nameserver is authoritative at each level and what each returned. This is the best way to diagnose delegation problems, SERVFAIL errors, and scenarios where some resolvers return different results than others.

What is a CNAME flattening or ALIAS record?

The DNS specification forbids CNAME records at the zone apex (the root domain itself, like example.com) because CNAME records cannot coexist with other record types including SOA and NS. Many DNS providers offer ALIAS, ANAME, or CNAME flattening as a proprietary extension that behaves like a CNAME at the apex by resolving the target to its A record and serving those IPs directly.

How do I check which nameservers are authoritative for a domain?

Use dig example.com NS to see the NS records published in the domain's zone. Use dig example.com NS @a.root-servers.net to ask a root nameserver what NS records are delegated at the registry level. If the two NS sets differ, the domain's nameserver configuration has changed but the registry has not yet updated its delegation, or vice versa — a common cause of resolution failures during nameserver migrations.

What is DNS-over-HTTPS and why does it matter for developers?

DNS-over-HTTPS (DoH) encrypts DNS queries inside HTTPS requests, preventing network observers from seeing which domains you resolve. Major browsers use DoH by default. For developers, this means: your OS resolver and browser resolver may return different results, corporate firewalls may not be able to intercept browser DNS as they previously did, and applications using the OS resolver will not benefit from browser-level DoH unless they explicitly implement it.

Why does my domain resolve on one machine but not another?

Different machines use different DNS resolvers, which may have different cached values. Check: what resolver does each machine use (cat /etc/resolv.conf on Linux, scutil --dns on macOS), test both with dig @8.8.8.8 to normalize to the same resolver, flush the OS DNS cache on the failing machine (sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder on macOS), and check if a VPN or corporate DNS is intercepting queries.

How do PTR records affect email delivery?

Mail servers verify that your sending IP has a PTR record pointing to your mail server's hostname, and that the hostname has a forward A record pointing back to the same IP. This FCrDNS check (forward-confirmed reverse DNS) is a basic spam filter. If your sending IP has no PTR record or the PTR does not match, major mail providers like Gmail and Outlook will either reject your email or score it as spam.

What is the difference between dig and nslookup?

dig is more precise and scriptable: it shows exact TTL values, the responding server, query timing, and all record sections (question, answer, authority, additional). nslookup is simpler, available on Windows by default, and useful for quick interactive lookups. For troubleshooting, dig is preferred because its output is unambiguous and includes all the information needed to diagnose caching and delegation issues.

Related guides

All tools run in your browser. Your data never leaves your device. Last updated: 2026-05-07.