MyRecon OSINTIP Geolocation and Reverse DNS: What an IP Really Reveals
An IP address looks like the most precise thing in an investigation and behaves like the least. It will tell you, reliably, which network an address belongs to and what kind of network that is. The map pin it comes with is an estimate, and treating it as a location has put innocent people through years of trouble.
How IP geolocation is actually produced
There is no location field in an IP address. Nothing in the protocol encodes geography. Every "IP location" you have ever seen is an inference, assembled by commercial and open databases from a handful of imperfect inputs:
- Registry records. The regional internet registries, ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC, publish which organisation holds each block and the country it registered from. This is the strongest input and it is why country-level answers are usually right.
- Routing data. BGP announcements show which network advertises a block and where it interconnects, which constrains roughly where the traffic enters the world.
- Latency measurement. Probes time round trips from known locations and triangulate. Physics puts a floor under how far away a host can be; it does not tell you which side of a city it sits on.
- ISP-supplied assignment data, where a provider chooses to share which blocks serve which regions.
- Inference from applications: devices that reported a GPS position while using a given address, feeding back into the estimate.
Vendors publish country-level accuracy figures in the high nineties. City-level accuracy is a different proposition entirely, and honest vendors publish a confidence radius alongside it, frequently tens of kilometres, sometimes far more.
The default-centroid problem. When a database knows the country but not the city, it has to return something, and for years the common practice was to return the geographic centre of the country. One rural property in Kansas sat at the centre of the United States and was consequently listed as the location of many hundreds of millions of addresses. The people who lived there spent a decade receiving police visits, threats and accusations over crimes committed by strangers. Nothing about that was a database error in the technical sense: the record said "somewhere in this country" and every tool downstream rendered it as a pin on a house. If a geolocation result lands exactly on a country's centroid, it is telling you it does not know.
ASN: the part that is actually reliable
Every routable block belongs to an autonomous system: a network with its own number, announcing its own routes. The ASN, and the organisation behind it, is registry data rather than inference, and it is the most dependable thing an address will give you.
More importantly, it tells you the kind of network, which usually matters more than the place:
- Residential ISP. A consumer connection. Note that the address may be shared and may have moved since, see below.
- Mobile carrier. Phone traffic, almost always behind carrier-grade NAT, with the poorest location accuracy of any category. A mobile address can present as a city hours away from the handset.
- Hosting and cloud. A server, a VPN exit, a proxy or a scraper, not a person at a desk. When traffic that should be a customer arrives from a data centre range, that is worth asking about.
- Business and corporate. A block assigned to a named organisation, which is the one case where an address genuinely does identify an entity.
- Education, government, CDN and other special-purpose networks, each with their own reading.
The distinction between residential and hosting is the single most useful classification in fraud work, and it is derived from ownership records rather than guessed.
Reverse DNS, and why it is controlled by someone else
Forward DNS turns a name into an address. Reverse DNS turns an address back into a name, through PTR records published in a special zone derived from the address itself.
The crucial detail is who may publish there: not the website owner, but whoever holds the IP block, the hosting provider or the ISP. You cannot claim a reverse name for an address you do not control, and that is what makes PTR records evidence rather than assertion.
What they leak in practice:
- Cloud provider and region. Default reverse names on major clouds encode the address and often the region, so the hostname itself says which provider and roughly which data centre.
- Connection type. ISP reverse names routinely contain words like dynamic, dsl, cable, pool or a city abbreviation. A hostname that announces itself as a dynamic residential pool is a stronger signal about the nature of the connection than any map pin.
- Deliberate naming. A reverse name set to a company's own mail hostname was configured on purpose, by someone who controls the range, which is a real link between the address and that organisation.
- Nothing at all. Plenty of addresses have no PTR, which is unremarkable for a web server and notable for a mail server, since many receivers treat a missing reverse name as a spam signal.
Forward-confirmed reverse DNS is the check that makes it meaningful. Take the address, find its PTR name, then look that name up again and see whether it resolves back to the same address. If it does, the two halves are controlled consistently and the name is worth something. If it does not, you have a reverse name that nobody has backed up, and it should carry no weight. This one round trip separates a real identification from a decorative hostname, and it takes seconds.
Why an address is not a person
This is the part that matters most, and it is the part that gets skipped.
- Addresses are shared. Carrier-grade NAT puts hundreds or thousands of subscribers behind one public address at a time. On mobile networks this is the norm, not the exception.
- Addresses move. Residential allocations rotate. An address that served one household last month may serve another today, which is why any claim about an address needs a timestamp attached or it is meaningless.
- Addresses are borrowed. A VPN, a corporate proxy, a coffee shop, an open router, a compromised machine used as a relay, all of them put someone else's traffic behind an address.
- Databases lag. Reassignments between networks can take weeks to show up, and geolocation vendors update on their own schedules.
The practical rule: an IP address identifies a connection at a moment. Turning that into a person requires records only the provider holds, obtained through a process built for the purpose. Everything short of that is an inference, and it should be written down as one.
VPN and proxy detection, and its limits
Services that flag an address as a VPN or proxy work mostly by enumeration: they subscribe to commercial VPN providers, record the exit addresses, and match against that list, supplemented by the hosting-versus-residential classification above.
This catches mainstream commercial VPNs reasonably well. It does not catch a private server someone rented and configured themselves, and it increasingly mislabels residential proxy networks, which route traffic through real consumer connections, sometimes with the consent of the person whose bandwidth is being used and sometimes without it. Both failure directions are common enough that a VPN flag belongs in the evidence pile, not at the end of it.
IPv6 changes the arithmetic
IPv6 allocations are enormous, a single household typically receives a block far larger than the entire IPv4 internet. That has two consequences worth knowing. Sharing is much rarer, so an IPv6 address is a more specific identifier than an IPv4 one. But privacy extensions rotate the address a device uses for outbound connections, often daily, so the specific address is less stable even as the surrounding block stays put. Reason about the prefix, not the full address.
Where addresses come from in real work
Two sources come up constantly, and both deserve a caveat. Email headers used to carry the sender's own address; major webmail providers have stripped that for years, so a header address now usually identifies the provider's outbound server, not the person. Server logs are the other, and there the address is genuine but subject to every caveat above, proxies, shared addresses, and the gap between an address and an account.
A sane order of operations
- Identify the network. ASN and organisation first. This is the reliable part.
- Classify the connection. Residential, mobile, hosting, corporate. This determines how to read everything that follows.
- Check reverse DNS, then forward-confirm it. An unconfirmed PTR is decoration.
- Read the location as a region with a confidence radius, never as a pin, and discard it entirely if it lands on a country centroid.
- Attach a timestamp to every statement about the address, because without one the statement is not checkable.
- Corroborate before concluding. An address is one input. Our guide to verifying an OSINT finding covers what a second input has to look like to count.
Look up any address with the MyRecon IP tool: network operator, ASN, connection type, reverse DNS and an estimated region, with the estimate labelled as an estimate.