Note

Why newly created DNS records seem broken if you checked them too early

3 min read

Here is a scenario almost everyone in IT runs into at least once:

  1. You need to set up a new record—for instance, a new subdomain like app.yourdomain.com or an email verification record.
  2. Before adding it (or right after clicking Save), you test it in your terminal or browser to see if it works:
    Resolve-DnsName -Name app.yourdomain.com
    # Result: Does not exist (NXDOMAIN)
  3. You go to your DNS provider (Cloudflare, GoDaddy, Route 53, etc.), add the record, and click Save.
  4. You test it again 30 seconds later, but it still says it does not exist.
  5. You wait 5 minutes. Still broken. You start doubting your settings, deleting the record, and re-adding it.

Meanwhile, your coworker on their phone or another network visits the link and says: “Works fine for me!”

What happened?


The Restaurant Analogy

Imagine calling a restaurant at 4:59 PM to ask if they are open. The receptionist says:

“No, we’re not open. And please don’t call back for an hour.”

If the restaurant unlocks its doors 60 seconds later at 5:00 PM, anyone walking by on the street can enter. But if your phone automatically refuses to dial them again until 5:59 PM because it remembered the previous “No”, you will think the restaurant is still closed.

That is exactly how DNS handles missing records.


What happens behind the scenes

When you look up a website or record, your computer does not talk directly to your domain’s control panel. It talks to a resolver (a middleman, like your home router, your ISP, or services like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1).

Resolvers cache (memorize) answers to make the internet faster:

  1. Positive caching: When a record exists, the resolver saves the answer so it doesn’t have to look it up again for a while.
  2. Negative caching: When a record does not exist, the resolver also memorizes that “No” answer so people can’t overwhelm the internet by repeatedly querying non-existent domains.

When you tested the record before it was ready, your resolver asked the authoritative server, got a “No, doesn’t exist”, and saved that negative answer in its memory.

Even if you created the record 2 seconds later, your resolver won’t check again until its “negative cache timer” expires—which is often anywhere from 5 minutes to an hour.


How to test if your record is actually live

If your local computer or router is stuck remembering the old “does not exist” answer, here is how to check what is actually published on your domain without waiting.

Step 1: Find your domain’s real nameservers

Don’t use generic names like ns1.cloudflare.com. Cloudflare assigns unique nameservers to every domain (such as lewis.ns.cloudflare.com and rose.ns.cloudflare.com). You can see yours right in PowerShell:

Resolve-DnsName -Name hardenedhost.com -Type NS

This returns the actual authoritative servers for your domain:

Name             NameHost
----             --------
hardenedhost.com lewis.ns.cloudflare.com
hardenedhost.com rose.ns.cloudflare.com

Step 2: Query your nameserver directly

Now bypass the middleman resolver and ask one of those nameservers directly with the -Server parameter.

To check your website’s main IP address:

Resolve-DnsName -Name hardenedhost.com -Type A -Server lewis.ns.cloudflare.com

To check an email or TXT record (always remember to specify the -Type!):

Resolve-DnsName -Name hardenedhost.com -Type TXT -Server lewis.ns.cloudflare.com

On Mac or Linux with dig:

dig hardenedhost.com TXT @lewis.ns.cloudflare.com

[!NOTE] PowerShell’s “Red Error” Trap: If a record doesn’t exist yet, PowerShell displays a red error ending in DNS name does not exist. That does not mean the command syntax failed—it simply means the nameserver answered and confirmed the record isn’t there yet.

If the command returns your new record, your setup is working correctly. You simply need to wait for local caching resolvers to forget the earlier “No” answer.

Step 3: Clear your own computer’s local DNS cache

Sometimes your own Windows or Mac machine remembered the failed result. You can clear your local cache:

  • Windows:
    Clear-DnsClientCache
    # Or: ipconfig /flushdns
  • macOS:
    sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

The takeaway rule

Whenever you are setting up a new service or domain: don’t test the record until after you have saved it.

Querying a record beforehand to “see if it’s there yet” is the very thing that delays it from working on your machine.