TR
← Back to blogGuides

How to Find Where a Website Is Hosted (and When You Can't)

Trace a website from domain to IP address to network owner, read reverse DNS, understand why CDNs hide the origin server, and know the limits of the method.

Published: · 6 min read

"Who hosts this website?" sounds like a question with a single answer. In practice the honest answer is often a short chain: the DNS is run by one company, the traffic passes through another, the server belongs to a third, and the mail has nothing to do with any of them.

This guide shows the method step by step, what each step really proves, and the point at which public data stops.

Step 1: resolve the domain to IP addresses

Everything starts with the A (IPv4) and AAAA (IPv6) records.

$ dig +short A www.example.com
192.0.2.10

$ dig +short AAAA www.example.com
2001:db8::10

On Windows, nslookup www.example.com gives the same information.

Two details are easy to miss:

  • example.com and www.example.com are different names. They often point to the same place, but not always. One may be a redirect service while the other is the real site. Check the hostname visitors actually end up on.
  • There may be a CNAME in between. If www is an alias for something like example.hosting-platform.example.net, the target name already tells you a lot. Platform and CDN hostnames are usually recognisable.
$ dig +short www.example.com
sites.platform.example.net.
192.0.2.10

Step 2: find the network that owns the IP

An IP address belongs to a block, and that block is announced to the internet by an autonomous system (AS): a network with its own routing policy and a number such as AS64500. Hosting companies, cloud providers, ISPs and large enterprises all run autonomous systems.

Mapping an address to its AS gives you:

  • the AS number and name, for example "AS64500 EXAMPLE-HOSTING"
  • the prefix the address is routed in, such as 192.0.2.0/24
  • the allocation country recorded by the regional internet registry (RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC)

For a site on ordinary shared hosting, a VPS or a cloud instance, the AS name is the answer most people are after. If the network is a well-known hosting company, that company operates the server.

Here is what it does not prove:

  • Resellers are invisible. A small hosting brand that rents servers from a large data-centre operator shows up as the large operator.
  • Cloud is not a host in the traditional sense. An AS name belonging to a big cloud provider tells you where the machine runs. It tells you nothing about who administers it.
  • The allocation country is not the server's location. It is where the organisation registered the block. A provider can use a block registered in one country in a data centre on another continent. Commercial geolocation databases try to do better, and they are educated guesses as well.

Step 3: read the reverse DNS

Reverse DNS maps an address back to a name through a PTR record.

$ dig +short -x 192.0.2.10
srv-10.fra1.hosting.example.net.

The PTR record is controlled by whoever holds the IP block, not by the owner of the website. That is what makes it useful. Providers' default names often contain their own domain, a region or data-centre code (fra1 here) and a server identifier. A custom PTR such as web01.example.com suggests a dedicated server or VPS whose owner took the trouble to set it.

Caveats: many addresses have no PTR at all, and a PTR is just a claim made by the block holder. If it matters, check that the name resolves forward to the same address.

Why CDNs and proxies hide the origin

If step 2 returns Cloudflare, Fastly, Akamai, Amazon CloudFront or a similar network, you have found the edge, not the host.

A reverse-proxy CDN works like this: the domain's DNS points at the CDN's addresses. Visitors connect to the nearest CDN location. The CDN serves cached content or forwards the request to the origin server, whose address is known only to the CDN and the site owner.

What follows from that:

  • The IP address you see is shared by a very large number of unrelated websites.
  • It is typically anycast: the same address is announced from many cities at once. Asking which country it is in has no meaningful answer.
  • The origin could be anywhere: a cloud instance, an office server, another hosting company.

This is deliberate. Hiding the origin is part of how these services protect sites from direct attack. For a CDN-fronted site, the correct answer to "where is it hosted?" is: behind that CDN; origin not publicly observable.

You will find articles describing tricks to unmask origins, such as historical DNS data, guessing subdomains, or searching certificate logs for other hosts. Sometimes they turn up a stale or misconfigured record. They are unreliable, the result is easy to get wrong, and using them to get around a protection someone put in place on purpose moves from lookup into reconnaissance. If you have a legitimate reason to reach the operator, such as abuse, a legal matter or a security report, the CDN's abuse process and the registrar's contact channels exist for exactly that.

What NS and MX records add

Two other record types help fill in the picture.

Nameservers (NS) show who runs the domain's DNS.

$ dig +short NS example.com
ns1.dns-provider.example.net.
ns2.dns-provider.example.net.
  • Nameservers belonging to a hosting company often mean the site is hosted there too, because shared hosting bundles DNS.
  • Nameservers belonging to a registrar mean only that the owner uses the registrar's default DNS.
  • Nameservers belonging to a CDN confirm that the CDN is in front.

Mail servers (MX) show where email is received. That is frequently a dedicated mail provider unrelated to the web host. If the MX points to mail.example.com on an address next to the web server, the site is probably on a classic all-in-one hosting package. The SPF record sometimes lists further services the owner sends mail through.

None of these is proof. Together they are usually enough for a sensible conclusion such as "DNS and CDN at one provider, mail at another, origin unknown".

A worked example

Suppose you look up shop.example and find:

  • www is a CNAME to shops.platform.example.net
  • the address resolves to a network named after a large cloud provider
  • reverse DNS shows a generic cloud hostname
  • NS records point to the domain's registrar
  • MX records point to a hosted email service

Reasonable reading: the shop runs on a hosted e-commerce platform (the CNAME gives it away), which itself runs on a big cloud. The owner uses registrar DNS and a separate mail provider. "Who hosts it?" has two fair answers, the platform and the cloud underneath it, and which one you need depends on why you are asking.

Limits and etiquette

  • Stick to public queries. DNS lookups, IP-to-ASN mapping and a normal HTTPS request are what every browser and resolver already does. Port scanning, brute-forcing subdomains and probing for origins are a different activity with different legal and ethical weight.
  • Do not over-read the data. A network name identifies infrastructure, not the person running a website. An allocation country is not a jurisdiction finding.
  • Report abuse through the right door. The network's abuse contact (listed in the RIR records), the CDN's abuse form and the registrar's abuse address are the channels that lead somewhere.
  • Expect change. Sites move. An answer is a snapshot with a timestamp.

Check it with OrbitProbe

The OrbitProbe IP and hosting lookup resolves a domain to its IPv4 and IPv6 addresses and shows reverse DNS, ASN, network name, prefix and allocation country for each. Addresses in known CDN and proxy ranges are labelled as edge addresses, so you do not mistake them for the origin. For nameservers, MX and registration data alongside, use the full live domain report.