Start by confirming which layer is broken. Most "DNS is down" problems are actually one of three things: the domain's nameservers point somewhere unexpected, a record is wrong or missing at the zone, or you're checking from a location that hasn't picked up a recent change yet. Work through these in order and you'll find the cause in a few minutes.
Step 1: confirm the nameservers
Before touching any record, check where the domain's nameservers actually point. In the portal, go to Domains, select the domain, and look at the DNS section. This screen controls nameservers only (up to 5) - it does not edit individual records. If the domain uses Flashcloud's nameservers, records are managed in the zone editor described below. If it points somewhere else (a registrar's default nameservers, Cloudflare's own, a previous host), every record change you make in our portal is invisible until the nameservers change, because the authoritative zone lives elsewhere.
A mismatch here is the single most common cause of "I updated the record and nothing happened." If you moved a domain to Flashcloud and DNS still looks wrong, verify the nameservers before doing anything else.
Step 2: check the actual records
Once nameservers are confirmed correct, go to Services → your hosting → DNS Zone Editor to see the real records. Compare what's there against what should be there:
- A record for the root domain and
wwwshould point to the correct server IP. - CNAME records should not coexist with other records on the same name - a CNAME has to be the only record for that hostname.
- MX records control where mail routes. If mail is failing but the site loads fine, this is usually the first place to look.
- TTL (time to live) determines how long resolvers cache a record. A high TTL (like 14400 seconds, 4 hours) means a recent change can take that long to be visible everywhere, even after propagation is otherwise complete.
Step 3: rule out propagation delay
DNS changes don't appear everywhere instantly. Every resolver between you and the authoritative nameserver can cache a record for up to its TTL, and different networks pick up changes at different times. Before assuming a change failed:
- Use a tool like
digor an online propagation checker to query multiple locations at once, rather than relying on what your own browser shows. - From a terminal,
dig yourdomain.com Aordig yourdomain.com MXshows exactly what a resolver is currently returning, plus the TTL on the response. - Clear your local DNS cache and try a different network (like a phone on cellular data) to rule out a stale cache on your end.
If dig against the authoritative nameserver directly shows the correct answer but your browser doesn't, the record is fine and you're waiting on propagation or a cached result somewhere in between.
Step 4: check for conflicting or duplicate records
Many "DNS is broken" tickets come down to leftover records from a previous setup: an old A record still pointing at a former host, a duplicate MX record, or a CNAME that conflicts with a new A record on the same hostname. Read through the full zone rather than only adding the record that looks missing. If you recently moved hosts, this is worth checking even if the site appears to be working, since browsers and some resolvers may still be serving a cached, correct-looking result from before the conflict.
Step 5: verify SSL after DNS is fixed
SSL issues are often a downstream symptom of a DNS problem, not a separate bug. Once records point correctly, a free Let's Encrypt certificate is issued automatically, usually within about 5 minutes, and renews on its own after that. If HTTPS still fails a few minutes after DNS resolves correctly, the DNS piece is done and the SSL issuance step is where to look next.
When to contact support
If you've confirmed nameservers, checked the zone for correct and non-conflicting records, verified with dig against the authoritative server, and waited past the TTL window, and something is still wrong, open a ticket from Support → New ticket in the portal or use live chat. Real humans handle DNS issues directly, and it helps to include the exact dig output and the domain in question so they can see precisely what the nameservers are currently returning.