Get a free website with any plan

See how
DOMAINS

Checking DNS with dig and nslookup

Last updated

IN SHORT

The dig and nslookup command-line tools show what the internet currently sees for your domain records. Run them against public resolvers or query Flashcloud nameservers directly using dig @ns1.flashcloud.com. If the returned values match your DNS Zone Editor settings, your DNS is live and any remaining problem is caused by local caching.

If a site or email isn't working after a DNS change, dig and nslookup tell you exactly what the internet currently sees for your domain, straight from the source. Run dig yourdomain.com (or nslookup yourdomain.com on Windows) and compare the answer against what you set in your DNS Zone Editor. If they match, the record is live and the problem is somewhere else, usually a local or ISP cache. If they don't match, you're just waiting on propagation.

Using dig

dig is available on macOS and Linux by default. The basic form:

dig yourdomain.com

Look at the ANSWER SECTION. It shows the record type, TTL, and the current value. For example:

yourdomain.com.    3600    IN    A    192.0.2.1

That number is the TTL in seconds, the time resolvers will cache this answer before checking again. The exact value depends on what's set for that record in your zone. To query a specific record type, add it after the domain:

dig yourdomain.com MX
dig yourdomain.com TXT
dig www.yourdomain.com CNAME

To see who's actually answering the query, check the SERVER line near the bottom of the output. By default dig asks whatever resolver your machine is configured to use, which might be your router, your ISP, or a public resolver. That matters because different resolvers can have different cached answers mid-propagation, as explained in how long DNS propagation takes.

To bypass your local resolver's cache and ask a specific server directly, use @:

dig @1.1.1.1 yourdomain.com
dig @8.8.8.8 yourdomain.com

This is the fastest way to check whether a change has reached a major public resolver, without waiting for your own ISP to catch up.

Checking your nameservers directly

If you want the authoritative answer, straight from the nameserver, skip caching resolvers entirely:

dig @ns1.flashcloud.com yourdomain.com A

If our nameservers already show the new value but public resolvers don't yet, the change is correct and you're just waiting on caches to expire elsewhere.

To confirm which nameservers a domain is actually using:

dig yourdomain.com NS

If this doesn't list ns1.flashcloud.com and ns2.flashcloud.com, DNS record edits need to happen at whatever provider does appear here, not in our DNS Zone Editor. If you're researching DNSSEC, see DNSSEC: what it is and whether you need it.

Using nslookup

nslookup ships on Windows, macOS, and most Linux distributions, and it's the more familiar tool if you're not comfortable with dig's output. Basic query:

nslookup yourdomain.com

The output is split into a "Server" block (which resolver answered) and an "Answer" or "Non-authoritative answer" block (the actual record). Query a specific type with -type:

nslookup -type=MX yourdomain.com
nslookup -type=TXT yourdomain.com
nslookup -type=NS yourdomain.com

To query against a specific server instead of your default resolver, add it as a second argument:

nslookup yourdomain.com 1.1.1.1

nslookup doesn't show TTL by default the way dig does, which is one reason sysadmins tend to prefer dig for anything beyond a quick sanity check. But for confirming "does this A record resolve at all," either tool gets you the answer in seconds.

Reading the result

Once you have output from either tool, there are really only three outcomes:

  • The value matches what you set. DNS is correct. Any remaining issue (site not loading, mail not arriving) is downstream of DNS, not caused by it.
  • The value is old or missing. The change hasn't propagated to the resolver you queried yet. Try a different public resolver, or wait and re-check.
  • NXDOMAIN or no answer at all. Either the record doesn't exist, the domain isn't using the nameservers you expect, or there's a typo in the name you queried.

If you flushed your local DNS cache and a public resolver like 1.1.1.1 still shows the old value well past the record's TTL, that's worth a closer look rather than more waiting.

When to contact support

If dig @ns1.flashcloud.com shows the wrong value for a record you edited in the DNS Zone Editor, or a record you added isn't showing up there at all, open a ticket from Support in the portal. Include the exact dig or nslookup output you're seeing so a human can compare it against what's actually in the zone.

Common questions

Why is my domain still showing the old IP address?

Your resolver is serving a cached result. Resolvers store records for the duration set by the TTL. Check a public resolver like 1.1.1.1 or query ns1.flashcloud.com directly to see if the new record is live at the source.

How do I check if my domain uses Flashcloud nameservers?

Run dig yourdomain.com NS in your terminal. If ns1.flashcloud.com and ns2.flashcloud.com do not appear in the results, update your records at the provider listed in the output instead of the Flashcloud DNS Zone Editor.

Should I use dig or nslookup?

Use dig if you need to see TTL values on macOS or Linux. Use nslookup on Windows or when you need a quick check to confirm whether a record resolves at all.

When should I contact support about a DNS record?

Open a ticket in the portal if dig @ns1.flashcloud.com shows the wrong value or nothing at all after your update. Include your exact dig or nslookup output so support can compare it against the zone.

CAN'T FIND IT?

Real humans answer fast.

Hosting with us? Open a ticket and a real person replies - no scripts, no upsells. Still choosing a host? The same team is included with every plan, from day one.