Domain lookup guide
Domain Lookup Explained: Registration Data, DNS Records and Website Status
A registered domain does not necessarily have a working website. Its registration can be active while DNS points to an old server, email uses another provider, or the website returns an error. A useful investigation treats registration, DNS and the website response as separate layers, each answering a different question.
PeerPeek’s Domain Checker brings together published registration details, six DNS record types and a website response snapshot. Use it to narrow down where a problem may be, then take the relevant evidence to your registrar, DNS provider or host. To look for a name to buy and compare registrar prices, use the separate Domain Search.
Start with the registered name, such as example.com. PeerPeek also accepts HTTP(S) URLs, but uses the hostname rather than the pasted path, query or fragment. It lowercases the name, handles internationalized names and removes a leading www.; other subdomains remain. IP addresses, credentials, nonstandard ports and private destinations are not supported. Input validation checks the name’s syntax; it does not establish registration.
Understanding registration data
A registry maintains the registration database for a top-level domain such as .com. A registrar provides registration and management services to customers. The registrant holds the rights to the registered name. These roles are distinct from operating a website or mail server. ICANN explains the registration process.
RDAP, the Registration Data Access Protocol, provides structured registration data and was developed to replace the older WHOIS protocol. PeerPeek’s Domain Checker uses RDAP, not a WHOIS lookup. It discovers a service for the TLD and requests the normalized name. Coverage and public disclosure vary across registries and TLDs; an unsupported service or a failed request leaves registration unknown. ICANN’s RDAP overview explains the protocol’s role.
Dates tell you about the record, not its whole history
PeerPeek displays Registered, Registrar, Registered on, Expires on, Registration updated, RDAP source, Registration statuses and Nameservers reported by RDAP, when available.
- Registered on comes from the RDAP registration event. It describes the reported registration, not when a website first launched.
- Registration updated comes from the “last changed” event. A record update does not establish that ownership changed.
- Expires on is the reported registration expiration event. It does not promise that the name will be available to buy that day. Renewal, grace and redemption processes can affect what happens next.
The date fields follow RDAP event definitions in RFC 9083. ICANN’s typical gTLD lifecycle illustrates why expiration and release are different events; TLD rules vary.
Not reported means that a usable value was not returned for that field. PeerPeek does not display registrant contact details. Public registration services may redact personal information or restrict its disclosure; missing public owner information is not evidence of suspicious ownership. See ICANN’s Registration Data Policy, including publication and redaction.
A transfer lock is different from a DNS hold
PeerPeek displays the status strings returned by RDAP rather than translating them into a diagnosis. Wording can differ from the EPP codes used between registrars and registries.
- transfer prohibited, or an EPP code such as clientTransferProhibited, restricts transfer to another registrar. It does not by itself stop a website resolving.
- clientHold or serverHold prevents activation in DNS. Investigate the hold with the registrar; changing an A record alone will not resolve that restriction.
- redemptionPeriod concerns a deleted registration’s restoration window. It is different from a normal renewal reminder or a transfer lock.
The ICANN status reference lists the EPP codes alongside their RDAP equivalents and explains their effects. Several statuses can coexist; read the complete set.
Unknown is not unregistered
Unavailable can mean a transport failure, rate limit or unusable RDAP response. Not supported means PeerPeek found no RDAP service for that TLD. Neither is evidence that the name is unregistered. The report can also complete while one provider is unavailable.
PeerPeek maps an RDAP HTTP 404 to Registered: No. That means no matching domain record was returned by that service, as described in RFC 7480’s negative answers. It is not a purchase guarantee. Other subdomains are preserved in the input, and PeerPeek does not reduce them to a registrable domain: a query for shop.example.com can miss a registration record even though example.com is registered. For registration questions, enter the registered name itself.
DNS records explained
DNS directs different services using different record types. PeerPeek queries A, AAAA, CNAME, MX, NS and TXT separately for the normalized hostname, through its system resolver. It does not enumerate subdomains, compare resolvers or show record TTLs.
The following values are illustrative, not a live lookup. example.com names and the IP addresses shown here are reserved for documentation.
Scroll the table horizontally on a small screen to read every column.
| Type | What it tells you | Illustrative value |
|---|---|---|
| A | IPv4 address for a name | example.com → 192.0.2.10 |
| AAAA | IPv6 address for a name | example.com → 2001:db8::10 |
| CNAME | Alias to another DNS name | shop.example.com → web.example.com |
| MX | Incoming mail destination and priority | example.com → 10 mail.example.com |
| NS | Authoritative DNS server name | example.com → ns1.example.com |
| TXT | Text used for verification or policies | example.com → verification=illustrative |
See the DNS record overview and RFC 1035’s record definitions. AAAA is defined in RFC 3596; the example address ranges are documented in RFC 5737 and RFC 3849.
Website, DNS, mail and registration can use different providers
An NS entry identifies a DNS server, not necessarily the web host. A registrar may manage registration while another company hosts DNS, a CDN handles web traffic and a separate provider receives email. Nameservers reported by RDAP and NS records returned by DNS come from different sources; PeerPeek shows both without verifying that they agree with the parent delegation.
A public A or AAAA address may belong to a CDN or reverse proxy, rather than the origin server behind it. An address alone does not identify the application’s origin hosting. Cloudflare’s proxy status documentation shows how proxied DNS answers can expose proxy addresses instead.
A CNAME is not an HTTP redirect. It aliases one DNS name to another; it does not tell the browser to change its URL. A redirect is a response from a web server after a connection is made.
Mail records need careful interpretation
For MX, a lower preference number is preferred: 10 mail.example.com is tried before a destination with preference 20. An MX entry identifies routing, not whether a mailbox exists, a server accepts a message or delivery reaches an inbox. If a successful DNS query returns no MX records, SMTP can fall back to the domain’s own address records. A Null MX, written 0 ., explicitly declares that the domain accepts no mail. See RFC 5321, section 5 and RFC 7505.
TXT records also need the correct query name:
- SPF authorizes sending hosts for an email identity’s domain. Its TXT record may be at
example.comor a sending subdomain such asbounce.example.com; it is not always at the apex. RFC 7208 defines its placement. - DKIM keys are looked up at a selector name, for example
selector1._domainkey.example.com. See the DKIM record explanation. - DMARC uses a name such as
_dmarc.example.com. See the DMARC record explanation.
An apex TXT lookup is therefore not a complete email authentication audit. PeerPeek does not discover DKIM selectors, test SPF evaluation, validate DMARC alignment or send mail. Its DNS table is also not a complete inventory of a domain’s subdomains.
Empty answers, errors and caching
In the report, No records found means that the query completed without returning records of that type. Lookup failed indicates a query error; Records unavailable indicates missing usable DNS data. Neither error establishes that no records exist. A missing AAAA record alone is not a fault when the service intentionally uses IPv4 only.
TTL, or time to live, controls how long a DNS answer may be cached. Different resolvers and devices can retain earlier answers, and a cached negative answer can also delay visibility of a newly added record. There is no universal “DNS propagation” duration. Lowering a TTL after an old answer was cached does not retroactively change that answer’s lifetime. See Cloudflare’s TTL documentation and RFC 2308 on negative caching. Inspect TTLs in your DNS provider or a separate DNS diagnostic tool; PeerPeek does not report them.
Website responses and redirects
PeerPeek starts at the normalized hostname’s root path, tries HTTPS first, and tries plain HTTP only if the HTTPS attempt fails at the transport level. An HTTP 403 or 500 is already a response, so it does not trigger that fallback.
The request uses GET. PeerPeek reads the response status and headers, then cancels the response without reading the body. It does not use HEAD, render JavaScript, crawl pages or inspect page content. Availability check time measures the probe through receiving headers, including followed redirects, rather than full page load time.
| Outcome | Meaning for the investigation |
|---|---|
| 200 | The request succeeded; this is not a security or quality verdict. |
| 301 / 308 | Permanent redirect to another URL. |
| 302 / 307 | Temporary redirect. 307 and 308 preserve the request method; 301 and 302 can change POST to GET in clients. |
| 403 | The server understood the request but refused it; access rules or bot filtering may be relevant. |
| 404 | No current representation was found, or the server will not disclose one; the domain may still be registered. |
| 5xx | Server-side failure; for example, 502 involves an invalid upstream response and 503 indicates temporary inability to serve. |
| Connection failure / timeout | No usable HTTP response was obtained. DNS, network, TLS or server availability may need investigation. |
The status meanings follow HTTP Semantics, RFC 9110, section 15. A failed automated request does not establish that every visitor is affected.
Redirects operate at the HTTP layer. PeerPeek follows up to four hops, rechecks destinations before connecting and reports Final URL, Redirects, HTTP status and whether the final endpoint used HTTPS. It does not display the complete hop-by-hop chain. At the limit, the displayed response can still be a redirect. A loop produces a failure explanation.
Website reachable: Yes means that the observed HTTP status was below 400, including redirects. Read the status and final URL alongside that label. A Skipped check means no A or AAAA address was available from the DNS result; look for DNS query failures before concluding that addresses are absent. Blocked means the destination was refused by the check’s network policy, not that the website is unsafe. Unavailable means the check could not provide a result.
Three practical troubleshooting scenarios
A. The domain is registered but the website does not open
Symptom: you renewed example.com, but visiting it still fails.
Relevant report fields: Registered, Expires on, Registration statuses, A/AAAA, DNS lookup errors, Website reachable, HTTP status and Website check details.
Interpretation: an active registration does not configure hosting. A hold can affect DNS publication. A successful lookup with no address records points toward DNS configuration; a failed lookup leaves that question open. If addresses exist but no HTTP response arrives, the failure may be during connection or TLS negotiation. If a 403, 404 or 5xx arrives, a server answered and the HTTP response is the next lead.
Next action: resolve any hold with the registrar first. Check the intended hostname’s records with the authoritative DNS provider. If addresses are correct, ask the host to examine virtual-host configuration, network access and TLS setup; the generic “no HTTP or HTTPS response” message does not distinguish these causes. For a certificate-specific investigation, use the separate SSL certificate guide. For an HTTP error, inspect web server or application logs at the recorded check time.
B. The old website appears after a hosting change
Symptom: some visitors see the new site, while others still reach the previous host.
Relevant report fields: analyzed hostname, Nameservers reported by RDAP, DNS NS, A, AAAA, Final URL and Analysis completed.
Interpretation: compare the returned addresses with those supplied by the new host. An updated A record can coexist with an outdated AAAA record, sending IPv6 clients elsewhere. PeerPeek’s website probe prefers IPv4 when available, so a successful probe does not verify every IPv6 route. If the authoritative configuration is correct, an earlier cached answer may explain a difference; an old page can also come from browser or CDN content caching rather than DNS.
Next action: confirm the parent delegation and query the authoritative servers using your DNS provider’s diagnostics or a DNS utility. Check both address families and the exact visitor hostname. PeerPeek removes a leading www., so its result does not establish that www.example.com is configured correctly. Correct unintended records, allow existing caches to expire according to their TTLs, and inspect HTTP redirects or content caches if addresses already match. PeerPeek does not compare resolver answers or read the page to determine which version appeared.
C. The website works but email does not
Symptom: example.com opens, but mail to person@example.com bounces or never arrives.
Relevant report fields: MX values and priorities, DNS lookup errors, NS and any returned TXT records. Website reachable is a separate observation.
Interpretation: the web address may be correct while MX still names the old mail provider. Conversely, apparently correct MX records do not establish that person exists or that the receiving service accepts mail. No MX, an MX query failure and an explicit Null MX require different interpretations. Apex TXT results cannot establish whether a message passes SPF, DKIM or DMARC.
Next action: compare routing with the mail provider’s required configuration and check that the MX destinations resolve. Confirm the mailbox exists and review the actual bounce message or provider delivery logs. For sending or spam-folder problems, examine the message’s authentication results and the provider’s selector and policy records. Domain Checker does not connect to SMTP servers, authenticate to mailboxes or test delivery.
Understanding the PeerPeek score
The overall score is the rounded sum of 30% Technical + 40% Brandability + 30% Memorability, each scored out of 100. Expand the report’s score breakdown to see the component points and explanations.
The Technical score awards up to 30 points for A/AAAA addresses, 25 for an HTTP response below 400, 15 for an observed HTTPS endpoint, 10 for MX presence, 10 for the number of NS records and 10 for registration and its expiration date. An HTTP error status receives 8 of the 25 response points. Registration receives 10 points when the reported expiry is more than 30 days away, 5 when closer or unpublished, and 0 when registration is not established.
These are coarse observations. The mail component counts MX records without assessing deliverability or distinguishing a Null MX. The nameserver component counts entries without testing independent infrastructure. Registration points do not interpret hold statuses. Failed or unavailable provider data can contribute zero points, so a low total may partly reflect missing evidence rather than a confirmed fault.
Brandability applies naming preferences to length, hyphens, digits, a fixed TLD tier list and token count. Memorability uses length, vowel balance, consonant runs, repeated characters, digits and hyphens. Tokens are split at hyphens and letter/digit boundaries, not recognized using a dictionary. The measured label is immediately left of the final dot, without public-suffix awareness; for example.co.uk, that label is co. Internationalized names receive a 0.8 multiplier on both naming scores, with neutral allocations where script-based measurements are unavailable.
Those naming rules are subjective heuristics, not measured demand or universal judgments across languages. The score is not a market valuation, a Google ranking prediction, a security certification, proof of legal ownership or a trademark-suitability check. Use the detailed findings to decide what needs investigation rather than treating the total as a verdict on the domain.
Recheck after changes
Save the earlier report URL, Analysis completed time and the fields you intend to change. That completion time is shown in UTC; it is separate from Registration updated, which comes from RDAP. The providers are checked during a run, not at one simultaneous instant.
Return to the Domain Checker and submit the same registered name after making a change. PeerPeek can return an analysis already in progress or reuse a completed result within its configured freshness window, 24 hours by default. Reuse does not advance the original completion time. The form does not offer a force-fresh option, so an immediate resubmission may show the same observation.
Opening or refreshing a stored report reads that analysis; it does not start a new check or provide continuous monitoring. When a new analysis has completed, compare its timestamp, hostname, record values, HTTP status and final URL with your saved result. A newer report can still encounter DNS caches, so use the relevant provider’s diagnostics when you need to verify an urgent change before PeerPeek can make a new observation.