About this tool

What you get back

All DNS records for the domain — A, AAAA, MX, NS, TXT, SOA, CNAME — pulled in parallel from Cloudflare's public resolver.
Server identification — for each IP found in those records, the netblock owner (the actual company that owns the IP range), the CIDR, and where possible the abuse contact and country.
Role labeling — each server is tagged web (from A/AAAA records), mail (from MX records resolved to IPs), or DNS (from NS records resolved to IPs). One IP can have multiple roles if it's serving multiple things.

What this is good for

Migration planning. You're moving a customer to a new host — you need to know whether their web, mail, and DNS are at the same provider or different ones. This shows you in 3 seconds.
"Where is this site actually hosted?" Marketing sites with private WHOIS often hide everything; the IP ownership tells you the real story (Squarespace, Wix, WordPress.com, Shopify, custom AWS, etc.).
Phishing investigation. If a phishing domain points its mail server at a hosting provider you can report abuse to — this shows you the abuse contact email.
Outage debugging. When a partner's site is down, this tells you whose support to call (their hosting provider, not them).

Limitations — the honest part

Some IPs won't resolve. Public RDAP servers (ARIN, RIPE, etc.) sometimes block bursts of requests from the same source IP. We retry across multiple servers but a fraction of lookups still fail, especially for shared CDN ranges (Cloudflare, Google, Akamai). Hit lookup again in a minute and missing rows usually fill in.
Postal addresses are usually empty for cloud IPs. AWS, Azure, GCP, etc. don't publish street addresses for their netblocks via RDAP. ARIN-allocated IPs sometimes have addresses; RIPE (Europe) hides them per GDPR.
20 IP cap. Domains with huge mail or DNS pools (Slack-tier infrastructure) get truncated to the first 20 IPs to stay within Cloudflare Workers' subrequest budget. We tag the response so you know there were more.
No DNS history. This tool shows current DNS only. Historical DNS records would require a paid data source like SecurityTrails or DNSDB and aren't free to provide. For now, snapshot a domain's records here, save the JSON, and compare yourself.
CNAME flattening. If the A record is actually a CNAME chain, we follow Cloudflare's resolver's flattening — same answer most consumer DNS resolvers would give.

How netblock ownership works

Every IP address on the public internet is part of a "netblock" allocated by one of five Regional Internet Registries: ARIN (North America), RIPE (Europe/Middle East), APNIC (Asia/Pacific), LACNIC (Latin America), AFRINIC (Africa). Those registries publish ownership data via the Registration Data Access Protocol (RDAP, RFC 7480-7484, the modern replacement for WHOIS). We query rdap.arin.net for every IP, which automatically redirects to the right RIR for IPs not allocated by ARIN. The result tells us which company holds the allocation, which gives us the hosting/network operator's identity.

Compare with WHOIS Lookup

If you only need who registered the domain itself — the registrar, expiration date, name servers — use the simpler and faster WHOIS / Domain Lookup. This tool (Domain Infrastructure) is the heavier sibling: it pulls all DNS records and looks up every IP's netblock owner. Use WHOIS for the "what registrar?" question, use this for the "where is everything actually hosted?" question.

Where the tool's inspiration came from

NirSoft's DomainHostingView, for Windows, has been my go-to for years when I want a single view of everything about a domain's infrastructure. It pulls DNS records, looks up each IP's network owner via ARIN, and displays the whole thing in one table. It's the fastest way to answer "who actually hosts this?" for domains you don't recognize.

The problem is it's a Windows-only utility that hasn't been meaningfully updated in years and requires downloading and running executable software just to look up basic information. For anyone on macOS, Linux, or a phone, or anyone who doesn't want to run unknown-provenance Windows binaries, there's been no equivalent tool. This site's Domain Infrastructure Lookup fills that gap by doing the same fundamental work through browser-accessible APIs.

How the pieces fit together

DNS records via DoH

The tool queries Cloudflare's DNS-over-HTTPS endpoint for all common record types in parallel: A, AAAA, MX, NS, TXT, SOA, and CNAME. DoH means the queries are encrypted between your browser and Cloudflare, and each query is a single HTTP request rather than the traditional UDP DNS query.

The result is a comprehensive picture of what the domain has published in DNS. For a well-configured domain, you'll see:

A/AAAA records pointing at web servers
MX records pointing at mail servers
NS records identifying the authoritative DNS provider
TXT records including SPF, DMARC, and various service verification tokens
SOA record showing the primary NS and administrative contact

MX-to-IP resolution

MX records point at hostnames, not IPs. To identify who hosts the mail service, we resolve each MX hostname to its IPs (another set of DoH queries in parallel). The result is a mapping from mail server hostname to actual IPs, which we then look up individually for ownership.

NS-to-IP resolution

Same treatment for NS records. Each nameserver hostname is resolved to its IPs so we can identify the DNS provider by netblock ownership.

Per-IP RDAP queries

Each unique IP found across all record types is looked up via RDAP against ARIN (which auto-redirects to the appropriate regional registry — RIPE, APNIC, LACNIC, or AFRINIC — for IPs allocated by non-ARIN registries). The RDAP response tells us:

The network handle (like WPENG for WPEngine IPs)
The organization name (like "WPEngine, Inc." or "Amazon.com, Inc.")
The CIDR of the netblock
The address range
The abuse contact email

Role labeling

Each IP is tagged with the role it plays: web (from A/AAAA records), mail (from MX records resolved to IPs), or DNS (from NS records resolved to IPs). One IP can have multiple roles if it's serving multiple things — a small-business setup where one server hosts web, mail, and DNS all in one place would show a single IP with all three tags.

What the results reveal in practice

A typical modern setup

Web at Cloudflare or a CDN, mail at Google Workspace or Microsoft 365, DNS at Cloudflare or Route 53. Three different providers doing three different jobs. The infrastructure lookup shows this clearly and lets you understand what services the domain depends on.

Everything at one hosting provider

Small business setups sometimes have web, mail, and DNS all at the same hosting company. This is simpler to manage but creates a single point of failure — if the hosting company goes down or has an issue, everything breaks at once. The infrastructure lookup makes this concentration visible.

Web and mail at same provider, DNS elsewhere

Common for domains that have moved to Cloudflare or Route 53 for DNS while keeping their original web and mail hosting. Signals recent modernization of the DNS layer.

Suspicious phishing setup

Web at a cheap VPS provider, mail on the same VPS, DNS at a bulk registrar's default DNS. This concentration on a single cheap provider is common for phishing operations because they need to spin up new domains cheaply and quickly. Legitimate businesses typically distribute across specialized providers.

Where I use this tool

Onboarding a new customer

When taking on IT for a business, the infrastructure lookup gives me the whole picture of their domain in about five seconds. I know who hosts their web, mail, and DNS, which tells me who I need to have credentials for and who to contact for changes.

Investigating a suspicious sender

A phishing email arrives claiming to be from a business partner. Running their domain through this tool tells me if the mail server is actually where I'd expect — the real business's Microsoft 365 or Google Workspace — or if it's at some unrelated VPS provider. Mismatches are red flags.

Assessing a domain for acquisition

If I'm considering buying a domain from someone or taking over management of an existing one, the infrastructure lookup shows me what services depend on it and how it's currently set up. This helps plan the migration.

Diagnosing an outage

If a customer's site is down, is it their web hosting, their DNS, or their upstream network? The infrastructure lookup helps me see who runs each piece so I can look at the right status page or contact the right support team.

Confirming a security assertion

A vendor claims their infrastructure is "hosted at AWS with global CDN." Running the infrastructure lookup either confirms this (real AWS IPs, real CDN provider) or reveals the claim is inflated (a single VPS with a marketing website in front).

The limits of what RDAP can tell you

Address information is sparse for cloud IPs

ARIN publishes physical addresses for legacy IP allocations. Cloud providers (AWS, Azure, GCP, Cloudflare, etc.) usually don't publish per-netblock addresses. The Address field in the results will be empty for most modern cloud IPs.

European IPs hide personal contact info

RIPE (Europe) redacts personal information per GDPR. Corporate ownership is still visible; individual contact details are not. This is intentional and standard.

Some CDN and shared-hosting IPs are opaque

An IP owned by Cloudflare or a large shared-hosting provider doesn't tell you which specific customer is behind that IP. You know it's Cloudflare's edge, but you don't know whose site it's serving unless the site's TLS certificate reveals it.

Historical ownership isn't available

RDAP shows current allocation. If an IP block was reassigned in the past, historical ownership requires paid databases (SecurityTrails, Farsight, etc.).

Rate limits and reliability

Public RDAP endpoints have rate limits. This tool caps at 20 unique IPs per lookup to stay under Cloudflare Workers' subrequest budget and to avoid overloading the RDAP endpoints. Domains with very large mail or DNS pools (Slack-tier infrastructure with dozens of MX records) get truncated to the first 20 IPs, with the response indicating that truncation occurred.

The RDAP endpoints (ARIN and rdap.org) sometimes rate-limit bursts of requests from cloud infrastructure. When this happens, some IPs in the result show as "Couldn't identify owner" rather than being resolved. Retrying the lookup a minute or two later usually fills in the missing entries, since results are cached individually per IP.

Related tools

For just the DNS records (not the IP ownership), use the simpler DNS Lookup tool. For just the registrar and expiration information about the domain, use WHOIS Lookup. For checking DNS propagation across multiple resolvers, use DNS Propagation Checker.

For confirming a specific IP's ownership (when you have the IP but want to look up its details directly), the IP Lookup tool provides the same underlying data in a single-IP-focused view.

Privacy

Queries run from our Cloudflare Worker to public DNS resolvers and public RDAP endpoints. The queries transmit only the domain and the IPs being looked up. No identifying information about who submitted the query is transmitted. Results are shown only to you and not retained beyond standard analytics.