Every website, every email and every app you use starts with a question that nobody sees: where does this name actually live? The Domain Name System answers that question billions of times a day, and the answers are stored in small text entries called DNS records. The Tooliqo DNS Records Checker above lets you read those entries for any domain, host name or IP address in a couple of seconds, straight from the public resolvers that the rest of the internet uses. This guide explains what the tool does, how to read its results, and everything worth knowing about DNS records themselves: what each type means, why they exist, how they are checked, where they came from, and how to fix the problems they reveal.
What the DNS Records Checker Does
At its simplest, the DNS Records Checker is a free online DNS lookup tool. Type a domain such as example.com, choose the record types you care about, press Check, and the tool queries a public DNS-over-HTTPS resolver for each type and lays the answers out in clean, copyable groups. It is the same information a command-line administrator would get from dig or nslookup, presented for people who would rather not open a terminal, and enriched with the context those commands leave out.
What makes it more than a basic DNS lookup is the amount of interpretation it does for you:
- Seventeen record types: the seven everyday types (A, AAAA, CNAME, MX, NS, TXT, SOA) are always one click away, and ten more (SRV, CAA, PTR, DS, DNSKEY, HTTPS, SVCB, TLSA, NAPTR, RRSIG) sit behind a "More types" button so the interface stays small until you need them.
- Two independent resolvers: Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1). If one cannot be reached, the tool silently retries the other, so a blocked endpoint never leaves you without an answer. Switching resolvers on purpose is also the quickest way to compare how a change is propagating.
- Structured parsing: an MX record is shown with its priority and mail server separated; an SOA record is broken into primary server, administrator email, serial number and timers; TXT records are unquoted and tagged as SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI or site verification; DNSSEC keys are labelled KSK or ZSK with their algorithm names.
- Human-readable TTLs: every record shows its time-to-live both as raw seconds and as a readable duration, so
86400reads as "1d" without mental arithmetic. - Input that forgives you: paste a full URL, an email address, a host with a port, an internationalised domain in Arabic or Chinese, or a raw IP address. The tool normalises it, converts non-Latin names to punycode, and turns IP addresses into a reverse (PTR) lookup automatically.
- DNSSEC and response flags: each result shows whether the answer was DNSSEC-validated by the resolver, whether it was truncated, and whether the answers followed a CNAME chain.
- Copy and export: one-click copy for any value or any group, plus "Copy all" as text, "Copy JSON" for scripts and "Copy zone file" in standard BIND format.
- Six languages and full screen: English, Spanish, French, Arabic (right-to-left), Chinese and Hindi, with a fullscreen mode for long result lists.
Nothing is stored. The tool keeps no cookies, no local storage and no account. The only data that leaves your browser is the name you look up, sent to the resolver you selected, exactly as it would be if you typed the address into your browser.
How to Check DNS Records Step by Step
- Enter a name. Type a domain (
example.com), a host (mail.example.com), a service name (_dmarc.example.com) or an IP address. Full URLs and email addresses are accepted; the tool keeps only the host part. - Pick record types. The common seven are preselected. Use Common, All or None to change the selection quickly, or open More types for the specialised ones. If you enter an IP address the selection is ignored and a PTR lookup runs instead.
- Choose a resolver (optional). Google or Cloudflare. Both are worldwide anycast services; both validate DNSSEC. Keep the default unless you are comparing propagation.
- Press Check or hit Enter. All selected types are queried at the same time; a progress counter shows how many have answered.
- Read the summary line: the queried name, the number of records, the total response time, the DNSSEC status and the resolver that answered.
- Open the groups. Records are grouped by type in a fixed order (A, AAAA, CNAME, MX, NS, TXT, SOA, then the rest). Each row shows the owner name, the TTL and the data, followed by parsed fields where they add meaning.
- Copy what you need. The small copy button next to each value copies just that value; the button in a group header copies every value in the group; the toolbar exports everything.
Recent lookups appear as small chips under the form for the rest of your visit, so switching between two domains during a migration is a single click. Escape clears the input, and pressing it again clears the results.
What you can type
| You type | What the tool looks up | Why it helps |
|---|---|---|
example.com | example.com | The apex or "root" domain, where NS, SOA, MX and most TXT records live. |
https://www.example.com/pricing?x=1 | www.example.com | Paste a link from your browser bar; scheme, path and query are stripped. |
Example.COM. | example.com | DNS names are case-insensitive; the trailing dot is the formal root and is removed for display. |
admin@example.com | example.com | Check the mail domain of an address without retyping it. |
_dmarc.example.com | _dmarc.example.com | Underscore labels are where DMARC, DKIM selectors and SRV services are published. |
mañana.com | xn--maana-pta.com | Internationalised names are converted to punycode; both spellings are shown with copy buttons. |
8.8.8.8 | 8.8.8.8.in-addr.arpa (PTR) | Reverse DNS: find the host name registered for an IPv4 address. |
2001:4860:4860::8888 | the 32-nibble ip6.arpa name (PTR) | Reverse DNS for IPv6, with the address expanded correctly. |
What DNS Is, and Why Records Matter
Computers find each other with numbers. A web server has an IP address such as 93.184.216.34 or 2606:2800:21f:cb07:6820:80da:af6b:8b2c; humans prefer example.com. The Domain Name System is the distributed, hierarchical database that maps the names we remember to the numbers machines need, plus a growing set of other facts about a domain: which servers accept its email, which certificate authorities may issue its TLS certificates, which cryptographic keys sign its data, and where a given service can be found.
Each of those facts is a resource record. A record has an owner name, a class (almost always IN for Internet), a type, a time-to-live and type-specific data. When you "check DNS records" you are reading those entries as a resolver on the public internet sees them at that moment.
How a DNS lookup actually travels
When your browser needs www.example.com, it asks a recursive resolver, usually the one run by your ISP, your company, or a public service like 8.8.8.8 or 1.1.1.1. If the resolver has a fresh answer cached, it replies immediately. If not, it walks the hierarchy from the top:
- It asks a root server which servers are responsible for
.com. There are thirteen root server identities (named A through M) operated by twelve organisations, served today from well over a thousand anycast locations around the world. - It asks a
.comTLD server which name servers are authoritative forexample.com. That referral is where the domain's NS records come from. - It asks one of the domain's authoritative name servers for the actual record. That server holds the zone file the domain owner or DNS provider maintains.
- It caches the answer for as long as the record's TTL allows and returns it to your browser.
The DNS Records Checker sits at the first step of that path. It asks a recursive resolver, not the authoritative server directly, which is a deliberate choice: what a public resolver returns is what real visitors experience, including caching. When you need the authoritative answer alone, look up the NS records, then query those servers with dig @ns1.example.com from a terminal. The two views normally agree; when they disagree, you are watching propagation in progress.
A short history of the Domain Name System
Before DNS, the entire internet fit in one text file. Through the 1970s and early 1980s, the Network Information Center at SRI International maintained HOSTS.TXT, a list of every host name and address on the ARPANET, curated by Elizabeth "Jake" Feinler's team. Administrators downloaded the file over FTP, sometimes several times a week. As the network grew from dozens of machines to thousands, the file became a bottleneck: names collided, updates lagged, and the transfer load on a single server became untenable.
In 1983, Paul Mockapetris at the University of Southern California's Information Sciences Institute designed a replacement that pushed responsibility outward. Instead of one file, there would be a tree of zones, each managed by whoever owned it, with caching everywhere. He published the design as RFC 882 and RFC 883 in November 1983 and wrote the first implementation, JEEVES. The specifications were reworked into RFC 1034 and RFC 1035 in 1987, and those two documents still define the core of DNS more than thirty-five years later, including the record types A, NS, CNAME, SOA, PTR, MX and TXT that the checker shows first.
Some milestones worth knowing when you read modern records:
| Year | Milestone | What it changed |
|---|---|---|
| 1983 | RFC 882/883 define DNS | Distributed naming replaces the central HOSTS.TXT file. |
| 1985 | First generic TLDs go live; symbolics.com registered on 15 March | .com, .org, .net, .edu, .gov and .mil become the first namespaces. |
| 1986 | RFC 974 defines MX records | Email routing gains its own record type with priorities. |
| 1987 | RFC 1034/1035 | The definitive DNS specification; BIND becomes the reference server. |
| 1995 | AAAA records (RFC 1886, later RFC 3596) | IPv6 addresses get a home in DNS. |
| 1998 | RFC 2308 negative caching | The SOA minimum field becomes the TTL for "no such record" answers. |
| 1999 | EDNS0 (RFC 2671, later RFC 6891) | Larger UDP answers and the flags DNSSEC needs. |
| 2000 | SRV records (RFC 2782) | Service discovery with priority, weight and port. |
| 2003 | IDNA and Punycode (RFC 3490/3492) | Domain names in Arabic, Chinese, Cyrillic and other scripts. |
| 2005 | DNSSEC (RFC 4033-4035) | Cryptographic signatures: DNSKEY, DS, RRSIG, NSEC. |
| 2008 | The Kaminsky cache-poisoning disclosure | Emergency patches worldwide; DNSSEC adoption accelerates. |
| 2010 | The root zone is signed (15 July) | A complete chain of trust from the root down becomes possible. |
| 2013 | CAA records (RFC 6844, updated by RFC 8659 in 2019) | Domain owners can restrict which CAs may issue certificates; mandatory CA checks since September 2017. |
| 2016 | DNS over TLS (RFC 7858); the Dyn attack (21 October) | Encrypted transport arrives; a botnet takes major sites offline by attacking their DNS provider. |
| 2018 | DNS over HTTPS (RFC 8484); Cloudflare launches 1.1.1.1 | Browsers and web tools, including this checker, can query resolvers over HTTPS. |
| 2023 | SVCB and HTTPS records (RFC 9460) | A record that advertises HTTP/3, ECH and IP hints before the first connection. |
| 2024 | Google and Yahoo enforce sender authentication | SPF, DKIM and DMARC records become a practical requirement for anyone sending mail at volume. |
Why does this history matter to a person checking a TXT record in 2026? Because almost every oddity you will meet is an artefact of it: the 63-character label limit and 255-character name limit come from 1987 packet economics; TXT records are split into 255-byte strings for the same reason; the quoted-string format the checker unwraps was designed for zone files typed by hand; and the reason SPF lives in TXT rather than its own type is that a dedicated SPF type (99) was tried in 2006 and abandoned in 2014 because too few resolvers and registrars supported it.
DNS Record Types Explained
The table below is the quick reference. The sections after it go deeper into the types people check most, with the exact fields the DNS Records Checker parses for each.
| Type | Full name | What it holds | Typical reason to check it |
|---|---|---|---|
| A | Address | An IPv4 address | Is the site pointing at the right server? |
| AAAA | IPv6 address | An IPv6 address | Does the site work for IPv6-only networks? |
| CNAME | Canonical name | An alias to another name | Where does www or a CDN host really go? |
| MX | Mail exchanger | Mail server and priority | Why is email bouncing or going to the wrong provider? |
| NS | Name server | Authoritative servers for the zone | Did the name-server change at the registrar take effect? |
| TXT | Text | Free-form text: SPF, DKIM, DMARC, verification tokens | Email authentication and domain-ownership checks. |
| SOA | Start of authority | Zone metadata: primary server, admin contact, serial, timers | Has the zone been updated? Are secondaries in sync? |
| SRV | Service | Priority, weight, port and target for a service | SIP, XMPP, LDAP, Minecraft, Microsoft 365 autodiscover. |
| CAA | Certification authority authorization | Which CAs may issue certificates | Certificate issuance failing unexpectedly. |
| PTR | Pointer | The host name for an IP address | Reverse DNS for mail servers and audits. |
| DS | Delegation signer | Hash of a child zone's key, published in the parent | Is DNSSEC correctly delegated from the TLD? |
| DNSKEY | DNS public key | The zone's signing keys (KSK and ZSK) | Key rollovers and DNSSEC troubleshooting. |
| RRSIG | Resource record signature | A signature over a record set, with validity dates | Expired signatures cause SERVFAIL for validating resolvers. |
| HTTPS / SVCB | Service binding | ALPN (HTTP/2, HTTP/3), IP hints, ECH configuration | Modern CDN setups and apex aliasing. |
| TLSA | TLS association (DANE) | Certificate or key fingerprints bound to a port | DANE-protected mail transport. |
| NAPTR | Naming authority pointer | Regex-based rewriting rules | ENUM telephony and SIP discovery. |
A and AAAA records: where the site lives
An A record maps a name to an IPv4 address; an AAAA record maps it to an IPv6 address. A name may have several of each, in which case clients choose among them (round-robin) and modern browsers race IPv6 and IPv4 connections against each other. When a site is behind a CDN you will typically see two or more A records that change from one lookup to the next; that is normal. What is not normal is a mismatch between the A record and where you think the site is hosted, which is the single most common cause of "my site shows the old server" reports after a migration.
In the checker, the A group also shows records that arrived as part of a CNAME chain. If you look up www.example.com and it is an alias for example.com, the resolver returns both the CNAME and the final A records; the tool groups each by its real type, shows the owner name on every row so you can see which name each address belongs to, and adds a note that the answers followed a CNAME chain.
CNAME records: aliases and their rules
A CNAME says "this name is an alias; go look at that name instead". It is how www.example.com points at example.com, how shop.example.com points at a hosted commerce platform, and how CDNs take over a host name. Two rules trip people up. First, a name with a CNAME cannot have any other record type, so you cannot put a CNAME at the zone apex (example.com itself) because the apex must hold SOA and NS records. Providers work around this with "ALIAS" or "ANAME" flattening, or with the newer HTTPS record. Second, MX and NS records should point at names with A/AAAA records, not at CNAMEs; many mail servers reject CNAME targets outright.
MX records: how email finds the mailbox
An MX record names a mail server willing to accept email for the domain, together with a priority number; lower numbers are tried first, and equal numbers share the load. A typical Google Workspace domain has a single smtp.google.com entry; a Microsoft 365 domain has one mail.protection.outlook.com host; self-hosted domains often list a primary and a backup. The checker sorts MX records by priority and shows the exchange host without the trailing dot, ready to paste.
When email breaks, check MX first, then the A record of each MX host, then the TXT records for SPF and DMARC. A domain with no MX record falls back to its A record, which is legal but almost always an accident.
TXT records: SPF, DKIM, DMARC and verification tokens
TXT records began as a place for free-form notes and became the workhorse of the modern zone. Today they carry the three email-authentication standards and dozens of ownership tokens. The checker unquotes each TXT record, joins strings that were split for length, and tags the ones it recognises:
| Tag | Record starts with | Published at | What it does |
|---|---|---|---|
| SPF | v=spf1 | the domain apex | Lists the servers allowed to send mail from the domain (RFC 7208). |
| DKIM | v=DKIM1 | selector._domainkey.example.com | Publishes the public key that verifies signatures on outgoing mail (RFC 6376). |
| DMARC | v=DMARC1 | _dmarc.example.com | Tells receivers what to do when SPF and DKIM fail, and where to send reports (RFC 7489). |
| MTA-STS | v=STSv1 | _mta-sts.example.com | Signals that a TLS policy for inbound mail is published over HTTPS. |
| TLS-RPT | v=TLSRPTv1 | _smtp._tls.example.com | Where to send reports about failed TLS connections. |
| BIMI | v=BIMI1 | default._bimi.example.com | Points to the brand logo shown next to authenticated mail. |
| Site verification | google-site-verification=, MS=, and many others | the apex | Proves domain ownership to a service such as Search Console or Microsoft 365. |
Since February 2024, Google and Yahoo require every sender to publish SPF or DKIM, and require bulk senders to publish DMARC as well; Microsoft followed with similar rules for Outlook.com in 2025. In practice this means a domain that sends any meaningful amount of email now needs three records: an SPF record with at most ten DNS-lookup mechanisms, at least one DKIM selector, and a DMARC record with a policy (p=none to monitor, p=quarantine or p=reject to enforce). The checker makes the audit a single lookup: query the apex for TXT and read the SPF tag; query _dmarc.example.com and read the DMARC tag; query selector._domainkey.example.com once you know the selector your provider uses.
NS records: who is in charge of the zone
NS records list the authoritative name servers for a domain. They appear in two places: in the parent zone (the delegation at the registry, which is what your registrar sets) and inside the zone itself. The two should match. When you move DNS hosting, the delegation is what changes, and the TLD's TTL for it is typically 24 to 48 hours, which is where the "up to 48 hours to propagate" folklore comes from. Checking NS with the tool shows you the resolver's current view; if it still lists the old provider, the change either has not been made at the registrar or is still cached.
SOA records: the zone's identity card
Every zone has exactly one SOA record. It looks cryptic in raw form, so the checker splits it into its seven fields:
| Field | Example | Meaning |
|---|---|---|
| Primary server (MNAME) | ns.icann.org | The name server that holds the master copy of the zone. |
| Admin email (RNAME) | noc@dns.icann.org | Stored as noc.dns.icann.org; the first dot stands for @. The tool converts it back. |
| Serial | 2024081419 | Increases with every change. Many zones use YYYYMMDDnn; the tool decodes that as a date and revision. |
| Refresh | 7200 (2h) | How often secondary servers check for a new serial. |
| Retry | 3600 (1h) | How long a secondary waits after a failed refresh. |
| Expire | 1209600 (14d) | How long a secondary keeps serving the zone if the primary is unreachable. |
| Minimum TTL | 3600 (1h) | Since RFC 2308, the cache time for negative answers ("no such name"). |
Two practical uses: comparing the serial across resolvers tells you whether a change has reached all secondaries, and a very large minimum TTL explains why a newly created record "does not exist" for an hour after you added it.
CAA records: who may issue your certificates
A CAA record has three parts: a flags byte (0, or 128 for "critical"), a tag (issue, issuewild or iodef) and a value. 0 issue "letsencrypt.org" allows Let's Encrypt to issue certificates for the domain and its subdomains; 0 issue ";" forbids everyone. Since September 2017 every publicly trusted certificate authority must check CAA before issuing, so a stray record copied from an old provider is a classic reason an SSL renewal suddenly fails. If the domain has no CAA record at all, any CA may issue, which is the default for most sites.
SRV records: services with ports
SRV records live at names like _sip._tcp.example.com and carry four numbers and a target: priority, weight, port and host. They let a client discover where a service runs without hard-coding a port, which is why Microsoft 365, SIP telephony, XMPP chat, LDAP directories and even Minecraft servers rely on them. The checker sorts them by priority and then weight and labels each field.
PTR records and reverse DNS
A PTR record maps an IP address back to a name. IPv4 addresses are reversed and placed under in-addr.arpa (8.8.8.8 becomes 8.8.8.8.in-addr.arpa; 192.0.2.1 becomes 1.2.0.192.in-addr.arpa). IPv6 addresses are expanded to 32 hexadecimal digits, reversed digit by digit and placed under ip6.arpa, which is why the name for 2001:4860:4860::8888 is 32 labels long. The checker builds these names for you, shows the constructed name with a copy button, and queries PTR directly. Reverse DNS matters most for outbound mail servers: many receivers reject or penalise mail from an IP whose PTR does not exist or does not match the sending host name, a check known as forward-confirmed reverse DNS.
DNSSEC records: DS, DNSKEY and RRSIG
DNSSEC adds digital signatures to DNS so a resolver can prove an answer was not forged. A zone publishes its public keys in DNSKEY records, signs each record set with an RRSIG, and asks its parent zone to publish a DS record containing a hash of its key-signing key. That DS record is the link in the chain of trust that runs from the root, through the TLD, to the domain.
The checker decodes the pieces: DNSKEY flags become "257 (KSK)" or "256 (ZSK)"; algorithm numbers become names such as ECDSAP256SHA256 or ED25519; DS digest types become SHA-256 or SHA-384; RRSIG timestamps become readable UTC dates. The summary line also reports the resolver's verdict: DNSSEC: validated means the resolver set the Authenticated Data flag on every answer, which happens only when the whole chain checks out. An unsigned domain shows "not validated", which is not an error. A signed domain that suddenly returns SERVFAIL from both resolvers usually has an expired RRSIG or a DS record that no longer matches its DNSKEY, a situation the RRSIG expiry field makes obvious.
HTTPS and SVCB records: the newest arrivals
Standardised in 2023, HTTPS records let a domain announce, before the first connection, that it supports HTTP/2 and HTTP/3, which IP addresses to try, and the Encrypted Client Hello configuration to use. They also solve the CNAME-at-apex problem: an HTTPS record at example.com can point browsers to a CDN host. Large CDNs publish them for every customer, so you will increasingly see them when you open "More types". The checker shows the priority, the target and the parameters as published.
Reading TTL and Understanding Propagation
Time-to-live is the number of seconds a resolver may keep a record before asking again. It is set per record by the zone owner and counts down in every cache that holds a copy, so the value you see from a public resolver is often lower than the value in the zone file; that is the remaining lifetime of the cached copy, not a mistake. "DNS propagation" is simply the time it takes for every cache in the world to expire its old copy.
| TTL | Readable | Typical use |
|---|---|---|
| 60 to 300 | 1m to 5m | Records you are about to change; failover and load-balanced services. |
| 3600 | 1h | The most common default for A, AAAA, MX and TXT records. |
| 14400 | 4h | A frequent cPanel and shared-hosting default. |
| 86400 | 1d | Stable records: NS, SOA, DNSKEY. |
| 172800 | 2d | The TTL most TLDs apply to delegations, the origin of "48 hours to propagate". |
The practical rule for any planned change: lower the TTL to 300 at least one old-TTL period before the change, make the change, verify it with the DNS Records Checker on both resolvers, then raise the TTL again once everything is stable. Because Google and Cloudflare keep separate caches, seeing the new value from one and the old from the other is the clearest evidence that propagation is under way rather than broken.
Reading the Response: Status Codes and Flags
A DNS answer carries a response code and several flags. The checker turns them into plain language, but knowing the originals helps when you compare with other tools:
| Code or flag | Shown as | Meaning |
|---|---|---|
| NOERROR with no answer | No records found | The name exists but has no record of that type. Common for AAAA and CAA. |
| NXDOMAIN | This domain does not exist | The name is not registered, is misspelled, or the subdomain was never created. |
| SERVFAIL | The DNS server failed to answer | The authoritative servers are down or unreachable, or DNSSEC validation failed. |
| REFUSED | The DNS server refused the query | The server is not configured to answer for that zone; often a lame delegation. |
| AD flag | DNSSEC: validated | The resolver verified the signature chain. |
| TC flag | answer truncated | The answer was too large for the transport and may be incomplete. |
When, Where and Why to Check DNS Records
People reach for a DNS lookup tool at very specific moments. These are the scenarios that account for almost all of them, with the record types that answer each one.
| Situation | Check these | What you are looking for |
|---|---|---|
| Website moved to a new host | A, AAAA, CNAME | The new IP on both resolvers; old values mean caching or an unsaved change. |
| Changed DNS provider | NS, SOA | The new name servers; a serial number that matches the new provider's zone. |
| Email not arriving | MX, then A of the MX host | A valid, reachable mail server at priority order you expect. |
| Email landing in spam | TXT (SPF, DMARC), DKIM selector, PTR of the sending IP | All three authentication records present and aligned; forward-confirmed reverse DNS. |
| SSL certificate will not issue | CAA, A | No CAA record blocking your CA; the A record pointing at the server requesting the certificate. |
| Verifying ownership for a service | TXT at the apex | The exact token the service asked for, with no stray quotes or spaces. |
| Setting up a CDN or hosted platform | CNAME, HTTPS | The alias pointing at the provider's host; HTTPS records where the provider publishes them. |
| DNSSEC troubleshooting | DS, DNSKEY, RRSIG | A DS that matches the KSK; signatures not yet expired. |
| Security review of a domain | All types, especially CNAME and TXT | Dangling CNAMEs to abandoned services (subdomain takeover risk), forgotten verification tokens, overly broad SPF. |
| Identifying an IP address | PTR | The host name and often the organisation behind an address in your logs. |
Where you check matters as much as what you check. A lookup from your own computer reflects your ISP's cache and possibly a hosts-file override; a lookup through Google or Cloudflare reflects what most of the world sees. Running the checker before and after a change, from a public resolver, is the closest thing to a neutral witness you can get without logging into ten servers.
Internationalised Domain Names and Punycode
DNS itself only understands ASCII letters, digits and hyphens. To allow names in other scripts, IDNA encodes each non-ASCII label with the Punycode algorithm (RFC 3492) and prefixes it with xn--. The Arabic test domain مثال.إختبار is stored as xn--mgbh0fb.xn--kgbechtv; the Japanese 例え.テスト becomes xn--r8jz45g.xn--zckzah; mañana.com becomes xn--maana-pta.com. The DNS Records Checker performs the conversion in your browser, queries the ASCII form, and shows both spellings with copy buttons so you can paste the punycode into a registrar or a certificate request. It also decodes xn-- names that appear in answers back to their readable form.
Two cautions: mixed-script names are frequently used for phishing (a Cyrillic "а" is not a Latin "a"), so an unexpected xn-- form in a familiar-looking name deserves suspicion; and Punycode is case-insensitive only after IDNA's normalisation step, which the tool applies before encoding.
DNS over HTTPS and Why the Checker Uses It
Classic DNS travels over UDP port 53 in plain text, which is fine for a server but impossible for a web page: browsers cannot open raw sockets. DNS over HTTPS wraps the same queries in ordinary HTTPS requests, which any page can make. Google Public DNS has offered a JSON API for this since the early days of its service, and Cloudflare launched 1.1.1.1 with the same capability in 2018. The checker sends each query to one of those endpoints, receives a JSON answer with the status, flags and records, and renders it. If the primary endpoint is unreachable it retries the same provider by IP address, then the other provider, so a corporate firewall that blocks one hostname rarely blocks the whole tool.
Privacy works in your favour here. The resolver learns only the name you typed, the same way it would if you visited the site. Nothing about the lookup is recorded by Tooliqo, and the tool has no account, no cookie and no storage of any kind; the "recent" chips vanish when you leave the page.
Troubleshooting Guide
| Symptom in the checker | Most likely cause | What to do |
|---|---|---|
| A record shows the old IP on one resolver only | Cached copy still within its TTL | Wait for the TTL to expire; compare the TTL countdown on both resolvers. |
| NXDOMAIN for a subdomain you just created | Negative caching from an earlier failed lookup | Wait for the SOA minimum TTL, or query the other resolver which may not have cached the failure. |
| SERVFAIL on a signed domain | Expired RRSIG or mismatched DS | Check RRSIG expiry dates; compare the DS at the parent with the DNSKEY in the zone. |
| MX points at a CNAME | Provider misconfiguration | Point MX at a host with A/AAAA records. |
| Two SPF records | A second v=spf1 added instead of edited | Merge into a single record; multiple SPF records fail validation. |
| CAA present but your CA is not listed | Record inherited from an old setup | Add an issue entry for your CA or remove the record. |
| PTR missing for a mail server | Reverse zone is managed by the IP owner | Ask your hosting or ISP to set the PTR; it cannot be set in your own zone. |
| Could not reach the DNS resolver | A firewall, extension or filtering DNS blocks DoH endpoints, or the page runs in a sandboxed preview | Open the page normally, disable the blocker, or use the other resolver. |
Exporting Results: Text, JSON and Zone Files
The three export buttons serve three audiences. Copy all produces a readable text report with a header, one group per type and one line per record, ideal for pasting into a ticket or an email to a client. Copy JSON produces a structured document with the query, the resolver used, the DNSSEC status, the elapsed time, every record with name, type, TTL, raw data and parsed value, and the status of each query, which scripts and monitoring tools can consume directly. Copy zone file produces lines in the BIND master-file format that every DNS server and most hosting control panels accept:
example.com. 3600 IN A 93.184.216.34example.com. 3600 IN MX 10 mail.example.com.example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
That last format is the one to keep before any migration: it is a complete snapshot of the records you looked up, and re-importing it restores them exactly.
Add the DNS Records Checker to Your Own Website
Run a hosting blog, a web-agency site, a developer wiki or a support page where a DNS tool would earn its place? You're welcome to embed the Tooliqo DNS Records Checker directly. It's fully self-contained, works in all six site languages, adapts to any screen from a narrow sidebar to a full page, and won't interfere with your page's own styling. Pick whichever of the two methods suits your platform, paste the snippet where you want the tool to appear, and you're done.
Note: this embed code is meant to be shared. It is valid for every platform and every website, Blogger, WordPress, Squarespace, Ghost, Wix, Google Sites or hand-written HTML, and it can be placed anywhere you like: inside a post, on a page, in a sidebar widget or a footer.
Method 1 — Direct iframe (best for Blogger posts and pages)
The most reliable option for Blogger and most content platforms. Drop this into the HTML view of your post exactly where the checker should sit. The allowfullscreen attribute keeps the built-in fullscreen button working inside the frame, and clipboard-write keeps the copy buttons working.
<iframe data-tooliqo src="https://tools.tooliqo.co/DNS-Records/?lang=en"title="Tooliqo — DNS-Records"style="width:100%;border:0;height:820px" height="820" loading="lazy" scrolling="no"allowfullscreen allow="fullscreen; clipboard-write"></iframe><script src="https://tools.tooliqo.co/embed.js" async></script>
Method 2 — Lightweight embed script
If your platform allows external scripts, this drop-in version keeps the tool sized automatically as results grow and shrink, and is the tidier choice for full themes. Place the div where you want the checker, and the script does the rest.
<div class="tooliqo-tool" data-tool="DNS-Records" data-lang="en"data-height="680"></div><script src="https://tools.tooliqo.co/embed.js" async></script>
To load the checker in another language, simply swap the language code — en, fr, es, zh, hi, or ar — in whichever snippet you choose. The Arabic version switches to a right-to-left layout automatically.
Frequently Asked Questions
Is the DNS Records Checker free?
Yes, completely. There is no sign-up, no limit on lookups for normal use and no data collection. The tool runs in your browser and talks only to the public resolver you choose.
How is this different from dig or nslookup?
It asks the same questions of the same resolvers. The difference is presentation: parsed fields, tagged TXT records, readable TTLs, DNSSEC and truncation flags shown in words, sorted MX and SRV entries, automatic punycode and reverse-name construction, and one-click exports. For scripted work or authoritative-only queries, dig remains the right tool.
Why do I see different answers on Google and Cloudflare?
Each resolver keeps its own cache. After a change, one may still hold the old value until its copy's TTL runs out. Different answers are the normal signature of propagation, not a fault in either service.
Why does a lookup say "No records found" when I just added the record?
Either the change has not been published by your DNS provider yet, or a resolver cached a negative answer earlier. Negative answers are kept for the SOA minimum TTL, commonly an hour. Try the other resolver, and check the SOA serial to confirm the zone actually changed.
Can I check DNS records for a subdomain?
Yes. Type the full host name, such as blog.example.com or _dmarc.example.com. Subdomains have their own records and can even be delegated to different name servers, which the NS lookup will reveal.
What does "DNSSEC: not validated" mean?
Most often that the domain is not signed at all, which is still the case for the majority of domains. It becomes a concern only if you know the domain is signed; then it points to a broken chain of trust that a validating resolver would eventually reject with SERVFAIL.
Can I look up an IP address?
Yes. Enter any IPv4 or IPv6 address and the tool performs a reverse lookup, building the correct in-addr.arpa or ip6.arpa name and querying its PTR record. The constructed name is shown with a copy button.
Does the tool show DNS propagation from many countries?
It shows the view of two global anycast resolvers, each of which answers from the location nearest to you. That is the view most of your visitors get. For a country-by-country map you would need probes in each country, which is a different kind of service; for practical migration work, comparing two independent resolvers over time answers the question that matters: has the change reached the caches most people use?
Which record types should a new website have?
At minimum an A record (and ideally AAAA) for the apex and www, NS and SOA records from your DNS provider, MX records if the domain receives email, and TXT records for SPF and DMARC plus a DKIM selector if it sends email. Add a CAA record once your certificate setup is stable.
Can I embed the checker on my own site?
Yes. Use either snippet in the section above. The tool adapts to its container, supports six languages, reports its own height to the embedding page, and never touches the host page's styles.
Glossary
| Term | Meaning |
|---|---|
| Apex (root domain) | The domain itself, example.com, as opposed to a host under it. |
| Authoritative server | A name server that holds the zone and gives definitive answers for it. |
| Recursive resolver | A server that finds answers on behalf of clients and caches them. |
| Zone | The portion of the namespace managed as a unit, described by one SOA record. |
| Delegation | NS records in a parent zone that hand a subdomain to other servers. |
| TTL | Time-to-live: how long a record may be cached, in seconds. |
| Propagation | The period during which caches worldwide still hold an old value. |
| Anycast | One IP address announced from many locations; queries go to the nearest. |
| DoH | DNS over HTTPS (RFC 8484): DNS queries carried inside HTTPS requests. |
| DNSSEC | Signatures that let resolvers verify DNS answers were not tampered with. |
| KSK / ZSK | Key-signing key (linked from the parent by DS) and zone-signing key (signs the records). |
| Punycode | The encoding that stores non-ASCII domain labels as xn-- names. |
| Lame delegation | NS records pointing at a server that does not actually serve the zone. |
| Dangling CNAME | An alias pointing at a host that no longer exists; a takeover risk. |
Final Thoughts
DNS is forty years old and still the quiet foundation under everything else on the internet. Its records are short, plain and public, yet a single wrong character in one of them can take down a website, silence a mailbox or block a certificate. The DNS Records Checker exists to make those records easy to read: paste a name, see what the world sees, understand every field without a manual, and copy what you need in the format you need. Bookmark it before your next migration, run it whenever email misbehaves, and use the section above to give your own readers the same shortcut.