Free Tool

Free DNS & CNAME Lookup Tool

Look up A, AAAA, CNAME, MX, TXT, NS, and SOA records across Cloudflare, Google, and Quad9 resolvers. Verify DNS propagation in seconds. Free, instant, no signup or API key required.

No signup required

Free forever

GDPR compliant

Quick Answer

A DNS checker queries multiple public resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) in parallel and shows whether each one returns the same answer. Used to verify DNS propagation after registrar or zone changes, debug intermittent CDN routing, and confirm SPF / DKIM / DMARC records are visible globally. The U2L DNS Checker exposes seven record types with no API key needed.

Quick Facts

Queries Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9 9.9.9.9 in parallel via DNS-over-HTTPS (DoH).
Supported record types: A (IPv4), AAAA (IPv6), CNAME, MX, TXT, NS, SOA. Same set covers most debugging needs.
Use the propagation diff view to spot inconsistent answers across resolvers - usually means a recent change that hasn't fully propagated.
TTL (time-to-live) is shown per record. Lower TTLs propagate faster; higher TTLs reduce DNS query load but slow propagation.
DoH means queries go over HTTPS, not raw UDP port 53. Works behind firewalls that block traditional DNS.
Cached at the U2L edge for 60 seconds to avoid hammering public resolvers; long-term changes appear within a minute.
Free, no API key. For bulk lookups (10+ domains at once), the U2L public API is on the roadmap.

How to check DNS records

Three steps. Domain, record type, results.

1
Enter the domain
Type the domain (or subdomain like blog.example.com) into the search box. Don't include protocol or path - the tool strips https:// and trailing /paths automatically.
2
Pick the record type
A for IPv4, AAAA for IPv6, CNAME for redirects, MX for mail, TXT for SPF/DKIM/DMARC/verification, NS for nameservers, SOA for zone metadata.
3
Compare results across resolvers
Three resolvers (Cloudflare, Google, Quad9) query in parallel. Matching answers across all three = fully propagated. Differences signal mid-propagation or asymmetric DNS.

What is a DNS / CNAME Checker?

DNS / CNAME Checker is a tool that queries multiple public DNS resolvers in parallel and shows their answers side by side. Instead of running 'dig' three times against three different resolvers, you get all answers in one view. The U2L checker uses DNS-over-HTTPS (DoH) so it works behind firewalls that block port-53 DNS queries.

DNS works through a hierarchy of resolvers caching answers at different layers. When you change a DNS record at your registrar, the change has to propagate from your authoritative server -> regional caches -> public resolvers -> end-user resolvers. Different resolvers update at different rates, so during propagation, some users see the new answer while others see the old one.

Multi-resolver checking catches this. If Cloudflare 1.1.1.1 returns the new IP but Google 8.8.8.8 still returns the old one, you know your change is half-propagated. If all three resolvers return the same answer, propagation is complete (modulo the user's own ISP cache, which the tool can't see). For DKIM, SPF, and DMARC TXT records, multi-resolver verification is critical because a missing TXT record on one resolver means email from that ISP's users may bounce.

DNS-over-HTTPS is critical for the tool's reach. Traditional DNS uses UDP port 53; that's blocked on many corporate networks, public Wi-Fi, and inside Cloudflare Workers themselves. DoH wraps DNS queries in HTTPS, so they look like normal web traffic and pass through firewalls. All three resolvers used here support DoH natively.

How does a DNS / CNAME Checker work?

When you submit a domain and record type, the U2L API normalizes the input (strips https://, www., trailing path), validates the domain format, then fires three parallel DoH requests to Cloudflare, Google, and Quad9. Each request has its own 4-second timeout. Results merge into one response.

Each resolver returns an Answer array containing record values, the resolver-side TTL, and a Status code (0 = success, 3 = NXDOMAIN, etc.). The U2L API normalizes these into a flat list per resolver and sends them back to the browser, which renders them in a side-by-side comparison view.

The TTL shown is the resolver-side TTL - how long that resolver will cache the answer before re-querying the authoritative server. The TTL you set at the registrar (the authoritative TTL) determines the maximum cache time; resolver TTLs may be lower if the answer was cached recently.

Results are cached at the Cloudflare edge for 60 seconds. Repeat queries for the same domain+type return instantly. If you're actively debugging DNS during a cutover, the 60s cache is short enough to follow the rollout in near-real-time. For longer-running monitoring, sign up for U2L Pro to schedule periodic checks with alerting.

Use Cases

How marketers, businesses, and developers use dns / cname checker.

Verify DNS migration completion

After updating nameservers at the registrar, run the checker every few minutes. Once all 3 resolvers return the new NS values, propagation is complete (usually 24-48 hours).

Debug intermittent email delivery

Some users' emails bouncing? Check MX, SPF (TXT), DKIM (TXT _domainkey.X), and DMARC (TXT _dmarc.X) across all 3 resolvers. Mismatched answers = ISP-specific outage.

Confirm SaaS verification records

Adding Google Workspace, M365, Mailchimp, or any SaaS that requires a TXT verification record. Check the TXT type and confirm all 3 resolvers return the verification string.

Verify CDN / load balancer routing

Changed your A or CNAME to point to a new CDN? Confirm all 3 resolvers see the new target. Different answers may mean a regional anycast slot lagging.

Test apex / subdomain delegation

Setting up subdomain delegation (NS records on a subdomain pointing to a different nameserver). Use the NS check on the subdomain to verify delegation is live.

Pre-launch DNS sanity check

Before a product launch, run the checker against the production domain for A, MX, and TXT. Catch broken records 24 hours before traffic hits.

Diagnose 'works for me but not them' bugs

User report 'site doesn't work for me' but it does for you. Check A across all 3 resolvers. If their resolver returns a different IP, you have asymmetric DNS or stale cache.

DMARC / SPF compliance audits

Email-deliverability audits require checking SPF and DMARC are visible globally. Run TXT lookups on the apex domain and on _dmarc.X to confirm both records are present.

Subdomain inventory checks

Quickly check whether a subdomain (mail.example.com, api.example.com, etc.) has DNS records configured. NXDOMAIN response means the subdomain doesn't exist.

Detect domain hijack or DNS poisoning

If your domain's A record returns an unexpected IP across all 3 resolvers, your DNS may have been hijacked at the registrar level. Multi-resolver check rules out local cache poisoning.

DNS / CNAME Checker vs Alternatives

Side-by-side feature and pricing comparison with the top alternatives.

Feature	U2L	dnschecker.org	whatsmydns.net	dig (CLI)
Free unlimited lookups
Multi-resolver comparison	3 resolvers	30+ locations	30+ locations	Manual
Browser-only (no install)
Returns TTL per record
Edge-cached for speed	60s	Unknown	Unknown
JSON / API output		Paid		Manual parse
DoH (works behind firewalls)
Whois lookup integration	Companion tool

DNS / CNAME Checker vs dnschecker.org

dnschecker.org checks DNS propagation across 30+ global locations. Best-in-class for full-propagation visualization. Free for basic checks; paid API for programmatic use.

U2L's checker focuses on three popular public resolvers (Cloudflare, Google, Quad9) which cover the dominant share of consumer DNS traffic. For propagation drilling at the country / region level, dnschecker.org wins. For fast 'are my records live and consistent across major resolvers?' check, U2L is faster and includes the JSON API free.

DNS / CNAME Checker vs dig (command line)

dig is the canonical Unix DNS lookup tool. Runs locally, supports every record type, and outputs full DNS metadata. Required for serious DNS debugging.

U2L's web tool is faster for quick comparison checks across multiple resolvers without scripting. For deep DNS forensics or scripting in CI/CD, use dig. For 'is my new TXT record visible?', U2L is faster.

Best Practices

Lower TTL before planned DNS changes

If you're planning a DNS change (migration, IP swap), lower the TTL to 300 seconds (5 minutes) at least 48 hours in advance. After the change, raise it back to 3600+ for performance.

Verify with all 3 resolvers, not just one

A change that's live on Cloudflare 1.1.1.1 may still be lagging on Google 8.8.8.8. Don't declare propagation complete until all 3 resolvers match.

Check TXT records for the full string, not just presence

SPF, DKIM, and DMARC are TXT records with specific syntax. Verify the full string matches what your SaaS provider issued, not just that 'a TXT record exists'.

Use NXDOMAIN as a positive signal

If you intentionally remove a record, the checker should return NXDOMAIN (no answer). If it still returns the old answer, propagation is incomplete.

Re-check after suspected DNS hijacks

If your A record returns an unexpected IP, lock down your registrar (enable 2FA, add transfer locks) and re-check across all 3 resolvers. Multi-resolver consistency rules out local DNS poisoning.

Don't confuse resolver TTL with authoritative TTL

The TTL shown is the resolver's cache TTL, not the original authoritative TTL. They start equal but the resolver TTL counts down as the answer ages in cache.

Use the SOA record to find the authoritative server

The SOA record's MNAME field is the primary authoritative nameserver. Useful for filing bug reports with your DNS provider or debugging asymmetric NS configurations.

Cache-aware re-checks during cutovers

U2L caches results for 60 seconds. If you're actively rolling out a change and want second-by-second visibility, hit dig from a terminal in parallel.

Common Mistakes to Avoid

Pasting the full URL with protocol and path

https://blog.example.com/post-1 works (the tool strips protocol and path) but typing blog.example.com directly is faster. The query goes against the hostname only.

Checking one resolver and assuming propagation

Cloudflare 1.1.1.1 updates fast. Other resolvers (especially Google 8.8.8.8) may take longer. Always verify all 3 match before declaring propagation complete.

Ignoring the TTL during propagation

Resolvers cache for the TTL duration. If TTL was 86400 (24 hours) before a change, expect up to 24 hours of stale answers. Lower TTL before changes to speed propagation.

Using the wrong record type for verification

Domain ownership verification is usually TXT (Google), CNAME (M365), or both depending on the SaaS. Check the SaaS's docs for the exact type before lookup.

Querying the apex when the SaaS wants a subdomain

M365 wants verification records on selector subdomains (selector1._domainkey.example.com), not the apex. Always check the SaaS's exact target hostname.

Trusting cached results during rapid cutovers

U2L caches for 60 seconds. If you're mid-DNS-cutover, the 60s cache may show stale results. Use dig from a terminal for second-by-second visibility.

Confusing CNAME with redirect

CNAME is a DNS-level alias (canonical name). It happens before HTTP. CNAMEs at the apex are not allowed by RFC; use ALIAS / ANAME records via your DNS provider for apex aliasing.

Technical Specifications

Resolvers	Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9
Protocol	DNS-over-HTTPS (DoH, RFC 8484)
Supported record types	A, AAAA, CNAME, MX, TXT, NS, SOA
Per-resolver timeout	4 seconds
Cache TTL	60 seconds at the Cloudflare edge
Punycode (IDN) support	Yes - input as xn-- form for canonical lookup
DNSSEC validation	Yes (resolver-side, transparent to user)
Whois integration	Companion tool /tools/whois-lookup for registrar + DNS combined
API endpoint	GET /api/tools/dns-checker?domain=X&type=A

Industry-Specific Use Cases

DevOps and SRE

Production DNS verification, post-deploy sanity checks, propagation monitoring during cutovers. Multi-resolver visibility catches issues local dig misses.

Email administrators

SPF, DKIM, DMARC verification across resolvers. Catch ISP-specific outages where one resolver doesn't return the email-auth record.

Web developers

Verifying CDN and load-balancer DNS routing. Confirming custom domains attached to Vercel, Netlify, Cloudflare Pages.

Security and incident response

DNS hijack detection, DNS poisoning forensics. Multi-resolver consistency rules out local cache attacks.

SaaS implementation teams

Customer onboarding requires DNS verification (TXT, CNAME). Self-service tool to confirm customer setup is correct before flipping the SaaS feature live.

Domain investors and aftermarket

Pre-purchase DNS sanity checks. Confirming a target domain's DNS resolves cleanly before completing a transfer.

Frequently Asked Questions

Why query 3 resolvers instead of 1?

Different resolvers cache for different durations and update at different rates. A change that's live on Cloudflare 1.1.1.1 may not yet be visible on Google 8.8.8.8. Comparing answers across resolvers tells you whether propagation is complete.

Which resolvers does it use?

Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9 9.9.9.9. These three together cover the dominant share of consumer DNS traffic in most regions.

What does it mean when answers differ across resolvers?

Either propagation is mid-rollout (some resolvers updated, others lagging), or you have asymmetric DNS configured (different answers per resolver, on purpose). The first case resolves itself within hours; the second is intentional and rare.

How long does DNS propagation take?

Depends on your TTL. With TTL=300 (5 min), most resolvers update within 5-10 minutes. With TTL=86400 (24 hours), full global propagation can take 24-48 hours. Lower TTL before planned changes.

What's the difference vs dig?

dig runs from your local machine and queries one resolver at a time. The U2L tool queries 3 resolvers in parallel via DoH and shows them side by side. For deep DNS forensics, use dig; for fast multi-resolver checks, U2L is faster.

Can I check subdomains?

Yes. Type the full subdomain (blog.example.com, api.example.com, mail.example.com). The query goes against the subdomain, not the parent.

What record types are supported?

A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (SPF/DKIM/DMARC/verification), NS (nameservers), SOA (zone metadata). Less common types (PTR, SRV, CAA) are on the roadmap.

Does it support DNSSEC validation?

Yes. All 3 resolvers validate DNSSEC by default; if a domain has DNSSEC enabled and the chain is broken, the resolver returns SERVFAIL and the tool shows an error.

Why does the same query return different TTLs each time?

TTLs count down. The TTL shown is the resolver's remaining cache time for that answer. If you query at TTL=300 and again 60 seconds later, the second query shows TTL=240. After TTL hits 0, the resolver re-fetches from the authoritative server.

Can I check via a specific country / region?

The 3 resolvers are global anycast - your query routes to the nearest CF/Google/Quad9 region. For per-country checks (e.g. 'what does Germany see?'), use dnschecker.org or whatsmydns.net which support 30+ regional probes.

Is there an API I can call programmatically?

Yes. GET https://u2l.ai/api/tools/dns-checker?domain=example.com&type=A returns JSON. Cached for 60 seconds. No auth required. Be polite - don't loop more than 1 request per second per IP for the same domain.

Why does my recently-added record show NXDOMAIN?

Either the change hasn't propagated yet, or you typed the wrong subdomain. Wait for the TTL window to pass and re-check. If it persists, verify the record exists at your DNS provider's dashboard.

What does 'Status: 3' mean?

DNS RCODE 3 = NXDOMAIN (no such domain). Either the domain doesn't exist or the record type doesn't exist for this domain. NS lookups on the subdomain return NXDOMAIN even when the parent has NS - that's expected.

Can I use this to detect DNS hijacks?

Indirectly. If all 3 resolvers return the same unexpected answer, your DNS may be hijacked at the registrar level (lock down 2FA on the registrar account immediately). If one resolver disagrees with the others, it may be cache poisoning.

Will this work for internal / private DNS?

No. The 3 resolvers used are public; private DNS records (split-horizon DNS, internal AD-DS records) won't resolve. Use dig from inside your network for private DNS.

Does it support IDN / punycode domains?

Yes. Input the punycode form (xn--caf-dma.com) for canonical lookup. The Unicode form (café.com) also works; the tool converts internally.

What if all 3 resolvers timeout?

Likely the authoritative DNS server for the domain is down. Check with your DNS provider. The tool returns errors for each resolver in that case.

Can I bulk-check multiple domains?

The current tool does one domain per request. For bulk DNS health checks, the U2L API can be hit in a loop with rate-limit backoff (1 req/sec/IP is safe). Bulk UI is on the roadmap.

Related Free Tools

Whois Lookup

Look up registrar, owner, creation date, expiry, and DNS for any domain. Free Whois data, no API key.

Free QR Code API

REST API for generating SVG and GIF QR codes. WiFi, vCard, URL, and text. Free, no API key, edge-cached.

SSL Certificate Checker

Inspect any SSL certificate: validity, issuer, chain, expiry, and protocol. Spot issues before users do.

HTTP Header Inspector

Inspect HTTP request and response headers for any URL. Cache, security, CORS, and server details.

URL Shortener Speed Test

Compare redirect response times across 10+ URL shorteners. Real measurements in your browser.

Deep Link Tester

Test iOS Universal Links and Android App Links. Validate scheme, host, and fallback behavior.

See all 50 free tools

Key Terms

DNS: Domain Name System - the protocol that translates human-readable domain names into IP addresses. Defined in RFC 1034-1035 (1987) and updated by dozens of subsequent RFCs.
Resolver: A DNS server that accepts queries from end users and returns answers (often by querying authoritative servers and caching results). Public resolvers like 1.1.1.1 and 8.8.8.8 serve billions of queries daily.
TTL: Time To Live - how long (in seconds) a DNS record may be cached before re-querying the authoritative server. Lower TTLs propagate changes faster; higher TTLs reduce DNS load.
Authoritative server: The DNS server that holds the canonical zone file for a domain. Set by the NS records at the registrar. Resolvers query authoritative servers when their cache expires.
DoH (DNS-over-HTTPS): DNS queries sent over HTTPS instead of UDP port 53. Standardized in RFC 8484. Works behind firewalls that block traditional DNS.
Propagation: The process of a DNS change spreading from authoritative server through resolvers worldwide. Usually completes within the TTL window after the change.
NXDOMAIN: DNS response code 3 - 'no such domain'. The queried name doesn't exist. Expected for un-configured subdomains; unexpected if you just configured one and it's still NXDOMAIN.
DNSSEC: DNS Security Extensions (RFC 4033-4035). Adds cryptographic signatures to DNS records so resolvers can verify answers haven't been tampered with. Increasingly common; many resolvers validate by default.

Want DNS change alerting and continuous monitoring?

Sign up free for scheduled DNS checks, change alerts, multi-domain dashboards, and integration with the U2L Whois Lookup tool. No credit card; takes 30 seconds.