How IPinfo Turns Registry Data into Real Intelligence

The Internet is a decentralized network by nature. Hundreds of thousands of computer networks, each with their own peculiarities and policies, are interconnected together to form a larger, global network. There is little to no coordination between these networks. Each network is mainly concerned with its peering neighbors, but it doesn’t need to care about networks further away. A network operator in Japan does not need to ever coordinate with a network operator in Europe to be able to exchange packets with them. They do not need to use the same equipment, vendors, software, or configurations on their networks. It might seem impossible for such a system to work at a global scale and over a long period of time, and yet, for the most part it does. This is achieved in part thanks to standards organizations like the IETF, which dictates the technical standards that must be used to interconnect networks, but also through the Regional Internet Registries (RIRs), which coordinate the allocation of IP addresses and other shared Internet resources. IETF IETF Regional Internet Registries Regional Internet Registries In this blog post I will explain what IP addresses and autonomous system numbers are, how they are allocated successfully on the Internet (along with their limitations), and how IPinfo’s actively measured datasets turn static registry data into a verifiable, real-time intelligence layer. IP Network Challenges IP Network Challenges The common point to all networks on the Internet is the use of the aptly named Internet Protocol, or IP protocol. In an IP network, each piece of equipment is assigned an IP address that can be used to send messages to others. There are two key challenges in IP networks: Finding paths, or routes, between two computersMaking sure each piece of equipment is assigned a unique address amongst a finite set of possible addresses Finding paths, or routes, between two computers Making sure each piece of equipment is assigned a unique address amongst a finite set of possible addresses To better understand the routing challenge, let’s have a closer look at an IP network. A typical IP network is made up of multiple computers interconnected together through a device called a switch. Each interface of the switch is either connected to a computer, or to another switch. Two IP networks. Within each network hosts are connected through a switch and can send broadcast messages to all other computers in the same network. Broadcast messages are not allowed past the network boundary. Instead a device called a router is used. A router knows in advance how to reach all other networks. Two IP networks. Within each network hosts are connected through a switch and can send broadcast messages to all other computers in the same network. Broadcast messages are not allowed past the network boundary. Instead a device called a router is used. A router knows in advance how to reach all other networks. A switch has two modes of operation when it receives a message from one computer to another. Either it knows, from observing the traffic, to which specific interface the message must be forwarded, or it doesn’t and it sends the message to all interfaces except the interface where the message arrived in a process called flooding. In this setup, there is no need to know the outgoing interface for all destinations in advance since a message can always be broadcast to everyone when the interface is not known. flooding broadcast Networks that support broadcast messages are convenient, but they also suffer from scalability issues. Imagine if every time a computer wanted to send a message to a new destination on the Internet, the message would be sent to all other computers on the Internet in the hope that it would eventually reach its intended destination. Not only would this be a privacy nightmare, this would also clog the network with useless traffic. From Local Networks to Autonomous Systems From Local Networks to Autonomous Systems To solve this scalability issue, broadcast messages are not allowed between networks. Instead, another type of device, called a router, is used to interconnect networks. Unlike a switch, a router must know the outgoing interface for each destination in advance: One way to populate this routing table is for the network to manually input each route into all routers. However, this process doesn’t scale to large networks and doesn’t allow dynamic reconfiguration when new routers are added or removed, or when links between them become unavailable (e.g. due to a broken cable). Instead, the most common way of populating routing tables is by using a routing protocol. Various kinds of routing protocols exist, but the main idea is for each router to share the list of the network it is connected to with its neighbors and also the networks it learned from its neighbors. After some convergence time, routers should share the same view of the network. One way to populate this routing table is for the network to manually input each route into all routers. However, this process doesn’t scale to large networks and doesn’t allow dynamic reconfiguration when new routers are added or removed, or when links between them become unavailable (e.g. due to a broken cable). routing table Instead, the most common way of populating routing tables is by using a routing protocol. Various kinds of routing protocols exist, but the main idea is for each router to share the list of the network it is connected to with its neighbors and also the networks it learned from its neighbors. After some convergence time, routers should share the same view of the network. In practice different organizations will use different routing protocols and policies depending on their needs, for example to optimize for throughput or latency. They might also want to filter which routes they accept from other networks to control where their traffic will go. A collection of networks that share a common routing policy is called an autonomous system, or AS. Typically ISPs and large organizations will operate one or more ASes. Within each AS they are free to use the routing protocol of their choice. The Internet is a collection of autonomous systems, each with their own internal routing protocols and policies, that use the Border Gateway Protocol (BGP) to exchange routes between them. A proto-Internet with two autonomous systems. Inside an AS the network operator is free to implement any routing policy and use any routing protocol. Between ASes the BGP routing protocol must be used. A proto-Internet with two autonomous systems. Inside an AS the network operator is free to implement any routing policy and use any routing protocol. Between ASes the BGP routing protocol must be used. One key requirement of the BGP protocol is that each AS has a unique number, called an Autonomous System Number (ASN) assigned to it. The Need for Unique Resources The Need for Unique Resources For the Internet to work we need two things: unique IP addresses and unique autonomous system numbers. If we let network operators pick these values at random, there is a very high risk of collision, which would result in parts of the network being unreachable, or receiving traffic not meant for them. The allocation of these resources is coordinated by the Regional Internet Registries (RIR). RIRs are nonprofit organizations that maintain a registry — or database — of Internet resources. There are five RIRs that cover different parts of the world: AFRINIC for Africa, ARIN for North America, APNIC for Asia and Oceania, LACNIC for South America, and the RIPE NCC for Europe and the Middle East. The exact types of records and metadata recorded in each database depend on the RIR, but the two most important are IP address ranges and autonomous system numbers. Resource allocation is hierarchical in nature. The Internet Assigned Numbers Authority (IANA) distributes these resources to RIRs, which in turn distributes them to organizations who need them, which in turn can distribute them to their customers. IPv4 addresses are by far the scarcest resources, with only 4.2 billion 32-bit addresses to split for every device on the planet. RIRs now have a waiting list in place, as they’ve run out of available IPv4 addresses and have strict quotas (for example the RIPE NCC limits the maximum number of IPv4 addresses allocated to an ISP to 256 addresses). IPv6 addresses do not suffer from this problem thanks to the use of 128-bit addresses, which provides a vastly larger address space. The majority of the IPv6 address space is currently unallocated and reserved for future use. ASNs used to be defined using 16 bit numbers, meaning a maximum of 65,536 ASNs could be allocated, but were later extended to 32 bits to account for the growing number of ASNs (more than 120k as of 2025). The current allocation of these resources to RIRs can be seen in the IANA IPv4 Address Space Registry, the IANA IPv6 Global Unicast Address Assignments, and the IANA Autonomous System Numbers List. IANA IPv4 Address Space Registry IANA IPv4 Address Space Registry IANA IPv6 Global Unicast Address Assignments IANA IPv6 Global Unicast Address Assignments IANA Autonomous System Numbers List IANA Autonomous System Numbers List The exact resource allocation policy depends on each RIR, but they will typically distinguish two types of allocations: ISPs and end users. ISP allocations can be further sub-allocated by the ISP to its own customers. We can also say that the ISP acts as a Local Internet Registry (LIR). For these kinds of allocations ISPs usually pay a membership fee that funds the registry operation. On the other hand, end-user allocations are usually exempt of membership requirements, but have the restriction that they cannot be sub-allocated. Let’s have a look at a concrete example, with the 2a01:c910:1:20e::/64 IPv6 range. The allocation hierarchy is as follows: We clearly see the IANA → RIR → LIR(s) → end user allocation hierarchy. Who Needs to Own Resources? Who Needs to Own Resources? One might wonder: why bother obtaining IP addresses from a RIR or LIR when an organization could just use the IP addresses handed out by their ISP? The main reasons for owning IP addresses are: Portability: The ability for an organization to move IP addresses across ISPs without renumbering all of its devices, i.e. having provider-independent address space.Multihoming: Announcing IP addresses from multiple ISPs for redundancy. Portability: The ability for an organization to move IP addresses across ISPs without renumbering all of its devices, i.e. having provider-independent address space. Portability provider-independent address space provider-independent address space Multihoming: Announcing IP addresses from multiple ISPs for redundancy. Multihoming Additional benefits can be: Reputation: By controlling how IP addresses are used, the owner can make sure they are not used for nefarious purposes (e.g. sending spam) and implement its own abuse handling policy by setting point of contact fields in the WHOIS database.Reverse DNS delegation: The IANA maintains the root zone for reverse DNS records (in-addr.arpa and ip6.arpa) and delegates the child zones to the RIRs, which in turn can delegate the zones matching the owned resources to the organization's own DNS servers (see RIPE NCC’s documentation for example) Reputation: By controlling how IP addresses are used, the owner can make sure they are not used for nefarious purposes (e.g. sending spam) and implement its own abuse handling policy by setting point of contact fields in the WHOIS database. Reputation point of contact fields in the WHOIS database point of contact fields in the WHOIS database Reverse DNS delegation: The IANA maintains the root zone for reverse DNS records (in-addr.arpa and ip6.arpa) and delegates the child zones to the RIRs, which in turn can delegate the zones matching the owned resources to the organization's own DNS servers (see RIPE NCC’s documentation for example) Reverse DNS delegation RIPE NCC’s documentation RIPE NCC’s documentation The reason for obtaining an AS number is simpler: it is required to establish public BGP sessions! Thus any network willing to announce IPs on the Internet must have its own ASN. Note that IP addresses and ASN allocations are independent. An organization might have an ASN, but only route IPs brought by its customer, and similarly an organization can own IPs, but not have the infrastructure to route them and rely on an ISP with an ASN for that. In practice, most smaller organizations are fine using IP space assigned by their ISP and don’t need their own ASN. Ownership becomes important for companies that run large-scale infrastructure, provide Internet services, or need independence and resilience—such as ISPs, hosting providers, CDNs, and enterprises with complex networks. For these organizations, direct resource ownership offers control, stability, and flexibility that simply leasing addresses from an ISP cannot match. What WHOIS and RIR Data Reveal What WHOIS and RIR Data Reveal IP address and ASN records in the RIR databases contain information about the owner of these resources, but they can also contain additional metadata like the intended usage of these resources or contact addresses. Let’s have a look at some resources. To do so we will use the WHOIS protocol with the whois command line utility, but note that there is also a newer HTTP-based protocol called RDAP. WHOIS WHOIS RDAP RDAP We can query the RIPE database for the 2a01:c910:1:20e::/64 range with the following command: whois -h whois.ripe.net – 2a01:c910:1:20e::/64 whois.ripe.net whois.ripe.net If the WHOIS server is not specified (whois.ripe.net in this case) then the whois command will use the IANA server (whois.iana.org), which will redirect to the appropriate RIR server in most cases. However, it’s good practice to specify the proper WHOIS server to make sure you get the expected record. whois.ripe.net whois.ripe.net whois.iana.org whois.iana.org inet6num: 2a01:c910:1:20e::/64 netname: FR-LA-POSTE-DISIT country: FR descr: SERVICES admin-c: DL7113-RIPE tech-c: DL7113-RIPE tech-c: AA2914-RIPE status: ASSIGNED mnt-by: PC80199-MNT created: 2015-05-27T11:38:38Z last-modified: 2015-05-27T11:38:38Z source: RIPE inet6num: 2a01:c910:1:20e::/64 netname: FR-LA-POSTE-DISIT country: FR descr: SERVICES admin-c: DL7113-RIPE tech-c: DL7113-RIPE tech-c: AA2914-RIPE status: ASSIGNED mnt-by: PC80199-MNT created: 2015-05-27T11:38:38Z last-modified: 2015-05-27T11:38:38Z source: RIPE IPv6 allocation in the RIPE database. The record tells us multiple things: The name of the IP range gives us a hint as to its purpose. In this case it seems allocated to the French post.The country tells us that this range is probably used in France, although this attribute is completely free for the user to set and might be unrelated to IP geolocation. See the next section.The admin-c and tech-c attribute give us the administrative and technical contacts for this IP range. In this case AA2914-RIPE links to a record containing the addresses of Orange Business Services (the LIR) support center while DL7113-RIPE tells us the address of the French postal service IT services.The mnt-by attribute tells us the entity allowed to make changes to the inetnum record itself. Naturally in this case it’s the LIR, Orange Business Services. The name of the IP range gives us a hint as to its purpose. In this case it seems allocated to the French post. The country tells us that this range is probably used in France, although this attribute is completely free for the user to set and might be unrelated to IP geolocation. See the next section. The admin-c and tech-c attribute give us the administrative and technical contacts for this IP range. In this case AA2914-RIPE links to a record containing the addresses of Orange Business Services (the LIR) support center while DL7113-RIPE tells us the address of the French postal service IT services. The mnt-by attribute tells us the entity allowed to make changes to the inetnum record itself. Naturally in this case it’s the LIR, Orange Business Services. The role records linked in the admin-c, tech-c and mnt-by attributes contain postal addresses, phone numbers and email addresses. For example, if we lookup AA2914-RIPE: role: Administration Adresses remarks: Internet Support Center address: Orange Business Services address: 6 avenue Albert Durand address: 31700 Blagnac France phone: +33969397520 abuse-mailbox: abuse.orange-business@orange.com nic-hdl: AA2914-RIPE remarks: http://www.orange-business.com mnt-by: RAIN-TRANSPAC created: 2004-03-12T12:24:14Z last-modified: 2024-11-26T14:37:29Z source: RIPE role: Administration Adresses remarks: Internet Support Center address: Orange Business Services address: 6 avenue Albert Durand address: 31700 Blagnac France phone: +33969397520 abuse-mailbox: abuse.orange-business@orange.com nic-hdl: AA2914-RIPE remarks: http://www.orange-business.com mnt-by: RAIN-TRANSPAC created: 2004-03-12T12:24:14Z last-modified: 2024-11-26T14:37:29Z source: RIPE Point of contact in the RIPE database. WHOIS and RIR Limitations WHOIS and RIR Limitations WHOIS ≠ Geolocation WHOIS records are often used as a proxy for IP geolocation. However, this usage is precarious as there is no guarantee that the addresses in the records are correct or linked to the actual location where the IP addresses are used. For example, the RIPE database documentation has this to say regarding the country attribute: documentation documentation This identifies a country using the ISO 3166-2 letter country codes. It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries. This identifies a country using the ISO 3166-2 letter country codes. It has never been specified what this country represents. It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries. Therefore, it cannot be used in any reliable way to map IP addresses to countries. Furthermore, the granularity of IP address allocation is often too coarse to represent anything below the country level. The proper solution for network operators to share geolocation information are geofeeds. geofeeds geofeeds Route Objects Are Informational Only Another common source of confusion regarding WHOIS records come from route records. These records tell us which ASNs are expected to announce an IP range. For example, the following record tells us that 90.38.0.0/16 should be announced by AS3215: route: 90.38.0.0/16 descr: France Telecom IP2000-ADSL-BAS origin: AS3215 mnt-by: FT-BRX created: 2012-12-11T10:07:49Z last-modified: 2012-12-11T10:07:49Z source: RIPE route: 90.38.0.0/16 descr: France Telecom IP2000-ADSL-BAS origin: AS3215 mnt-by: FT-BRX created: 2012-12-11T10:07:49Z last-modified: 2012-12-11T10:07:49Z source: RIPE Route record in the RIPE database. However, these records are purely informational. Some network operators might use them to reject routes where the origin ASN doesn’t match, but some might not use those records at all. Furthermore these records can exist even if an IP range is not actually announced. As such, these records cannot be used to determine which ASN announces an IP range. This information can, however, be obtained from the BGP routing protocol. The Messiness of Public Registry Data The Messiness of Public Registry Data The RIRs databases are publicly available, which makes them great sources of information about the entities operating on the Internet. However, this data can also be quite messy. RIRs do not all support the same record types, and even for common records, the attributes supported might be different. Furthermore, some fields, like the address, are freeform and their validity is not enforced by the RIRs. It is not uncommon to find invalid or mangled addresses in WHOIS records. How IPinfo Transforms Static Records into Dynamic Intelligence How IPinfo Transforms Static Records into Dynamic Intelligence The Internet’s addressing system was built on a cooperative trust model: registries publish allocations, operators document routing intentions, and the community assumes these records are correct. However, this model also allowed some actors to disguise malicious or unwanted traffic. For example, web crawlers can rotate IP addresses and ASNs often to evade detection (see this Cloudflare blog post for a recent example). blog post blog post IPinfo data sheds light into these issues with our rich data: IP WHOIS Our IP WHOIS data maps IP ranges to their owners in a standardized and enriched format across all regional Internet registries. This data is useful to understand the allocation hierarchy and history of an IP address and, for example, to distinguish stable, ISP-allocated IPs from IPs from IP brokers who might change hands frequently. This data can also be used to discover assets owned by a particular organization, and estimate their attack surface for proactive management. IP to Company and IP Ranges Our IP to Company and IP Ranges dataset are distilled versions of our WHOIS dataset that always return the most specific information for an IP address. They are useful when one cares only about the final owner of an IP address and not the full allocation hierarchy. They allow users to easily obtain all IP ranges belonging to an organization by looking up its name or domain name. IP to ASN Our IP to ASN data maps IP addresses to their origin ASN — the organization that routes the IP address on the Internet. This data can be used to know the ISP of a user, but also to filter human traffic from bot traffic often originating from hosting and cloud providers ASNs. IP Geolocation Our IP geolocation data, informed by ProbeNet, our internet measurement platform, provides accurate location attribution down to the city level, detecting discrepancies between WHOIS country codes and the IP’s observed geography. IP Privacy Detection Our IP privacy detection data flags IPs using VPNs, proxies, Tor nodes, residential proxies and other anonymizing services, enabling users to filter bot traffic, prioritize investigations, and handle anonymized connections with the appropriate caution. From Assumptions to Evidence From Assumptions to Evidence Traditional registry data is valuable but incomplete. Without validation, it’s easy to misattribute ownership, geography, or routing, leading to costly blind spots. IPinfo uses publicly available signals, like WHOIS data and geofeeds, standardizes and organizes that information into a consistent format, and builds off that foundation with partner/vendor data as well as our own proprietary intelligence. This approach turns registry data from a static directory into a dynamic, verifiable intelligence layer. It enables network defenders, researchers, and operators to move from assumption-based analysis to evidence-backed mapping of Internet resources, reducing false positives and uncovering infrastructure that would remain hidden in traditional WHOIS-only workflows. Ready to see beyond registry records? Static WHOIS and RIR data only tell part of the story. IPinfo’s datasets combine registry information with real-time measurements, advanced privacy detection, and curated intelligence to give you a complete view of the Internet’s infrastructure. About the Author: Maxime Mouchet Max currently works as a data engineer on IP geolocation at IPinfo. Previously, he was a postdoctoral researcher at Sorbonne Université where he worked on multipath traceroute measurements.