DNS Lookup Tool
Every outage, email delivery failure, or failed certificate issuance starts here. Pull every DNS record for a domain in one request — A, AAAA, MX, CNAME, TXT, NS, SOA, CAA — with TTLs and priorities, so you can compare what should be there with what actually is.
Understanding DNS Records and Their Role in Website Performance
DNS is the invisible infrastructure that makes the internet work. Every website visit, email sent, and API call starts with a DNS lookup. Misconfigured or slow DNS records directly impact your site's availability, deliverability, and performance.
Common DNS issues this tool helps diagnose:
- Missing or incorrect A records: If your A record points to the wrong IP, your site is unreachable. After a server migration, this is the first thing to verify.
- MX record misconfiguration: Wrong MX records mean email to your domain gets lost. Check priority values and that all mail servers are listed.
- SPF/DKIM in TXT records: Email authentication policies live in TXT records. Missing or malformed SPF/DKIM records cause legitimate emails to land in spam.
- TTL values too high: Very high TTL (24–48 hours) makes DNS changes slow to propagate, causing extended downtime during server migrations.
- CAA misconfiguration: CAA records control which CAs can issue SSL certificates for your domain. An incorrect CAA record can block certificate renewal.
How to interpret the results
Each record type answers a different question. Scan them in this order:
- NS — who is authoritative for this zone? If these do not match what your registrar shows, the domain is being served from somewhere you may not control.
- A / AAAA — what IP does the domain resolve to? Compare against the IP your hosting dashboard shows. A mismatch means either propagation is in progress, or the zone is edited on the wrong provider.
- CNAME — is this hostname an alias? A CNAME on the apex (example.com) is invalid per RFC 1035; use ALIAS/ANAME or an A record instead. A CNAME chain longer than 2–3 hops slows every lookup.
- MX — where does email go? Lower priority wins. A missing or typo'd MX and inbound mail bounces. A stale MX pointing to a decommissioned server silently loses mail.
- TXT — verification tokens, SPF (v=spf1…), DKIM, DMARC. More than one SPF record on the same name is a spec violation; merge them.
- CAA — which certificate authorities may issue for the domain. A CAA of
0 issue "letsencrypt.org"blocks every other CA. If your cert provider changes, update CAA first. - SOA — serial number and TTLs. The serial increments on every zone change; comparing it over time confirms a change has actually been published.
- TTL — how long resolvers cache the answer. Low TTL = fast propagation, more queries to your nameserver. High TTL = cheaper, slower to change.
Common issues and fixes
Changed the A record, users still see the old IP
The browser, OS, and recursive resolver are all caching the previous record until its TTL expires. Flush the local cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and re-query through a public resolver (1.1.1.1, 8.8.8.8) to bypass your ISP cache.
Emails to Gmail land in spam after a domain move
The SPF record on the new zone is missing or does not include the new sending service. Run a DNS lookup, confirm the TXT starts with v=spf1 and includes every mail origin, and that there is exactly one SPF TXT record.
Let's Encrypt renewal suddenly fails with "CAA record prevents issuance"
A CAA record was added (often by a security hardening script) that lists a different CA. Add 0 issue "letsencrypt.org" or remove the conflicting entry.
Apex CNAME is not resolving
RFC does not allow a CNAME at the zone apex. Use your DNS provider's ALIAS, ANAME, or CNAME-flattening feature — or an A record pointing directly to the IP.
What to do next
DNS is the silent dependency: when it breaks, everything else looks broken. After confirming the records look correct right now, the next step is catching drift before it costs you mail or uptime.
- Lower the TTL to 300s at least 48 hours before any planned change, then raise it back afterwards.
- Snapshot the current zone (export to a file) so you have a known-good baseline to diff against.
- Turn on DNS change monitoring on FlashMon.app — any unexpected edit to A, MX, or NS records triggers an alert, which is how most DNS hijacks are caught early.
Monitor DNS changes automatically
Get instant alerts when any DNS record for your domain changes — catch misconfigurations before they cause downtime.
Frequently Asked Questions
DNS (Domain Name System) is the internet's phonebook — it translates human-readable domain names like example.com into IP addresses like 93.184.216.34 that computers use to route traffic. When you type a URL into a browser, your system queries a chain of DNS resolvers: first the local cache, then a recursive resolver (usually from your ISP or Google/Cloudflare), which contacts root nameservers, then top-level domain nameservers (e.g. .com), and finally the domain's own authoritative nameservers to get the final answer. This entire process typically completes in under 100ms.
DNS records are instructions stored in authoritative nameservers. The most important types: A records map a domain to an IPv4 address. AAAA records map to IPv6. CNAME records create aliases pointing one name to another. MX records identify which mail servers accept email for the domain, with priority values (lower = preferred). TXT records store arbitrary text — commonly used for domain ownership verification, SPF anti-spam policies, and DKIM email authentication. NS records identify which nameservers are authoritative for the domain. SOA (Start of Authority) records contain zone metadata including the primary nameserver, admin contact, and cache timing parameters. CAA records specify which certificate authorities are allowed to issue SSL certificates for the domain.
TTL (Time to Live) is a value in DNS records that tells resolvers and caches how long to store the record before requesting a fresh copy from the authoritative nameserver. A TTL of 3600 means caches will keep the record for 1 hour. TTL matters enormously when making DNS changes: if your A record has a TTL of 86400 (24 hours), changing your server IP could take up to 24 hours to propagate globally because all caches need to expire before re-querying. Best practice before a planned migration: lower your TTL to 300 (5 minutes) at least 48 hours beforehand, make the change, then raise it back after confirming everything works.
DNS resolution adds latency to every new connection. Even though DNS lookups often complete in 10–100ms, they happen before the TCP handshake, TLS negotiation, and HTTP request — all adding up to the initial TTFB (Time to First Byte). Strategies to minimize DNS impact: use a premium anycast DNS provider (Cloudflare, AWS Route 53, Google Cloud DNS) which routes queries to the nearest server; reduce the number of third-party domains your page loads from (each requires a separate DNS lookup); use DNS prefetching (`<link rel='dns-prefetch'>`) for critical third-party origins; set appropriate TTLs to maximize cache hit rates; and use DNS-over-HTTPS (DoH) which combines DNS and HTTPS to reduce round trips.
Nameservers are the DNS servers that are authoritative for your domain — they hold the actual DNS records and answer queries about your domain. When you register a domain, you point it at nameservers (usually provided by your DNS host or registrar). Every domain must have at least two NS records for redundancy. Nameservers are critical: if they go down or are misconfigured, no one can resolve your domain and your entire site becomes unreachable. Large enterprise sites often use premium DNS providers with 100% uptime SLAs and anycast routing for maximum availability and speed. FlashMon monitors nameserver availability continuously.
DNS propagation refers to the time it takes for updated DNS records to spread to all resolvers worldwide. After making a change, propagation completes when the previous cached records expire (based on the old TTL) and resolvers fetch the new values. You can check propagation by querying DNS from multiple geographic locations and comparing results — if some locations return the old IP and others return the new one, propagation is still in progress. Common tools include using multiple DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's resolver) to compare answers. Full propagation typically takes minutes to hours — rarely more than 48 hours. FlashMon's monitoring detects DNS changes automatically and notifies you the moment a change is detected.
Three common reasons. First, propagation is not instant — even with a 300s TTL, intermediate resolvers may still be serving the old answer. Query your authoritative nameservers directly (dig @ns1.yourdns.com example.com A) to confirm the record is live at the source. Second, the record was added to the wrong zone — for example, to the apex example.com when the working zone is on a subdomain registered separately. Third, some dashboards accept a save before fully writing it; refresh and confirm the change is still there after a few minutes.
You don't need them, but publishing an AAAA record when you have no IPv6 service can make things worse: dual-stack clients will try IPv6 first, time out, and fall back to IPv4 — adding seconds to first-byte time on mobile networks. Either publish both A and AAAA with equivalent service behind them, or publish only A. Do not publish an AAAA that points at an unreachable host.
SPF has a hard limit of 10 DNS lookups per evaluation. Every include: in your record (Google, Microsoft 365, Mailgun, Salesforce, etc.) counts, and those includes can trigger their own lookups. Exceeding 10 causes a permerror and receiving servers may treat your mail as unauthenticated. Flatten rarely-used includes, replace include chains with explicit IPs where the vendor publishes them, or use a managed SPF flattening service.
That is how MX works — it points to a hostname, and the receiving mail server then resolves that hostname to an A/AAAA. This indirection lets providers (Google Workspace, Microsoft 365, Zoho) change their infrastructure IPs without requiring every customer to update DNS. Check that the hostname itself resolves to a live IP and that priority values are set correctly (lower = preferred).