IP Geolocation Lookup

A complete IP lookup returns four layers of information. Layer one is geography: country, region/state, city, latitude/longitude, and timezone. This layer is a probabilistic fit derived from geolocation databases (MaxMind GeoIP2, IP2Location, etc.) plus carrier-reported data — it is an educated guess, not GPS. Layer two is network ownership: the ASN (Autonomous System Number, e.g. AS15169 Google, AS13335 Cloudflare), registered name, and operator. This layer comes from authoritative allocation records held by the RIRs and is far more reliable than the geographic layer.

Layer three is the usage verdict: is this IP residential broadband, a datacenter, mobile cellular (4G/5G), or a hosting/VPN exit? The verdict draws on ASN type, rDNS naming patterns (keywords like static, pool, dynamic, host), port fingerprints, and known datacenter-range databases. Layer four is reputation and risk: blacklist hits, Tor exit status, and whether the IP is flagged as a proxy or abuse source.

Most free lookup sites stop at the first one or two layers. IPOK aggregates all four at once: enter any IP and you see geolocation and ASN alongside a datacenter/residential verdict and a risk score. For developers troubleshooting, cross-border sellers vetting accounts, and fraud analysts, the decision-grade value lives in layers three and four — not in a single dot on a map.

An IP's 'birth certificate' lives not in geolocation databases but in the registration databases of the five RIRs (ARIN for North America, RIPE NCC for Europe/Middle East, APNIC for Asia-Pacific, LACNIC for Latin America, AFRINIC for Africa). The traditional way to query this is the WHOIS protocol (plaintext over port 43), but WHOIS formats vary by registry, are hard to parse by machine, and have had many personal fields redacted since GDPR took effect in 2018. RDAP (Registration Data Access Protocol) is its structured successor: it returns standard JSON over HTTPS, with fields for the network range (cidr0), the assigned entity, registration and last-changed dates, the abuse contact email, and references to parent and child networks.

Reading RDAP solves problems WHOIS can't. To confirm a range truly belongs to a given cloud provider, the organization and parent-network fields are more reliable than the display name. To report an abuse source, the email in abuse-c is the official channel. To judge whether a range is freshly allocated or long-established, the registration and last-changed dates give clues — newly allocated ranges are often not yet well covered by reputation databases, so they carry a higher misclassification rate.

In practice RDAP has a few gotchas: some older ranges remain WHOIS-only and require a fallback; the record tells you who a range was assigned to, not who is currently using it (a large network may be sub-leased downstream); and geographic fields in RDAP are usually absent or only show a registration address — never treat them as the real location. Geolocation still relies on geo databases; network ownership relies on RDAP. Each has its job.

City-level error in IP geolocation is the norm, not an anomaly. The root cause: an IP carries no geographic coordinates of its own. Every location is inferred by a geo database from indirect signals — carrier allocation regions, user submissions, latency measurements. MaxMind's own documentation is explicit: country-level accuracy is high, but city-level accuracy in many regions is reference-only, and remote areas, corporate leased lines, newly allocated ranges, and mobile networks are especially unreliable.

Typical distortions: (1) Mobile cellular IPs often land at the carrier's core datacenter rather than the user's real location, so phone-data users in a small town may geolocate to the provincial capital; (2) Corporate and campus exits route through a single NAT at headquarters, so a branch thousands of miles away shows as the HQ city; (3) Anycast IPs from cloud providers and CDNs announce the same address at many points globally, so the database can only give one nominal location; (4) After a range is reassigned or resold, the database lags weeks to months behind and still shows the old owner.

So for precision-sensitive use cases (compliance geo-restrictions, anti-fraud geo-verification), don't trust a single database's city field alone. Cross-validation is sturdier: check the ASN's operator type, check rDNS, check whether the timezone is consistent with the claimed region, check whether it's a datacenter or proxy exit. IPOK aggregates multiple sources precisely for this — when one source's geolocation contradicts the network type and risk signals, that contradiction is itself a red flag worth heeding.

Developers and ops: when triaging request origins, check the ASN first to tell a real consumer ISP from a cloud/scraper datacenter; when blocking abusive traffic, acting per ASN or per /24 range is far more efficient than IP-by-IP; before configuring geo-routing or compliance blocks, verify range ownership via RDAP to avoid collateral damage. An IP that suddenly shifts from a residential ASN to a datacenter ASN in your logs is often an early signal of attack or abuse.

Cross-border e-commerce sellers: platforms are extremely sensitive to the residential/datacenter verdict on a login IP — logging into a store account from a datacenter IP can trigger risk control or even linked-account bans. Before registering or signing in, confirm the IP is residential-native, low-risk, and consistent with your target market. And if neighbors in the same /24 are heavily flagged for abuse, your otherwise-clean IP can be tarred by association — a /24 (C-block) profile surfaces that risk in advance.

VPN/proxy users: is the 'residential IP' you bought actually residential? One lookup tells you — a datacenter ASN, an rDNS containing 'datacenter', or a multi-source proxy flag all give the game away. Fraud and risk professionals can treat the lookup as a profiling entry point, where an anomalous location, datacenter exit, blacklist hit, or Tor exit each feeds a weighted score. IPOK is privacy-first and does not log the IPs you look up — which matters when you vet sensitive addresses in volume.