Enter a domain → A, AAAA, CNAME, MX, NS, and TXT records when our resolver returns them.
Run a lookup to see records.
Users type your domain; DNS tells their browser and API clients which IP addresses and mail servers to use. When DNS is wrong, slow, or mid-propagation, your application can be healthy while everyone sees connection errors. DNS failures are reliability incidents — not a separate “network team only” topic.
This tool queries common record types from our server. Free, no signup. Honest limit: one resolver path, not a global DNS audit platform.
You moved origin from 198.51.100.10 to 203.0.113.50 but A still shows old IP globally.
Customers hitting old IP see errors. Fix: lower TTL before cutover; verify with this tool from external view; purge CDN if cached.
Attempted CNAME at root example.com — some providers forbid it (RFC convention).
Use ALIAS/ANAME records or redirect www → apex instead of broken apex CNAME.
Let's Encrypt DNS-01 needs TXT at _acme-challenge.example.com.
Missing TXT → renewals fail in 90 days → SSL outage. Check TXT during automation setup, not on expiry eve.
Before migration: lower TTL to 300 seconds 24–48 hours ahead. After change: verify with this tool, wait one old TTL period, verify again. Document both checks in change ticket.
Corporate laptops on VPN may resolve internal DNS views. This tool shows what many public users see — if results differ from your office dig, trust the public view for customer impact.
MX misconfiguration during website migration is common: team changes A records, forgets MX still pointing at old provider. Website works; invoices and password resets vanish. Include MX in every domain change checklist alongside A/AAAA.
SPF TXT records have lookup limits (10 DNS lookups). Over-nesting includes breaks mail silently. Use SPF flattening services or simplify includes when approaching limits — specialist topic beyond this lookup tool but surfaced when you inspect TXT here.
Keep baseline exports in change tickets. During rollback debates, “what did we change?” answered with diff beats memory.
When you change a DNS record with TTL = T seconds, resolvers that cached the old value may serve it until the cache expires — worst case roughly T from last lookup, often up to 2T during cutovers if timing aligns badly. Before migration: lower TTL to 300 seconds 24–48 hours ahead. After change: wait at least old TTL, then re-run this tool. Propagation percent is not binary globally — some resolvers update in 2 minutes, stragglers take 45 minutes with TTL 3600.
rough_max_stale_minutes ≈ previous_TTL_seconds / 60
cutover_verification_window = old_TTL + new_TTL + manual buffer (often 15 min)
Change: A record app.example.com from 198.51.100.10 → 203.0.113.50 at 14:00 UTC. Previous TTL: 3600s.
14:05 UTC — this tool still shows 198.51.100.10 (cached).
15:10 UTC — shows 203.0.113.50 (expected after ~1h).
15:12 UTC — Availability on new IP: 200 in 156 ms.
Support tickets citing “cannot connect” dropped from 23/hr to 2/hr by 16:00 UTC — stragglers on old TTL.
Public resolver path from our infrastructure only. No DNSSEC chain validation, no authoritative zone transfer audit, no historical DNS change log. Cannot see your internal Active Directory DNS. Use for external triage during migrations — not enterprise DNS governance.
During domain transfers, verify MX, SPF TXT, and DKIM CNAME/TXT together. A successful web cutover with broken SPF may not surface for days until marketing sends a campaign and bounce rate hits 18%. Include TXT inspection in every domain migration ticket — this tool surfaces records quickly for baseline screenshots attached to change requests.
CAA records restrict which CAs may issue certs for your domain. Adding CAA without including your current CA blocks renewal at day 30 panic. Before tightening CAA, export current issuer from SSL Checker and allow that CA in CAA.
Adding AAAA without testing IPv6 path may strand users whose networks prefer v6 while v6 routing is broken. After adding AAAA, run availability check and confirm both families if your monitoring supports it. This DNS tool shows A and AAAA together — mismatch (A points new origin, AAAA still old) causes intermittent “works for me” reports that are nightmare to debug without family-specific tests.
Many teams buy domain at registrar A but host DNS at Cloudflare or Route53. NS records must point at authoritative provider — editing A record at registrar while NS delegate elsewhere produces “we changed DNS but nothing happened” during incidents. This tool’s NS section is the first check when changes do not stick: if NS still show old provider, update delegation before A record edits matter globally.
CNAME pointing to decommissioned SaaS (old marketing landing page, expired Heroku app) enables subdomain takeover — attacker claims dangling target. During DNS review, flag CNAME targets you no longer control. Removing orphan CNAME beats incident response after takeover. TXT records for domain verification left after vendor offboarding can also signal cleanup debt worth auditing quarterly.
Before any DNS change window, paste this tool’s output into change ticket as “before” snapshot. After TTL window, paste “after” and diff mentally or with text diff. Disputes during rollback (“which IP was prod?”) resolve in minutes when baselines exist — not from on-call memory at 3 a.m.
DNS mispoint during cutover causes full customer outage until TTL expires — log minutes and run Downtime Cost even when root cause is “DNS typo,” not application bug. Reliability reviews should treat DNS changes with same rigor as database migrations.
Availability Checker · SSL Checker · REST API Checker · Free Tools.
DNS maps names to infrastructure. Errors or propagation delays cause outages that look like application failures.
A, AAAA, CNAME, MX, NS, and TXT when our resolver returns them.
Results come from our server's resolver path — not every global vantage point.
Caching, resolver choice, and TTL timing cause differences. Check authoritative NS during cutovers.
Yes. Wrong MX breaks mail while A records still serve the site.
Domain verification, SPF/DKIM, and ACME DNS-01 challenge tokens for certificates.
No dedicated DNSSEC validation. Use specialized tools if signatures are in scope.
Run Availability, SSL, and API checks on resulting hostnames.