2026-03-23•DNS

DNS Lookup: How to Diagnose DNS Problems That Take Your Site Down

Changed hosting providers and your site disappeared? DNS problems are the #1 cause of silent downtime. Learn how to diagnose and fix them fast.

You migrated your site to a new server, updated the nameservers in your domain registrar, and went to sleep. The next morning, half your customers say the site is down — but it loads just fine for you. Or worse: some users are hitting the old server, checkout is broken because the database is on the new one, and you have no idea why.

This scenario has a name: a DNS problem. And it's the number one cause of silent downtime — the kind that doesn't trigger alerts, doesn't generate a 500 error, it simply makes your site disappear for part of the world without any warning.

The good news is that DNS follows well-defined rules. Once you understand how it works, diagnosing and fixing these issues becomes straightforward. This guide shows you how to do it in practice.


How DNS Works (The Phone Book Analogy)

Think of DNS as the contacts app on your phone. When you want to call "Office," you don't need to memorize the number — your phone handles that translation for you.

DNS does the same thing for internet addresses. When someone types yoursite.com into a browser, the computer doesn't know where that site lives. It needs to ask DNS: "what's the IP address for yoursite.com?"

Here's how the process works:

  1. The browser asks the user's DNS resolver (usually their ISP's resolver, or a public one like Google's 8.8.8.8)
  2. The resolver asks the root servers (the internet's top-level authority)
  3. The root servers point to your domain's authoritative nameservers (the ones you configure at your registrar)
  4. The nameservers respond with the correct IP address
  5. The browser connects to that IP and loads the site

The entire process takes milliseconds. Problems start when any link in that chain returns the wrong information — or when a cache still holds the old information.


DNS Record Types and When Each One Matters

Every DNS record has a specific purpose. Knowing each type is the first step toward diagnosing where the problem actually is.

A Record (Address)

Maps a domain to an IPv4 address. It's the most fundamental record: yoursite.com → 203.0.113.10. If the A record is wrong or still pointing to the old IP after a migration, the site simply won't load.

AAAA Record (Quad-A)

The IPv6 version of the A record. Maps a domain to an IPv6 address (format: 2001:db8::1). Sites without a AAAA record are unreachable for users on IPv6-only networks — a growing share of mobile users, especially outside the US.

CNAME Record (Canonical Name)

Creates an alias pointing to another domain. Commonly used for www: www.yoursite.com → yoursite.com. It's also the record type used by CDNs and platforms like Vercel and Netlify, which ask you to create a CNAME pointing to their domain.

Important: never place a CNAME at the root of your domain (@). It breaks other records. Use an A or ALIAS record at the apex instead.

MX Record (Mail Exchange)

Defines where emails sent to your domain should be delivered. If the MX record is wrong, nobody can email @yoursite.com — and you probably won't notice until a customer calls to complain.

TXT Record (Text)

Stores arbitrary text, but has critical uses for email authentication:

  • SPF: lists which servers are allowed to send email on behalf of your domain (v=spf1 include:...)
  • DKIM: a cryptographic signature that proves an email genuinely came from your server
  • DMARC: a policy that tells receiving servers what to do with emails that fail SPF or DKIM

Without these three records properly configured, your emails land in spam — or get rejected outright.

NS Record (Name Server)

Indicates which nameservers are authoritative for your domain. This is the record that tells the internet where to look for all your other records. If the NS records are wrong after a migration, none of your other records will be found.

SOA Record (Start of Authority)

The SOA is the administrative record for the DNS zone. It contains the zone administrator's email, the zone serial number (used for synchronization between nameservers), and default TTL values. You rarely need to edit it manually, but it appears in queries and helps verify the zone is configured correctly.


Common DNS Problems (and How to Spot Them)

A Record Pointing to the Wrong IP

The classic migration scenario. You set up the new server, but the A record still points to the old one. The site loads — just from the wrong place. Form submissions go to the wrong database, uploads disappear, and checkout fails.

How to identify it: run a DNS lookup and compare the returned IP against your current server's IP. If they don't match, the A record needs to be updated.

Misconfigured MX Record

Emails sent to your domain never arrive because the MX record points to a nonexistent server, has the wrong priority, or simply doesn't exist. Many businesses only discover this problem when a customer calls saying their email bounced.

How to identify it: check the domain's MX records and verify that the listed hosts resolve to valid IPs and that the mail servers are actually running.

High TTL Delaying Propagation

The TTL (Time to Live) defines how long DNS resolvers around the world cache the response to a query. A TTL of 86400 seconds (24 hours) means that after a record change, it can take a full day before all users see the new value.

Best practice: before a planned migration, lower the TTL to 300 seconds (5 minutes) 24 to 48 hours in advance. After the migration is complete, raise the TTL back to a higher value (3600 or more) to improve resolution performance.

Missing AAAA Record (IPv6)

Mobile networks — particularly in the US and parts of Europe — increasingly use IPv6 as their primary protocol. If your site has no AAAA record, those users may experience timeouts or connection errors as their device tries to resolve an IPv6 address and fails.

How to identify it: run a DNS lookup and check whether any AAAA records are returned. If not, evaluate whether your server supports IPv6 and configure the record accordingly.


How to Diagnose: Using FlashMon's DNS Lookup

Command-line tools like dig and nslookup work, but they require technical knowledge and return raw output that's hard to interpret. FlashMon's DNS Lookup solves that with a visual interface.

Just enter the domain and the tool queries and displays all record types in a single request, organized into tabs by type:

  • A/AAAA tab: confirm your IPv4 and IPv6 addresses
  • CNAME tab: see active aliases and where they point
  • MX tab: check mail servers and their priorities
  • TXT tab: inspect SPF, DKIM, and DMARC records
  • NS tab: confirm which nameservers are answering for the zone
  • SOA tab: view the zone serial and configured TTL values

For each diagnosis, the workflow is simple: query the records, compare them against what should be configured, identify the discrepancy, and fix it in your DNS provider's panel.


DNS Propagation: Why It Takes Time and How to Monitor It

After fixing a record, the change doesn't appear instantly for everyone. The reason is caching: every DNS resolver around the planet stored the old version of the response for the duration defined in the TTL. Until that timer expires, it keeps returning the old value.

In practice, global propagation takes anywhere from a few minutes (if the TTL was low) to 48 hours (with a high TTL). During that window, users in different regions and with different ISPs may see different results for the same domain — which explains the "works for me but not for my customer" phenomenon.

To monitor propagation in real time, use FlashMon's DNS Propagation Checker. It queries multiple public resolvers around the world simultaneously and shows whether each one has already picked up the updated value. This eliminates guesswork: you can see exactly which regions have the new record and where it's still pending.

If you want to investigate the domain's history — registration date, historical nameservers, or registrar information — the WHOIS Lookup complements the diagnosis with domain registration data.


Summary: The DNS Diagnosis Checklist

When a site is down or behaving strangely after a DNS change, follow this workflow:

  1. Run a DNS lookup on the domain and check the A, AAAA, MX, and NS records
  2. Compare the returned IPs with your current server's IPs
  3. Check MX and TXT records if the problem involves email delivery
  4. Check the current TTL — if it's high, propagation may take hours
  5. Use the propagation checker to confirm whether the change has reached different regions
  6. Wait or force a refresh — in some cases, you simply have to wait for the TTL to expire

DNS problems are rarely mysterious when you have the right tools. The difference between spending hours wondering why your site vanished and resolving the issue in minutes is knowing exactly where to look.

FlashMon also monitors your domain continuously: if your DNS records change unexpectedly, or if the site goes down for any reason, you get an immediate alert — before your customers notice.


Keep exploring

Written by FlashMon Team

Monitoring & Reliability Specialists

Liked this article?

Sign up for our newsletter to get the latest monitoring tips and tricks.

Subscribe