An IP lookup can be useful within seconds and misleading for much longer. The trouble usually starts when a plausible city, company name, or hostname gets promoted from a clue to a conclusion. A result might describe the network that announces an address, a geolocation vendor's estimate for that address range, and DNS data chosen by an operator. Those facts answer different questions. None of them, alone, identifies the person behind a request.
This guide is about reading the actual DomScan IP Lookup response in that spirit. It covers the fields worth checking first, what the confidence summary does and does not mean, and when to move from the enriched IP result to raw RDAP. For the underlying allocation and routing model, read IP address lookup: geolocation, ASN, privacy, and hard limits.
Start with the question, not the city
Before opening a lookup, write down what you need to decide. Is this login unusual for the account? Does the address appear to belong to a cloud network? Which public registry covers the range? Does a mail server's reverse DNS agree with its forward DNS? A single response can help with each question, but the useful fields change with the purpose.
A city can support a low-stakes anomaly signal when compared with a user's recent history. It is poor evidence for a physical-location claim. An ASN can help route an incident to the right network team. It does not prove that the ASN holder operated the application that generated the traffic. A valid FCrDNS result can show a consistent DNS configuration. It does not authenticate the hostname's owner or make the traffic safe.
Run the live DomScan lookup
The endpoint accepts either a public IP in the `ip` parameter or a domain in the `domain` parameter. A domain query resolves the name to an IPv4 address and then looks up that address. Private, loopback, link-local, and carrier-grade NAT IPv4 ranges are rejected because public geolocation has no sensible answer for them. The response is cached for up to 24 hours.
curl -sS \
-H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/ip?ip=8.8.8.8" | \
jq '{ip, domain, geolocation, network, security, intelligence_summary, meta}'For `8.8.8.8`, a production response can identify AS15169 and Google LLC, classify the address as cloud or datacenter infrastructure, and return `dns.google` as its PTR with successful forward confirmation. The geolocation may name a city such as Ashburn. The network and DNS portions are useful context. The city is still a database estimate, not a claim that every packet using Google's anycast resolver reached equipment at one fixed point.
Read the response in layers
1. Query and source metadata
Check `ip`, `domain`, and `meta` before interpreting anything else. When you pass an IP, `domain` is null. When you pass a domain, the result reports the resolved IPv4 address and retains the input domain. `meta.cached` tells you whether DomScan served its cached result, while `meta.source` identifies the lookup pipeline. The normal source is `ip-api.com+enrichment`; if the geolocation provider is unavailable, the response may carry partial enrichment and a warning code instead.
That source label matters. The geolocation, ISP, ASN, proxy, and hosting inputs begin with IP-API fields, then DomScan adds cloud-range, Tor-exit, ASN, classification, and FCrDNS checks. This is an interpreted intelligence response. If you need the RIR's registered network object, use RDAP rather than treating `network.asn_org` as a substitute.
2. Geolocation
The `geolocation` object includes country, region, city, postal code, coordinates, and timezone when the upstream source provides them. DomScan does not currently return an accuracy radius for these coordinates. Do not invent one, and do not treat a coordinate pair as more exact because it has decimal places. It may represent a city centroid, a provider location, or the best estimate for a much larger range.
Published accuracy figures are vendor-specific, dataset-specific, and uneven by country and access type. MaxMind, for example, says its own products are never precise enough to identify a household, person, or street address. It estimates 99.8 percent country accuracy overall, but about 66 percent city accuracy within a 50 km radius for United States addresses. Those numbers describe MaxMind's products, not a warranty for every provider or every DomScan result. They are useful because they show how quickly precision falls once a lookup moves below country level.
3. Network and ASN
The `network` object contains `asn`, `asn_name`, `asn_org`, `isp`, and `connection_type`. An autonomous system is a routing domain that presents a coherent routing policy to other networks. In practical terms, the ASN often tells you which network is announcing the prefix. It is usually more useful for grouping activity than a city label because many addresses in the same routed network share operational characteristics.
Keep the organizational layers separate. The RIR may have registered a large block to a provider. BGP may show an origin ASN for a more specific prefix. A cloud provider may lease a virtual machine to a customer. A residential ISP may assign an address dynamically to a subscriber. A corporate VPN may then carry an employee's traffic through it. `asn_org` and `isp` can identify network context without identifying the end user or the software operator.
4. Security and hosting signals
The `security` object can include proxy, VPN, Tor, datacenter, cloud, and coarse residential or datacenter classification fields. These are signals, not verdicts. DomScan's upstream `proxy` field groups proxies, VPNs, and Tor exits. The current implementation separately enriches known Tor exits and cloud ranges, and marks some VPN-associated ASNs as suspected. The exact detection coverage differs by signal. A false value can mean no match, not proof of absence.
`threat_score` also needs restraint. In the current IP path it is a narrow heuristic, not a reputation history or a probability that an actor is malicious. An upstream proxy match sets it to 50; otherwise it can be zero. Likewise, `is_datacenter` and `is_cloud` describe infrastructure type. Many legitimate APIs, search crawlers, monitoring systems, and remote workers use cloud networks. Blocking every cloud address would break a great deal of ordinary traffic.
5. PTR and FCrDNS
A PTR record maps an IP address to a hostname through reverse DNS. The holder of the reverse DNS delegation, often an ISP or hosting provider, controls that record. A descriptive PTR such as `mail.example.net` is an assertion in DNS. It is not a certificate, registry assignment, or proof of the human organization currently using the machine. RFC 1035 also warns that reverse and forward zones can be inconsistent because they are separate DNS data.
DomScan's `security.fcrdns` object makes one consistency check. It looks up the IPv4 PTR, resolves that hostname's A records, and sets `fcrdns_valid` to true when the original IP appears in the answer. False can mean no PTR, no matching A record, or a mismatch. Null or a missing object can mean the chain could not complete. The current implementation does not perform this check for IPv6, so absence there is expected.
6. Intelligence summary
The `intelligence_summary` condenses field presence and risk flags. Its `confidence_score` rewards available country, ASN, organization, classification, and provider data. It does not measure the probability that the city or coordinates are correct. A score of 100 means the response is well populated according to that completeness calculation. It does not turn every field into verified ground truth.
Use `risk_flags` as an index into the detailed fields. A `cloud` or `datacenter` flag should send you to infrastructure policy. `fcrdns_mismatch` should send you to the PTR and forward records. `partial_provider_data` tells you that the normal geolocation provider path degraded. Avoid converting the number into a universal allow or block threshold without testing it against your own traffic.
Move to raw RDAP for registration evidence
RDAP answers a different question: what registration data does the responsible registry publish for this number resource? IANA coordinates the global IP and AS number spaces and allocates large pools to five Regional Internet Registries. The RIRs register allocations and assignments within their regions. RDAP exposes those records as structured JSON over HTTP.
curl -sS \
-H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/rdap?type=ip&query=8.8.8.8" | \
jq '{query, type, status, rdap, entity_summary, lookup_summary}'A raw response can contain the registered start and end addresses, handle, name, events, notices, links, and public entities. DomScan also extracts an `entity_summary` when the response publishes roles such as abuse, registrant, administrative, or technical. This is the right place to look for a public abuse contact. The main `/v1/ip` response does not return abuse contacts.
Do not call the registrant field the subscriber without more evidence. ARIN says its public registry lacks some smaller customer reassignments and privatized residential customers. It also says the registry does not contain routing information or authoritative geolocation. The result can identify the organization responsible for a block, or an upstream provider, while the time-specific subscriber remains known only to the ISP.
Reverse IP is not an inventory
Reverse IP services try to list domain names that have resolved to an address. That sounds complete until shared hosting, CDNs, rapidly changing DNS, wildcard records, multiple A and AAAA answers, and limited observation windows enter the picture. There is no DNS query that asks an IP address for every domain that points to it. Providers build datasets from observations, crawls, certificates, user queries, or other sources, and each dataset has blind spots.
DomScan's `/v1/reverse/ip` endpoint is deprecated. For a single IP, it searches a passive KV index populated by prior DomScan API lookups. Results describe domains the service has previously observed, subject to retention and limits. They are not an internet-wide list. A domain may also have moved since its last observation.
Domain Profile has a narrower job
If an investigation starts from a domain found in logs, the Domain Profile can normalize that domain's RDAP registration context. Its production response includes fields such as registrar, registration dates, status values, nameservers, DNSSEC status from RDAP, privacy indicators, source provenance, and a link to raw RDAP when available. It remains a registration profile.
Domain Profile does not bundle live DNS record resolution, SSL analysis, hosting detection, backlinks, or traffic estimates. Use the relevant DNS, SSL, hosting, and other APIs for those questions. Keeping this boundary clear prevents an attractive registration summary from being mistaken for a complete infrastructure picture.
A defensible incident workflow
- Preserve the raw event: IP, UTC timestamp, request or message identifiers, and enough log context to explain why it matters.
- Run `/v1/ip` and record the source, cache state, ASN, organization, infrastructure classification, and any partial-data warning.
- Treat country as a coarse signal. Treat region, city, postal code, and coordinates as estimates that need corroboration.
- Inspect PTR and FCrDNS separately. Record missing data as missing, not as malicious or safe.
- Query `/v1/rdap?type=ip` for the registered range and any public entities. Use the published abuse role only when the evidence supports a report.
- Check current BGP and RPKI data with a routing source if origin authorization or route anomalies matter. DomScan's IP response does not make that determination.
- Correlate with application evidence such as authentication history, user agent, request behavior, account changes, and other indicators before acting.
- State the conclusion at the same strength as the evidence: estimated, observed, registry-published, DNS-consistent, or independently verified.
Writing these qualifiers takes a little longer than reading one line and declaring an owner. It also makes the result reviewable. A useful IP report says what the lookup source observed, when it observed it, and what still needs verification. That is better incident work than a precise-looking map pin with no account of uncertainty.