Network

DNS Lookup Guide: Records, TTLs and Troubleshooting

ToolMellow · Updated October 6, 2026

A DNS lookup asks a resolver for a particular record type at a particular name. Use ToolMellow's DNS checker to inspect returned addresses, aliases, mail routes or text records, compare the selected providers, and save a dated observation. Start with the exact DNS name and the record type relevant to your task.

The tool queries Cloudflare and Google Public DNS through the available ToolMellow query locations. Its results describe those requests; they do not establish what every user, device or resolver sees. This guide explains the controls, how to read each result, and what to investigate when a record differs from the value you expected. All example names, addresses and record values below are illustrative, not live measurements.

DNS lookup

How to run a DNS lookup

Open the DNS checker and wait for its connection configuration to load. Enter a name such as www.example.com, select a record type, choose one or both providers, and select the available query location or locations. Press Check DNS to submit the request. Loading the page or editing the name does not automatically look up its records.

Read the provider, location, status and timestamp before interpreting the returned values. If you know the value you need, enter it in the optional expected-value field and choose exact or contains matching. Download DNS report saves the current observation as dns-results.json; keep that file if you need a before-and-after comparison.

Each check uses one DNS name and one record type. Run separate A and AAAA checks when investigating both address families.
The interface defaults to A, both providers and the main ToolMellow location. Available locations come from the current service configuration.
Changing the name, record type, provider or location clears the previous result. Editing the expected value or match mode compares the current result locally.

Choose the DNS record type for your task

DNS records answer different questions. An A lookup is not a request for every record at a domain, and an MX lookup does not send a test email. The selector supports nine types. Expected-value matching supports the eight forward-query types listed below; PTR results can be inspected and downloaded, but their expected-value comparison is unavailable.

Choose the DNS record type for your task
Type	What it contains	Practical interpretation
A	IPv4 address data	Check the returned IPv4 address for the requested name; it does not test the website at that address.
AAAA	IPv6 address data	Check IPv6 separately from A; a working IPv4 destination does not establish that IPv6 works.
CNAME	An alias target name	Inspect the alias and its returned spelling. A DNS alias does not itself create an HTTP redirect.
MX	Mail exchanger preference and target name	Read both preference and hostname. Record presence does not prove successful mail delivery.
TXT	Text carried in DNS	Inspect verification or email-related data at the precise owner name supplied by your provider.
NS	Nameserver names	Inspect returned nameserver data; these names are distinct from the recursive provider selected for the lookup.
SOA	Zone authority metadata	Inspect zone metadata and negative-response context; the query timestamp is not the record's edit time.
CAA	Certificate-authority authorization data	Inspect published authorization data; this is not a certificate or HTTPS validity test.
PTR	A reverse-DNS name pointer	Enter a complete reverse-DNS owner name. Raw IP input and expected-value matching are not supported here.

RFC 1035: DNS implementation and record formats RFC 3596: DNS extensions for IPv6 RFC 8659: Certification Authority Authorization

Enter the right DNS name, including TXT owners and IDNs

Use the DNS owner name, without a URL scheme, path, email address or port. The root domain and its www name are different inputs. A provider's verification instructions may require a subdomain or underscore-prefixed owner; looking up TXT at the root will not automatically find TXT at those other names.

The checker trims surrounding whitespace, recognizes supported Unicode dot variants, removes a final root dot, converts supported internationalized names to ASCII with Node's domainToASCII, and lowercases the query name. It requires at least two labels, each within 63 ASCII characters after conversion, and a total within 253. Ordinary labels allow letters, digits and interior hyphens. Supported underscore-prefixed service labels are accepted, but arbitrary interior underscores are not.

Enter the right DNS name, including TXT owners and IDNs
Illustrative input	Use	Input detail
`example.com`	Root-domain records	Select the type you need; this does not list every type or subdomain.
`www.example.com.`	Records at the www name	The final root dot is accepted and removed from the normalized query.
`_dmarc.example.com`	DMARC-related TXT observation	Choose TXT. This lookup alone does not evaluate complete DMARC policy discovery or message alignment.
`selector._domainkey.example.com`	DKIM-related TXT observation	Replace selector with the selector supplied by your mail service.
`bücher.example`	Internationalized-name input	Supported IDNs are converted to an ASCII-compatible query name; review the normalized name in the result.
`10.113.0.203.in-addr.arpa`	PTR owner-name input	The IPv4 octets are reversed for this illustrative reverse-DNS owner; expected comparison is unavailable.
`https://example.com/path`, `203.0.113.10`, `*.example.com`	Rejected input forms	Use a DNS name instead. For an IP literal, use the separate IP lookup or reverse-DNS tool.

RFC 5891: Internationalized domain names Node.js: URL domainToASCII conversion RFC 1035: DNS implementation and record formats RFC 6376: DKIM signatures and selector-based key lookup RFC 9989: DMARC policy discovery and alignment

Recursive providers and authoritative nameservers have different roles

An authoritative nameserver publishes data for a DNS zone. A recursive resolver obtains answers on behalf of clients and can reuse cached information. Selecting Google Public DNS or Cloudflare selects the recursive service used for this observation; it does not mean that service hosts your zone or is your domain's authoritative nameserver.

ToolMellow sends requests from its server or configured probe to fixed provider HTTPS endpoints and reads their JSON responses. This provider-defined JSON format differs from the DNS wire-format messages standardized for DNS over HTTPS. The lookup does not change your device's DNS settings, query an arbitrary nameserver you enter, or trace every delegation from the root.

RFC 1034: Domain names, resolution and caching RFC 8484: DNS queries over HTTPS Google Public DNS: JSON API for DNS over HTTPS Cloudflare 1.1.1.1: JSON DNS over HTTPS requests

Read record owners, TTLs and observation details together

An answer row includes its owner name, record type, returned TTL in seconds and textual data. Read the owner as well as the value: a recursive response may include an alias chain and an address for the alias target. A supporting CNAME or another returned type is not interchangeable with the record type you requested. Expand Authority records when a negative or referral response needs context.

Each provider/location result has an observation timestamp and elapsed duration. The timestamp describes this query, not when the domain administrator last edited DNS. Duration includes the request path and HTTP/processing work; it is not a DNS-only benchmark for your own connection. If a result has no records or flags because the request failed, treat those details as missing rather than guessing their values.

RFC 1035: DNS implementation and record formats RFC 2308: Negative caching of DNS queries

Interpret DNS statuses without confusing absence and failure

A valid negative answer and a request that could not be completed need different follow-up. In ToolMellow, a positive NOERROR classification contains an answer of the requested type. Other successful DNS responses are classified using their SOA, CNAME or NS context. The table explains the visible status, rather than treating every empty answer as a nonexistent domain.

A truncated response is incomplete even when part of it contains the text you expected. The tool marks expected-value comparison inconclusive for truncation and operational failures. One provider can succeed while another fails; preserve both outcomes instead of treating the failure as proof that the record is missing.

Interpret DNS statuses without confusing absence and failure
Status or condition	Meaning in this checker	Useful next step
NOERROR	A requested-type answer is present in the successful response	Inspect every relevant value, its owner and TTL; DNS success does not test the destination service.
NXDOMAIN	The resolver reports that the queried DNS name does not exist	Check the spelling and intended owner. This is not a registrar availability check.
NODATA	No requested-type answer; SOA authority accompanies the successful response	Check whether the name should have this type. A missing AAAA record is not equivalent to a missing domain.
ALIAS_ONLY	A CNAME is returned without the requested-type answer, after the SOA check	Inspect the alias and investigate its target; a CNAME-only A response does not provide the expected A value.
REFERRAL	NS authority is present without the requested answer, after the preceding classification checks	Inspect Authority records; this is not a completed requested-record answer.
EMPTY_ANSWER	No requested answer or recognized SOA, CNAME or NS context	Retain the response details; do not relabel it NXDOMAIN.
SERVFAIL or REFUSED	The DNS server reports failure or refusal	Investigate the provider and domain configuration; the status alone does not identify one specific cause.
HTTP, timeout, malformed response or probe failure	The observation could not be completed reliably	Check connection feedback and retry deliberately when appropriate; record absence is unproven.
Truncated / TC	The provider reports an incomplete response	Treat comparison as inconclusive and retain the partial-response flag.

RFC 2308: Negative caching of DNS queries Google Public DNS: JSON API for DNS over HTTPS Cloudflare 1.1.1.1: JSON DNS over HTTPS requests

What DNS TTL means after a record change

TTL expresses a cache lifetime in seconds. A recursive resolver may return the remaining lifetime of information it has cached, so two responses can show different TTLs for otherwise identical data. The returned number is not a countdown to the moment every resolver worldwide will use your new value.

Positive answers, negative answers and delegation information can have separate cache histories. Lowering a record's TTL now does not retroactively shorten the lifetime assigned to a copy already cached. Some resolvers can also serve stale data under specified resilience policies. A new lookup therefore supplies another observation, not a certificate that every cache is fresh.

For a planned change, confirm the intended owner and values with the DNS hosting service, retain the old and new observations, and repeat relevant checks at useful intervals. Use the hosting provider's change instructions and the prior cache context to plan verification. A blanket 24- or 48-hour claim cannot describe every DNS change.

RFC 2181, section 8: Time to live RFC 2308: Negative caching of DNS queries RFC 8767: Serving stale DNS data

Why provider agreement does not prove global DNS propagation

Google and Cloudflare can return different answers because they have different cached observations or resolution behavior. Location-dependent authoritative responses can also matter. First compare the same normalized name and type at recorded times, then inspect statuses, owners, values and TTLs. A disagreement does not automatically identify which answer is correct.

Each check can select at most four configured query locations, but only locations actually listed in the interface are available. If one location is listed, both providers are queried through that location. A location's declared region is not independently established geography when its region-verification flag is false. Do not infer a worldwide probe network from the selectable-provider count or the configured selection limit.

Agreement establishes agreement among these observations. Your device, another network or a private corporate resolver may still see something else, especially with local caches or split-horizon DNS. Use a suitably scoped multi-location service or your network's own diagnostics when the task requires those additional perspectives.

RFC 1034: Domain names, resolution and caching RFC 8767: Serving stale DNS data

Compare expected values literally, with exact or contains matching

Expected-value comparison scans Answer values of the requested supported type. Exact means the whole returned text equals your expected text; contains means that text includes your expected substring. Both are case-sensitive. One matching value makes that provider/location result a match, even if additional values differ. It does not establish that the entire record set equals your intended configuration.

The comparison does not trim text, remove quotes or final dots, normalize IPv6 spelling, or parse DNS policy syntax. It does not support regular expressions. DNS hostname comparisons can be case-insensitive at the protocol level, while this string check remains case-sensitive. Use the returned presentation when you need literal equality, and inspect full data before using a short substring as evidence.

NXDOMAIN and NODATA responses normally compare as different when there is no requested value; they are valid negative observations, not request failures.
Failed or truncated results are inconclusive. Empty expected text, text exceeding 4,096 JavaScript string units, and PTR comparison are also unavailable.
Expected text stays in this tab and the downloaded report. It is not sent with the DNS query. A text match alone proves neither DNSSEC validation nor domain ownership.

Compare expected values literally, with exact or contains matching
Illustrative returned data	Expected text	Comparison lesson
A: `203.0.113.10`	`203.0.113.10`	Exact matches this value; other A answers may still contain other addresses.
CNAME: `target.example.com.`	`target.example.com`	Exact differs because of the final dot; contains matches the substring.
MX: `10 mail.example.com.`	`mail.example.com`	Exact differs because priority and the final dot are present; contains is only a text-fragment check.
TXT: `"verification=sample-token"`	`verification=sample-token`	Exact differs when returned quotation marks are included; contains can find the fragment.
CNAME: `Target.example.com.`	`target.example.com.`	Literal exact differs by case even though DNS name equality has separate semantics.
TXT: `"part-one" "part-two"`	`part-onepart-two`	The helper does not join quoted text chunks or interpret a complete policy.

RFC 4343: DNS case insensitivity

Read the DNSSEC authenticated-data flag with its source

The Authenticated indication reflects the selected recursive resolver's AD flag. That resolver is asserting authenticated data; ToolMellow does not independently verify DNSSEC signatures or the trust chain. Relying on the assertion also depends on trusting the resolver and the channel carrying its response.

Not authenticated means the provider did not assert AD. Unsigned data can produce this result, so the flag alone does not establish a broken or malicious domain. A SERVFAIL response likewise needs investigation rather than an automatic DNSSEC diagnosis. This checker requests DNSSEC-related response data with checking enabled at the provider, but it is not a complete DNSSEC audit or a browser DNS-leak test.

RFC 4035: DNSSEC and authenticated-data assertions Google Public DNS: JSON API for DNS over HTTPS Cloudflare 1.1.1.1: JSON DNS over HTTPS requests

Check website DNS before investigating hosting and HTTPS

When a site points to an old destination, check the exact hostname visitors use. Compare A and AAAA separately, and inspect CNAME for an alias such as the www name. Do not assume the root and www names have identical configuration. Compare the result with the intended records documented by your hosting service, including any required alias target.

A correct-looking DNS value is one part of website diagnosis. HTTP redirects, virtual-host routing, certificate validity and application responses require their own checks. A CNAME is an alias in DNS, while redirecting a visitor to another URL is HTTP behavior. CAA data concerns certificate-authority authorization; its presence does not confirm that the current site serves a valid certificate.

RFC 1035: DNS implementation and record formats RFC 8659: Certification Authority Authorization

Look up TXT verification, SPF, DKIM and DMARC at the correct owner

For domain verification, copy the owner name from the service's instructions and choose TXT. Compare the full returned record with the required token, taking its displayed quotation and chunking into account. Finding the token in a response is useful evidence, but the requesting service applies its own ownership-verification process.

SPF policy uses TXT at the relevant mail domain. DKIM key lookup uses a selector-specific name such as selector._domainkey.example.com; obtain the selector from the mail service rather than guessing it. A DMARC-related check commonly starts with TXT at _dmarc.example.com. Modern DMARC policy discovery and identifier alignment involve further rules, which a single TXT observation does not evaluate.

MX records describe mail routing, while these TXT-based mechanisms have separate roles. This checker does not follow all SPF includes, validate a signed message, evaluate complete DMARC policy discovery, analyze DMARC reports or test delivery. Record presence and a contains match cannot substitute for those checks.

RFC 7208, section 3.1: SPF policies in TXT records RFC 6376: DKIM signatures and selector-based key lookup RFC 9989: DMARC policy discovery and alignment

Understand query privacy and share a useful DNS report

The name and type you query go through the ToolMellow broker or selected probe to the selected public resolver. The resolver sees the probe's network address; ToolMellow does not forward visitor client-IP headers to it. Hosting still receives ordinary request metadata. HTTPS transport does not make the entire activity anonymous or establish a zero-logging policy, and the name itself may be sensitive.

Expected text is compared locally and can be included as expectedComparison in dns-results.json. Before sharing a report, inspect its query name, returned data and expected text, particularly verification tokens. Send the relevant observation to an intended recipient rather than assuming every exported value is appropriate for public posting.

For a support request, include the exact name and type, intended configuration, provider/location, observation time, status, relevant Answer and Authority data, and whether any result was truncated or failed. The downloaded report is a snapshot; the tool does not maintain a server-side record history or export your entire DNS zone.

Troubleshoot a missing or unexpected DNS answer

Begin by checking the normalized owner and selected type against your DNS host's instructions. Then distinguish a negative DNS response from a failed request, inspect aliases and Authority details, and compare both provider observations. If you used an expected value, check the full returned text and comparison mode before concluding that the underlying configuration differs.

After a change, save a report and make deliberate follow-up checks. The tool does not retry lookups automatically, and repeated requests do not flush all caches. Use Retry connection when offered for configuration problems, respect rate-limit feedback, and submit a new DNS check when appropriate. Cancel stops pending client work and propagates cancellation upstream, but it cannot undo a query already sent.

Use the separate IP lookup or reverse-DNS tool when starting from an address, and your local operating system's DNS diagnostics when investigating the resolver path used by that device. This checker does not enumerate every subdomain, select SRV, DS, DNSKEY or ANY, transfer a zone, or assess registrar availability. Match the diagnostic to the question before interpreting a successful response as a broader result.

Frequently asked questions

How do I check all DNS records for a domain?

Run separate checks for the owner names and supported types relevant to your task. ToolMellow uses one name and type per request; it does not enumerate all subdomains, transfer the zone or provide a complete all-records inventory.

Why do Google and Cloudflare show different DNS results?

Their cache histories and resolution behavior can differ, and authoritative answers can depend on location. Compare the same normalized name and type, observation times, statuses, owners, values and TTLs. Disagreement alone does not identify the correct answer.

Does the TTL tell me when DNS propagation will finish?

No. The returned TTL is cache-lifetime information for the observed data. Positive and negative caches, delegations and stale-answer policies can affect other observations. It does not establish a worldwide completion time.

What is the difference between NXDOMAIN and NODATA?

NXDOMAIN reports that the queried name does not exist. NODATA means the requested type has no answer; this checker identifies it using SOA authority with a successful response. A name can have A records while returning no AAAA data.

Why does exact matching fail for my TXT or CNAME record?

The helper compares the complete returned text, case-sensitively. Quotes, spaces, final dots, MX preference text and different presentation can matter. Inspect the full value; contains checks only a substring and does not validate a complete record or policy.

Does a match mean every DNS record is correct?

No. One matching Answer value of the requested supported type makes that provider/location result a match. Other values may differ, and literal matching does not prove ownership, DNSSEC validation, email delivery or worldwide agreement.

Can I enter an IP address to check PTR records?

Use the separate IP lookup or reverse-DNS tool for a raw address. In this DNS checker, PTR requires a complete reverse-DNS owner name, such as the illustrative 10.113.0.203.in-addr.arpa. PTR expected-value comparison is unavailable.

How do I check SPF, DKIM and DMARC records?

Choose TXT at the relevant SPF domain, the provider-supplied DKIM selector under _domainkey, or the appropriate _dmarc owner. These lookups inspect published text; they do not evaluate all SPF dependencies, a message's DKIM signature or complete DMARC discovery and alignment.

Does Not authenticated mean my domain is unsafe?

Not authenticated means the selected provider did not assert the AD flag. Unsigned data can produce that result. ToolMellow does not independently validate DNSSEC, and that indication alone does not establish an unsafe domain.

Does this checker test my device's DNS server?

It queries the selected public providers through ToolMellow's available locations. That path can differ from the resolver and caches used by your own device, browser or private network. Use local diagnostics for that question.

Does agreement between two providers prove global propagation?

It proves only agreement among the completed observations. Two providers queried through one listed location are not a worldwide probe network. Available locations and region-confidence details determine the scope of the report.

Is my expected value sent to the DNS providers?

No. Expected text stays in the browser tab and can appear in your downloaded report. The actual DNS name and type do go to the selected resolver through the service. Inspect verification tokens and other report data before sharing.