IP Lookup Explained: What an IP Address Lookup Really Tells You

01 / Scope

What an IP lookup actually does

A lookup is not a probe. Supplying an address to an IP intelligence tool does not require a ping, port scan, or connection to the host using that address. The tool asks other systems about the address: routing collectors, RPKI data, RIR registration services, DNS, and location databases. The target host does not need to respond for those lookups to work.

That distinction helps classify the output. Some values are deterministic: IPv4 versus IPv6, special-use scope, or whether an address falls inside a known prefix. Some are observations from external systems: a BGP collector’s current view or a PTR answer returned by DNS. RDAP is administrative registry data. Geolocation and network-type labels are inferences built from external evidence. They have different failure modes, update schedules, and levels of confidence.

Freshness also differs by source. A route collector may lag a routing change or simply lack a path visible from another vantage point. A live DNS query can still encounter caching elsewhere in the chain. Registry data changes when the responsible registry or registrant updates it. Geolocation changes on the vendor’s own release cadence. A timestamp without the source behind it is not enough to judge freshness.

02 / Classification

Start with the address itself

Before enrichment, classify the address. The two first questions are simple: which address family is this, and does the address belong to globally usable unicast space or to a special-purpose range?

IPv4 uses 32-bit addresses. IPv6 uses 128-bit addresses. That difference changes notation, address planning, and the surrounding data available for a lookup, but it does not change the basic discipline: first decide whether global routing, registry, and geolocation data are even meaningful for the input.

The 100.64.0.0/10 range deserves care. RFC 6598 reserves it as Shared Address Space for provider use, commonly between a subscriber edge and carrier-grade translation. Seeing a WAN address there while an external service sees a different public IPv4 is a strong CGNAT indicator. The address alone, however, does not prove a particular provider topology.

A well-built lookup stops or changes its interpretation for special-purpose space. Asking a geolocation database where 192.168.1.24 is located is meaningless because the same address can exist in millions of unrelated private networks — see What Is an IP Address? for the full addressing model. The current IANA IPv4 and IPv6 Special-Purpose Address Registries are the reference point for these classifications.

03 / Prefix

Why the covering prefix matters

BGP exchanges reachability for prefixes, not for an abstract concept of “IP ownership.” For a supplied address, the routing question is: what is the most-specific route visible from the collector that covers this destination?

Host routes are real. IPv4 /32 and IPv6 /128 routes are common inside networks and can also appear in specialized interdomain designs. On the public Internet, operational filtering often limits how far very specific announcements propagate; /24 for IPv4 and /48 for IPv6 are common filtering thresholds, not universal laws. Policy differs by network and relationship.

The selected covering route defines the granularity of the routing facts shown by the lookup. If the collector sees 203.0.113.0/24 as the best covering route for an address, the origin AS and RPKI state belong to that route. Reputation and geolocation do not have to use the same granularity; commercial datasets can distinguish addresses or smaller ranges inside one routed prefix.

04 / ASN

What the ASN and origin AS tell you

An Autonomous System Number identifies an autonomous system participating in interdomain routing. In ordinary BGP interpretation, the origin AS is the AS at the origin end of the AS_PATH for the announcement. Real routing includes edge cases such as confederations, AS-path rewriting, and multiple-origin prefixes, so a serious lookup should not force every prefix into a simplistic “one address, one ASN forever” model.

The origin AS is usually the most useful first routing field because it establishes operator context. A national broadband network, mobile carrier, hyperscaler, university, CDN, and small hosting provider create very different priors for what the rest of the lookup means.

It is not a location field. Large ASes operate in many countries and announce many independent address blocks. It is not a legal ownership field either. Address space can be allocated to one organization and routed by another through leasing, customer announcements, acquisitions, managed services, or network restructuring. If multiple origin ASNs are observed for the same prefix, that is a multiple-origin situation that requires context before it is treated as an incident.

05 / Routing

How BGP routing data changes the lookup

BGP is the control-plane protocol autonomous systems use to exchange reachability information. A route collector records the BGP paths visible from its peers. A lookup can then ask which covering prefix and origin AS are visible for the supplied address. That view is extremely useful, but it is still a collector view, not a synchronized snapshot of every router on the Internet.

Keep the control plane and forwarding plane separate. BGP selects and distributes routing information. Routers install selected routes into their local Routing Information Base and Forwarding Information Base according to platform and policy; packets are forwarded from the FIB, not by querying BGP for every packet. During convergence, policy changes, or failures, different networks can temporarily hold different views.

The first check is not “does the exact RDAP allocation appear in BGP?” It is “is there a usable covering route visible for this address, and what is the most specific one?” A more-specific route can sit inside a larger registered block, while a registered block may be carried only by a less-specific aggregate.

If no covering route is visible from the collectors used by the lookup, treat that as a routing clue rather than courtroom proof. A source address with no globally visible return route can result from spoofing, a logging artifact, a private or tunneled context, or collector visibility limits. Likewise, a new more-specific announcement or a sudden origin change deserves investigation, but traffic engineering, migration, and policy changes are legitimate explanations too.

Anycast adds another constraint. The same prefix can be announced from multiple physical sites so that routing selects a nearby instance. The lookup can show the route context; it cannot infer which anycast site a user in another part of the world will reach without path measurements from that user’s vantage point.

06 / RPKI

What RPKI validation actually means

RPKI Route Origin Validation answers one narrow question: is the origin AS observed for this route authorized by the validated RPKI data covering the prefix?

A Route Origin Authorization is a signed RPKI object. Under the current ROA profile in RFC 9582, one ROA identifies an AS and can carry one or more IP address prefixes; each prefix entry can constrain the maximum prefix length that AS is authorized to originate. A validator verifies the RPKI repository objects and produces validated payloads that routing software or a lookup can compare with observed BGP announcements.

The three familiar outcomes have precise meanings.

• Valid — the observed route is covered by validated RPKI data that authorizes the origin AS and permits the announced prefix length.
• Invalid — validated authorization data covers the address space, but no applicable authorization matches the observed origin and prefix length. Common causes include an origin mismatch, an announcement more specific than the permitted maximum length, stale authorization, or operator configuration error. A hijack is possible, but the state alone does not diagnose intent.
• Not Found — no validated authorization covers the route. RPKI therefore provides no origin-authorization verdict for that announcement. Not Found is not a security warning by itself.

Do not read more into the result. RPKI Valid does not mean the host is safe, the organization is trustworthy, the geolocation is correct, or the rest of the AS path has been validated. Route Origin Validation validates the prefix-origin relationship. It does not authenticate every AS hop in the path.

IPRevealed’s current IP Lookup reports this layer separately and obtains Route Origin Validation from its independent US1 RPKI service. That separation is correct: RPKI belongs next to the route, not next to host-security or reputation claims.

07 / RDAP

RDAP, WHOIS and RIR registration

Registration answers an administrative question: what does the responsible Internet registry record about this address block? It does not answer which AS is currently carrying the route or where the addresses are physically deployed.

The five Regional Internet Registries are ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. Their records describe number-resource allocations and assignments within the regions and hierarchies they administer. Terminology and field population vary, so avoid treating every RDAP object as if it exposes one universal “owner” field.

RDAP is the modern structured interface. RFC 7480 defines HTTP usage; RFC 9082 defines query patterns; RFC 9083 defines JSON responses; RFC 9224 defines how clients locate the authoritative RDAP service. Legacy WHOIS remains in use, but it is text-oriented and inconsistent across registries. RDAP and WHOIS are views into registration systems, not guaranteed byte-for-byte copies of each other.

The useful fields are administrative context: the network registration, associated organization or entities, handle, range, dates, remarks, and contact roles when the RIR publishes them. An allocation can belong to an ISP or LIR that assigns space downstream. A customer can use or route space whose registration still points to an upstream organization. Transfers, leases, mergers, and delayed updates create further separation between registry and routing views.

Country fields need restraint. In RDAP they are registration attributes attached to network or entity objects according to the registry’s schema and data practices. They are not a measurement of where packets enter the Internet. A registration-country/geolocation-country mismatch is therefore not automatically an error.

The abuse contact is often the most useful operational field because it gives you a starting point for a report. It can still be stale, delegated, or routed through an upstream organization, so use the surrounding registration and routing context before assuming the contact represents the end user.

08 / Reverse DNS

What reverse DNS tells you

Reverse DNS starts with an address and asks DNS for a PTR record under in-addr.arpa for IPv4 or ip6.arpa for IPv6. The answer is naming data published under control of the reverse zone. It is useful context, not identity.

PTR names often contain infrastructure hints: access pools, router roles, POP codes, customer labels, or city abbreviations. Those conventions are operator choices. They can be accurate, historical, generic, or deliberately opaque.

Forward-confirmed reverse DNS is a stronger consistency check: take the PTR hostname, resolve its A and AAAA records, and see whether the original address appears in the forward result. A match shows that reverse and forward DNS agree for that name. It still does not prove legal ownership, user identity, or physical location.

No PTR is normal. Many residential, mobile, cloud, and infrastructure addresses either have no reverse record or use automatically generated names. Absence should not be promoted into a reputation signal.

One naming trap is worth removing. A reverse DNS lookup is an IP-to-PTR DNS query. The phrase reverse IP lookup is also used by hosting and SEO products for a different operation: finding domains that appear to share a server or address. Those are not the same dataset or method.

IPRevealed’s current Reverse DNS Lookup performs the PTR query through its US1 probe. It does not currently perform FCrDNS automatically, so forward confirmation remains an additional check rather than a field to imply is already present.

09 / Location

What the location field really means

An IP address contains no city, latitude, or GPS coordinate. Geolocation providers attach location estimates to addresses or address ranges using external evidence. Depending on the vendor, that evidence can include registry attributes, network topology, operator geofeeds, measurement data, infrastructure naming, historical observations, and proprietary datasets.

The result is an inference. Country-level mapping is commonly stronger than city-level mapping, but there is no universal accuracy percentage that applies to every vendor, country, access network, or release. If a provider returns coordinates and an accuracy radius, read them according to that provider’s definition; the coordinates are not a device position.

The network path explains many “wrong city” cases. Mobile IPv4 commonly uses centralized or regional carrier egress and can also use CGNAT. VPNs and proxies expose the exit address. Enterprise networks can centralize Internet breakout. Hosting addresses describe infrastructure rather than the administrator’s location. Anycast can make a single location conceptually wrong.

IPRevealed’s current IP Lookup uses MaxMind GeoLite2 City for its regional-context estimate and labels that layer as inferred. For the full mechanics, the separate IP Geolocation pillar is the right place to discuss vendor disagreement, geofeeds, latency, and accuracy radius in detail. If the immediate problem is a specific wrong city, Why Is My IP Address Showing the Wrong Location? walks through that diagnosis.

10 / Network Type

Network type changes the interpretation

“Residential,” “mobile,” “hosting,” “enterprise,” and “VPN/proxy” are not BGP attributes. They are classifications built from business context, registration data, ASN knowledge, reverse-DNS patterns, and, in commercial products, proprietary observations. Treat them as a separate evidence layer.

Residential IPv4 often sits behind home NAPT, but the same subscriber can also be behind provider CGNAT. Mobile IPv4 frequently uses shared carrier egress; native IPv6 uses a different addressing model and should not be forced into an IPv4-CGNAT assumption. Hosting space describes a server or service edge that can be administered from anywhere. Enterprise egress can represent thousands of users behind one corporate perimeter.

VPN and proxy labels need the most discipline. The routing facts may clearly identify a hosting or VPN provider, but “this specific address is an active VPN exit” is a classification claim unless it is directly observed. Commercial feeds can be useful, but they have their own collection methods, freshness windows, and false positives.

IPRevealed currently emphasizes routing, registration, RPKI, reverse DNS, and location context rather than presenting a definitive per-address VPN/proxy verdict inside the core IP Lookup. That is a sensible boundary: the tool can show the evidence without pretending a routing field proves user intent.

11 / Limits

What an IP lookup cannot prove

An IP lookup is context, not attribution. By itself it does not establish:

• A person’s identity. None of the public layers contains a reliable person-level identifier.
• A home or street address. IP geolocation is not a subscriber directory.
• Who used a shared address at a particular time. Dynamic assignment, NAT, and CGNAT break that inference.
• Physical presence at the geolocated point. The location layer describes network-address use, not device GPS.
• Malicious intent. Routing and registration records describe infrastructure and authorization, not behavior.
• Ownership of a device. An address can be reassigned, translated, shared, proxied, or anycast.
• That RPKI Valid means safe. It says the origin is authorized for the route under the validated data.
• That a PTR hostname is true identity. The reverse-zone operator controls the label.

Subscriber attribution under CGNAT is the clearest example of why public lookup data stops at the provider edge. When many subscribers share one public IPv4 at the same time, the access provider’s translation and session records are needed to distinguish flows. Depending on the implementation, useful correlation fields include the public IPv4, translated source port or port block, protocol, precise timestamp, and subscriber or session state. Access to those records depends on the provider, jurisdiction, and applicable process.

Logging quality matters. A server log that keeps only the public IPv4 may be insufficient for CGNAT attribution. Keeping the source port and an accurate, timezone-qualified timestamp preserves much more diagnostic value. That does not turn a public log into proof of identity; it gives the provider-side records something precise to correlate with if a legitimate investigation requires it.

12 / Workflow

How to read an IP lookup like a network engineer

The order matters because each layer constrains the next. Start with hard classification and routing facts. Read derived estimates last.

1. Classify scope. Public, private, shared, loopback, link-local, documentation, or another special-purpose range?
2. Note the address family. IPv4 or IPv6 affects notation and the surrounding data you should expect.
3. Find the most-specific covering route visible to the lookup. Do not assume the RIR allocation boundary is the route boundary.
4. Check BGP visibility and origin. Which collector views see the route? Is one origin AS visible or several?
5. Read RPKI next to the route. Valid, Invalid, or Not Found; if Invalid, distinguish origin mismatch from prefix-length mismatch.
6. Read RDAP as administrative context. Which RIR, network record, organization or entities, and contacts are associated with the block?
7. Inspect PTR data. Treat the hostname as an operator-published hint; forward-confirm it separately if that matters to the investigation.
8. Classify network context. Residential, mobile, hosting, enterprise, CDN, or another service type — and record whether that classification is direct or inferred.
9. Read geolocation last. Use the accuracy information and the network architecture to decide how much city-level detail deserves weight.
10. Cross-check the layers. Agreement raises confidence in the overall network story. Disagreement tells you which layer needs investigation.

The goal is not to make every field agree. The goal is to understand why they agree or disagree.

13 / Disagreement

What mismatched fields tell you

Different fields are maintained by different systems. A mismatch is useful only after you identify which layer owns the discrepancy.

Registration organization differs from origin AS. This can be legitimate. The space may be leased, delegated, routed for a customer, in transition, or represented differently across registry and routing systems. Check the prefix boundaries and recent route history before calling it suspicious.

Registration country differs from geolocation country. Administrative registration and network deployment answer different questions. Multinational networks, transfers, centralized operations, and vendor update lag can explain the difference.

Origin AS looks consistent, but the city is wrong. The BGP layer can be completely healthy while the location estimate is stale or too coarse. That is a geolocation problem, not a routing problem.

Prefix is visible, but RPKI is Invalid. Inspect the reason. An origin mismatch and a maximum-length violation are different failures. Check the ROA and validated payloads, recent origin history, and the operator’s intended announcement before assigning cause.

PTR suggests one city while geolocation suggests another. Both are hints. The PTR may encode an old POP name or internal naming convention; the geolocation record may describe a service area. Neither field alone establishes physical location.

Mobile network, distant geolocation. Centralized or regional egress can make that entirely normal. Confirm the carrier architecture and whether IPv4 CGNAT or another shared-egress design is in use before treating the city as user location.

WAN address in 100.64.0.0/10, different public IPv4 externally. That combination strongly points to provider-side carrier-grade translation. The public address describes the shared egress, not the individual CPE or subscriber.

14 / Worked Example

A worked example — reading a report field by field

The values below are deliberately synthetic. 203.0.113.0/24 is an IPv4 documentation prefix and AS64500 is in the documentation ASN range. No claim is being made that these values exist as live Internet routing, RDAP, DNS, RPKI, or geolocation data. Pretend the same field pattern was returned for an ordinary globally routed public address.

Read the result in layers. The routing, registration, and reverse-DNS fields are mutually consistent with a residential-access network. RPKI Valid adds one separate fact: the observed prefix-origin pair is authorized by the validated RPKI data. It does not strengthen the geolocation estimate or say anything about the host’s security.

Now change only three fields: the origin AS appeared recently, it differs from the expected operational history, and RPKI becomes Invalid because the observed origin is not authorized. That combination deserves routing investigation. It still does not prove a hijack without corroborating route history, operator information, and vantage-point data.

The value of the lookup is not any single field. It is the relationship between independent layers.

15 / In Practice

Using the IPRevealed IP Lookup

The live IPRevealed IP Lookup follows the same separation. Start at the network-identity summary, then read registration, routing, RPKI, reverse DNS, and regional context as distinct evidence blocks.

For routing, the current IP Lookup page identifies RIPE NCC RIS data retrieved through the RIPEstat API as its BGP source. The collector view supplies the visible prefix and origin information; it should not be described as every router’s global truth. RPKI is validated independently through IPRevealed's US1 RPKI service. Registration is queried from the responsible RIR over RDAP. Reverse DNS is resolved through the IPRevealed US1 probe. Regional context uses MaxMind GeoLite2 City and is presented as inferred evidence.

Use the tool in the same order described above: scope and address family, covering route, origin AS, RPKI, registration, PTR, then location. If the question is about your own connection rather than a third-party address, the VPN Leak Test answers a different problem: which public, DNS, IPv6, and browser paths are visible from the current session.

16 / FAQ

Common questions

17 / References

Technical references

RFC 4271

Border Gateway Protocol 4 (BGP-4)

RFC 4632

Classless Inter-Domain Routing (CIDR): address strategy and aggregation

RFC 1918

Address Allocation for Private Internets

RFC 6598

Shared Address Space for Carrier-Grade NAT (100.64.0.0/10)

RFC 5737 / 3849 / 5398

Documentation IPv4, IPv6, and ASN ranges used for examples

RFC 6480

Resource Public Key Infrastructure architecture

RFC 6811

BGP Prefix Origin Validation, with later operational updates including RFC 8481, RFC 8893 and RFC 9324

RFC 9582

Current Route Origin Authorization profile; obsoletes RFC 6482

RFC 7480

HTTP Usage in RDAP

RFC 9082

RDAP Query Format

RFC 9083

RDAP JSON Responses

RFC 9224

Finding the authoritative RDAP service; obsoletes RFC 7484

RFC 1035

DNS implementation and specification, including the PTR record type

RFC 1912

Common DNS operational guidance, including forward/reverse consistency

IANA

IPv4 Special-Purpose Address Registry and IPv6 Special-Purpose Address Registry

RIPE NCC

RIS / RIPEstat — the BGP collector data disclosed by the current IPRevealed IP Lookup

IPRevealed

Methodology and tool-level data-provenance disclosures — evidence categories, data sources, and limitations