How to Check Which DNS Records Your Site Actually Uses

To find out which DNS records a site actually uses, you query the authoritative nameservers directly and read the answers they return. Everything else, including cached lookups from your laptop or a public resolver, is a copy that may be stale, filtered, or rewritten, so the authoritative zone is the only place where the real answer lives. This is the practical version of how to check DNS records for a website: not just "what does my resolver say" but "what does the zone owner publish, and who is allowed to say it."

Start with the delegation, not the record

Before you ask for an A record, find out who is authoritative for the name. The parent zone holds NS records that delegate the domain, and those records are what every resolver follows. Query the parent directly rather than a recursive resolver, because a recursive resolver will happily answer from its cache and hide a recent delegation change.

dig +norecurse @a.root-servers.net example.com NS
dig +norecurse @<tld-nameserver> example.com NS

The first command walks you to the TLD servers, the second asks one of them for the delegation. What you want is the authority section, which lists the NS names, and the additional section, which usually carries their addresses. If the NS set at the parent does not match the NS set at the child, you have found a delegation mismatch, and that alone explains a surprising number of "my change did not take effect" tickets.

Once you have the authoritative nameserver names, query them by name and let the resolver find them, or query their addresses directly with @. Querying by name is safer when the addresses are anycast, because you will reach whichever node the network hands you, and every node in a correct anycast deployment serves the same zone.

Ask the authoritative server with recursion disabled

Recursion is the setting that lets a server chase answers on your behalf. On an authoritative server it should be off. If you send a query with recursion desired and the server answers from its cache instead of its zone, you have learned something important about that server, but you have not learned what the zone contains. Use +norecurse and read the flags in the header.

dig +norecurse @ns1.example.net www.example.com A
dig +norecurse @ns1.example.net example.com MX
dig +norecurse @ns1.example.net example.com TXT

The header tells you most of what you need. aa means the answer is authoritative. rd is what you asked for, ra is what the server is willing to do. If aa is absent on a query sent to a server you believe is authoritative, you are talking to the wrong server or the zone is not loaded there. The ANSWER count tells you how many records came back, and the AUTHORITY section on a negative answer tells you which name holds the SOA that defines the zone.

That SOA record is worth reading every time. Its serial number increments on every zone change, so comparing serials across nameservers is the fastest way to detect a server that has not picked up a transfer. If one nameserver reports a lower serial than another, the zone is out of sync and any audit you run against the lagging server is worthless.

Walk the record types in a fixed order

Auditing a zone means checking every record type that carries traffic, and doing it in the same order every time so you notice what is missing. The set that matters for a typical site is A and AAAA for the apex and for www, CNAME for any aliases, MX for mail routing, TXT for verification and policy records, NS for the zone itself, and CAA for which certificate authorities may issue for the name.

Do not forget the apex. A common and expensive mistake is to point www correctly while the bare domain still holds an old address, so mail and web traffic diverge depending on which name the visitor typed. Query both, and query the MX targets too, because an MX that points at a hostname with no reachable A record is a mail outage waiting for a queue to fill.

for t in A AAAA CNAME MX TXT NS CAA; do
  dig +norecurse +short @ns1.example.net example.com $t
done

The +short flag strips the header and gives you just the data, which is what you want when you are diffing two nameservers. Run the same loop against every authoritative server and compare the output. Any difference is either a transfer in progress or a genuine misconfiguration, and both deserve a look before you touch anything.

Check the resolver path separately

Authoritative answers are the truth about the zone, but your users do not query the zone. They query a recursive resolver, which caches according to the TTL on each record. That means the zone can be perfectly correct while some users still see the old address, and the only way to see what they see is to query the resolver they use.

dig @<resolver-address> www.example.com A
dig +trace www.example.com

The +trace form replays the delegation chain from the root down, printing each step, which is the clearest way to see where a broken chain diverges from what you expect. If the trace stops at a nameserver that does not answer, you have found the failure point without guessing.

Watch the TTL values as you go. A record with a long TTL will sit in caches for a long time after you change it, and lowering the TTL well before a planned change is the standard way to make the change propagate quickly. Raising it back afterward reduces query volume. Neither step requires any special tooling, just discipline about the order of operations.

Read the header, trust the zone

The header flags are not decoration. aa tells you the answer came from the zone. tc tells you the response was truncated and you should retry over TCP, which matters for large TXT sets and for DNSSEC responses. ad tells you the resolver validated the chain, and its absence on a signed zone is a signal worth investigating rather than ignoring.

If you want the full picture in one pass, ask for ANY against the authoritative server. Many servers refuse it or return a minimal set, and relying on it is a bad habit, but as a first look it can save you a handful of queries. Follow it with explicit queries for each type you care about, because the explicit query is what you will compare and what you will document.

Next, write down what you found before you change anything. A short text file with the domain, the nameservers, the serial numbers, and the current values of every record type you audited is enough. Take a second copy after the change and diff them. That habit turns a scary DNS edit into a routine one, and it means that when something does break, you already know what the zone looked like when it worked.