DNS Lookup Tool

Enter a domain and run a lookup.

JSON will appear here after lookup.

A DNS lookup queries the Domain Name System to retrieve the DNS records published for a domain — showing where it points, how email is routed, and which services are configured. To perform a DNS lookup online: enter a domain name above, select the record type (or query all), and click Lookup. Supported record types: A (IPv4 address), AAAA (IPv6), MX (mail servers), TXT (SPF, DKIM, DMARC verification), CNAME (aliases), NS (nameservers), SOA (zone authority), PTR (reverse DNS), SRV (service records), and CAA (certificate authority). Queries go from your browser directly to DNS-over-HTTPS (DoH) providers — no data passes through bitlist servers.

Use cases

• Verify A/AAAA records after a new deploy or DNS change.
• Confirm MX and TXT records for email authentication (SPF, DKIM, DMARC).
• Check CNAME or SRV records when a service is not resolving as expected.
• Compare answers across resolvers during DNS propagation windows.

How it works

The tool queries DNS-over-HTTPS (DoH) providers directly from your browser. Results are shown in a human-readable format and as raw JSON for automation or audits.

DNS record types at a glance

• A maps a hostname to an IPv4 address.
• AAAA maps a hostname to an IPv6 address.
• CNAME aliases one hostname to another.
• MX defines mail servers for a domain.
• TXT stores verification and policy strings (SPF, DKIM, DMARC).
• NS lists authoritative name servers.
• SOA shows the zone serial and timing parameters.
• SRV defines service endpoints with priority and port.
• CAA controls certificate authority permissions.

What this DNS lookup provides

• Filter by record type (A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA).
• Copy-ready output plus JSON export for audits and automation.
• Propagation checks across multiple public resolvers.

API Endpoint

The API URL shown uses DNS-over-HTTPS (DoH) providers. You can copy it directly into scripts or monitoring tools.

Propagation Notes

Propagation results can vary by resolver due to caching and TTL. If answers differ, wait for TTL to expire and re-check.

Privacy

Queries run directly from your browser to the selected resolver. Results are not stored by this site.

Tips

• Use AAAA to verify IPv6 readiness.
• Check MX and TXT for email configuration issues.
• Use PTR with reverse lookup names (e.g., 1.0.0.127.in-addr.arpa).

Understanding DNS Record Types in Detail

A Record (IPv4 Address)

A records map domain names to IPv4 addresses (32-bit format like 192.0.2.1). This is the most fundamental DNS record type—when you visit a website, your browser queries the A record to find the server's IP address. Multiple A records enable load balancing and redundancy.

Example: example.com → 93.184.216.34. TTL: Typically 300-3600 seconds (5 minutes to 1 hour). Lower TTL enables faster updates but increases DNS query load.

AAAA Record (IPv6 Address)

AAAA records (quad-A) map domain names to IPv6 addresses (128-bit format like 2606:2800:220:1:248:1893:25c8:1946). Essential for modern IPv6-enabled networks. Browsers try AAAA first if IPv6 is available, falling back to A records.

Use case: Verify your site supports IPv6 connectivity. Many mobile carriers and modern ISPs prefer IPv6. Dual-stack configurations have both A and AAAA records.

CNAME Record (Canonical Name)

CNAME records create aliases pointing one domain to another. The aliased domain (target) resolves to its A/AAAA records. CNAMEs cannot coexist with other record types at the same name (RFC restriction).

Example: www.example.com CNAME → example.com. Useful for CDN configurations (www points to cdn.provider.com) or subdomain management. Limitation: Cannot use CNAME at apex/root domain (example.com) per RFC 1034—use A/AAAA or ALIAS records instead.

MX Record (Mail Exchange)

MX records define mail servers for a domain, with priority values (lower number = higher priority). Email servers query MX records to route messages to the correct mail server.

Example: example.com MX 10 mail.example.com, MX 20 backup-mail.example.com. If priority-10 server fails, senders try priority-20. Multiple MX records provide email redundancy. Common priorities: 0 (highest), 10 (primary), 20-50 (backups).

TXT Record (Text)

TXT records store arbitrary text data, commonly used for email authentication (SPF, DKIM, DMARC), domain verification (Google Search Console, SSL certificates), and security policies.

SPF example: v=spf1 include:_spf.google.com ~all authorizes Google servers to send email for your domain. DKIM: Public keys for email signature verification. DMARC: v=DMARC1; p=quarantine; rua=mailto:reports@example.com sets email authentication policy.

NS Record (Name Server)

NS records delegate a domain or subdomain to specific authoritative name servers. These servers are responsible for providing DNS records for the zone.

Example: example.com NS → ns1.nameserver.com, ns2.nameserver.com. Typically set at your domain registrar and must match your hosting provider's name servers. Misconfigured NS records prevent DNS resolution entirely.

SOA Record (Start of Authority)

SOA records define authoritative information about a DNS zone: primary name server, admin email, serial number (version), refresh/retry/expire timers, and minimum TTL.

Serial number: Increments with each zone update (format: YYYYMMDDNN). Secondary name servers check serial to detect updates. Refresh: How often secondaries check for updates (3600s typical). Retry: Wait time if refresh fails (600s). Expire: Max time secondary serves stale data (604800s/7 days).

SRV Record (Service)

SRV records specify hostname and port for specific services, commonly used for SIP, XMPP, LDAP, Minecraft servers, and Microsoft Active Directory.

Format: _service._protocol.domain SRV priority weight port target. Example: _minecraft._tcp.example.com SRV 0 5 25565 mc.example.com. Priority: Lower = preferred (like MX). Weight: Load balancing between same-priority servers.

CAA Record (Certification Authority Authorization)

CAA records specify which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for your domain, preventing unauthorized certificate issuance.

Example: example.com CAA 0 issue "letsencrypt.org". Flags: 0 (non-critical) or 128 (critical—CA must understand the record). Tags: issue (all certs), issuewild (wildcards only), iodef (violation reports). Security best practice for preventing mis-issued certificates.

PTR Record (Pointer / Reverse DNS)

PTR records provide reverse DNS lookups—mapping IP addresses back to hostnames. Essential for email servers (many mail servers reject email from IPs without PTR records).

Format: IP in reverse + in-addr.arpa (IPv4) or ip6.arpa (IPv6). Example: 34.216.184.93 → 93.184.216.34.in-addr.arpa PTR example.com. Set by your hosting provider or ISP, not your DNS provider.

Common DNS Troubleshooting Scenarios

Scenario 1: Website Not Loading After DNS Change

Symptoms: Website unreachable, DNS errors in browser after updating A/AAAA records.

Diagnosis: Run lookup for A/AAAA records across multiple resolvers. If old IP appears, issue is propagation (cached records). If NXDOMAIN (name doesn't exist), NS records may be misconfigured.

Solution: Wait for TTL expiration (check old record's TTL value). Use propagation check to monitor global resolver updates. Flush local DNS cache: Windows ipconfig /flushdns, macOS sudo dscacheutil -flushcache, Linux sudo systemd-resolve --flush-caches.

Scenario 2: Email Delivery Failures

Symptoms: Emails bouncing, SPF failures, or messages marked as spam.

Diagnosis: Check MX records (must exist and point to valid mail servers). Verify TXT records for SPF (v=spf1...), DKIM (selector._domainkey.domain), and DMARC (_dmarc.domain). Check PTR records for your mail server's IP.

Common issues: Missing SPF record (default deny), SPF with -all (hard fail) instead of ~all (soft fail), MX pointing to CNAME instead of A/AAAA (violates RFC 2181), missing PTR record for outbound mail server.

Scenario 3: CDN or Load Balancer Configuration

Setup: Verifying www subdomain points to CDN (Cloudflare, Fastly, Akamai) while root domain works.

Check: CNAME record for www → cdn-provider.com. If CDN doesn't work, verify CNAME target resolves (lookup cdn-provider.com A records). For apex/root domain, CDN providers typically give A/AAAA records or ALIAS records (Cloudflare's CNAME flattening).

Tip: Some DNS providers don't support ALIAS records. Use A/AAAA records at root, CNAME for www. CDN IPs may change—use CNAME when possible for automatic updates.

Scenario 4: Subdomain Not Resolving

Symptoms: Main domain works (example.com) but subdomain fails (api.example.com).

Diagnosis: Check if subdomain has A/AAAA/CNAME record. Lookup api.example.com specifically. If NS records delegate subdomain to different name servers, query those NS servers directly.

Common mistake: Wildcard record (*) exists but specific subdomain needs explicit record. Wildcards don't override specific names. Verify subdomain isn't accidentally delegated to non-existent NS servers.

Scenario 5: SSL Certificate Validation Errors

Setup: Let's Encrypt or other CA can't verify domain ownership for certificate issuance.

Diagnosis: Check TXT records for _acme-challenge.example.com (DNS-01 challenge). Verify CAA records don't block the CA. Ensure A/AAAA records resolve if using HTTP-01 challenge.

Solution: CAA record must include your CA: 0 issue "letsencrypt.org". Remove old _acme-challenge TXT records after verification completes. Propagation delays can cause validation failures—wait for full DNS propagation before retrying.

DNS Over HTTPS (DoH) and Privacy

This tool uses DNS-over-HTTPS (DoH), which encrypts DNS queries over HTTPS (port 443) instead of plain UDP/TCP (port 53). Benefits: prevents ISP snooping, protects against DNS hijacking, bypasses DNS-based censorship, improves privacy.

Resolvers supported: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), OpenDNS, and others. Each has different logging policies—Cloudflare doesn't log queries beyond 24 hours, Google logs for troubleshooting. Choose resolver based on privacy requirements.

Limitations: DoH queries still reveal target domain to resolver (not ISP). For complete privacy, use DoH + VPN. Some corporate networks block DoH to enforce content filtering.

DNS Propagation and TTL

TTL (Time To Live) specifies how long DNS records are cached (in seconds). Lower TTL = faster updates but more DNS queries. Higher TTL = better performance but slower changes.

Typical TTL values: 300s (5 min) for frequent changes, 3600s (1 hour) for stable services, 86400s (24 hours) for rarely-changed records. Before DNS migration, lower TTL to 300s 24-48 hours in advance for quick rollback.

Propagation timing: Changes take effect immediately at authoritative servers, but recursive resolvers cache old values until TTL expires. Global propagation takes hours (not "24-48 hours" myth)—typically TTL duration + query time. Use propagation check to verify updates across multiple global resolvers.

Best Practices for DNS Configuration

• Use multiple NS records: Minimum 2, ideally 3-4 name servers for redundancy. Spread across different networks/geographic locations.
• Set appropriate TTL: 3600s (1 hour) for production, 300s (5 min) before migrations. Too low = unnecessary DNS load, too high = slow updates.
• Implement email authentication: SPF, DKIM, DMARC TXT records prevent email spoofing and improve deliverability.
• Add CAA records: Restrict which CAs can issue certificates for your domain, preventing unauthorized SSL issuance.
• Verify DNS changes: Test with multiple resolvers (Google, Cloudflare, Quad9) before considering migration complete.
• Monitor DNS health: Set up monitoring for DNS resolution failures, TTL issues, NS server availability.
• Avoid CNAME at apex: Root domain (example.com) must use A/AAAA records, not CNAME, per RFC 1034.
• Document DNS records: Keep spreadsheet or version-controlled config of all DNS records for disaster recovery.
• Enable DNSSEC: If your registrar supports it, sign your zone to prevent DNS spoofing and cache poisoning attacks.

Frequently Asked Questions

What is DNS propagation?

Propagation is the time it takes for DNS changes to reach and update caches across different recursive resolvers worldwide. When you update a DNS record (change IP address, modify MX), authoritative name servers update immediately, but millions of recursive resolvers (Google, Cloudflare, ISPs) still have cached copies of old records. These caches expire based on TTL (Time To Live) values—only after TTL expires do resolvers query for fresh data. Global propagation typically completes within hours (not the mythical "24-48 hours"), specifically within the old record's TTL duration plus time for resolvers to re-query.

Why do resolvers return different answers?

Propagation depends on TTL and each resolver's cache behavior. Different resolvers may have queried at different times, cached records with different remaining TTLs, or have different refresh policies. For example, if you changed an A record from 192.0.2.1 to 192.0.2.2 with 3600s TTL, Google DNS might still show old IP (cached 30 minutes ago, 3330s TTL remaining) while Cloudflare shows new IP (cache expired, queried fresh). This is normal—wait for TTL to fully expire across all resolvers. Additionally, some resolvers ignore TTL and cache longer, or use different authoritative servers that haven't synchronized yet.

Can I export results as JSON?

Yes. Use the "Copy JSON" button to copy raw JSON response to clipboard, or "Download JSON" to save as a .json file. JSON output includes all record data (name, type, TTL, answers) in structured format suitable for automation, audits, monitoring scripts, or integration with other tools. The JSON follows standard DNS-over-HTTPS response format compatible with most DNS analysis tools and scripts. Ideal for tracking DNS changes over time, documenting configurations, or feeding into monitoring systems.

Is this the same as a dig command?

It provides similar record data using DNS-over-HTTPS (DoH) from public resolvers, versus dig's traditional DNS (UDP/TCP port 53). Key differences: (1) DoH is encrypted (HTTPS), dig is plain text. (2) This tool queries public resolvers (Google, Cloudflare), dig queries your system's configured resolver. (3) Output format differs—this shows simplified human-readable format + JSON, dig shows BIND-style output. (4) dig supports more advanced queries (+trace, +short, +dnssec) not available here. For basic record lookups (A, AAAA, MX, TXT), results are equivalent. For advanced diagnostics, use dig or nslookup.

How do I reduce DNS propagation time?

Before making changes: Lower TTL to 300 seconds (5 minutes) 24-48 hours in advance. This ensures all resolvers cache records for only 5 minutes maximum. Make the change: Update DNS records at your DNS provider. After the change: Old records expire after old TTL (if you didn't lower it pre-change, propagation takes original TTL duration). Restore TTL: After full propagation, raise TTL back to 3600s (1 hour) to reduce DNS query load. You cannot force resolvers to clear cache—they respect TTL values. Some resolvers ignore low TTLs and enforce minimums (60s typical).

What should I do if my DNS isn't propagating?

1. Verify at authoritative servers: Query your domain's NS servers directly using a direct lookup tool or dig: dig @ns1.yourdns.com example.com. If correct there, issue is propagation (wait for TTL). If wrong there, changes didn't save at DNS provider. 2. Check NS records: Ensure NS records at registrar match your DNS provider's name servers. Mismatch prevents all DNS resolution. 3. Clear caches: Flush local DNS cache (ipconfig /flushdns on Windows, dscacheutil -flushcache on macOS). 4. Wait for TTL: Check old record's TTL value—propagation takes that long minimum. 5. Test multiple resolvers: Use propagation check to verify across Google, Cloudflare, Quad9, OpenDNS.

Can I use this for private/internal domains?

No. This tool queries public DNS resolvers (Google, Cloudflare, Quad9) which only resolve public, internet-facing domains. Internal domains (.local, 192.168.x.x, 10.x.x.x private IPs, corporate intranet domains) won't resolve because they're not published to public DNS. For internal DNS, use your organization's DNS server directly with tools like nslookup, dig, or host. Example: nslookup intranet.company.local 10.0.0.1 (query internal DNS server at 10.0.0.1).

What's the difference between recursive and authoritative name servers?

Authoritative name servers store the actual DNS records for a domain—they're the "source of truth" (e.g., ns1.example-dns-provider.com). When you update DNS, you change records at authoritative servers. Recursive resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's DNS) query authoritative servers on behalf of clients, cache results, and serve cached answers to reduce load. This tool queries recursive resolvers (DoH providers), not authoritative servers directly. Authoritative servers always have current records; recursive servers may have stale cached data until TTL expires.

Why does my domain show "NXDOMAIN"?

NXDOMAIN (Non-Existent Domain) means the domain name doesn't exist in DNS—no records found at authoritative servers. Common causes: (1) Typo in domain name—verify spelling. (2) Domain not registered—check WHOIS to confirm ownership. (3) NS records misconfigured at registrar—verify name servers match your DNS provider. (4) Recent registration—newly registered domains take hours to propagate globally (24-48 hours for new domains, not changes). (5) Expired domain—if domain registration lapsed, DNS stops working immediately. Use WHOIS lookup to check domain status and expiration date.

Can I check DNS from a specific geographic location?

This tool queries public DoH resolvers (Google, Cloudflare, Quad9) which have global anycast infrastructure—your query routes to nearest data center automatically, not specific geo-location. The propagation check queries multiple resolvers simultaneously, showing different resolver results but not specific geographic servers. For true geo-specific testing, use external services like "DNS Checker" tools that query from servers in specific countries, or use VPN + this tool to query from different regions. Most propagation issues aren't geo-specific—they're resolver-specific based on cache timing.

What does TTL mean and how do I set it?

TTL (Time To Live) is the duration (in seconds) that DNS records are cached by resolvers before they must query again for fresh data. Set at your DNS provider: Edit your DNS record (A, AAAA, MX, etc.) and specify TTL value—common options: 300s (5 min), 1800s (30 min), 3600s (1 hour), 86400s (24 hours). Trade-offs: Low TTL (300s) = changes propagate in minutes but increases DNS query load and costs. High TTL (86400s) = fewer queries and better performance but DNS changes take a day to propagate globally. Best practice: Use 3600s (1 hour) for production, temporarily lower to 300s before planned DNS migrations.