---
title: DNS change not working? How to check DNS records with the DNS Lookup
description: You edited a DNS record, saved it, and the site, mail or verification still behaves as before. To check DNS records properly, ask two places: the domain's authoritative nameserver, which shows what your DNS host really serves, and a public resolver, which shows what visitors get. Here's how to do both with the free DNS Lookup, how to read the answer, and the dig commands that show the TTLs.
canonical: https://watchfor.io/blog/how-to-check-dns-records
---

# DNS change not working? How to check DNS records with the DNS Lookup

2026-10-04 · WatchFor Team · Guides · guides, dns, networking

You edited a DNS record, saved it, and the site, mail or verification still behaves as before. To check DNS records properly, ask two places: the domain's authoritative nameserver, which shows what your DNS host really serves, and a public resolver, which shows what visitors get. Here's how to do both with the free DNS Lookup, how to read the answer, and the dig commands that show the TTLs.

To check DNS records, look the record up twice: once at the domain's
authoritative nameserver, and once at a public resolver such as `1.1.1.1`.
The authoritative answer is the truth your DNS host serves right now. If it
already shows the new value, the edit worked and anything older you still see
is a cache. If it shows the old value, the edit never reached the provider
that actually answers for your domain.

The free [DNS Lookup](/dns-checker) does both: pick a record type (A, AAAA,
MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV, TLSA, HTTPS or SVCB) and a resolver,
including any IP you type in, and it queries from a real WatchFor location.
No signup.

## What this tool answers

*What does this DNS server say about this name, right now?* Reach for it
after any record change that doesn't seem to take effect, when a site
resolves to the wrong address, or when a service tells you it "can't find"
a record you're sure you added. Unlike a lookup on your laptop, you choose
who answers: the location's own resolver, a public service like Cloudflare,
Google or Quad9, or your authoritative nameserver directly.

## A real example

### Checking DNS records when an edit doesn't take effect

The most common reason a DNS edit "does nothing" is that it was made at the
wrong provider. A domain registered at one company often has its DNS hosted
at another; editing the registrar's zone then changes a copy nobody queries.
The fix is a two-step check, which we ran on `mozilla.org`.

**Step 1: find who answers for the domain.** An NS lookup (or our
[nameserver guide](/blog/how-to-find-a-domains-nameservers)) shows that
`mozilla.org` is delegated to four Akamai servers, `ns1-240.akam.net`
among them. That's where any edit has to happen. `ns1-240.akam.net` resolves
to `193.108.91.240`.

**Step 2: ask that server directly.** In the [DNS Lookup](/dns-checker) we
typed `mozilla.org`, kept record type **A**, set the resolver to
**Custom IP** with `193.108.91.240` and pressed **Run lookup**:

![The DNS Lookup querying mozilla.org's A record at the custom resolver 193.108.91.240 (Akamai's ns1-240.akam.net) from Europe / Lithuania: NOERROR, 1 record, address 35.190.14.201, resolve time 8 ms](/blog/how-to-check-dns-records-result.webp)

The authoritative server answered `NOERROR` in 8 ms with **one record:
35.190.14.201**. The result line names the server that answered
(`resolver 193.108.91.240:53`), so there's no doubt you're looking at the
source and not a cache. Cloudflare's and Google's resolvers returned the
same address (see the command line section).

**The answer:** the source and the public resolvers agree, so nothing is
stale for this domain. For your own domain, read the two answers like this:

| Authoritative server says | Public resolver says | What it means |
| --- | --- | --- |
| New value | New value | Done. Anyone still seeing the old one has a local cache. |
| New value | Old value | The edit worked; the resolver's cache expires within the old TTL. |
| Old value | Old value | The edit didn't reach the provider your NS records point to. Edit the zone there. |
| No such record | Anything | The record is missing at the source, often a typo in the name field. |

## How to read the results

| What you see | What it means |
| --- | --- |
| **Resolve time** | How long the query took. Green under 50 ms, amber under 200 ms, red above. A cached answer is fast; slow usually means the resolver had to ask upstream. It says nothing about whether the value is right. |
| **Record type chip** | The type you asked for. |
| **NOERROR** (green) | The server answered normally. |
| **NXDOMAIN, ERROR, TIMEOUT** (amber) | No usable answer. For A, AAAA, MX, TXT, NS and CNAME the tool can report NXDOMAIN both when the name doesn't exist and when it exists without that record type; `dig` tells the two apart. |
| **N records** | How many records came back. |
| **resolver …** | Shown when you chose a resolver; absent means the location's own resolver. |
| **Record rows** | The values: `address` for A/AAAA, `host` and `priority` for MX, `value` for TXT and CNAME, `host` for NS, and the full fields for SOA, CAA and SRV. |
| **TTL** | Shown for SOA, CAA, SRV, PTR, TLSA, HTTPS and SVCB records. For A, AAAA, MX, TXT, NS and CNAME the tool shows the values only; use `dig` for the TTL. |
| **Location** | Signed out, the query runs from the WatchFor location nearest you; paid plans can pick any region. |

## More ways to use it

- **Before a migration.** Query the records you're about to change at the
  authoritative server and note them, so you can roll back exactly.
- **Comparing resolvers.** Run the same name against Cloudflare, Google and
  Quad9. If one disagrees, that service still caches the old value; it's not
  your zone.
- **Checking a new provider before switching nameservers.** Point the
  resolver at the new provider's server (Custom IP) and confirm every record
  is there *before* you change the delegation.
- **Reading records that most tools skip.** HTTPS and SVCB records advertise
  HTTP/3 and alternative endpoints; TLSA records pin certificates for DANE.
- **Reverse lookups.** Choose PTR and type an IP to see its hostname, the
  check mail providers run on sending servers.

## Tips and gotchas

- **Edit where the NS records point.** If your registrar's dashboard has a
  DNS editor but your nameservers are elsewhere, edits there do nothing.
- **Authoritative servers only answer for their own zones.** Asking Akamai's
  server about a domain it doesn't host returns a refusal, not a recursive
  answer.
- **TTL decides how long caches hold the old value.** The relevant TTL is the
  one the record had before the change. The
  [propagation guide](/blog/how-to-check-dns-propagation) covers the timing
  across 20 locations.
- **GeoDNS and CDNs answer differently by location.** Different addresses
  from different places can be correct; compare with your provider's
  configuration, not with another lookup.
- **Service names start with an underscore.** Look up `_dmarc.example.com`
  as TXT or `_sip._tcp.example.com` as SRV by typing the full name; the
  [SRV guide](/blog/how-to-check-srv-records) covers service records.

## Check it from the command line too

First the delegation, then the same question to the source and to two public
resolvers:

```bash
dig +short NS mozilla.org
dig +noall +answer @ns1-240.akam.net mozilla.org A
dig +noall +answer @1.1.1.1 mozilla.org A
dig +noall +answer @8.8.8.8 mozilla.org A
```

```text
ns5-65.akam.net.
ns7-66.akam.net.
ns4-64.akam.net.
ns1-240.akam.net.
mozilla.org.		600	IN	A	35.190.14.201
mozilla.org.		132	IN	A	35.190.14.201
mozilla.org.		345	IN	A	35.190.14.201
```

The authoritative server shows the full TTL, 600 seconds. The resolvers show
what's left on their cached copies, 132 and 345 seconds: after a change,
each of them would serve the old address for at most that long. A cached
answer can never outlive the TTL the source published when it was fetched.

To tell "no such name" from "no record of this type", read dig's status line
(`dig mozilla.org TXT` prints `status: NOERROR` with or without answers, and
`NXDOMAIN` only when the name doesn't exist at all).

## Keep watching it

A lookup answers once. A [DNS monitor](/dns-monitoring) resolves the record
on a schedule from several locations, and its **Upstream DNS Resolver**
setting accepts a custom IP such as your authoritative server, to catch a
stale or broken zone before the world does. With the **Expected DNS
Records** rule it opens an incident when the answer stops matching the values
you set; the incident's root cause shows what differed.

## FAQ

**How do I check what DNS records a domain has?**
Look up each type you care about (A, AAAA, MX, TXT, NS, CNAME) at a public
resolver or the domain's nameserver. DNS has no "list everything" query
that servers answer reliably, so tools ask one type at a time. Which record
does what is in [DNS record types explained](/blog/dns-record-types-explained).

**Why do I still see the old DNS record after changing it?**
Either the change was made at a provider your nameservers don't point to, or
a resolver still has the old answer cached. Query your authoritative
nameserver directly: if it shows the new value, wait out the old TTL or
flush your local cache.

**What is an authoritative nameserver?**
The server that holds your zone and answers for it with no cache in front.
The domain's NS records name these servers; every other resolver gets its
answers from them. [How DNS works](/blog/how-dns-works) walks through the
chain.

---

Canonical page: https://watchfor.io/blog/how-to-check-dns-records · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt