An IP address can lead to a registered network range, an observed route, a likely country, a reverse DNS name, and perhaps a public contact. Those answers look as if they describe one thing. They do not. They come from different systems, change on different schedules, and carry different levels of authority.
The most common mistake in IP research is collapsing network facts into identity. A registry record may name an ISP. A BGP table may show an origin ASN. A geolocation database may name a city. The traffic could still come from one of thousands of subscribers, a cloud tenant, a VPN user, a compromised device, or an anycast service operating in many cities at once.
This article explains the systems behind those fields. For a field-by-field DomScan workflow with commands and response examples, use How to read an IP lookup without overclaiming.
Five questions hiding inside one lookup
- Registration: which organization or provider is recorded for the address range, and which RIR serves the record?
- Routing: which autonomous system currently appears to originate the covering prefix, as observed by a route collector or network?
- Location: where does a geolocation dataset estimate that the address is used?
- Naming: what PTR hostname, if any, has the reverse DNS operator published for the address?
- Attribution: which subscriber, tenant, device, or person used the address at a specific timestamp?
The first four questions can produce public clues. The fifth usually depends on time-specific operational logs held by an ISP, employer, cloud provider, VPN service, or application. Sometimes those logs no longer exist. Sometimes several layers of NAT or proxying separate the public address from the device. No public lookup can fill that gap by making the earlier fields more precise.
How addresses reach networks
IANA coordinates the global pools of IPv4 addresses, IPv6 addresses, and autonomous system numbers. It normally allocates large pools to five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC. Those RIRs distribute resources under regional policies to network operators and, in some regions, through national or local Internet registries. Providers can then make assignments or reassignments to customers.
This hierarchy is why an IP registration search often returns an upstream organization rather than a household or cloud customer. The public record can be accurate at the level it was designed to document and still be too coarse for the question an investigator wants to answer. ARIN explicitly says its public registry omits some small downstream reassignments and some privatized residential customers.
Calling the registration name the `owner` also hides important distinctions. Internet number resources can be allocated, assigned, transferred, reallocated, or reassigned under registry policy and provider contracts. A safer description is `registered resource holder`, `registered organization`, or `upstream provider`, depending on the record. That wording leaves room for the customer relationship the public record may not expose.
RDAP provides the registry view
Registration Data Access Protocol, or RDAP, exposes number-resource records as structured JSON over HTTP. An IP network object can identify a start and end address, a handle, status values, events, notices, links, and public entities. The responsible server follows the IANA bootstrap registries and RIR referral structure. DomScan's raw endpoint requires an explicit type for an IP query: `/v1/rdap?type=ip&query=8.8.8.8`.
A public entity can carry roles such as registrant, administrative, technical, or abuse. Fields vary by registry, object, policy, and redaction. DomScan's raw RDAP response includes an `entity_summary` when it can extract those public roles. That does not mean every query will return an abuse email, and the main `/v1/ip` geolocation endpoint does not claim to provide one.
ASN is routing context, not customer identity
The Border Gateway Protocol exchanges reachability information between autonomous systems. RFC 4271 describes an AS as routers under a technical administration that present a coherent routing plan to other ASes. In a route, the address space appears as a prefix and the AS path describes autonomous systems associated with the advertised path.
For an IP lookup, the origin ASN is often the last AS in an observed path for the covering prefix. It can identify the network making the route visible to the rest of the Internet. That is valuable for grouping addresses, understanding provider relationships, and choosing an escalation path. It is not automatically the same organization shown in the RIR's less-specific allocation, and it does not expose a tenant behind a cloud address.
BGP data is observational. A route collector sees announcements through its peers at a given time. Another network may select a different path, a more-specific announcement may change the origin, and withdrawals or leaks can alter the view. The RIPEstat BGP State API makes this explicit by returning routes with a target prefix, AS path, source collector, and peer. There is no physical coordinate in that model.
RPKI answers a narrow authorization question
Resource Public Key Infrastructure lets a resource holder publish cryptographically verifiable statements about which ASN may originate a prefix. A Route Origin Authorization contains an origin ASN, a prefix, and a maximum prefix length. Validators compare an observed announcement with those objects.
A result can be valid, invalid because of the ASN, invalid because the prefix is too specific, or unknown because no covering ROA exists. RIPEstat exposes those states for a prefix and ASN pair. `Unknown` does not mean malicious. `Valid` does not certify the business behind a server, the full AS path, the security of an application, or the truth of a geolocation estimate. It says the origin announcement matches an applicable authorization.
Why IP geolocation is an estimate
The Internet has no authoritative registry that maps every routable IP to a device coordinate. Geolocation providers assemble their own datasets. Inputs can include operator-published feeds, network topology, routing observations, latency measurements, commercial relationships, and corrections from known locations. Each provider has different coverage, update cycles, and inference methods. Two reputable products can disagree without either database being obviously broken.
RFC 8805 illustrates one useful input: a network operator can self-publish a CSV feed mapping prefixes to country, region, and city codes. This can correct third-party databases, but it remains optional and coarse. It describes where the operator says a prefix is deployed. It does not locate an individual connection inside that prefix.
Vendor accuracy statistics require context. MaxMind publishes an estimate of 99.8 percent country accuracy for its own products, about 80 percent state or region accuracy for United States addresses, and about 66 percent for cities within a 50 km radius. It also says IP geolocation is never precise enough to identify a household, individual, or street address. These figures cannot be copied onto every database, country, or address type, but they show why a city label should not be treated like GPS.
Network designs that break the map
Anycast
Anycast allows the same address or prefix to be announced from multiple sites. Routing policy sends a user toward one available instance, which may differ by network and time. Public DNS resolvers, CDNs, and security services commonly use this design. A database still has to return one location, a representative location, or a coarse country for a service that has no single rack. The familiar `8.8.8.8` address is a good reminder: a city result cannot establish which Google site handled a particular query.
VPNs, proxies, and Tor
A VPN or proxy presents its exit address to the destination. The lookup can sometimes locate or classify that exit infrastructure. It cannot see the user's original network through the public IP alone. Corporate gateways create the same separation without being anonymity services. Tor adds further relays, and the destination normally sees an exit address. A detection flag can be useful, but a false result is not proof that no intermediary exists.
Mobile and satellite gateways
Mobile carriers can route users through gateways serving large areas and can shift addresses as devices move. Satellite systems can exit through ground infrastructure far from the terminal. A country may remain useful while the city describes a gateway, provider convention, or stale range mapping. The network can know more through its internal session records than any public lookup can reveal.
CDNs and shared hosting
A CDN address can represent an edge shared by unrelated customer domains, while the origin server remains hidden. A shared hosting address can serve hundreds or thousands of names. Conversely, one domain can use many addresses across regions. This is why an address cannot yield a complete domain inventory through DNS. DomScan's deprecated reverse IP endpoint only searches domains previously observed in its own lookup-derived cache. Its results are incomplete by design, and zero results are not evidence that no domain uses the address.
IPv4 sharing and the importance of time
Public IPv4 scarcity encourages address sharing. Home routers translate many private devices behind one public address. Carrier-grade NAT can place many subscribers behind provider-controlled translators. RFC 6598 reserves `100.64.0.0/10` as shared address space for service-provider NAT, but the public side of the translator uses globally routable addresses seen by websites.
Under sharing, an IP and date alone may be insufficient even for the provider that operated the network. The provider may need the precise UTC timestamp, source port, destination address and port, protocol, and its NAT logs to isolate a session. Clock drift and timezone mistakes matter. Investigators should preserve those details rather than expecting a later lookup to recreate them.
Dynamic assignment creates another time problem. A residential address can move from one subscriber to another after a lease changes. A cloud address can return to a pool and be assigned to a new tenant. A reputation hit, PTR record, or reverse-IP observation from last month may describe a different user of the same number. Current enrichment is current context, not a historical subscriber ledger.
IPv6 changes scale, not the attribution rule
IPv6 provides a vastly larger address space and can reduce the pressure to share one public address through NAT. That does not make a public address a permanent device serial number. Networks delegate prefixes, hosts can use several addresses at once, and assignments still change. The visible address may identify a network and interface at a moment without identifying the human who caused the traffic.
RFC 8981 defines temporary IPv6 addresses intended to reduce correlation based on stable interface identifiers. A device can rotate those addresses while remaining on the same network. Enterprise privacy policies, mobile addressing, and prefix changes add more movement. Geolocation databases also vary in their IPv6 coverage because large allocations can be deployed gradually across many places.
DomScan accepts IPv4 and IPv6 input on `/v1/ip`, but its current FCrDNS implementation performs the reverse and forward confirmation chain only for IPv4. An absent FCrDNS object for IPv6 is therefore a product boundary, not evidence of bad DNS. Raw RDAP supports IPv6 address and CIDR queries when `type=ip` is explicit.
Reverse DNS is a label, not an identity document
The operator of reverse DNS can publish a PTR hostname for an address. That hostname might encode a provider, region, rack, customer label, or no useful meaning at all. Some addresses have no PTR. Some have a stale record. RFC 1035 notes that reverse and normal DNS can disagree because they live in different zones.
Forward-confirmed reverse DNS checks whether the PTR name resolves back to the original address. It can detect one kind of inconsistency and is useful in mail and operations work. It does not prove who registered the domain, who leased the server, or who sent a request. Even a neatly named, forward-confirmed host can be compromised or shared.
What DomScan's confidence means
DomScan's `/v1/ip` endpoint returns an `intelligence_summary` with a confidence band and score. The calculation measures response completeness: it adds points when country, ASN, organization, infrastructure classification, and normal provider data are present. It is not a geolocation confidence percentage and does not validate a subscriber identity.
The main response combines IP-API geolocation and network fields with DomScan enrichment for cloud ranges, known Tor exits, datacenter ASNs, selected VPN-associated ASNs, and FCrDNS. Its security booleans have different sources and coverage. Read them as independent observations. `is_vpn: false`, for example, cannot rule out every VPN because that field is not backed by universal visibility.
When registry evidence is required, follow with `/v1/rdap?type=ip`. When route origin or authorization matters, consult current BGP and RPKI data. When a domain appears in the case, Domain Profile can normalize that domain's RDAP registration data, including registrar, dates, status, nameservers, DNSSEC and source context. It does not add live DNS answers, SSL state, hosting, backlinks, or traffic.
Match the claim to the evidence
- Strong: `The RIR RDAP response registered this address range to Organization X at lookup time.`
- Strong: `A route collector observed AS64500 as the origin for the covering prefix at this time.`
- Strong: `The geolocation source estimated the address in Country Y and City Z, with no accuracy radius in the DomScan response.`
- Strong: `The PTR was host.example and its A records included the original IPv4 address when checked.`
- Weak: `The person was in City Z.` The lookup does not locate a person.
- Weak: `Organization X carried out the activity.` Registration or routing context does not identify the actor.
- Weak: `No domains use this IP.` No reverse-IP dataset has complete negative visibility.
Useful IP intelligence keeps its evidence categories intact. Registration says who is recorded for number resources. BGP says how a prefix was observed in routing. RPKI says whether the origin matches an authorization. Geolocation estimates place. DNS supplies operator-controlled names. Identity still requires logs, time, and corroboration. An IP lookup works well within those boundaries and becomes unreliable when its clues are promoted into facts the underlying systems cannot know.