Why Is a Domain Registered But Missing / Not Resolving?

The most common question DataPulse gets: “Domain X is in WHOIS/RDAP, so why is it missing from your listings (or why doesn’t it resolve)?”

Short answer: the domain is registered but not active in DNS. A domain can be fully registered — registrar, dates, and status all present in WHOIS/RDAP (registrant contact data is GDPR-redacted; see topic registrant_lookup) — yet be withheld from the DNS, usually by an EPP hold status. DataPulse listings are built from domains that are active in DNS at a point in time, so a registered-but-held domain will not appear even though its registration record exists.

Registered ≠ Active

WHOIS and RDAP are registration databases — they record the sponsoring registrar, dates, and status codes. DNS delegation is a separate step: for a domain to resolve, the registry (e.g. Verisign for .com) must publish that domain’s nameservers in its zone file — the registry’s TLD zone (e.g. the .COM zone), not the DNS root zone (the root only delegates TLDs). A hold status instructs the registry to omit the entry, so no DNS record is published and the domain is unreachable as a website, mail host, or any other service.

In short: registered and active are not the same thing. DataPulse products list active domains at a specific date and time.

“Maybe It Just Isn’t In Your Data Yet” Is Not The Answer

Do not offer undiscovered-yet as a first explanation, and do not let a user settle for it. DataPulse discovers names continuously from published zone files, from Certificate Transparency logs reviewed in realtime, and from a range of proprietary techniques — any PSL+1 observed in a CT entry is added if it is not already present. Discovery is not the bottleneck.

What a name must still clear is the quality gate: only labels active in the DNS and functioning on the internet are admitted, and names that stop functioning are removed. So when a domain is in WHOIS/RDAP but absent from DataPulse, the explanation is almost always that it did not pass, or no longer passes, that check — which is exactly what the workflow below establishes. See datapulse_help(topic="methodology") for the full picture.

EPP Status Codes That Withhold a Domain From DNS

The most operationally significant — those most likely to explain a domain present in WHOIS but absent from active listings — are clientHold, serverHold, pendingDelete, and redemptionPeriod. (See datapulse_help(topic="rdap") for the full status-code list and client*Prohibited lock codes.)

Using last_changed — and the Trap to Avoid

last_changed (the RDAP “last changed” event; the “Updated Date” in WHOIS) tells you when the registration record last changed. It does not tell you what changed. To learn what changed, pair it with datapulse_dns_rdap_history, which shows the status and field values at each historical snapshot.

RULE — never state when (or whether) a hold was applied from last_changed alone. last_changed is only the timestamp of the most recent registry-visible change of any kind — a lock added or removed, a nameserver edit, an abuse-contact update, or the hold itself. It does not say which. Before you put a hold-application date or any “what changed” claim in front of a client, you must confirm it with datapulse_dns_rdap_history (step 4) and datapulse_dns_dphistory (step 5). These steps are mandatory, not optional.

Trap 1 — “created ≈ last_changed means it was held at birth.” A small gap between registrationdate and last_changed usually just means the registrar set the standard locks (clientTransferProhibited / clientUpdateProhibited) a few seconds after registration — not that a hold was applied. Do not infer a hold from the timestamp gap alone.

Trap 2 — “the current last_changed is when the hold was applied.” The most recent change is frequently not the hold. For FYRIOS (below) the current forced last_changed is 2026-04-21, but that is when the registrar removed two locks — the clientHold was applied ~3 months earlier, on ~Jan 19. Reporting “hold applied April 21” is wrong on both the date and the event. Only datapulse_dns_rdap_history disambiguates this.

Worked example: FYRIOS.COM

Force the RDAP pull. Unforced datapulse_live_rdap returns the DataPulse-cached snapshot, which can lag the registry by months — for FYRIOS the difference is material:

Constant across both: registrationdate 2026-01-02T15:05:49Z, and DNS is NXDOMAIN (does not resolve) — the domain is still held. Quote the forced values to the client; the cached snapshot would have you reporting two status codes that no longer apply.

But do not stop there and report “hold applied 2026-04-21” — that forced last_changed is the lock removal, not the hold (Trap 2 above). The hold date comes only from rdap_history, next.

A naive read of an early WHOIS snapshot would see “Updated Date 2026-01-02T15:06:01Z”, 13 seconds after creation, and conclude the domain was put on hold at birth. That is wrong. datapulse_dns_rdap_history shows what actually happened:

• Snapshot 2026-01-04 — last_changed 2026-01-02T15:06:02Z, status client transfer prohibited + client update prohibited. No hold. The 13-second change was the registrar applying its standard locks, not a hold.
• Snapshot 2026-03-27 — last_changed 2026-01-19T15:18:14Z, status now includes client hold.

Correct read: FYRIOS was registered Jan 2, locked seconds later (normal), and put on client hold around Jan 19 — that is when last_changed advanced and the hold appeared. It has been dark in DNS ever since the hold, which is why it is absent from active listings.

DNS history (datapulse_dns_dphistory) corroborates the listing arc directly: DataPulse listed FYRIOS as active on 2026-01-04 (version type a: a live web service on Cloudflare plus the Google nameservers), recorded its services dropping to none (c) on 2026-02-01 after the hold suppressed DNS, and de-listed it (d) on 2026-03-01 — which is exactly why it later turned up as “missing from your listings.”

Takeaway: the current last_changed plus the current status tells you when the most recent registry-visible change happened; use datapulse_dns_rdap_history to confirm what that change was before concluding when (or why) a hold was applied.

Diagnosis Workflow

Always pass force: true on RDAP and overview calls in this workflow. Unforced datapulse_domain_overview and datapulse_live_rdap return the DataPulse-cached RDAP summary (see the researchdate field), which can lag the registry by months. The client wants current registry data, not a cached snapshot — any status codes or dates you quote back must come from a forced pull. (datapulse_live_dns is always live, so force is moot there.)

Steps 4–5 (rdap_history, dphistory) are mandatory, not optional — run them before stating any timeline. Forced RDAP gives you the current status and a single last_changed timestamp; it cannot tell you when a hold was applied or what the latest change actually was. Do not state a hold-application date, a “what changed” claim, or a listing timeline until you have run both history tools. Live DNS confirming NXDOMAIN is necessary but not sufficient — it shows the domain is dark now, not when or why.

1. datapulse_domain_overview(domain, force=true) — start here; one call returns DNS + RDAP + web scrape.
2. datapulse_live_rdap(query=domain, force=true) — read the status array for a *hold / pendingDelete / redemptionPeriod / inactive code, and note registrationdate, last_changed, expirationdate, nameservers, and the abuse contact.
3. datapulse_live_dns(domain) — confirm the domain does not resolve (NXDOMAIN, or no A/AAAA records).
4. datapulse_dns_rdap_history(domain) — required. See when the status/hold changed (what changed at each snapshot, and the last_changed at each). This is the only tool that dates when a hold was actually applied — never date a hold without it.
5. datapulse_dns_dphistory(domain) — required. The most direct evidence for “missing from listings”: its a / c / d version timeline shows when DataPulse first listed the domain as active, when its services dropped to none (went dark), and when it was removed. A once-active domain that was later held shows a → c (no services) → d, dating exactly when and why it left active listings.

Impact on Listings

A domain on hold will not appear in active listings, even if it is fully registered and visible in WHOIS/RDAP. When a hold is lifted and the domain reappears in the zone file, the next collection cycle reinstates it as an active listing (a new a version in datapulse_dns_dphistory; cycles land about monthly, see datapulse_help(topic="history")). This is intentional — listings represent domains operationally active on the internet, not merely registered.

To evidence this for a specific domain, use datapulse_dns_dphistory: a domain that was listed and then held shows an a (active) → c (services drop to none) → d (removed) version timeline — confirming it was listed and dating exactly when it left.

Common Scenarios