When a domain misbehaves, a request lands on the wrong server, or an unfamiliar IP shows up in your logs, the instinct is to fire off a single command and hope it answers everything. It rarely does. DNS, IP ownership, geolocation, and subnet membership are four separate questions answered by four separate systems. Treating them as one lookup is how you end up confidently wrong. This guide lays out a repeatable workflow that keeps the questions — and the data sources behind them — straight.

The layered workflow

Work the problem in order. Each step feeds the next, and skipping ahead is what produces misdiagnosis.

  • 1. Resolve the hostname to A/AAAA records. Turn the name into one or more addresses. An A record returns an IPv4 address; an AAAA record returns IPv6. A name can return several of each.
  • 2. Look up the resolved IP's owner, ASN, and geolocation. An address on its own tells you nothing about who controls it. Map it to the organization that announces it, the Autonomous System Number that controls the routing, and an approximate physical location.
  • 3. Check whether the IP falls inside a known subnet/CIDR range. If you have a range you care about — an allowlist, a cloud provider's published blocks, a VPN egress range — test whether the resolved address is a member.
  • 4. For domains, pull registration/abuse data via WHOIS/RDAP. Who registered the name, when, through which registrar, and where do abuse reports go. RDAP is the modern, structured replacement for legacy WHOIS.
  • 5. Cross-check across steps. Does the ASN match the registrant's stated organization? Does geolocation contradict the registrar's country? Disagreement between layers is the signal worth chasing.
Why order matters: ownership, CIDR, and WHOIS questions all depend on the address (or name) you got from the step before. Resolve first, then attribute. If resolution itself is the problem, you stop at step 1 and debug DNS — there is nothing downstream to attribute.

Which lookups are local vs which need external data

This distinction is the difference between a tool that works offline and one that can't. Some of these operations are pure arithmetic on the bits of the address. Others have no answer encoded in the address at all — the answer lives in a remote database, and you must query it.

Local — pure math, no network

These run entirely in your browser or shell. The input fully determines the output; nothing needs to be fetched.

  • CIDR subnet calculation. Network address, broadcast address, usable host range, and total addresses for a given prefix are all derived by masking bits. 10.0.0.0/24 contains 10.0.0.0–10.0.0.255 by definition.
  • IP-format conversions. An IPv4 address is a 32-bit integer. Rendering it as dotted-decimal, binary, decimal, or hex is just choosing a base. 192.168.1.1 is 11000000.10101000.00000001.00000001 is 3232235777 is 0xC0A80101 — same number, four notations.
  • Checking if an IP is inside a CIDR by hand. Mask the candidate address with the prefix length and compare it to the network address. If they match, it's a member. No lookup required.

External — must hit the network

For these, the address or name carries no answer on its own. You are asking a remote authority a question only it can answer.

  • DNS resolution (A/AAAA). The mapping from example.com to an address lives in DNS, maintained by the domain's authoritative nameservers. There is no way to compute it locally; you must query a resolver.
  • WHOIS/RDAP registration data. Registration dates, registrant org, registrar, and abuse contacts live in registry and registrar databases. They are not derivable from the name or the address.
  • IP geolocation and ASN. Which network announces an address (its ASN) is held in routing registries; the rough physical location is held in commercial or community geo databases. The 32 bits of the address tell you nothing about either until you look them up.

The honest version of this: a CIDR calculator and an IP-format converter never need to phone home, and you should be suspicious of one that does. A hostname resolver, WHOIS client, or geo lookup fundamentally cannot work without a network call, because the answer simply isn't in the input.

DNS-over-HTTPS in the browser

A browser has no direct access to the operating system's DNS resolver — there is no gethostbyname exposed to JavaScript. So a browser-based resolver does the next best thing: it speaks DNS-over-HTTPS (DoH), sending the query as an HTTPS request to a public DoH endpoint such as dns.google or cloudflare-dns.com and parsing the JSON response.

GET https://dns.google/resolve?name=example.com&type=A
Accept: application/dns-json

{
  "Status": 0,
  "Answer": [
    { "name": "example.com.", "type": 1, "TTL": 280, "data": "93.184.215.14" }
  ]
}

The practical consequence: you are querying the global DNS through that provider's resolver, not your machine's local resolver. That has two effects worth understanding:

  • You bypass your OS resolver cache and any /etc/hosts or internal split-horizon overrides. The browser tool may show a public answer that differs from what your applications actually resolve.
  • The DoH provider's own cache and geographic location influence the result. A geo-balanced name like a CDN hostname can return different addresses depending on where the resolver sits, not where you sit.
When results disagree: if a browser DoH lookup and your local dig/nslookup return different addresses, you've likely found a caching difference, a split-horizon DNS setup, or geo-based answers — not a bug. That divergence is itself diagnostic information.

Reading the results

TTL and propagation

Every DNS record carries a TTL (time-to-live) in seconds, telling resolvers how long to cache it. A record with TTL 280 can sit in caches for nearly five minutes after a change. "Propagation delay" after a DNS edit is almost always just caches expiring at their own pace — it is not a single global push. Lower the TTL before a planned migration so changes take effect quickly.

Multiple A records

A name that returns several addresses is doing load distribution. Resolvers hand them out in rotating order (round-robin), and clients typically try the first. This is the cheapest form of load balancing and also why two lookups seconds apart can list the same addresses in a different order.

example.cdn.net.  60  IN  A  203.0.113.10
example.cdn.net.  60  IN  A  203.0.113.11
example.cdn.net.  60  IN  A  203.0.113.12

ASN identifies the controlling network

The Autonomous System Number is the authoritative answer to "who runs this address space." Each ASN is a network that announces routes via BGP. A few you'll recognize on sight:

  • AS15169 — Google
  • AS13335 — Cloudflare
  • AS16509 — Amazon (AWS)

Geolocation is best-effort — a city or country guessed from a database that can be stale or deliberately coarse, especially for cloud and VPN ranges. The ASN, by contrast, reflects who actually controls the routing, which is why it's the field to trust when you're attributing ownership.

A worked example

Say login-secure-update.example shows up in a phishing report and you want to assess it. Work the layers.

1. Resolve. An A-record lookup returns a single address:

login-secure-update.example.  300  IN  A  198.51.100.42

2. Owner / ASN / geo. Look up 198.51.100.42. Suppose it maps to a small hosting ASN with a geo hint of a country unrelated to the brand the domain is impersonating. The ASN tells you the real operator; the geo hint is a soft corroborating signal, not proof.

3. CIDR check. You maintain a list of legitimate corporate egress ranges. Test membership: is 198.51.100.42 inside 198.51.100.0/24? Mask and compare — in this case yes, the address is in that block, but that block belongs to the budget host from step 2, not to the impersonated brand. Confirmation it's hosted somewhere it shouldn't be.

4. WHOIS/RDAP. Pull registration for the domain. A creation date of three days ago and a privacy-shielded registrant are classic newly-registered-domain phishing markers. Note the abuse contact for the registrar — that's where a takedown request goes.

Domain:        login-secure-update.example
Created:       2026-06-03
Registrar:     Example Registrar, Inc.
Registrant:    REDACTED FOR PRIVACY
Abuse contact: [email protected]

5. Cross-check. Recently registered, privacy-shielded, hosted on an unrelated budget ASN in a mismatched country, impersonating a known brand in the hostname. No single field is damning; the agreement across all five layers is. You now have an abuse contact and the evidence to support a report.

Related tools

Related guides