DNS Lookup Explained: How to Check DNS Records Online

DNS Lookup Explained: How to Check DNS Records Online

DNS is the invisible infrastructure that makes the internet work. Every time you visit a website, send an email, or use an API, DNS resolution happens in the background - usually in milliseconds. But when DNS is misconfigured, things break in ways that are not always obvious. Understanding DNS records and how to inspect them is an essential skill for developers, sysadmins, and anyone who manages a domain.

This guide explains every major DNS record type, how DNS resolution works end to end, how to look up and diagnose DNS records, and what to do when things go wrong.

---

What Is DNS?

DNS (Domain Name System) is a distributed, hierarchical database that maps human-readable domain names to machine-readable IP addresses. When you type example.com into your browser, your computer does not know where to go. DNS tells it: "the server for example.com is at IP address 93.184.216.34."

Without DNS, the internet would require everyone to memorize IP addresses. With it, you get readable names that can point to any server, anywhere, and can be changed without requiring users to know the new address.

DNS is also much more than hostname-to-IP mapping. It carries email routing instructions, security policy records, domain ownership verification tokens, and more - all in the same distributed system.

---

DNS Record Types Explained

A domain can have many different types of DNS records, each serving a distinct purpose.

A Record - IPv4 Address

The A record (Address record) is the most fundamental DNS record. It maps a domain or subdomain to an IPv4 address.

example.com.      IN  A  93.184.216.34
www.example.com.  IN  A  93.184.216.34
api.example.com.  IN  A  10.0.1.5

When a browser needs to load example.com, it performs a DNS lookup for the A record and gets the IP address. The connection is then made to that IP on port 80 or 443.

When to check A records:

• Website is not loading and you suspect a misconfigured IP
• You just pointed a domain to a new server and want to verify the change propagated
• You want to confirm which server is receiving traffic for a domain

AAAA Record - IPv6 Address

The AAAA record maps a domain to an IPv6 address. IPv6 uses 128-bit addresses, which look like this:

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

IPv4 addresses are running out. IPv6 adoption has grown steadily and most hosting providers now assign IPv6 addresses. If your server supports IPv6, add an AAAA record alongside your A record. Clients that support IPv6 (the majority of modern devices) will prefer AAAA records over A records.

When to check AAAA records:

• You need to confirm IPv6 is configured correctly for your domain
• Some users report connectivity issues that only affect IPv6 paths
• You are migrating infrastructure and need to verify both address families are updated

CNAME Record - Canonical Name

A CNAME record creates an alias from one hostname to another. Instead of pointing to an IP address, a CNAME points to another domain name, which is then resolved further.

www.example.com.       IN  CNAME  example.com.
blog.example.com.      IN  CNAME  myblog.ghost.io.
app.example.com.       IN  CNAME  myapp.vercel.app.
cdn.example.com.       IN  CNAME  d1234567.cloudfront.net.

CNAMEs are used extensively when pointing subdomains to external services. The provider (Vercel, Netlify, Cloudflare, etc.) manages the IP addresses behind their hostname. If they change IP addresses, your CNAME continues to work because it points to their name, not their IP.

Critical CNAME limitation: You cannot use a CNAME at the root domain (also called the zone apex). For example, you cannot have a CNAME for example.com itself - only for subdomains like www.example.com. This is because the zone apex must contain SOA and NS records, which are incompatible with CNAME.

Many DNS providers offer proprietary workarounds:

• Cloudflare CNAME Flattening: resolves the CNAME chain and returns the final IP as an A record
• AWS Route 53 ALIAS: works like a CNAME but is allowed at the zone apex
• DNS Made Easy ANAME: similar proprietary solution

When to check CNAME records:

• A subdomain points to an external service and is not resolving correctly
• You want to verify that a custom domain on Vercel, Netlify, or GitHub Pages is configured properly
• A CNAME chain is longer than expected and you want to trace it

MX Record - Mail Exchange

MX records specify which mail servers are responsible for receiving email for a domain. Without correct MX records, no email can be delivered to your domain.

example.com.  IN  MX  10  aspmx.l.google.com.
example.com.  IN  MX  20  alt1.aspmx.l.google.com.
example.com.  IN  MX  30  alt2.aspmx.l.google.com.
example.com.  IN  MX  40  alt3.aspmx.l.google.com.

The number before the hostname is the priority value. Lower numbers have higher priority. When an email is sent to user@example.com, the sending mail server looks up MX records and tries the lowest-priority (numerically smallest) value first. If that server is unavailable, it tries the next one.

When to check MX records:

• Email is not being delivered to your domain
• You just switched email providers and want to confirm the new MX records are active
• You are debugging deliverability issues and need to confirm which mail server is responsible

TXT Record - Text

TXT records store arbitrary text data associated with a domain. Despite the name, they carry structured data in well-defined formats used for authentication, verification, and security policy.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
example.com.  IN  TXT  "google-site-verification=abc123def456"
example.com.  IN  TXT  "ms=ms12345678"
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

#### SPF (Sender Policy Framework)

SPF specifies which mail servers are authorized to send email on behalf of your domain. An SPF record is a TXT record starting with v=spf1.

"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

• include:_spf.google.com - Google's mail servers are authorized
• include:sendgrid.net - SendGrid's servers are authorized
• ~all - all other sources are "soft fail" (treat with suspicion but don't reject)
• -all - all other sources are "hard fail" (reject)

If your SPF record is missing or incorrect, email from your domain will land in spam or be rejected.

#### DKIM (DomainKeys Identified Mail)

DKIM authenticates email using cryptographic signatures. The private key is on your mail server; the public key is in DNS as a TXT record.

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

The selector (google in this case) identifies which DKIM key to use. Your email provider will give you the exact TXT record to add.

#### DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds on SPF and DKIM to tell receiving mail servers what to do when authentication fails, and where to send reports.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

• p=none: monitor mode (take no action on failures)
• p=quarantine: send failing messages to spam
• p=reject: reject failing messages entirely

Start with p=none to observe without breaking email delivery, then move to quarantine and eventually reject once you have confirmed all legitimate sources pass authentication.

#### Domain Verification

Services like Google Search Console, Microsoft 365, and GitHub verify domain ownership via TXT records. You add the provided TXT record, the service queries DNS to confirm it is there, and domain ownership is verified.

example.com.  IN  TXT  "google-site-verification=U8eiCJbk8Bfd1..."
example.com.  IN  TXT  "MS=ms12345678"

When to check TXT records:

• Email is landing in spam and you need to verify SPF/DKIM/DMARC configuration
• Domain verification is failing for a service
• You want to audit all text records to remove stale verification tokens

NS Record - Name Server

NS records specify the authoritative nameservers for a domain. These are the DNS servers that hold the actual records for the domain.

example.com.  IN  NS  ns1.cloudflare.com.
example.com.  IN  NS  ns2.cloudflare.com.

When you register a domain and point it to a DNS provider (Cloudflare, Route 53, Google Cloud DNS, etc.), you update the NS records at your domain registrar to point to that provider. Once propagated, all DNS queries for your domain are answered by those nameservers.

When to check NS records:

• You just transferred a domain and want to confirm the new nameservers are active
• DNS changes are not propagating and you suspect you are editing the wrong DNS provider
• You need to identify which DNS provider currently controls a domain

SOA Record - Start of Authority

The SOA record contains administrative information about the DNS zone. It includes:

• The primary nameserver for the zone
• The email address of the zone administrator (with @ replaced by .)
• A serial number incremented with each change
• Timing parameters: refresh interval, retry interval, expire time, and minimum TTL

example.com.  IN  SOA  ns1.cloudflare.com. dns.cloudflare.com. (
    2024010101  ; Serial
    10800       ; Refresh (3 hours)
    3600        ; Retry (1 hour)
    604800      ; Expire (7 days)
    300         ; Minimum TTL (5 minutes)
)

You rarely edit the SOA record directly - your DNS provider manages it. But examining the serial number helps confirm whether a zone has been updated recently.

SRV Record - Service Location

SRV records specify the location (hostname and port) of specific services. They are used by protocols like SIP (VoIP), XMPP (messaging), and some game servers.

_sip._tcp.example.com.    IN  SRV  10  60  5060  sip.example.com.
_xmpp-client._tcp.example.com.  IN  SRV  5  0  5222  xmpp.example.com.

Format: priority weight port target

CAA Record - Certification Authority Authorization

CAA records specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for a domain. This reduces the risk of misissued certificates.

example.com.  IN  CAA  0  issue  "letsencrypt.org"
example.com.  IN  CAA  0  issue  "digicert.com"
example.com.  IN  CAA  0  issuewild  "letsencrypt.org"
example.com.  IN  CAA  0  iodef  "mailto:security@example.com"

• issue: permits the specified CA to issue certificates
• issuewild: permits the CA to issue wildcard certificates
• iodef: contact address for reporting policy violations

If no CAA record exists, any CA can issue certificates for the domain.

PTR Record - Pointer

PTR records are the reverse of A records. They map IP addresses back to domain names. They are used for reverse DNS lookups, often required by email servers to verify that a sending IP's reverse DNS matches the sending domain.

34.216.184.93.in-addr.arpa.  IN  PTR  example.com.

Set up by your hosting provider, not in your domain's DNS zone. If your email server's IP does not have a PTR record (or the PTR does not match your mail domain), your emails are more likely to be marked as spam.

---

DNS Record Reference Table

---

How DNS Resolution Works End to End

When you visit a website, a complex sequence of queries happens in milliseconds. Understanding it helps you diagnose propagation delays and resolution failures.

Step 1: Browser Cache

The browser first checks its own DNS cache. Modern browsers cache DNS responses for a short time (30 seconds to several minutes). Chrome's DNS cache can be viewed at chrome://net-internals/#dns.

Step 2: Operating System Cache

If the browser does not have a cached answer, it queries the operating system's DNS resolver. The OS maintains its own cache and also checks the hosts file (/etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows).

Step 3: Recursive Resolver

If the OS cache misses, the query goes to a recursive resolver - typically your ISP's DNS server, or a public resolver like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. The recursive resolver does the heavy lifting: it queries other nameservers on your behalf and caches the result.

Step 4: Root Nameservers

If the recursive resolver does not have a cached answer, it queries one of the 13 root nameserver clusters (operated by ICANN, Verisign, and others). The root server does not know the answer - it delegates to the appropriate TLD nameserver.

Step 5: TLD Nameserver

The TLD nameserver for .com, .org, .io, etc. knows which nameservers are authoritative for the specific domain being queried. It returns the NS records for the domain.

Step 6: Authoritative Nameserver

The recursive resolver queries the authoritative nameserver (e.g., Cloudflare, Route 53) returned in step 5. The authoritative nameserver has the actual DNS records and returns the answer.

Step 7: Caching and Response

The recursive resolver caches the result for the duration of the TTL, then returns the answer to your OS, which caches it, which returns it to the browser, which caches it. The website loads.

Total time: typically 20–100ms for a cold lookup, <1ms for a cached lookup.

---

TTL: Time To Live

Every DNS record has a TTL value measured in seconds. It tells resolvers and caches how long to keep the record before querying again.

The TTL migration strategy:

1. 24-48 hours before a DNS change, lower the TTL to 300 seconds
2. Make the DNS change
3. Wait for the old TTL to expire (so all caches refresh with the new value)
4. After confirming the change is working, raise the TTL back to 3600 or 86400

If you do not lower the TTL in advance, your change may take up to 24 hours to propagate because resolvers continue serving cached records until they expire.

---

DNS Propagation

"Propagation" refers to the time it takes for DNS changes to be visible everywhere on the internet. This is often misunderstood.

When you change a DNS record:

• Your authoritative nameserver has the new record immediately
• Recursive resolvers that have cached the old record will not see the change until their cached copy expires (after TTL seconds)
• Resolvers that have not cached the record will get the new value immediately

This means propagation time equals the old record's TTL, not some fixed global delay. A record with a 1-hour TTL will propagate within 1 hour. A record with a 24-hour TTL may not propagate for up to 24 hours.

Some ISPs also violate TTL and cache records longer than specified. This is an edge case but it happens. Using Cloudflare's 1.1.1.1 or Google's 8.8.8.8 as your resolver avoids this problem because they respect TTLs.

---

How to Check DNS Records With ToolBox

The DNS Lookup Tool queries DNS records for any domain in seconds. It uses DNS over HTTPS (DoH), which encrypts your DNS queries so your ISP cannot observe which domains you are looking up.

How to use it:

1. Open the DNS Lookup Tool
2. Type any domain name (e.g., example.com, mail.google.com)
3. Select the record type: A, AAAA, CNAME, MX, TXT, NS, SOA, or All
4. Click Lookup to see the current DNS records

What the results include:

• The record type and value
• The TTL (how long until the record expires from cache)
• The full record in standard DNS zone file format

No software to install. No API keys. No signup required.

---

Debugging Common DNS Problems

Problem: Website Not Loading

Checklist:

1. Look up the A record for your domain - does it point to the correct IP?
2. Check the NS records - are they pointing to your intended DNS provider?
3. Check the TTL - if you recently made changes, wait for the old TTL to expire
4. Look up the domain from multiple geographic locations using online tools to distinguish local caching from a global issue

Problem: Email Not Being Delivered

Checklist:

1. Look up MX records - do they point to your email provider's mail servers?
2. Check SPF TXT record - is your email provider's sending infrastructure included?
3. Check DKIM - the TXT record should exist at [selector]._domainkey.[yourdomain]
4. Check DMARC - the TXT record at _dmarc.[yourdomain] defines your policy
5. If any are missing or incorrect, email will land in spam or be rejected

Common SPF mistakes:

• Too many DNS lookups in the SPF record (limit is 10 include: lookups)
• Missing entries for email sending services (transactional email, marketing platforms)
• Using -all before confirming all sending sources are included (causes legitimate email to be rejected)

Problem: SSL Certificate Errors

Common causes:

• The domain's A or CNAME record points to a server that does not have a valid certificate for that domain
• The domain was recently transferred and the new server has not yet provisioned a certificate
• DNS is still pointing to the old server due to caching

Checklist:

1. Verify the A or CNAME record points to the new server
2. Check if a certificate has been provisioned for the domain on the new server
3. Wait for DNS propagation if the record was recently changed

Use the SSL Certificate Checker to inspect the current certificate without needing any tools.

Problem: DNS Changes Not Taking Effect

Checklist:

1. Confirm you are editing the DNS records at the correct provider (check NS records to find the authoritative provider)
2. Check the current TTL - if it is 86400, you may need to wait up to 24 hours
3. Flush your local DNS cache:

- Windows: ipconfig /flushdns

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

- Linux: sudo systemd-resolve --flush-caches or sudo /etc/init.d/nscd restart

1. Test the lookup using a public resolver like 1.1.1.1 to bypass local caching

Problem: Subdomain Not Resolving

Checklist:

1. Confirm the A or CNAME record exists for the subdomain (not just the root domain)
2. If using a CNAME, check that the target domain resolves correctly
3. Check for a wildcard DNS record (*.example.com) that might be interfering
4. Verify the TTL on the subdomain record

---

Command-Line DNS Lookup Tools

For developers who prefer the terminal:

dig (Linux, macOS)

# Look up an A record
dig example.com A

# Look up all record types
dig example.com ANY

# Look up MX records
dig example.com MX

# Look up TXT records (including SPF, DKIM, DMARC)
dig example.com TXT

# Look up a specific subdomain
dig mail.example.com

# Specify a DNS server to query
dig @1.1.1.1 example.com A

# Short output
dig +short example.com A

# Check a DKIM record
dig +short google._domainkey.example.com TXT

# Check DMARC
dig +short _dmarc.example.com TXT

# Trace the full resolution path
dig +trace example.com

nslookup (Cross-platform)

# Basic lookup
nslookup example.com

# Look up specific record type
nslookup -type=MX example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Reverse lookup
nslookup 93.184.216.34

host (Linux, macOS)

# Simple lookup
host example.com

# Specific record type
host -t MX example.com

# Verbose output
host -a example.com

---

DNS Security

DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that the responses they receive have not been tampered with. Without DNSSEC, DNS responses can be forged (DNS cache poisoning).

A domain with DNSSEC configured will have additional DS and DNSKEY records visible in lookups. Many TLDs and registrars now support DNSSEC - enabling it is recommended for security-sensitive domains.

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

Traditional DNS queries are unencrypted and visible to anyone on the network path - including your ISP and anyone intercepting traffic. DNS over HTTPS (DoH) wraps DNS queries in encrypted HTTPS connections, providing privacy.

The DNS Lookup Tool uses DoH by default, which means:

• Your lookup queries are encrypted
• Your ISP cannot see which domains you are querying
• Results are authenticated by the DoH provider

Subdomain Takeover

If a CNAME points to a service (like an old Heroku or GitHub Pages deployment) that has been deleted, an attacker can register the same service and take over the subdomain. Periodically audit your CNAME records and remove any that point to deprovisioned services.

---

Related Tools

• DNS Lookup - Query DNS records for any domain
• SSL Certificate Checker - Inspect the SSL certificate for any domain
• HTTP Headers Checker - View the HTTP response headers for any URL
• Website Speed Test - Test page load performance
• IP Address Lookup - Look up geolocation and ISP information for any IP address
• SEO Analyzer - Analyze SEO and meta tag configuration for any page
• Webhook Tester - Test webhook endpoints

---

Try It Now

Look up DNS records for any domain instantly in your browser:

DNS Lookup Tool - Free, private, no signup required. Queries are made via DNS over HTTPS for privacy.