DNS Checker & Lookup

What is DNS?

The Domain Name System (DNS) translates human-readable domain names like example.com into IP addresses that computers use to connect to each other. DNS is the first step in every web request.

Why is DNS resolution speed important?

DNS resolution is the first step in every web request. Slow DNS adds latency before the browser can even start connecting to the server. Resolution under 100ms is good; over 200ms is slow.

What this tool checks

We query every meaningful record type for the given domain: A (IPv4), AAAA (IPv6), MX (mail routing), TXT (general, including SPF / DMARC / verification records), NS (delegation), CNAME (aliases), SOA (zone origin + serial + TTLs), CAA (which CAs may issue certificates for this domain), and SRV (service location) where present. Each query runs against the authoritative nameservers — not your resolver's cache — so the answer reflects the zone as published, and the round-trip time is measured per query to surface the slow-responding nameserver if one server in the rotation is degraded. Email-authentication records get extra parsing: SPF is decomposed into its included mechanisms and lookups-count (DNS has a 10-lookup ceiling for SPF), DMARC's policy verb (none / quarantine / reject) is highlighted, and DKIM selector probing covers the major mailbox providers' default selectors so a misconfigured DKIM publishing setup is visible at a glance.

How we present the results

Results group by record type with the value rendered in the conventional zone-file format (so it can be pasted directly into bind / route53 / cloudflare without translation). Per-record TTLs are surfaced explicitly — long TTLs are good for cache hit rates but slow propagation when the value changes, short TTLs amplify load on the authoritative servers, and an outlier TTL on one record in a set often indicates a forgotten manual override. Authoritative-server timing is measured separately from resolver timing so you can tell whether a slow page-load DNS lookup is your zone's fault or your visitors' resolver's fault. When a record type is absent we say 'no record' explicitly rather than failing silently, because missing-by-design (AAAA on an IPv4-only origin) reads identically to missing-by-mistake (CAA never configured) and the distinction matters when you're debugging.

Common findings on real sites

Five patterns repeat. First, no CAA record — meaning any public CA can issue a certificate for the domain; CAA pins issuance to a specific set (Let's Encrypt, your enterprise CA, etc.) and closes a real attack vector. Second, no AAAA — IPv6 is now ~45% of mobile traffic on major carriers; an IPv4-only origin costs latency and reliability for that half of users. Third, weak or missing email-auth: SPF without DMARC sends mail to spam folders at the major mailbox providers; DMARC with policy=none after a year of monitoring is forgetting to flip the switch. Fourth, very high TTLs (24h+) on records you might need to change quickly (MX during a mailbox migration, A during a region failover) — set them to 300s a day before any planned change. Fifth, dangling CNAMEs pointing at decommissioned cloud resources — these are the bread and butter of subdomain-takeover attacks where an attacker registers the abandoned bucket / heroku app and hosts content under your domain.

How to fix common DNS issues

Add a CAA record naming your authorized CAs ('letsencrypt.org' for ACME-based issuance is the typical line). For email auth, layer three records: SPF ('v=spf1 include:_spf.google.com -all' if you use Workspace), DKIM (publish the public key your provider gives you under the published selector), and DMARC ('v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain'). Add AAAA records when your origin or CDN supports IPv6 (Cloudflare proxies always do; AWS ALB does behind dualstack mode). For TTL hygiene, drop TTL to 300s on records you may need to change in the next week; restore to 3600s or 86400s once the change has settled. For subdomain takeover risk, periodically dump all CNAME targets and confirm each resolves; any 'NXDOMAIN' or 'no such bucket' answer is a takeover-grade hazard to be deleted immediately. Most registrars / managed-DNS dashboards let you bulk-export the zone, so an audit pass is cheap.

Why DNS hygiene matters

DNS sits before everything else: it's the first lookup on every visit, the gating step for email deliverability, and the substrate cert authorities use to decide whether to issue a certificate at all. A misconfigured SPF doesn't just send your mail to spam — it tells receivers your domain is a potential spoofing source, which damages sender reputation across all messages from that domain. A missing CAA quietly increases the blast radius of any DNS-hijack or BGP-attack scenario by enabling rogue certificate issuance. A dangling CNAME is a takeover waiting to happen and the attacker's content speaks with your DNS authority — which is to say, indistinguishably from you to every visitor and to most security-scanning tools. None of this requires running your own resolver: every managed-DNS provider (Cloudflare, Route 53, NS1, Vercel) gives you the surface area to fix all of it through a dashboard or API, usually in under an hour.