DNS Record Explorer

DNS Record Explorer: Understand What a Domain Publishes

DNS, or the Domain Name System, translates human-readable names such as example.com into information that computers can use. That information is stored in DNS records. A domain may publish records that identify its web servers, mail providers, authoritative name servers, verification tokens, certificate authorities, and other services.

The WHOISDR DNS Record Explorer helps you inspect public DNS records for a domain or hostname. It is useful when you need to confirm how a domain is configured, investigate a website or email issue, review a domain’s public service footprint, or compare DNS results during a migration.

DNS is distributed and cached. The records you see are a public view of DNS at the time of the lookup, not a complete picture of every private network setting or historical configuration. Correct interpretation therefore requires attention to the record type, queried name, response status, returned values, and time-to-live information where available.

What DNS Records Do

Each DNS record has a name, type, value, and usually a TTL, or time to live. The name identifies the DNS label being queried, the type determines what kind of information is requested, and the value contains the answer. For example, an A record maps a hostname to an IPv4 address, while an MX record identifies a mail server.

Records can exist at the domain apex, such as example.com, or on subdomains such as www.example.com, mail.example.com, or _acme-challenge.example.com. A lookup for the apex domain is not necessarily the same as a lookup for www. When investigating a problem, query the exact hostname used by the application, browser, mail system, or verification service.

Common DNS record types

• A: Maps a name to an IPv4 address, such as 203.0.113.10. Web browsers and other clients may use this address to connect to a service.
• AAAA: Maps a name to an IPv6 address. A hostname can publish both A and AAAA records, allowing clients to use either IP version.
• MX: Lists mail exchangers for a domain. Each MX record normally includes a preference value; lower numbers have higher priority relative to other MX records for the same domain.
• NS: Identifies the authoritative name servers for a DNS zone. These servers are responsible for publishing the zone’s records.
• TXT: Stores text data. Common uses include SPF policy, domain ownership verification, and service configuration. TXT records are not limited to one specific application.
• CNAME: Creates an alias from one hostname to another canonical hostname. The target is another domain name, not an IP address.
• SOA: Describes core zone information, including the primary name server reference, responsible-party mailbox format, serial number, refresh interval, retry interval, expiration interval, and minimum or negative-caching value.
• CAA: States which certificate authorities are permitted to issue certificates for a domain, when CAA policy is published and honored by the issuing process.
• PTR: Supports reverse DNS, mapping an IP address back to a name. Reverse lookups are performed against reverse-mapping zones and are separate from ordinary forward lookups.
• SRV: Describes the location and priority of services such as certain voice, messaging, or directory protocols. It includes a service name, protocol, priority, weight, port, and target.
• CAA, DNSKEY, DS, and related DNSSEC records: These may appear when a domain publishes DNSSEC information. Their meaning depends on the complete validation chain, not just on the presence of one record.

Not every domain publishes every record type. An absent record is not automatically an error. For example, a domain that does not receive email may have no MX record, and a hostname intended only for IPv4 access may have no AAAA record.

How the DNS Record Explorer Works

1. Enter the domain or hostname. Use the exact name you want to inspect. For example, compare example.com with www.example.com rather than assuming they share identical records.
2. Choose or review the record type. A targeted lookup is useful when troubleshooting a known issue, while reviewing several record types gives a broader view of the domain’s public DNS configuration.
3. Run the lookup. The tool requests publicly available DNS information and presents the returned records in a readable form. Results depend on the name, type, DNS delegation, resolver path, and current state of DNS caching.
4. Review the response details. Examine the record name, type, value, priority or other fields, TTL, and any response status or indication that no record was returned.
5. Compare related names and record types. A useful investigation often involves checking the apex, common subdomains, authoritative name servers, mail records, and text-based policies together.

The explorer is designed for public DNS inspection. It does not reveal private DNS zones, records available only inside an organization, or configuration stored solely in a DNS provider’s administrative console. If a record is visible only to internal resolvers, a public lookup may correctly show no answer.

How to Interpret Results

A and AAAA records

Use A records to see where IPv4 traffic for a hostname may be directed. Use AAAA records for IPv6 destinations. Multiple addresses are common and may support redundancy, geographic routing, load distribution, or a combination of services.

An IP address in DNS does not prove that a web server is healthy or that the intended website is being served. The address may belong to a reverse proxy, content delivery network, hosting platform, firewall, or shared server. To investigate HTTP behavior, follow up with a website headers check or another relevant website inspection tool.

MX records

MX results show which hosts are designated to receive mail for the queried domain. The preference value establishes ordering, but it is not a percentage, performance score, or guarantee that the lower-numbered server is currently operational.

After finding an MX target, inspect that target separately if you need to understand its address records. Do not assume that the mail host uses the same IP addresses as the website. Also remember that outbound sender authentication involves more than MX records. SPF, DKIM, and DMARC commonly use TXT records or selector-specific names, and their evaluation depends on the complete published policy and message context.

NS and SOA records

NS records identify the name servers delegated for a zone. They are important during registrar changes, DNS provider migrations, and delegation troubleshooting. If the expected provider’s name servers are not present, the domain may still be delegated to an old provider or to a different configuration than intended.

The SOA record provides operational values for the zone. The serial number can help indicate that a zone version changed, but it is not a universal timestamp and should not be interpreted as one. Refresh, retry, and expiration values describe behavior for secondary DNS servers in conventional authoritative setups. The SOA minimum field has historically had several interpretations; in modern DNS practice it is commonly associated with negative caching, but exact behavior depends on the DNS implementation and context.

TXT records

TXT records can contain several unrelated policies or verification strings at the same name. A long value may be split into multiple quoted character strings in DNS presentation, and some policies have strict syntax or length rules.

For SPF, look for a value beginning with v=spf1. The visible text is only the published policy; determining whether a specific sender passes requires evaluating the sending IP, envelope domain, mechanisms, redirects, and any DNS lookup limits. A TXT lookup alone does not validate a complete email message.

Verification records may contain a token tied to a hosting, analytics, email, or certificate service. Treat unfamiliar tokens as configuration data, not as proof that a service is currently active. Removing a token can affect ownership verification or service operation.

CNAME records

A CNAME points one hostname to another name. The target then needs to be resolved separately to determine its addresses. CNAMEs are commonly used for hosted services and traffic platforms.

DNS rules restrict where a CNAME can be used. A name with a CNAME generally cannot also contain ordinary records such as A, MX, or TXT at the same label. The domain apex can require special provider behavior because the zone apex must carry records such as SOA and NS. Provider-specific alias or flattening features may make the user interface appear to support an apex alias even when the authoritative DNS response differs from a conventional CNAME.

CAA and DNSSEC-related results

CAA records can limit which certificate authorities may issue certificates for a domain. No CAA record does not automatically mean certificates cannot be issued; it means the domain has not published a CAA restriction at the relevant name, subject to inheritance and issuer behavior.

DNSSEC records require careful interpretation. A DS record at the parent zone, DNSKEY records in the child zone, and valid signatures must form a consistent chain. Seeing one DNSSEC-related record does not by itself establish that validation succeeds. For certificate and encryption checks, use a relevant SSL certificate check as a separate layer of investigation.

Practical Use Cases

• Website migration: Confirm whether the intended A, AAAA, or CNAME records are published. Check both the apex and the exact hostnames used by links, applications, and redirects.
• DNS provider changes: Review NS records and SOA details to determine whether delegation has moved and whether the expected authoritative zone is answering.
• Email setup: Inspect MX records and related TXT records when configuring a mailbox provider or diagnosing delivery problems. Check the domain used in the relevant mail headers, which may differ from the visible From address.
• Domain verification: Search TXT records for service tokens and confirm that the token is published at the exact label requested by the service.
• Subdomain inventory: Review known subdomains and their record types to understand which public services a domain advertises. This is useful for maintenance and reducing forgotten DNS entries.
• Certificate policy review: Inspect CAA records before changing certificate providers, then use a certificate-focused tool to examine what is actually presented by a live server.
• Incident investigation: Compare current records with trusted configuration records or prior observations. DNS results can help identify unexpected destination changes, but they are only one part of an investigation.

Common Mistakes

• Checking the wrong name: The apex, www, mail host, and application subdomain may all have different records.
• Confusing nameservers with web servers: NS records identify DNS authorities; they do not identify the server hosting the website.
• Treating TTL as propagation time: TTL indicates how long a resolver may cache an answer. It does not guarantee that every resolver will refresh at exactly that time.
• Assuming one resolver represents everyone: Different networks may have different cached answers, filtering policies, transport paths, or DNS views.
• Reading TXT as a single policy: Several independent TXT records can coexist. Identify the policy prefix and evaluate its syntax and context.
• Expecting DNS to prove service health: A record can point to an unreachable, misconfigured, or shared service. DNS only describes published naming data.
• Editing records without checking dependencies: A TXT token, MX target, CNAME, or CAA policy may support a service that is not obvious from the record value.

Troubleshooting DNS Results

1. Confirm the spelling and scope. Remove accidental protocol prefixes and paths, and query the hostname rather than a full URL. Check whether a trailing dot or internationalized domain representation is relevant.
2. Check the record type. A hostname can return no MX record even though it has an A record. A CNAME lookup can differ from an A lookup because the name may be an alias.
3. Inspect delegation. Review NS records and verify that the authoritative servers are the ones expected. A delegation problem can cause apparently inconsistent answers.
4. Allow for caching. After a change, old data may remain available until cached TTLs expire. Some recursive resolvers may also retain negative responses for a period.
5. Compare authoritative and recursive views. If you have access to an authoritative DNS query method, compare it with public recursive results. A mismatch may indicate caching, delegation, split-horizon DNS, or an incomplete zone update.
6. Check dependent records. For an MX, CNAME, or SRV result, inspect the target name and its address records. A syntactically correct target can still lack usable destination records.
7. Look for conflicting address families. An incorrect AAAA record can affect IPv6-capable clients even when the A record is correct. Review both where relevant.

For broader domain ownership and registration context, use the WHOIS lookup. For questions about whether DNS changes are visible from different locations or have likely reached recursive resolvers, use a DNS propagation check if that is the more appropriate investigation.

Limitations, Accuracy, and Privacy

DNS responses are time-sensitive and can vary by resolver location, caching state, transport, filtering, and configuration. The explorer reports the public response available to its lookup process; it cannot guarantee that every network, resolver, or application sees the same answer. DNS providers may also use geographic, policy-based, or client-specific responses.

A successful lookup does not validate the contents of a website, the identity of an organization, the safety of an IP address, or the deliverability of email. Likewise, a missing response may be intentional, temporary, private, filtered, or caused by an error in delegation. Treat results as evidence for investigation, not as a standalone security verdict.

Public DNS is intended to be observable, but records can still expose operational information such as hosting providers, mail platforms, verification relationships, service names, and internal naming choices. Avoid publishing confidential data in TXT records. Use separate internal DNS views where appropriate, and review old records after migrations so that obsolete service references are not left publicly available.

When investigating a domain you do not control, limit activity to passive inspection of publicly available information and respect applicable laws, policies, and authorization boundaries. DNS inspection is generally low impact, but the information can contribute to a broader technical or security profile.

When to Use Related WHOISDR Tools

Use the DNS Record Explorer when your question is about what names, services, policies, or destinations a domain publishes in DNS. Move to another WHOISDR tool when the question concerns a different layer:

• Use WHOIS lookup for registration details, registrar information, domain status, and registration dates when those details are available through the relevant registry or registrar data.
• Use SSL certificate inspection to examine the certificate and TLS-related details presented by a live service. DNS records alone cannot show whether the certificate matches the hostname.
• Use website headers inspection to review HTTP response headers and redirect behavior after DNS identifies the likely destination.
• Use DNS propagation checking when comparing how a DNS change appears across multiple lookup locations is more important than inspecting one result set.

Used together, these tools provide a layered view: WHOIS describes registration context, DNS describes public naming and service records, HTTP inspection describes application responses, and certificate inspection describes the encryption endpoint. Keeping those layers separate helps avoid drawing conclusions that the DNS data alone cannot support.