Find every domain hosted on any IP — reverse IP lookup, reverse DNS, and infrastructure details. Free.

Six dimensions of information about an IP, combined into a single response. Each is independently useful; together they answer most operational and investigative questions you'd ask about an unfamiliar address.

An IP address by itself is just four octets. The useful question is what's on the other end — which domains, which infrastructure, which neighbors, which provider. Reverse IP answers all of it:

• Map an organization's infrastructure footprint. Find every domain pointing at an IP you've identified as belonging to a target. Standard reconnaissance, due-diligence, and competitor-research workflow — used by everyone from SOC analysts to acquisition teams.
• Investigate phishing and malware infrastructure. Identified a malicious domain? Find every other domain on the same IP — they're often part of the same campaign. This is one of the first steps in any IoC pivot.
• Verify your hosting setup. Paying for a 'dedicated IP' or 'private server'? Run reverse IP against your IP. If 500 unrelated domains show up, you're on shared hosting regardless of what the marketing page said.
• Discover the origin behind a CDN. Sites behind Cloudflare, Akamai, or Fastly hide their real origin IP. Historical passive DNS sometimes captures the origin before the CDN was put in place — surfaceable via reverse lookups on suspected origin IPs.
• Find sibling domains you forgot you owned. Reverse-lookup your own infrastructure IPs. Catches forgotten subdomains, stale staging environments, and rogue services that never got decommissioned.

There's no single 'reverse IP' protocol. We combine three independent data sources — each with different coverage, freshness, and trust level — then deduplicate and rank:

• Stage 1 — PTR query (reverse DNS) Standard DNS PTR query against the in-addr.arpa zone (for IPv4) or ip6.arpa (for IPv6). Returns what the IP block owner has officially set — usually one hostname, sometimes none. Authoritative, but limited in coverage.
• Stage 2 — Network ownership lookup BGP routing data to identify the announcing ASN, ISP/organization, and the CIDR block being announced. Tells you who is responsible for the IP at the network level.
• Stage 3 — Passive DNS search Aggregated DNS observation data from global resolvers. For any IP, returns the domains we've seen resolve to it in the wild. Coverage is broad (most popular domains observed within hours of first appearance) but not exhaustive — domains that have never been queried publicly won't appear.
• Stage 4 — SSL Certificate Transparency search Cert SAN entries from public CT logs. If an IP's SSL certificate covers 156 domains (as 1.1.1.1's does), every one of those domains is associated with the IP — even those not yet captured by passive DNS. Very fresh; cert issuance is logged within minutes.
• Stage 5 — Live HTTP probe Direct connection to port 443 to capture the HTTP Server header, SSL cert details, and response time. Confirms the IP is actually serving HTTP and gives a fingerprint of the underlying stack (nginx, ECS load balancer, etc.).
• Stage 6 — Dedupe, score, return Merge results across all three discovery methods, dedupe, and rank by confidence. PTR is exact. Passive DNS is the most comprehensive. SSL SAN is the freshest. The combined list is what you see.

These two terms get used interchangeably, but they mean different things. Conflating them causes confusion when results don't match expectations. The shortest accurate framing: reverse DNS is what an IP says about itself; reverse IP is what the rest of the world says about it.

• Reverse DNS — a DNS protocol Defined in RFC 1035. A standard DNS PTR query against the in-addr.arpa zone. Asks: 'what hostname is this IP?' The answer is set by whoever owns the IP block (the ISP or hosting provider). Returns one hostname, usually. Authoritative — if the answer is `one.one.one.one`, that's because Cloudflare configured it to be.
• Reverse IP lookup — an aggregated data product Not a protocol. A search over external observation data. Asks: 'which hostnames POINT to this IP?' The answer comes from passive DNS feeds, SSL Certificate Transparency logs, and historical scanning data — not from the IP itself. Returns many hostnames. Best-effort, not authoritative.
• Why they disagree PTR is what the IP block owner has chosen to publish about itself — often nothing, or a generic provider-default hostname. Reverse IP is what the world has observed pointing at the IP — every domain anyone has ever pointed at this address. The two answers can be completely disjoint, and usually are.
• When to trust each PTR for protocol-level requirements (mail server delivery — most receivers require matching forward and reverse DNS), IP-block ownership verification, and any case where the IP's self-declaration matters. Reverse IP for shared-hosting discovery, sibling-domain enumeration, infrastructure mapping, and any case where you want to know what's on an IP that the IP wouldn't necessarily volunteer.
• Why this tool returns both The PTR record is shown for completeness and protocol-level use. The hosted domains list (passive DNS + SSL SAN) is shown because that's what most users searching for 'reverse IP' actually want. Different signals, different uses — exposed clearly.

The number of domains returned is itself diagnostic. Different hosting setups produce characteristic signatures. Reading the count alongside the network owner usually tells you exactly what kind of infrastructure you're looking at:

• Just a PTR, no other domains — Dedicated IP Single-tenant server, often enterprise-grade. The IP is provisioned for one customer's use. Common on AWS Elastic IPs, dedicated cloud instances, and Tier-1 hosting setups.
• 2 to 10 domains — Small VPS or multi-site setup A small VPS hosting a few related projects, an agency hosting client sites on shared infrastructure, or a single business with multiple brand domains pointing at one server. Normal and not concerning.
• 10 to 100 domains — Mid-tier shared hosting Typical for shared-hosting customers at the $5–20/month tier. Also common for accounts on a single Cloudflare or Vercel team — every site that team manages can land on the same edge IP.
• 100 to 1,000 domains — Cheap shared hosting at scale Budget shared hosting tiers (HostGator, GoDaddy, Bluehost shared plans). Also common on CDN edge nodes where many customers' sites resolve through the same Anycast IP. Not inherently bad, but performance and security posture are shared with everyone else on the box.
• 1,000+ domains — CDN, hyperscaler, or extreme shared Major CDN edge (Cloudflare, Akamai, Fastly), large cloud-provider IP, or shared hosting at the bottom of the market. The IP isn't really 'hosting' anything in the traditional sense — it's a routing endpoint that fronts thousands of unrelated customers.
• Variable / unstable count — Load balancer or Anycast Cloud load balancers, Kubernetes ingress IPs, and Anycast networks can return different domains depending on the geographic vantage point or the moment of measurement. The IP doesn't have a fixed list of hosted domains because it doesn't really host them — it just routes traffic for them.

Reverse IP isn't a perfect mirror of reality. Five categories of domains are systematically missing or misrepresented. Being explicit about this helps you interpret results correctly — and helps you understand why your domain might not appear when you expect it to.

• Domains behind a CDN proxy Cloudflare, Akamai, Fastly, and similar CDNs front-end your real origin. When you reverse-lookup your CDN-protected domain, you'll see the CDN's IP, not your actual origin server. To find your real origin, attackers (and researchers) sometimes use historical passive DNS — the IP your domain resolved to before the CDN was put in place may still be observable.
• Newly created domains Passive DNS coverage takes hours to days to catch up with newly published records. A domain registered yesterday and pointed at an IP today may not appear in reverse-IP results for a week. SSL CT log search is faster — usually visible within minutes of cert issuance.
• Domains never resolved publicly Internal-only domains, intranet hostnames, and any subdomain that has never been queried from a public resolver won't appear in passive DNS feeds. If your DNS records exist but no external client has ever asked for them, the world doesn't know.
• Deep subdomains Coverage is best at the apex and www level. Three- and four-level subdomains (e.g., `staging.eu.api.example.com`) have spottier passive DNS coverage — they're typically used internally and queried less often from public resolvers.
• Wildcard DNS records A wildcard record (`*.example.com → 1.2.3.4`) matches infinite hostnames, but only the ones actually queried get into passive DNS. The reverse-IP result will show the queried ones, not the full wildcard space — which is usually fine, but worth understanding when results look incomplete.

Every field returned on this page is available as JSON. Useful for SOC pipelines, threat-intel enrichment, hosting verification scripts, and acquisition due diligence at scale. Free tier rate-limited per IP; API keys available for high-volume use.

const res = await fetch(
  'https://api.domainscan.in/v1/ip/reverse?ip=1.1.1.1'
);
const data = await res.json();

console.log(data.ptr?.[0]?.data);                   // 'one.one.one.one'
console.log(data.hostedDomains?.length);            // count via passive DNS
console.log(data.isp?.isp);                         // 'Cloudflare'
console.log(data.isp?.asn?.number);                 // 13335
console.log(data.infrastructure?.sslDomainCount);   // 156 (cert SAN entries)
console.log(data.infrastructure?.httpServer);       // 'ECS (lga/4E8F)'
console.log(data.infrastructure?.responseTime);     // 43 (ms)

// Pivot: for each hosted domain, run a full WHOIS lookup
for (const domain of data.hostedDomains.slice(0, 10)) {
  const whois = await fetch(
    `https://api.domainscan.in/v1/lookup?domain=${domain}`
  ).then(r => r.json());
  console.log(domain, whois.details?.registrar?.name);
}

{
  "ip":      "string (the queried IP)",
  "class":   "Class A | B | C | D | E",
  "private": "boolean",

  "ptr": [
    { "name": "1.1.1.1.in-addr.arpa", "class": "IN", "type": "PTR", "ttl": 642, "data": "one.one.one.one" }
  ],

  "hostedDomains": [
    { "domain": "one.one.one.one", "source": "ptr | passive_dns | ssl_san", "firstSeen": "ISO 8601", "lastSeen": "ISO 8601" }
    /* ... more domains, deduped across discovery methods */
  ],

  "isp": {
    "isp":          "Cloudflare",
    "organization": "Cloudflare",
    "network":      "1.1.1.0/24",
    "asn":          { "number": 13335, "organization": "CLOUDFLARENET" },
    "type":         "ISP | Hosting | CDN | ...",
    "details":      "string"
  },

  "location": {
    "continent":         "string",
    "country":           { "code": "ISO 3166", "name": "string" },
    "registeredCountry": { "code": "...", "name": "..." },
    "state":             "string",
    "city":              "string",
    "location":          { "latitude": "number | null", "longitude": "number | null", "timeZone": "..." },
    "security":          { "isVPN": false, "isProxy": false, "isTorExitNode": false, "isHostingProvider": false, "isAnonymous": false }
  },

  "infrastructure": {
    "httpServer":      "string (HTTP Server header)",
    "sslCertValid":    "boolean",
    "sslDomainCount":  "number (domains in cert SAN field)",
    "sslCertExpiry":   "ISO 8601",
    "responseTime":    "number (ms)",
    "securityStatus":  "Good | Warning | Risk"
  }
}

Six patterns we see most often:

• What's the difference between reverse IP lookup and reverse DNS (PTR)? Reverse DNS is a protocol — a DNS query against the in-addr.arpa zone, returning what the IP block owner has officially configured (usually one hostname). Reverse IP lookup is an aggregated data product — a search over passive DNS observations and SSL Certificate Transparency logs, returning every hostname we've ever seen pointing at this IP (often many). PTR is what the IP says about itself; reverse IP is what the rest of the world says about it. Both are returned by this tool.
• Why does my IP show only one domain when I host many on it? Most likely you're on a CDN. If your domains all point at Cloudflare/Akamai/Fastly IPs, the reverse-IP search will return whatever the CDN provider has there — usually one PTR record, sometimes a handful of CDN-owned hostnames. To see your real domain footprint, run reverse-IP on your origin IP (the one your CDN points at internally), not the CDN edge IP that the public sees.
• Why are some of my domains missing from the results? Three common reasons. (1) The domain was never queried publicly — passive DNS only captures records that someone has actually resolved. (2) The domain is very new — passive DNS coverage takes hours to days to catch up. (3) The domain only exists as a wildcard match — wildcards aren't enumerable. If your domain has been live for a few weeks and is being queried by real users, it should appear.
• Can I find the real origin behind Cloudflare or another CDN? Sometimes. CDNs hide the origin from current DNS lookups — but the origin IP usually existed before the CDN was added, and historical passive DNS may still have it cached. If you reverse-lookup a suspected origin IP and your target domain appears, that's almost certainly the real origin. This is one of the most common practical uses of reverse IP in security research.
• How fresh is the passive DNS data? Most popular domains are observed within hours of their first DNS query. Less popular domains can take days. SSL Certificate Transparency log search is much faster — certs are logged within minutes of issuance, so any domain with a fresh certificate is usually discoverable almost immediately.
• What does a high domain count tell me? Usually that you're looking at shared infrastructure. A handful of domains is normal for single-tenant hosting; hundreds suggests cheap shared hosting; thousands almost certainly means a CDN edge node or hyperscaler routing IP. Cross-reference with the network owner: hundreds of domains on an IP owned by HostGator means shared hosting; hundreds on an IP owned by Cloudflare just means it's a CDN endpoint.
• Is reverse IP lookup legal? Yes — all the data comes from public sources (DNS queries, Certificate Transparency logs, BGP routing tables). You're not bypassing any access control or interacting with the target's infrastructure beyond a single HTTP probe. Reverse IP is used routinely by security researchers, journalists, due-diligence teams, and law enforcement. Its legitimacy isn't seriously contested.
• Can someone use reverse IP to attack my hosting? It can be the first step in mapping your infrastructure, which an attacker would do anyway via other means. The mitigations are at the layers that actually matter: a CDN/WAF in front of your origin, network-level access controls, and treating any IP that's publicly resolvable as known to attackers. Hiding your origin IP entirely is possible but requires discipline — once any DNS record has ever pointed at it, passive DNS has captured it.