reincoder

Please take a look: https://x.com/reincdr/status/2111245089125339538

Thank you very much.

I work for IPinfo. We really would appreciate more constructive feedback on how to present data driven stories that is approachable to everyone.

> I stopped reading after the first graphic.

Now, let's see what we had before the first graphic.

1st Paragraph: Explains what BGP is.

2nd Paragraph: Tells a story about the Pakistani ASN accidental BGP hijack. A story which is known in the network engineering community, but not by most people.

3rd Paragraph: Introduces RPKI.

4th Paragraph: Summary states that builds the foundation of the article.

Then the first graphic shows the RPKI validation. That is all.

How would you structure the blog post about RPKI adoption, which is a data-driven technical story? I am not absolutely trying to be demeaning, but would you rather start from what BGP, RPKI, and those things are?

Then we have a series of community post around them:

- https://shubhamjain.neocities.org/bgp-explainer (HIGHLY RECOMMENDED)

- https://community.ipinfo.io/t/internet-from-scratch-in-10-sl...

- https://community.ipinfo.io/t/how-your-internet-traffic-actu...

- https://community.ipinfo.io/t/understanding-an-asn-page-peer...

I work for IPinfo (but not the author here). We really appreciate the feedback!

So, what we have been doing is we publish a blog and we publish an interactive dashboard as well

  - https://ipinfo.io/reports/most-popular-places
  - https://ipinfo.io/blog/united-states-walmart-wifi-data

We could have done something similar here as well. It is really challenging to balance the stats and explainers. So, the approach we sometimes take with high-impact topics is to provide companion blogs and dashboards for users to explore the data themselves.

I work for IPinfo but my colleague is the author. It is very interesting challenge to "translate" vast amounts of data we have into stories that are insightful.

So, what we have been doing recently is publishing a blog and a companion dashboard. Check it out here:

  - Report: https://ipinfo.io/reports/most-popular-places
  - Blog: https://ipinfo.io/blog/united-states-walmart-wifi-data

Now, that is a good approach for high-impact data to build a dashboard and have a companion piece that only provides surface-level information, so it keeps things interesting and invites you to explore.

But building the dashboards is not an easy task, as you have to deal with data pipelines and work with engineering teams to bring them online.

I am absolutely not being demeaning at all, but just look at the graphics and diagram and skip the text. I think the graphics are a pretty solid explainer of what the article is about. The text dives more into granular information that you may not find useful if you want skimmable content.

Check out an anycast IP directly: https://ipinfo.io/1.1.1.1

We show locations hints for anycast IPs.

We have country level breakdown for ASNs.

  - https://ipinfo.io/AS214822#geolocation

We have some IP range breakdown as well:

  - https://ipinfo.io/AS214822/45.8.228.0/24
  - https://ipinfo.io/ips/45.8.228.0/24

We have the data. How would you like us to present it? (Bonus point if you can tell me why that will be helpful because that will help me to make a better pitch to engineering!)

I recently learnt about Transatlantic telegraph cable: https://en.wikipedia.org/wiki/Transatlantic_telegraph_cable

It was laid in 1858. During its brief three-week lifespan, only 732 messages (amounting to roughly 400 total telegrams) were successfully transmitted before the cable died.

Not an advert. I wish we ran example.com. However, we run a few other services.

The issue with example.com is this statement:

> This domain is for use in documentation examples without needing permission. This is not a service; avoid relying on it for testing and monitoring purposes.

The problem is that, disclaimer or not, if a website provides a useful utility, people will use it as a service.

If example.com breaks, IANA can reasonably say it was never intended to be stable. But that does not change the fact that people will use it for testing and monitoring.

What we do is adopt legacy services whose maintainers can no longer afford, want, or have the resources to maintain them, and invest in keeping them running reliably.

We (IPinfo) have a practice of adopting low-maintenance, high-utility services. Generally, we adopt websites that would have become defunct and run them as services.

Even though IANA says example.com is intended for documentation purposes and not as a service, I feel that it nonetheless serves as a service to the broader internet. I think there are some cornerstone services on the internet, regardless of the maintainers' intentions or their legal definitions.

For example, we ourselves sometimes have to recognize that we are not a standard API service. Considering that we expect to process 3 trillion requests this year, a major outage could take down a good chunk of IT systems everywhere. So, we invested in infrastructure to avoid outages. We then started adopting other cornerstone services and running them indefinitely because we might as well support the users who depend on them because we have infrastructure to support them and us.

I have been part of this community for over a decade, and in my experience the mods do take flagging and voting irregularities seriously when they are reported. If you believe there is manipulation happening on your posts, that is worth raising directly with them, since they have visibility we do not.

---

On the broader point, we process 3 trillion requests last year, have more than 80 employees, and run a dedicated privacy engineering team led by an ex-cybersecurity company founder. We invest in research on new detection methods and stay closely engaged with the developer community. If there are specific gaps you see in our product, I would be glad to hear them and discuss.

---

Whether any dataset, including residential proxy IP data, is valuable depends heavily on the application. Treating a dataset as invalid because it does not fit one particular model can lead to decisions on shaky ground.

We are regarded as one of the more if not the most accurate IP geolocation providers, and we spend considerable effort on education, solutions architecture, and documentation so customers understand what our data can and cannot support. For example, IP geolocation, even at highest level of accuracy, is not a person identifier. It will never be a 1:1 replacement of GPS geolocation.

Many of the largest companies in AI, anti-bot, fingerprinting, KYC, and CDN spaces use our data. If anti-bot systems and CAPTCHAs were fully reliable on their own, there would be less need for additional signals like residential proxy data. We do not assign a score or label an IP as good or bad. That judgment sits with the customer's own threat or analytics model.

Residential proxy IPs are, by and large, mostly used in web scraping operations of many different forms. If a company sees a moderate to high amount of traffic mimicking human behavior, it can struggle to tell bot traffic apart from real users. Anti-bot mechanisms can help, but they add friction to the user experience, and they are not cheap to run at scale.

Residential proxy detection data is one of the easiest zero-knowledge ways to gather intelligence. There is no need for users to solve a puzzle or for multi-page traversal to collect fingerprint data. All that is needed is the IP address.

Our residential proxy data customers tend to be on the more sophisticated side of cybersecurity. Suggesting that this data is a silver bullet for all their security needs would not reflect well on their expertise or ours. We present the data as is, and from there we work with customers on the right solution for their case.

I work for IPinfo. We offer a residential proxy detection service, which you can check at ipinfo.io/my.

We had a previous discussion about surfacing visitor IP address resproxy status explicitly. Should we have some sort of badge or a more explicit alert to show if a site visitor's IP address is part of a residential proxy network?

Even though it is great for demonstrating the product's value, it is kind of a low-tier value. What can a user actually do when they realize their IP address is part of a residential proxy pool?

The first issue is that residential proxy SDK infiltration is massive. If you start connecting to different IP addresses and constantly check your IP address on our website, you will often see that many of those IP addresses were, at some point, part of a residential proxy pool. We provide frequency information showing how many times an IP address was observed in a residential proxy pool, with a default observation period of 7 days.

Then there is the question of what a user can actually do about it. If it is a controlled IT environment with paranoid IT admins, sure, they can actively monitor traffic and identify why their IPs are showing up in residential proxy pools. They can attempt to do something about it. But it is not easy even then.

Residential proxy SDKs can simply be baked into almost any smartphone or smartphone-derived OS that allows app installation through marketplaces. So, many residential networks are already cooked (because of android TVs). Moderate-scale NAT connections almost always see residential proxy flags, as do public Wi-Fi hotspot IPs, which we also detect.

Identifying the apps that are generating background network traffic is quite hard. You need some level of DNS monitoring or a network sniffer. Alternatively, you need router-level firewall software.

These SDKs are not always sending high-volume, constant traffic that makes them easy to detect. If you see a 100% residential proxy flag for your IP address, then they probably are. But in many cases, the traffic is intermittent and much harder to identify.

Nobody has an answer to what I should do when I see my IP address in a residential proxy pool. It has been accepted in spirit as a "consented malware" for the last few years. It is undetectable and extremely hard to remove because the SDK has been baked into apps themselves.

I was looking into the IPv6 adoption of US government websites (https://community.ipinfo.io/t/the-state-of-ipv6-across-us-go...) when we discovered that Cloudflare had essentially dethroned Akamai for government content hosting over a number of years. The post primarily focuses on IPv6, but according to our data, Cloudflare hosts 70% of US government websites.

You can block entire ASNs. If you are frustrated with bots, blocking Tencent's entire IP address space would have very few downsides.

If you have fail2ban or NGINX logs, you can use our CLI to summarize those IPs and identify the ASNs you want to block. But before you block entire ASNs, make sure they are not classified as "ISP" type. For that, visit our website's ASN page first.

I have quite a few community posts around this approach. https://community.ipinfo.io/

If you have raw logs, you can send them to me as well, and I can review them and provide some guidance.

I work for IPinfo. We offer IPinfo Lite for free. With a little bit of time in identifying the ASNs, you can implement a decent way to block a good number of bots fairly easily using the free data alone.

The project directly references us, so it is only fair we provide more context.

The idea of a pitch means that there is some sort of price attached to it, which IPinfo Lite does not have. In fact, it is designed as commercially permissive as possible.

According to MaxMind, they offer a variety of databases with different pricing tiers of accuracy. Geolite2 as a database service is free but its accuracy is compromised by design. If you want a more accurate version of their database, you have to pay for the GeoIP2 database. Now, this applies to country-level data as well. They have a free, accuracy-compromised country database, and then they have their database with better accuracy available for purchase.

We would rather not compromise on accuracy at all and provide the highest possible accurate country-level data for free. We do not have a compromised accuracy variant of any database. We sell the city database and offer the country database for free to anyone.

There are three layers of cost here with a self-hosted project. You pay for the VM, you set up the project, and you have to maintain it. So, for some folks, the API service makes sense because the cost maintaining the infrastructure for it is on us.

We offer an offline version of the IPinfo Lite database for download: https://ipinfo.io/developers/ipinfo-lite-database

We do not comment to advertise. We participate in IP geolocation discussions because there is a lot of misinformation in this space, and we feel a responsibility to provide accurate information publicly.

In this case, the recommendation was for a free product that requires no setup and no VM cost. The opposite of a sales pitch.

I work at IPinfo. We offer unlimited free requests through the IPinfo Lite API. By unlimited, I mean millions of requests per day. The free API provides country and ASN data.

As far as I know, GeoLite2 does not have city-level data for a large number of IP addresses. Even when it does, the city-level accuracy can be quite poor.

So I'd suggest just using our API and pointing to the capital city. That would also remove the need to pay for a VM.

I work for IPinfo. We do not provide reputation scoring, by the way. Reputation is such a subjective matter.

It would be easy for us to make a very quick sales if we start offering reputation scoring, but we, as a company, would rather support fraud detection, threat intelligence and bot detection services with raw data from us.

In fact, the 1400 servers we operate for internet measurement all have very sophisticated honeypots baked into them, but still, we have not productized that data. In our experience of the fast-moving world of IP addresses, reputation scoring, even with the best intentions, can introduce some downsides. We can do many things which will be better than most things out there, but we have to really balance the consequences of our product.

Yes, we do use user agents to separate requests to our websites and API service. However, we request users to switch to api.ipinfo.io (dedicated API infrastructure) and use ipinfo.io/json for an explicit request for the API endpoint.

There are indeed some limitations to this implementation. The primary one being IPv6 support. The implementation prioritizes convenience over internet limitations, requiring us to roll out IPv6 dual stacking on the web request level as opposed to the DNS level. On an API level, this results in users with IPv6 addresses making API requests to v6.ipinfo.io.

So, last year we rolled out dedicated API infrastructure for api.ipinfo.io

You have to ask them. I tried but did not get a clear answer.

We operate nearly 1,400 servers across almost 160 countries ourselves. From our perspective, it is VERY hard to maintain and expand a network infrastructure of this scale. When you start getting servers in West Africa, Northern Africa, the plains in North America, or Oceania, the Eastern Indian Ocean, you are expected to pay magnitudes more compared to servers with equal performance in NYC or Amsterdam. Maintaining such a diversified network infrastructure from a technical point of view is extremely challenging. Then there is the official and bureaucratic process.

Now, we are just scratching the surface. VPNs require high volume traffic throughput. Some countries (entire countries) just do not have the capacity to offer that.

So, most of the time VPN companies tend to work with specialty VPN infrastructure companies. They provide everything from hosting to networking across dozens of locations they operate in. I believe there are even white-label VPN companies that handle everything from infrastructure handling all the way to billing and even support handling. You just bring your branding. It can be argued that there is little incentive to go out there, do it all from scratch.

Is it intentional or just obscuring? From what we see, it leans intentional. The location they report is not inaccurate information by accident, it looks quite deliberate. Legacy IP geolocation services rely on something called a geofeed. A geofeed is a self-reported unverifiable report published by a network operator. Geofeeds are not widely adopted (1.5% of IPv4 and 0.70% of IPv6 allocated prefixes, 2023 data), but VPN providers maintain theirs diligently. They actively publish the locations they want IP geolocation providers to report.

One point raised by a journalist on the reporting side: imagine your VPN server points to one of the offshore islands in the Caribbean that sit outside US jurisdiction, only to find out the actual VPN server is in Miami. That is a bit risky.

Windsribe and iVPN.

https://ipinfo.io/vpnreport

I work for IPinfo. Even though we are in the VPN detection business, I will give Mullvad the benefit of the doubt, to be honest. They were one of the three VPN providers we found that did not attempt to submit inaccurate geolocation information to IP geolocation providers like us. I am sure they will fix the issue.

I used the same methodology to observe AI crawlers. This is not an investigative blog but is rather designed to address our (IPinfo) customers who are asking us to identify IP addresses as "AI Agents" or, more accurately, "AI Crawlers".

https://community.ipinfo.io/t/can-we-detect-ai-agents-we-can...

Most AI crawlers self-identify with a UA. However, Grok uses resproxies and sends a high volume of simultaneous requests. Even though we can detect resproxies, it is not possible to map these resproxy IPs to grok.

I still could not figure out why I saw legitimate Googlebot IPs when I requested Perplexity to review the website. I verified those Googlebot IPs using both using UA and the listed IP address ranges published by Google.

  ---
  Edit to my parent company
  ---

I am scaling back this enthusiasm a bit. We need to work with mature organizations instead of individuals.

We need SSH through a public IP address and use Ubuntu as an operating system. Since we need to determine where these servers are located, we need to collaborate with universities, various organizations, IXP, DCs, telecom/ISP consulting companies with a mature understanding of network engineering.

We actually have app-based data collection capabilities and initiatives. Our goal, or more appropriately, vision, is to map the internet in real time. This involves SSH access to devices to run different forms of measurements at a very high frequency and have control over those devices.

Managing 70k probes is not going to be super hard.

Managing 1,400 servers is just a normal business operation, not a technical challenge. Each probe has a standard OS-level configuration. Automation and configuration are deployed from a central system. Each probe is actively monitored and troubleshot. Data is dumped to a data warehouse. We make incremental improvements to our network. When servers go down, we talk to vendors.

We do a lot of novel engineering things from the infrastructure, data, and research team. Having a very identical set of servers really allows us to focus on product and performance engineering, not troubleshooting engineering. With application-based probing, I assume it will complicate things quite a bit, as there are different operating systems, different devices, etc.

For us, lately the challenge is not technical. It has been exclusively procurement. This quarter (https://ipinfo.io/blog/probenet-q1-2026-expansion), we exclusively focused on regional diversity which involved outreach to national ISPs or telecoms. Securing servers from telecoms is an extremely bureaucratic and expensive process. So, we are hoping to partner up with eyeball networks and the larger NOG community.

I work for IPinfo and we operate a distributed network consisting of around 1,400 servers. I think we have reached a point where it is extremely hard for us purchase VPSes from interesting ASNs.

To support lots of ISPs, universities, and different organizations we have been asking them if they have an old laptop lying around that they can host our software on. Goal is to reach 70,000 probes within the next couple of years.

It is a simple probe software and we share some data or we can pay 20-30 bucks a month for it. We have a couple of NUCs in remote regions but no laptops yet. Basically, we are even happy if an ISP (or any one) hosts our software from a laptop dangling by a charging cable from a socket in some random corner.

We can send over a RPI or NUC, but with remote hands, and setup and all that it can get quite expensive. So, we always first ask if they have an old laptop lying around and can install our software there.

For us, at least, we are not interested in the hardware aspect. We are interested in the network. The old laptop approach only acts as a last resort. We will be more than happy to go with the predictability of a traditional VPS hosted in a traditional data center. Colocation, no matter what form it takes, involves a lot of moving parts.

> I couldn't get /lite/ to work.

Email me: abdullah@ipinfo.io

I think there is an issue with setting up our API.

> Do you happen to know if anyone is compiling all of this data about VPNs into one place? It would be super interesting to know which VPNs are providing genuine services vs masquerading the locations. Maybe even an SEO for you.

We made that report independently and, according to our analysis, we only identified three VPNs: Windscribe, Mullvad, and iVPN to not have virtual VPN server locations.

> Just to clarify: You are suggesting that we don't pro-actively enrich every IP address, store IPs, and only enrich them when troubleshooting something?

I think you should experiment with this yourself a little. The Lite API is completely free. So you can do ingestion enrichment and post-enrichment enrichment. See what works best for you.

> I am assuming the inferred data, but that also feels counter-intuitive (since the data does not align with what ASN/ISP are reporting).

That is a very good question. Now, geofeed does not have a verification system. Active measurement is something we use to verify ASN or ISP itself.

Even active measurement has its own limitations. Now in those case where we see active measurements not producing reliable data, we do reach out to ISPs and ASNs to purchase a server in their facility. Geofeed as a system is voluntary and most major ISPs actually do not maintain or even publish that. For example, today I found out a major UK-based telecom geolocated 500k IP addresses in a town with 200k people. ISPs are not inherently incentivized to maintain the accuracy of their self-reported, voluntarily published location data. So, we do proactive outreach to purchase a server from them so we can provide consistent accurate data for their IP addresses.

On the matter of advertised locations not matching actual location, I highly recommend reading this: https://ipinfo.io/blog/vpn-location-mismatch-report

For residential ISPs, we do a lot of outreach and open communication to build a good partnership with them. The goal is that we pay for the privilege to report accurate data for them.

> How often does your active measurement data disagree with geofeed data?

Very frequently.

Here is the summary peer reviewed research paper on this matter: https://community.ipinfo.io/t/ip-geolocation-and-geofeeds-wh...

Active Measurement (1,330 probes, 27.7M RTTs):

  - Country-level: 92.0% accurate → 8% wrong country
  - City-level: 79.6% accurate → 20.4% wrong city

Mobile Device GPS (169 devices, 24 countries):

  - Country-level: 84.5% accurate
  - City-level: 29.9% accurate → 70% wrong city

> How do you handle mobile/cellular IPs

Primarily through active measurement, we are also running a lot of research around more reliable mobile geolocation data.

Because our data is updated daily, I think due to the refresh rate we have an accuracy advantage.

> If I am troubleshooting a support case that is days/weeks/months old, wouldn't this mean that enriching this information at a later date may give me different data than what it was associated with at the time the requests were made? My understanding was that IPs get re-assigned.

You will be surprised to know that historical IP location does not have much demand.

If you are evaluating a support case after some time, you should work with your current data. If the customer raises a question, you address this in real time with their current IP address.

Usually, I do not recommend storing historic IP geolocation information. In most operations, the enrichment happens in real time within the day. Unless you want to do periodic reporting of some sort.

Internally, we of course have the data, but because our IP geolocation is so accurate, it currently sits at around 700 MB. If you add a historical layer to that data, it will be a terabyte of data. There is not much consumer need for it.

> How frequently do IP-to-location mappings change in practice?

https://ipinfo.io/blog/how-many-ips-change-geolocation-over-...

On the city level is 1.3% each day and 16% each month.

> Do you offer historical IP data snapshots?

I highly recommend that you work with current day's data.

In cases where we provide historical data, it is usually for academic research.

---

Let me know if you have any more questions.

I work for IPinfo. We provide a free country and ASN database on a free tier with an unlimited amount of requests. You can download the entire database or use the API services. For country and ASN, it is free.

However, we do not offer city level data for free. > How would one even go about verifying it?

We believe we are the most accurate IP data provider out there, but you should come to that conclusion yourself.

I can tell you why our data is super accurate compared to the rest of the industry. The industry as a whole uses self-reported information that is offered by ASN and ISPs. It is called "geofeed". The issue with geofeed is that IP geolocation providers do not tend to verify the accuracy. Many providers just aggregate these public records and repeat what the ISPs and ASNs want them to tell them. This is a quite bad practice.

So we built a network of distributed servers (currently 1360 servers across 160 countries) that run ping, traceroute and other internet measurements and try to infer the location of IP geolocations. This means when you come to asking how do I know you are accurate, we can share our active measurement data and tell you that this is the evidence.

Now, comes the qustions of how you identify accuracy yourself.

First, if you have access to a large pool of known locations of IP addresses, you can run comparisons across different vendors. You need a GPS-backed device to locate IP addresses.

If you do not have a large pool of well-known location IPs, you can take a sample of IP addresses and check them yourself across multiple vendors. You can then use a tool like ping.sx or our own tool ipinfo.io/probenet/live to see evidence of where these IP addresses are located based on latency.

Do not bet on consensuses among IP geolocation providers; run your own tests.

Our data was evaluated by peer-reviewed academic research. You can take a look at that as well, if you want.

> I am not really using this data for anything other than have enough data to troubleshoot customer support/fraud.

Now, I will be honest...you should not pay anything to us. The way you have describing your issue, it seems like the free services we already offer that should satisfy your need.

Do you really need large scale IP address enrichment of all the IP addresses that visit your website? If yes, then for the first layer use our free data that provides ASN and country information.

Then, when you need troubleshooting with your customers, you can look up those individual IP addresses for free on our website, where we provide all our data for free access.

---

Let me know if you need any help, always happy to answer questions.