The phrase "reverse IP lookup" sounds more definitive than it is. An ordinary DNS lookup starts with a name and asks for records such as A or AAAA. DNS has no current standard query that starts with an IP address and enumerates every name whose A or AAAA record points there. The old IQUERY operation was retired by RFC 3425 because DNS data is indexed by name, not by value. Reverse IP services therefore search a separately assembled dataset. Their answers are only as complete, current and well sourced as that dataset.
DomScan's /v1/reverse/ip endpoint has a deliberately narrow dataset and is deprecated. It can surface recent domain observations made through DomScan, but it cannot discover all domains on an IP, reconstruct historical DNS, or prove that two domains share an owner or origin server. Treat its results as leads for further investigation.
What the deprecated endpoint actually searches
The endpoint searches a best-effort per-IP index populated only when /v1/dns/all successfully observes A or AAAA answers. It does not continuously crawl DNS, consume an internet-wide passive DNS feed, ingest Certificate Transparency logs, or scan the public internet. A domain that nobody has looked up through that DomScan route will not be present solely because it currently resolves to the requested IP.
Each IP retains at most 10,000 recent entries. An observation refreshes that IP's seven-day retention window and moves the observed domain to the newest end of the list. Index writes are intentionally best effort, so a failed write does not make the original DNS request fail. That design protects the DNS lookup, but it also means gaps are possible.
The TTL belongs to the whole per-IP key, not to each domain in its list. A new write rewrites the list and resets the key's TTL, so an older member can remain while other observations keep the key alive. Per-domain enrichment expires separately. Seven days describes the index mechanism, not a guarantee that every returned row was observed during the past seven days.
Reverse IP is not an inverse DNS query
A and AAAA records map names to IPv4 and IPv6 addresses. PTR records provide a separate address-to-name mechanism under in-addr.arpa for IPv4 and ip6.arpa for IPv6. RFC 1035 also notes that reverse zones can be inconsistent. A PTR answer is therefore not a list of every forward-DNS name using an address, and a reverse IP dataset is not a substitute for PTR.
Other products may build broader datasets from recursive DNS observations, Certificate Transparency, web crawls or active internet scans. Those are separate collection methods with different coverage and legal or operational considerations. Certificate Transparency, for example, records publicly trusted certificate activity. It does not by itself provide a current domain-to-IP map. DomScan's deprecated reverse endpoint does not claim any of those broader sources.
How DomScan records an observation
- A client requests /v1/dns/all for a domain.
- The DNS result contains one or more successful A or AAAA answers.
- DomScan canonicalizes each observed IPv4 or IPv6 address before indexing it.
- The domain is added or moved to the recent end of that IP's index.
- The index keeps no more than 10,000 entries and uses a best-effort seven-day retention window.
Canonicalization matters most for IPv6 because the same address can be written with different compression and leading-zero forms. It also gives IPv4 input one consistent representation. A valid equivalent spelling should reach the same index entry. Invalid IP input is rejected rather than searched as text.
Making a request
The required input is an IPv4 or IPv6 address. limit must be an integer from 1 to 1,000 and defaults to 100. dedupe_apex defaults to true. Set it to false when observed hostnames, rather than one representative per registrable apex, are important to your analysis.
curl -G 'https://domscan.net/v1/reverse/ip' \
-H 'X-API-Key: YOUR_API_KEY' \
--data-urlencode 'ip=203.0.113.42' \
--data-urlencode 'limit=100' \
--data-urlencode 'dedupe_apex=true'Legacy ASN, CIDR, cursor, expansion and cache-preference parameters are not part of this IP lookup contract. The response reports expand as none, returns no next cursor and leaves IP context null.
Reading the response
{
"query": {
"ip": "203.0.113.42",
"asn": null,
"expand": "none",
"dedupe_apex": true
},
"deprecated": true,
"deprecation_notice": "This endpoint is deprecated. It only searches a best-effort seven-day passive index populated by prior /v1/dns/all lookups and capped at 10,000 recent entries per key. It is not an internet-wide reverse DNS dataset.",
"ip_context": null,
"results": [
{
"domain": "status.example.com",
"apex": "example.com",
"ips": ["203.0.113.42"],
"last_seen": "2026-07-10T08:25:00.000Z",
"reason": {
"type": "ON_IP",
"matched": "203.0.113.42",
"source": "A/AAAA"
}
},
{
"domain": "shop.example.net",
"apex": "example.net",
"ips": ["203.0.113.42"],
"last_seen": null,
"reason": {
"type": "ON_IP",
"matched": "203.0.113.42",
"source": "A/AAAA"
}
}
],
"summary": {
"total_found": 2,
"returned": 2
},
"coverage_summary": {
"source": "passive_dns",
"cache_status": "passive_cache_only",
"passive_index": true,
"result_count": 2,
"returned_count": 2,
"apex_deduped_count": 0,
"warning_count": 1,
"warnings": ["passive_cache_only"],
"last_seen_span_days": null
},
"page": {
"limit": 100,
"next_cursor": null
},
"meta": {
"generated_at": "2026-07-10T08:25:12.000Z",
"source": "passive_dns",
"query_time_ms": 12,
"note": "Best-effort seven-day index populated only by prior /v1/dns/all lookups"
},
"cache": {
"hit": null,
"age_s": null,
"ttl_s": null,
"key": null
}
}This illustrative example follows the live response shape. domain is the observed hostname, apex is its registrable-domain grouping, ips contains the domain's most recently stored canonical A and AAAA answers, and reason.matched contains the canonical IP used for this query. last_seen comes from the domain enrichment record and can be null when that record is unavailable. It is not a first-seen date, registration date or proof that the matched address still resolves now.
summary.total_found and coverage_summary.result_count describe the raw index size before the request's limit and apex deduplication. summary.returned and returned_count describe the final rows. coverage_summary also reports the source, cache-only status, index availability, warnings and the effect of deduplication. last_seen_span_days is calculated from non-null timestamps in the limited raw result window and is null when fewer than two timestamps are available. If the index cannot be read, the source becomes passive_dns_unavailable, passive_index is false and DomScan returns no unverified result rows. The endpoint does not return an ASN, hosting provider, CDN classification, domain owner or complete history. Use separate tools and sources for that context.
Limit is applied before apex deduplication
The endpoint first selects the newest raw entries up to limit, then applies dedupe_apex when it is enabled. It does not scan older entries to refill the response after duplicates collapse. For example, if the newest 100 hostnames belong to 20 apex domains, a request with limit=100 can return 20 rows even when older distinct apex domains exist in the index.
This ordering favors recency and keeps request cost bounded, but it affects analysis. Compare result_count, returned_count and apex_deduped_count in coverage_summary. If hostname-level detail matters, repeat the request with dedupe_apex=false. Raising limit can expose more recent raw entries, up to the maximum of 1,000 per request, but it still cannot make the underlying index exhaustive.
What a shared IP does and does not prove
Modern hosting routinely serves many hostnames through one IP address. HTTP uses the request authority, commonly carried in the Host header, to select a virtual host. TLS can use Server Name Indication to select configuration before the encrypted HTTP request arrives. Load balancers, reverse proxies and network address translation add further layers between the public IP and an origin.
Two observed domains on the same IP may share a front end while belonging to unrelated customers, applications or owners. They may reach different origin systems behind that front end. Conversely, one site may use several addresses for availability or regional routing. An IP association is useful infrastructure evidence, but the phrase "hosted on the same server" is often too strong.
CDNs and reverse proxies can hide the origin
A proxied DNS record can return the CDN or reverse proxy's edge address instead of the origin. Cloudflare documents that proxied A, AAAA and CNAME records answer with Cloudflare anycast addresses, while DNS-only records answer with the origin address. Many unrelated customers can therefore appear together on an edge IP.
Do not infer common control from that cluster. Check the IP with DomScan's IP Lookup, compare it with the provider's published address ranges, inspect the target domains directly and look for independent evidence. Even when an address belongs to a known CDN, a reverse observation can still be useful for triage. It simply describes an observed edge association, not the hidden origin.
PTR is a different question
A PTR lookup asks the address holder's reverse DNS zone for a name. It may return no name, one name or multiple names, and that data is administered separately from the forward records of unrelated domains. It does not enumerate all A or AAAA records that point to the address. Likewise, finding a hostname in DomScan's observation index says nothing about whether the IP has a matching PTR record.
For IPv4, reverse DNS uses in-addr.arpa. For IPv6, it uses nibble-reversed names under ip6.arpa as specified by RFC 3596. DomScan canonicalizes both address families for its observation index, but that normalization does not turn the endpoint into a PTR service.
A careful investigation workflow
- Start with a current A or AAAA lookup for the domain or with a known IP from a trusted event.
- Query /v1/reverse/ip knowing that it covers only recent DomScan /v1/dns/all observations.
- Read the deprecation notice, coverage warnings, raw counts, returned counts and nullable last_seen values.
- Choose dedupe_apex=true for apex-level grouping or false for observed hostname detail, remembering that limit comes first.
- Classify the IP separately by provider, ASN and known CDN range.
- Re-resolve interesting domains and compare TLS certificates, HTTP behavior, content and other lawful ownership evidence.
- Record the observation time and your uncertainty instead of presenting the result as a complete inventory.
For incident response, the endpoint can help generate candidate domains from an IP seen in logs. For brand or fraud research, it can reveal a recent association worth checking. In both cases, corroboration matters. A matching IP can be caused by commodity hosting, a shared reverse proxy or a short-lived DNS configuration.
Freshness and absence
DNS changes quickly, but this endpoint does not continuously re-resolve indexed domains. Because the TTL is attached to the whole IP key, a listed member can be older than seven days when other observations keep that key alive. last_seen can also be null. Always perform a fresh DNS lookup before making a current-state claim.
Absence is even less conclusive. A missing domain may never have been queried through /v1/dns/all, its observation may have expired, its index write may have failed, or it may have fallen outside the per-IP cap or request limit. The safe conclusion is "not returned by this query," not "not associated with this IP."
Questions people usually ask
Does reverse IP find every domain on an address?
No. There is no standard DNS query for that inventory, and DomScan searches only its recent best-effort observation index. The endpoint can return useful candidates, not a complete population.
Is this an internet-wide passive DNS service?
No. The source is limited to successful A and AAAA answers observed through DomScan's /v1/dns/all route. It is lookup driven, stored under per-IP keys with a best-effort seven-day TTL that refreshes on new observations, and capped at 10,000 recent entries per IP.
Is reverse IP the same as reverse DNS or PTR?
No. PTR is a DNS record in the address holder's reverse zone. DomScan's reverse IP endpoint searches previously observed forward A and AAAA relationships. Neither answer should be treated as an exhaustive substitute for the other.
Why did I receive fewer results than my limit?
With dedupe_apex enabled, DomScan applies the limit to recent raw hostnames first and then keeps one row per apex. Duplicate apex domains are not replaced with older entries, so the final row count can be lower than the requested limit.
Does a result prove two domains share an owner?
No. Shared hosting, CDNs and reverse proxies routinely put unrelated domains on the same public IP. Confirm ownership or operational control with independent evidence.
Using the result responsibly
The deprecated endpoint is most useful as a small, recent lead generator for existing DomScan integrations. Preserve its coverage metadata, distinguish null evidence from positive evidence and avoid completeness language in reports. Pair each interesting result with a fresh DNS lookup and separate network context before drawing conclusions.