DNS Lookup Tool

What is DNS and how does a lookup work?

The Domain Name System (DNS) is the internet's phonebook — it translates human-friendly names like freedevtool.org into machine-friendly IP addresses like 104.21.x.x. Every web request, every email, every API call begins with at least one DNS lookup. The DNS protocol is defined in RFC 1035 (1987) with dozens of subsequent updates that added security, IPv6, and modern transport protocols.

A typical DNS lookup involves four parties:

• Stub resolver — your OS's DNS client. Asks the recursive resolver and caches answers.
• Recursive resolver — your ISP's resolver, or a public one (1.1.1.1, 8.8.8.8). Walks the DNS hierarchy to find authoritative answers, then caches.
• Root and TLD servers — the global hierarchy. Root servers (.) point to TLD servers (.com, .org). TLD servers point to authoritative servers for individual domains.
• Authoritative server — owned by the domain's DNS provider (Cloudflare, Route53, Namecheap). Has the actual records.

This tool uses DNS-over-HTTPS (DoH) to bypass your local resolver and query Cloudflare's 1.1.1.1 directly. That means you see what Cloudflare's cache contains right now, ignoring stale entries on your laptop, router, or ISP. Useful when debugging "DNS hasn't propagated" — the answer is often that your local cache is stale, not the global DNS.

The 8 most important DNS record types

Email DNS — SPF, DKIM, DMARC explained

Setting up reliable email delivery in 2026 requires three TXT-record-based standards working together. Skip any one and your domain ends up in spam folders.

SPF (Sender Policy Framework)

Tells receiving mail servers which IPs are allowed to send mail "from" your domain. A TXT record on the domain root:

example.com.    TXT    "v=spf1 include:_spf.google.com include:mailgun.org -all"
                                ↓                       ↓                  ↓
                          Google Workspace        Mailgun           hard-fail
                          allowed               allowed           anything else

DKIM (DomainKeys Identified Mail)

Cryptographically signs outgoing email so receivers can verify it wasn't tampered with. The public key lives in DNS:

google._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGS..."
       ↑                                      ↑       ↑       ↑
   "selector"                              version  algorithm  public key

The selector is provider-specific (e.g. google for Google Workspace, k1 for Mailgun, s1 for SendGrid). Outgoing mail headers reference which selector to look up.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Tells receivers what to do when SPF or DKIM fails. Required by Google, Yahoo, and Apple as of 2024 for bulk senders.

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
                                       ↓                     ↓
                                   policy             where to send aggregate reports
                                 (none/quarantine/reject)

# Start with p=none, monitor reports for 2 weeks, escalate to quarantine, then reject.

How to use this tool to verify email setup:

• TXT lookup on root domain → check SPF
• TXT lookup on _dmarc.example.com → check DMARC
• TXT lookup on SELECTOR._domainkey.example.com → check DKIM (selector varies)
• MX lookup → confirm mail routing is correct

DNS query in 8 environments

dig (the gold standard)

# Basic lookup (default = A record)
dig example.com

# Specific record type
dig example.com MX
dig example.com TXT

# Short output (just the answers)
dig +short example.com

# Use a specific resolver
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# Full DNS trace (root → TLD → authoritative)
dig +trace example.com

# DNSSEC validation
dig +dnssec example.com

# Reverse lookup (PTR)
dig -x 8.8.8.8

nslookup (Windows-friendly)

# Basic lookup
nslookup example.com

# Specific record type
nslookup -type=MX example.com
nslookup -type=TXT example.com

# Specific server
nslookup example.com 1.1.1.1

host

host example.com               # all common record types
host -t MX example.com
host -t TXT example.com
host -a example.com            # ANY (often blocked by modern resolvers)

JavaScript (DoH from the browser)

// Cloudflare DoH JSON API
async function dnsLookup(name, type = 'A') {
  const r = await fetch(
    `https://cloudflare-dns.com/dns-query?name=${encodeURIComponent(name)}&type=${type}`,
    { headers: { Accept: 'application/dns-json' } }
  );
  const data = await r.json();
  return data.Answer || [];
}

const records = await dnsLookup('example.com', 'MX');
records.forEach(r => console.log(r.data));

Node.js (built-in)

import { promises as dns } from 'node:dns';

await dns.resolve4('example.com');         // ['93.184.216.34']
await dns.resolveMx('example.com');         // [{ priority: 10, exchange: 'mail.example.com' }]
await dns.resolveTxt('example.com');        // [['v=spf1 ~all']]
await dns.reverse('8.8.8.8');               // ['dns.google']

Python (dnspython)

import dns.resolver

resolver = dns.resolver.Resolver()
resolver.nameservers = ['1.1.1.1']  # use Cloudflare

# Query records
for rdata in resolver.resolve('example.com', 'MX'):
    print(rdata.preference, rdata.exchange)

# DoH (Python 3.7+)
import dns.message, dns.query
q = dns.message.make_query('example.com', 'A')
r = dns.query.https(q, 'https://cloudflare-dns.com/dns-query')

Go

import "net"

ips, _ := net.LookupIP("example.com")
mx, _ := net.LookupMX("example.com")
txt, _ := net.LookupTXT("example.com")
ns, _ := net.LookupNS("example.com")

// For DoH or custom resolvers, use github.com/miekg/dns

curl (simplest DoH command line)

# JSON-format DoH (Cloudflare)
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=MX' | jq

Common DNS issues — and how to debug them

1. "DNS hasn't propagated yet"

The most common DNS complaint, and almost always caused by caching at one of three layers: your OS, your router, or your ISP's resolver. Fix: use this tool (queries Cloudflare directly, bypassing all your caches), or run dig @1.1.1.1 example.com. If Cloudflare shows the new value, propagation is done — your local cache is the culprit. Flush DNS:

• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): sudo resolvectl flush-caches
• Windows: ipconfig /flushdns
• Browser: clear browser DNS cache (Chrome: chrome://net-internals/#dns)

2. CNAME at the apex (root domain)

RFC requires that the root of a domain (apex / "naked" domain) cannot have a CNAME record alongside MX, NS, or other records. So example.com → CNAME proxy.cloud.com isn't legal. Cloudflare and Route53 work around this with "ALIAS" or "ANAME" records that resolve at query-time. Fix: use ALIAS/ANAME records, or just use an A record pointing to the resolved IP.

3. SPF lookup limit (10 DNS lookups)

SPF records have a strict 10-lookup limit per evaluation (RFC 7208). Each include:, a:, mx:, exists: counts. Adding too many third-party senders → SPF "permerror" → mail rejected. Fix: consolidate, use SPF flattening services (sparingly — they break when underlying records change), or remove unused senders.

4. Wrong PTR record on outbound mail

Major email providers (Gmail, Outlook, Yahoo) reject mail from servers without proper reverse DNS. The PTR record for your sending IP must match the HELO/EHLO hostname. Fix: request reverse DNS from your hosting provider (AWS: through Route53 or support ticket; DigitalOcean: control panel).

5. TTL set too high during migration

If you plan to move DNS providers and your TTL is 24 hours, plan to wait 24 hours after the change for everyone to see the new values. Fix: lower TTL to 300 seconds (5 minutes) at least 48 hours before the migration. After migration completes, raise TTLs back to 3600 or higher for stability and performance.

6. CAA records blocking certificate issuance

If your CAA records list letsencrypt.org only, but you try to issue a cert via DigiCert, the CA must refuse. Fix: review CAA records before switching CA providers; add the new CA's identifier first.

MX record lookup and DKIM selector check — a 60-second deliverability audit

Once a sender complaint lands ("Gmail keeps rejecting our mail"), run this five-step lookup right here:

1. Query MX for the sending domain — confirm the records point to your actual mail provider, not a stale Postini or G Suite legacy entry.
2. Query TXT at the apex — find the v=spf1 record. Count include: hops (limit is 10, hard fail past 10).
3. Query TXT at selector._domainkey.example.com using the selector your provider configured (Mailchimp uses k1, SendGrid uses s1/s2, Google uses google).
4. Query TXT at _dmarc.example.com — verify there's a single record with a valid policy.
5. If all four pass and Gmail still rejects, the problem is reputation or content — not DNS.

For testing the underlying transport (TLS handshake, IP geolocation, reverse DNS), the IP lookup tool and the HTTP status checker cover the next layer down.

DNS best practices for 2026 production domains

• Use multiple authoritative DNS providers. A single provider is a single point of failure (Dyn 2016, Route53 2019 outages). Set up secondary DNS at a second provider for redundancy.
• Enable DNSSEC. Cryptographically signs your DNS responses, preventing cache-poisoning attacks. Most providers enable it with one click.
• Set CAA records. Limit which certificate authorities can issue TLS certs for your domain. Prevents rogue cert issuance.
• Lower TTLs before migrations. Drop to 300 seconds 48 hours before any planned change. Raise back after stability.
• Monitor your records. Use uptime monitors that check DNS resolution, not just HTTP. UptimeRobot, Pingdom, BetterUptime all support this.
• Set up SPF, DKIM, DMARC. All three. Required by Google & Yahoo for bulk senders since 2024. Even small senders see deliverability boost.
• Document your DNS records. A wiki page or Notion doc with each record's purpose, owner, and last-changed date saves you when things break in 3 years.
• Use IPv6 (AAAA records) alongside IPv4. Major mobile networks now run IPv6-only. Without AAAA, you're slower or unreachable for those users.
• Don't use CNAME at the apex. Use ALIAS/ANAME if your provider supports it, or A records.
• Reverse DNS for mail servers. PTR records matching your HELO hostname are mandatory for production email.