First, clarify: are you looking up registration, routing, location, or risk?
IP lookup tools are numerous, but the core distinction is that they answer different questions. If you want to know which organization holds an address block, contact emails, or abuse reporting channels, consult RDAP registration data. If you want to know which autonomous systems currently announce a prefix, check BGP routing table snapshots. If you want to verify whether a specific prefix has a valid route origin authorization, check RPKI validation status. And if you want to assess the abuse or proxy risk of an IP, you can refer to IP reputation reports. Mixing these questions, or expecting a single tool to provide precise physical location, real-time path, and business risk score simultaneously, often leads to misjudgment.
The country field on a page may come from resource registration or from a GeoIP database; you must first read the source. A user seeing inconsistencies in country, page language, or network brand may infer the use of a VPN or Anycast, but the evidence is insufficient. You can start by recording each field using an IP lookup, then verify RDAP, BGP, and location estimates separately; if reputation matters, refer to an IP Reputation Check: Risk Scores, Blocklists and Proxy Tags. These tools do not answer the same question.
Operations personnel handling faults or security incidents should limit each tool's conclusions to its scope of evidence. For example, a BGP route query can only tell you the observed route announcements and AS_PATH attributes; it cannot directly prove which physical links a packet traverses end-to-end. Using query output as a troubleshooting clue, combined with other evidence such as traceroute, flow data, or interface counters, leads to reliable judgment. Avoiding the dismissal of all other information based on a single query result is a basic discipline in interpreting IP data.
What registration questions can RDAP answer?
RDAP (Registration Data Access Protocol) provides registration data through structured responses, used for Internet number resources as well as domain registrations; this article focuses on IP networks and autonomous system resources. Responses may include address ranges, object handles, contact roles, and events, but the degree of public availability and completeness of fields is determined by registry policy and the specific record. You cannot assume every query will yield an end user, complete history, or a usable abuse email.
It is important to note that contact addresses in RDAP are public registration addresses, typically the registered organization's office or legal address, and cannot be equated with the location of the IP device or the user's current position. For example, a multinational company's RDAP address may be registered in its headquarters city, while the server actually using that IP may be in a data center in another country. Using the RDAP address map directly as "IP geolocation" overestimates accuracy. Protocol specifications RFC 9082 and RFC 9083 define RDAP query and response structures, but do not require registration data to include physical location.
When you need to confirm the responsible party for a prefix, using an RDAP lookup tool to view the original record is more reliable than relying on secondhand summaries. Query results show the network name, country code, registry, status (e.g., allocated, assigned), event history, and abuse contact email. These fields help operators judge whether an address block has long-outdated registration information or belongs to a special allocation, but they cannot infer whether the block is launching attacks, hosting malicious services, or belongs to a specific end user. RDAP evidence covers only the registration lifecycle, not real-time behavior.
Why isn't an ASN equal to a service provider brand?
An ASN (Autonomous System Number) identifies a routing policy domain under the control of one or more network operators. Prefixes under the same ASN can be used for various services, including data center hosting, cloud services, CDN, content networks, and transparent proxy services for different retail brands or tenants. Therefore, an ASN alone cannot determine which consumer brand or specific location an IP belongs to. A large cloud provider's ASN may simultaneously host IP addresses for dozens of enterprises, and the registered organization name may have no direct relationship with these enterprises.
An autonomous system can span multiple regions and businesses, and the organization name may differ from retail brands, customers, or cloud tenants. A multinational operator may announce prefixes in multiple countries, and the same company may manage multiple ASNs. Anycast is one possible service deployment method, and its operational boundaries are referenced in RFC 4786, but you cannot directly infer a specific IP's geographic location, tenant identity, or Anycast deployment from the ASN's registration country or company name.
In security analysis, a small ASN cannot simply be equated with high risk. An autonomous system with a few prefixes and a short history may be a legitimate emerging content provider, research network, or regional ISP. Risk assessment should be based on routing behavior, historical announcement stability, RPKI validation status, and actual abuse complaint records, rather than solely on ASN size or the age of registration information. Viewing an ASN's BGP routes and history can help understand its announcement habits, but this is still just one piece of evidence to aid judgment.
BGP Prefixes, Origin ASN, and AS_PATH
BGP queries show control plane information received from specific observation points, including prefixes, origin ASN, AS_PATH, and time. When querying a single IP, the tool may select the longest prefix covering that IP. Longest prefix match is an important forwarding lookup rule: when the forwarding table has a more specific match, packets are forwarded according to that entry; it differs from BGP best path selection among multiple candidate routes for the same prefix. Neither can directly provide a complete list of physical links.
The AS_PATH attribute lists the sequence of autonomous systems traversed by a route, but it is not equivalent to the actual forwarding path of packets in the data plane. Routing policies, local preference, MED values, BGP confederations, and MPLS tunnels can all make the actual packet path differ from the control-plane AS_PATH. For example, a packet may transit a remote peer that does not appear in the AS_PATH. Therefore, using BGP route lookup to determine the current announcer of a prefix can help assess route control, but cannot precisely infer the end-to-end traffic path.
If you need to view the announcement history of a prefix, such as whether it previously changed its origin ASN or whether more specific announcements appeared, you can refer to BGP history data. Historical snapshots can show the announcement state and AS_PATH changes of a prefix at a given point in time, but missing historical data may also be due to incomplete observation points or routes not being collected. Any single route collector view is only a part of the global Internet routing state and cannot be treated as the complete truth. Combining data from multiple observation points provides a more reliable understanding of routing stability.
RPKI: Valid, Invalid, and NotFound
RPKI (Resource Public Key Infrastructure) authorizes an ASN to announce specific prefixes by issuing ROAs (Route Origin Authorizations), and may optionally specify a maximum prefix length, maxLength. When performing origin validation, routers or validation tools compare the prefix and origin ASN in a BGP route against the set of VRPs (Validated ROA Payloads) generated from valid ROAs. The validation result falls into one of three states: Valid, Invalid, and NotFound.
The Valid state means that at least one VRP exists whose authorized prefix covers the announced prefix, the origin ASN matches, and the prefix length is within the allowed range (typically considering maxLength). The Invalid state means that one or more VRPs cover the prefix, but the origin ASN does not match or the prefix length exceeds the authorized range. According to RFC 6811, Invalid does not automatically equate to route hijacking or malicious behavior, because misconfiguration, delayed ROA updates, or operator error can all lead to Invalid.
The NotFound state indicates that no VRP covers the prefix, usually because the resource holder has not created a ROA, or the validator has not yet fetched the latest ROA data. NotFound should not be interpreted as an attack signal; it merely indicates that origin authorization cannot be determined through RPKI. Using the RPKI validation tool allows you to view the validation status, matching ROA details, and validation time for a specific IP prefix. Operators should record the timestamp of each validation, because RPKI data is dynamic and a prefix's status may change as ROAs are published or revoked.
Why is Valid not a security certificate?
RPKI origin validation checks whether a route’s origin ASN and prefix length are authorized by the currently validated ROA payloads. A Valid result does not authenticate the rest of the AS_PATH, prove packet security, establish the trustworthiness of endpoint devices, or assess user behavior and content safety. A malicious network can hold a valid ROA for its own prefix, have its route classified as Valid, and still carry out harmful activity on its infrastructure. A Valid origin-validation result for the route covering an IP address is therefore no guarantee that the address will not be used for abuse or that the service is trustworthy.
Similarly, the Invalid state cannot be directly judged as route hijacking. Common engineering scenarios include: an operator migrating prefixes without updating ROAs in time, or incorrectly setting maxLength so that more specific announcements are not allowed. These are route registration configuration issues; correcting the ROA restores the Valid state. On the other hand, genuine hijackers may exploit uncovered prefixes (i.e., NotFound) for announcements, further illustrating that the state alone does not constitute a security conclusion.
When reporting to operators, you should retain the observation time, specific prefix, origin ASN, authorized ASN and maxLength of the covering VRP, and the validator or data source. A schematic wording is: "At the listed time, 203.0.113.0/24, origin AS64496 was validated as Invalid; covering VRP exists, but no record simultaneously satisfies the origin and length requirements." This uses documentation example resources, not an actual routing alert. The recipient needs to check the complete matching set and cannot ignore another valid authorization just because one mismatching VRP was seen.
Why do registration country and geolocation country differ?
A mismatch between registration country and geolocation country does not automatically indicate a location error or the presence of Anycast. IP addresses are allocated by regional Internet registries to multinational organizations, which may choose to register in the country of their headquarters while actual usage occurs in global branches or data centers. For example, a European enterprise registers an entire IP block in the Netherlands, but the leased servers are located in Singapore; the registration country shows the Netherlands while network latency and routing observations point to Singapore. This is normal, not an anomaly.
After upstream ISPs obtain large blocks of resources, they may allocate them to different customers or regions, and registration records, commercial geolocation databases, and website caches each update independently. Resource transfers, allocation changes, or record revisions can cause time lags, and it cannot be assumed that they will synchronize after a fixed number of weeks or months. You should record the specific query time and source, distinguish between current registration objects, historical snapshots, and location estimates, and avoid using one field to override the meaning of another.
Network layout factors include CDNs, cloud service providers, and multinational private lines, which deploy the same prefix addresses in multiple countries. In such cases, any single "registration country" cannot represent the actual traffic entry point. To determine whether an IP provides services in a specific country, you should combine the AS path in BGP routes, active ping/traceroute measurements, and public region information from cloud providers. Inferring Anycast solely from country inconsistency is insufficient evidence.
What is the difference between Anycast and broadcast?
Anycast allows multiple service instances to use the same address, with routing sending a single request to one of the reachable instances; common Internet deployments announce the prefix carrying that address from multiple locations. The selected instance depends on routing policy and does not guarantee geographic proximity, lowest latency, or least load. Broadcast, on the other hand, sends a packet to multiple receivers within a broadcast domain; the two are completely different. Anycast engineering practices can be referenced in RFC 4786.
Determining Anycast can combine the operator's explicit documentation for the service address with measurements from multiple locations and time periods, as well as instance identifiers. The same ASN can appear at multiple Anycast sites, so endpoint ASNs do not need to differ; different ASNs or different traceroute paths also do not automatically prove Anycast, because routing changes, tunnels, and measurement limitations can all affect results. The evidence should be described in terms of how far it supports a conclusion, and an address should not be characterized based solely on a few country labels.
A common misconception is to treat "country field differences" as proof of Anycast, for example when the same IP shows as the United States in one commercial database and Germany in another. This only indicates inconsistent geolocation data sources, possibly due to registration, routing, or database update issues, and is by no means a sufficient condition for Anycast. Any operational judgment must clearly distinguish between possibility and proof, and avoid presenting unverified assumptions as conclusions.
Illustrative case: Who are the registrant, operator, and tenant?
The following is an illustrative scenario, not based on any real measurements. Suppose the documentation example address 192.0.2.10 is queried, RDAP shows the registration country as the United States and the registrant as Example Corp, while the BGP route announcement originates from an ASN belonging to a European cloud service provider. This discrepancy could be because Example Corp leases the address block to the cloud provider, which deploys edge nodes in Frankfurt and Tokyo but does not update the registration information. Based on this information alone, it is impossible to confirm the current physical location of the IP or whether Anycast is used.
Continuing this assumption: two measurement points near Frankfurt and Tokyo each reach a local service instance and obtain verifiable, different instance identifiers, while the request target remains the documentation example address 192.0.2.10. Combined with the operator's explicit Anycast statement for this address, this can support a judgment of multi-location deployment. This is only a logical example and does not claim that latency below 10 milliseconds can be achieved from any location worldwide. RPKI Valid still only verifies prefix origin authorization and does not prove instance locations.
In this case, unknown issues include: the specific identity of the tenant, whether service ports are open to all regions, the state synchronization mechanism between instances, and whether there is intermediate network packet filtering. Operational staff should record these unknowns truthfully rather than using the 'Anycast' label to cover up missing evidence. Classification does not equal maliciousness, and a miss does not equal an attack; clearly explaining the boundaries is the foundation of professional judgment.
Why do historical records and current results differ?
RDAP events are typically described by fields such as eventAction and eventDate, for example "registration" or "last changed"; some interfaces may summarize this as "updated". These dates describe events on the registration object, not the time when the server physically moved. Changing email, status, or administrative information can alter the update time, while the service location may change without being reflected in the relevant fields. The original event names must be preserved, and all dates should not be uniformly interpreted as address migration.
Prefix splitting and resource transfer are common causes. After a large /16 block is split into multiple /24s, some of the smaller blocks may be allocated to other organizations, but the parent registration information's country field retains the original value. In this case, querying the RDAP for a particular /24 may return a historical country value from the parent, while BGP routing shows that the small block is now announced by an ASN in another country. Different observation points also cause inconsistencies: commercial IP databases are based on different data sources and collection times, and snapshot differences can be as long as several months.
The following hypothetical example illustrates how to record the evidence. The correct approach is to retain all original records and annotate the query time. For example: in January 2024, RDAP showed the country as the United Kingdom; in June 2024, the BGP path passed through Germany; in September 2024, a traceroute from a certain observation point ended in the Netherlands. One cannot simply say 'the IP moved to the Netherlands'; instead, one should say 'there are differences across different times and observation points, possibly involving routing adjustments or database lag.' This preserves the evidence while avoiding over-inference.
How to combine evidence and preserve unknowns?
A complete IP query judgment should be divided into four categories of evidence. Registration background comes from RDAP and WHOIS, including registrant, country, registration date, contact email, and status, but does not include physical location or end-user identity. Routing status comes from BGP and RPKI, including the announced ASN, AS path, RPKI validity or invalidity, and visibility; this only reflects control-plane reachability and does not guarantee the complete data-plane path. Location estimates come from commercial IP databases, latency, and traceroute, and are probabilistic judgments.
Direct behavior must be recorded independently, such as whether it actively initiates scans, whether there is malicious domain resolution, or whether it responds to specific ports. An IP with residential ISP registration information, even if its geolocation matches a certain city, does not mean that the IP belongs to a real home user, because proxies or hosting services may be present. For key points on distinguishing residential and native IPs, see Residential, ISP-Hosted and Datacenter IPs: Key Differences. When observation point coverage is insufficient, the same IP may show route unreachability in some regions, which does not prove global unreachability; refer to /24 Subnet Reputation: Coverage, Risk Rates and Unknown IPs.
Suppose the registration country is Canada, the ASN is managed by a Canadian ISP, RPKI is Valid, commercial databases estimate Toronto, and latency is lower from some Canadian measurement points. One could state that these results are consistent with a service location in Canada, but this cannot be written as proof of physical location, nor can normal business operations be inferred from RPKI. Registration is data, routing is observation, location is estimation, and behavior records also have sources and measurement boundaries; all conclusions must note the time, conditions, and parts that cannot yet be confirmed.
Frequently Asked Questions and Review Materials
FAQ 1: Does an ASN change mean the carrier has changed? Not necessarily. An ASN represents a routing policy domain; large carriers may own multiple ASNs, and an enterprise may migrate to a cloud service provider while retaining its original IP block. It is necessary to check whether the IP prefix is announced by different ASNs in the same BGP route, or whether there are AS path changes, and to combine registration information to determine whether the network provider has truly changed.
RPKI origin validation cannot prevent all routing attacks, nor does it authenticate the full AS_PATH. A rigorous phrasing is "the route is Valid, Invalid, or NotFound relative to the current VRP set"; do not abbreviate Invalid as "ROA invalid", as these are not the same concept. RDAP is also not a tool for locating individual end users: even if a public object contains personal or contact information, it is still resource registration data and cannot be used to identify the person currently initiating a request or their precise address.
A ticket review framework should require the submitter to provide: query time (UTC), specific IP or prefix, RDAP/WHOIS snapshot, BGP routing table or traceroute observation source, current status (such as connection failure or route leak), and the specific request. Based on this, operational staff should first check the registration fields, then examine RPKI and AS path, and finally refer to geolocation and active measurements. Using this framework can reduce misjudgments such as 'country fields do not match, so it is compromised.'
