Lookup · live DNS + ASN

What's hosting this site?

Resolve any hostname to its IPs and find the ASN, geo, reverse DNS, and cloud provider behind each one — Cloudflare, AWS, Google Cloud, Vercel, Fastly, Azure, you name it.

Resolves A + AAAA via Cloudflare DoH

What this tool reveals

Every website lives on at least one server, that server has at least one IP address, and every IP belongs to an Autonomous System (an ASN) operated by some organization. This tool walks that chain from a hostname you know — like example.com — out to all the IP addresses serving it, then back to who runs those IPs. It resolves the host's A (IPv4) and AAAA (IPv6) records over DNS, follows any CNAME aliases, and for each resulting address looks up the network behind it.

For each IP found in the A or AAAA records, we surface:

  • Address family — v4 or v6. Modern sites are dual-stack; v4-only sites are still common but increasingly notable as IPv6 deployment grows.
  • Approximate geo — the city and country a geo-IP database places the address in. For CDN edges this is the nearest point of presence, not the origin.
  • ASN and organization — the network operator. AS13335 Cloudflare means the site is fronted by Cloudflare; AS16509 Amazon.com means an AWS-hosted server.
  • Reverse DNS (PTR) — the name the IP claims for itself. A useful tie-breaker when the ASN alone is ambiguous, since a hostname like vercel-edge-fra1.vercel.app can identify the real provider even when the announcing ASN is a CDN's.
  • Cloud-provider detection — when the ASN matches a known cloud brand we tag it, so you can tell at a glance that a site is “on AWS” or “behind Cloudflare” without decoding the raw ASN yourself.

How the detection actually works

There's no single registry that says “this IP is hosted on Provider X.” We infer it. First, DNS resolution turns the hostname into a set of addresses. Each address is then matched against routing data to find its ASN — the network that announces the IP block to the rest of the internet via BGP. Big providers operate well-known, stable ASNs (Cloudflare is AS13335, Amazon AS16509, Google AS15169), so an ASN match is a strong signal. Where the ASN is generic transit, the reverse-DNS hostname and geo become the deciding clues. This is why detection is rock-solid for the major clouds and fuzzier for small regional hosts or bare-metal setups whose IPs sit on an upstream ISP's ASN rather than a recognizable brand.

Why CDN-fronted sites look the way they do

A large share of the popular web sits behind Cloudflare, Fastly, AWS CloudFront, Akamai, or similar. When you look up a CDN-fronted site, the IPs you see are the CDN's anycast edges — not the origin server. That is normal, and those edges are genuinely what serves your visitors' requests, so for most purposes the CDN is the host. Finding the origin hidden behind a CDN is sometimes possible through DNS history, mail-server IPs, or certificate-transparency logs, but it is a separate exercise and often defeats the very protection the CDN exists to provide.

What this is not

  • Not a CMS or tech-stack detector. Knowing the IP is Vercel doesn't tell you whether the site is Next.js, Astro, or static files. That requires fetching the HTML and matching fingerprints.
  • Not a real-time monitor. Each lookup is a snapshot. Sites switch providers, so a result from a year ago may not reflect today.
  • Not authoritative for the legal owner. The ASN tells you which network operates the IP; legal ownership of the name lives at the domain-registration layer. Use the domain age checker for that.

Frequently asked questions

How accurate is the cloud-provider detection?

Very accurate for the big players — Cloudflare, AWS, Google Cloud, Azure, Fastly, Akamai, Vercel, Netlify — because their ASNs are well known and stable. It's less precise for small regional providers or self-hosted setups, where the IP sits on a generic transit ISP's ASN rather than a recognizable cloud brand.

What if the site is behind a CDN?

You'll see the CDN's IPs, not the origin's — which is almost always what you want, since the CDN really is doing the hosting for visitors. Reaching the origin behind a CDN means bypassing it (mail records, historical DNS, certificate-transparency logs), and doing that for a site you don't own can be ethically questionable.

Why do some sites resolve to multiple IPs?

Anything large uses multiple IPs for load balancing and redundancy; DNS usually returns several A records in rotating order so different clients hit different servers. Anycast networks return the same handful of IPs everywhere, but each one is announced from many physical locations, so users still reach different points of presence.

JSON API

Everything above is machine-readable: GET /api/hosting/<hostname>. It's CORS-enabled and edge-cached, returning the resolved IPs, ASN, geo, reverse DNS, and detected provider as JSON — handy for inventory scripts or monitoring a fleet of domains.

Related tools

Pair this with the domain age checker for registration and registrar details, the DNS lookup to query any record type directly, WHOIS / RDAP for the owner of a single IP, the reverse DNS tool to resolve an address back to a name, and what is a CDN for why so many sites land on Cloudflare, Fastly, or CloudFront.