When you look up a domain's IP address, you might assume the result tells you where the website is hosted. Often it does. But in many real-world setups, the IP address points to an intermediary — not the actual server delivering the website.
This is increasingly common and worth understanding if you're using DNS lookups as part of an investigation or infrastructure assessment. The IP address tells you where the door is. It doesn't always tell you what's behind it.
Domain to IP Lookup
Resolve all six DNS record types for any domain, auto-detect CDN providers and email infrastructure, and parse SPF/DMARC policies — all processed client-side via DNS-over-HTTPS.
Open Domain to IP LookupA Real-World Example
Consider a website originally hosted entirely on Microsoft Azure — the frontend, backend, DNS, and CDN (Azure Front Door) were all within Microsoft's ecosystem. The A record pointed to Azure Front Door, and the IP resolved to something in the 13.107.x.x range, clearly owned by Microsoft Corporation.
Later, the website's frontend was migrated to Cloudflare Pages. The HTML, CSS, and JavaScript are now served from Cloudflare's global network. But the domain's DNS remained managed in Azure, and the root domain's A record still pointed to Azure Front Door.
The result? Azure Front Door receives the incoming request, then forwards it to Cloudflare Pages as a backend origin. The traffic flow looks like this:
- User's browser makes a DNS query for the domain
- Azure DNS resolves the domain to an Azure Front Door IP
- Azure Front Door receives the HTTP request
- Cloudflare Pages actually serves the website content
If you run a Domain to IP lookup on this domain, you'll see a Microsoft IP address. You'd reasonably conclude the site is hosted on Azure. But the website content is actually delivered by Cloudflare — Azure is just a pass-through.
Investigation tip: When a DNS lookup shows a CDN or cloud provider IP, check whether that provider is the actual host or just a routing layer. Compare the root domain and www subdomain — they may resolve to different infrastructure, revealing a layered setup.
Why This Happens
This kind of layered setup is more common than you might expect. It occurs in several scenarios:
Partial Migrations
The frontend moved to a new provider, but DNS or the CDN layer hasn't been updated yet. The old infrastructure still handles traffic routing even though it's no longer serving the content. Migrations happen in phases, and it's normal for the outermost layer to lag behind.
Root Domain CNAME Restrictions
DNS standards don't allow CNAME records at the domain apex (e.g., example.com without www). Some DNS providers support workarounds like CNAME flattening or alias records, but others don't. This forces the root domain to keep an A record pointing to the old infrastructure, even when subdomains like www have already moved to the new host.
Multi-Service Domains
A domain might use one provider for its website, another for its API, and a third for email. The DNS and CDN layer may route to different backends depending on the request path, but the IP address from a lookup only reflects the outermost layer. Path-based routing at the CDN level is invisible to DNS queries.
Security and Compliance Layers
Some organisations deliberately route traffic through a WAF (Web Application Firewall), DDoS protection service, or corporate proxy before it reaches the actual hosting. The IP address reflects the protective layer, not the origin. This is a security best practice, not a misconfiguration.
Investigation tip: A domain with p=reject DMARC policy, enterprise nameservers, and a CDN-proxied IP is likely a security-conscious organization with multiple infrastructure layers. Treat each DNS record type as evidence of a different layer rather than assuming they all point to the same service.
What the IP Actually Shows
When you see an IP address from a Domain to IP lookup, you're seeing the first point of contact — the outermost layer of the infrastructure. This might be any of the following:
- The actual hosting server — for simple setups where the domain points directly to its web server
- A CDN edge node — Cloudflare, Azure Front Door, AWS CloudFront, Akamai, or Fastly
- A reverse proxy or load balancer — distributing traffic across multiple backend servers
- A WAF or DDoS mitigation service — filtering traffic before it reaches the origin
- A combination of the above — chained together in sequence
An IP lookup alone cannot tell you how many layers exist behind it. A Microsoft IP doesn't necessarily mean the website runs on Azure. A Cloudflare IP doesn't necessarily mean the origin server is managed by Cloudflare. These are entry points, not destinations.
The resolved IP address is accurate — it correctly identifies the server your browser connects to first. But "where the connection goes" and "where the content lives" are different questions in modern infrastructure. Always consider whether the IP represents the host or just a gateway.
How to Dig Deeper
If you need to understand the full hosting chain rather than just the outermost layer, several techniques can help:
Check HTTP Response Headers
Headers like Server, X-Served-By, CF-Ray (Cloudflare), X-Azure-Ref (Azure Front Door), or X-Cache can reveal which platforms are involved in serving the response — even when the IP suggests a different provider. Multiple provider-specific headers in the same response are a strong indicator of layered infrastructure.
Compare Root Domain and www Subdomain
In the example above, the root domain pointed to Azure while www had a CNAME pointing directly to Cloudflare Pages. Differences between root and subdomain resolution often indicate a layered or mid-migration setup. The Domain to IP Lookup tool resolves both A and CNAME records, making this comparison straightforward.
Follow CNAME Chains
If a subdomain has a CNAME record, follow the chain. It may resolve through multiple services before reaching a final A record. Each hop in the chain can reveal a different layer of infrastructure. A CNAME from www to something.azurefd.net to something.cloudflare.pages.dev tells a clear story of traffic flowing through Azure Front Door to Cloudflare.
Check Nameservers
The nameserver provider tells you who manages DNS, which is not always the same as who hosts the website. A domain using Azure DNS with a Cloudflare-hosted site will show Microsoft nameservers despite Cloudflare delivering the content. NS records reveal one layer; A records reveal another.
Inspect TLS Certificate Details
The SSL/TLS certificate served by the site can indicate which platform issued it. A certificate from DigiCert might suggest Azure or an enterprise CDN, while a Let's Encrypt certificate issued by Cloudflare confirms Cloudflare is in the serving chain. Mismatches between the certificate issuer and the IP owner are a strong signal of layered infrastructure.
IP Lookup
Take any resolved IP from your DNS lookup and investigate it further — get geolocation, ISP details, ASN data, and VPN/proxy detection in a signed PDF report.
Open IP LookupKey Takeaway
A Domain to IP lookup gives you the resolved IP address at the time of the query — this is accurate and useful. But it reflects the outermost layer of potentially complex infrastructure. For investigative purposes, treat a DNS lookup as a starting point, not a conclusion. Combine it with header analysis, CNAME inspection, certificate checks, and subdomain comparison to build a fuller picture of where a website's content actually lives.
