What is a DNS record?
A DNS record (resource record) is one entry in a zone: an owner name, a type such as A, MX or TXT, a TTL in seconds and the data for that type. Records of the same name and type form an RRset that resolvers fetch from the zone's authoritative servers and cache for the TTL, which is why a change becomes visible only as caches expire.
How to use DNS Record Comparison
- On side A, type a domain name or paste records (for example the zone exported from your current DNS provider).
- On side B, do the same for what you compare against — the new provider's zone, the other resolver, or another name.
- For lookups, choose the record type and the resolver of each side; tick "Ignore owner names" to compare data only.
- Press Compare and work through the rows marked only in A or only in B; the "What was compared" panel shows how each side was read.
DNS Record Comparison features
- Each side is a live lookup (Cloudflare or Google, chosen per side) or pasted records — mix them freely
- Reads dig answer lines, zone-file lines ($ORIGIN, $TTL, @, parentheses, indented continuation lines) and plain dig +short output
- Order-insensitive comparison that ignores letter case, trailing dots, spacing and how TXT strings are split
- One table of every record marked only in A, only in B or in both, downloadable as CSV
- TTL differences listed apart from real differences, with both values
- Two pasted sides are compared entirely in your browser; nothing is sent anywhere
Inputs and outputs
Inputs
- Side A and side B — each either one domain name (looked up) or pasted records (dig output, zone-file lines or dig +short output).
- Record type for lookups — the type asked for on any side that is a domain name (A by default); with a lookup on one side, the pasted side is compared for that type and CNAME only.
- Resolver for side A / side B — Cloudflare 1.1.1.1 or Google Public DNS, so the same name can be compared across two resolvers.
- Ignore owner names — compare type and data only; applied automatically when names cannot match.
Outputs
- Summary — the result (= or ≠), how many records are only in A, only in B and in both, and how many shared records differ only in TTL.
- Records — every distinct record with its type, name, data, presence on each side and both TTLs.
- Findings — the comparison verdict, TTL differences, records set aside, and why owner names were ignored.
- What was compared — how each side was read: the lookup and its response code, or the number of pasted records and any lines that could not be read.
DNS Record Comparison example
Two exports of the same zone before a move
Input:
Side A: example.com. 3600 IN MX 10 mail1.example.net. · example.com. 3600 IN MX 20 mail2.example.net. · example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
Side B: the same, with MX 20 at TTL 1800 and the SPF ending in ~allOutput:
Result: ≠ · Only in A: 1 · Only in B: 1 · In both: 2 · TTL differences: 1
TXT "v=spf1 include:_spf.example.net -all" in A only
TXT "v=spf1 include:_spf.example.net ~all" in B only
Findings: 1 record only on side A (TXT), 1 only on side B (TXT), 2 in common. 1 record on both sides with a different TTL: MX 20 mail2.example.net (3600 s vs 1800 s).How to read the DNS Record Comparison results
"=": both sides hold the same records. A TTL difference alone on two lookups is cache age; on two zone files it is a real configuration difference.
"Only in A" rows are records side B lacks (to create on the new provider, for example); "only in B" rows are records side A lacks (to remove, or to add on the old side).
A difference inside a quoted TXT value — such as -all against ~all in SPF — is a real policy change, not formatting.
Lines reported as "not understood" were not compared; check them, because a missed line can hide a missing record.
When to use DNS Record Comparison
- Before switching nameservers: compare the zone at the new DNS provider with the old one, record by record.
- Comparing what Cloudflare and Google resolvers return for the same name during a change.
- Checking that a staging host and its production counterpart (www vs www-staging) carry the same records.
- Reviewing a zone-file change in a pull request against what is live.
Troubleshooting
- Everything shows as different although the records match: one side may hold relative names; add a $ORIGIN line to the pasted text or tick "Ignore owner names".
- Lines reported as "not understood": each line needs a record type (A, MX, TXT…) between the owner/TTL/class and the data; dig +short output is accepted only when no line has a type.
- A side meant as a lookup is read as pasted text: a lookup side must contain exactly one domain name and nothing else.
- Records of other types disappear: when one side is a lookup, only the selected type (and CNAME) is compared; paste both sides to compare whole zones.
Frequently asked questions about DNS Record Comparison
What can I put on each side?
Either one domain name, which is looked up live with the record type and the resolver chosen for that side, or pasted records: dig answer lines, zone-file lines (with $ORIGIN, $TTL, @ and parentheses) or plain dig +short output, which is read as the selected record type.
Which differences are ignored?
Order, letter case in host names, trailing dots, spacing outside quotes, IPv6 address spelling and how a long TXT record is split into strings. What is inside a quoted string is compared exactly, and TTLs are listed separately because they usually reflect cache age rather than a change.
Are pasted records sent to a server?
No. When both sides are pasted, the comparison runs entirely in your browser. Only a side that is a domain name causes a lookup, and then only that name and the record type are sent through the Mutqan server to the chosen resolver.
How do I compare my old and new DNS provider before switching nameservers?
Paste the zone export of the new provider on one side and the live domain name on the other — a lookup compares one record type per run — or paste both providers' exports to compare whole zones. Records only in A or only in B are the ones you still have to create or remove.
Why were owner names ignored?
When the two sides look up different names, or one side is a lookup and the other pasted text, owner names cannot match, so only type and data are compared. Tick "Ignore owner names" to do the same for two pasted sets.
Technical notes
Record data is normalised before comparison: addresses to their canonical RFC 5952 / dotted form, host names lower-cased without the final dot, TXT character-strings concatenated and unescaped as RFC 7208 §3.3 does, CAA tag case folded. Inside quoted strings nothing is changed, so "-all" and "~all" stay different.
Pasted text follows the master-file format of RFC 1035 §5: owner, optional TTL and class, type, data; $ORIGIN completes relative names (also inside NS, CNAME, MX, SRV and SOA data), $TTL supplies a default TTL, and parentheses join multi-line records such as SOA. A lookup side returns one RRset from the resolver, including any CNAME chain.
Limitations and methodology
A lookup side asks one record type for one name through one public resolver from the Cloudflare edge; it is a cached view, not the authoritative zone (use the Nameserver Checker for that).
The parser covers the common master-file syntax; $INCLUDE, $GENERATE and TTL units such as 1h are not expanded, and only the first 5,000 lines are read.
DNSSEC signatures (RRSIG) returned by lookups are left out of the comparison.
Security and privacy
Pasted records are parsed in your browser and never sent. A side that is a domain name sends only that name and the record type from the Mutqan server to the resolver chosen for that side; nothing is stored.
References
- RFC 1035: Domain Names - Implementation and SpecificationThe DNS message format, record types and response codes (NOERROR, NXDOMAIN, SERVFAIL, REFUSED) that every resolver still uses.
- RFC 1034: Domain names - concepts and facilitiesThe DNS model: the name space as a tree, zones and delegation, authoritative servers and resolvers, and how a resolver follows referrals and aliases.
- RFC 2181: Clarifications to the DNS SpecificationRules the original DNS RFCs left open: an RRset shares one TTL, TTL limits, and that MX and NS targets must not be aliases (CNAME).