ip-fd.net
Sign in

Data sources and method

Where our data comes from, how often it is updated and how we decide the location of an address.

Registry networks
6.8M
Announced prefixes
941.5k
Geofeeds in use
3,139

Registration data

Every night we download the public database dumps of the RIPE NCC, APNIC and AFRINIC and update networks (inetnum and inet6num), organisations, AS numbers and abuse contacts. For addresses managed by ARIN and LACNIC, whose WHOIS data is not published as a bulk dump, we use the delegation files of all five registries as mirrored by the RIPE NCC. They tell us who received a block and in which country.

The public RIPE dumps replace organisation addresses with placeholders. When we need an organisation's address we fetch it from the RIPE Database REST API and keep it for 60 days.

Last completed import: 2026-09-14 22:00 UTC.

Routing data

Announced prefixes and AS neighbours come from the RIPE NCC's Routing Information Service (RIS) through RIPEstat. We collect them for every routed AS (55,226 at the last run). The origin AS of an address is the AS that announces the most specific route covering it. AS names and countries for all registries come from the RIPE NCC's AS name list.

How we locate an address

A registry record tells you who holds an address, not where it is used. A hosting company registered in one city often runs data centres in many others, so we combine several sources and use the most reliable one available:

  1. Manual correction. A location we set after checking a report.
  2. Operator geofeed. Many networks publish an RFC 8805 file listing the location of each prefix and reference it from their inetnum object. We download 3,139 of these feeds daily and use them at full precision. Following RFC 9092, a feed may only describe addresses inside the record that points to it.
  3. Registry coordinates. The geoloc: attribute some networks add to their records.
  4. Network rule. For large networks that publish no geofeed we keep rules that map their naming scheme to locations.
  5. RIPE IPmap. The RIPE NCC's geolocation service, which measures latency from RIPE Atlas probes.
  6. Reverse DNS. Router and server names often contain a city or airport code, for example ae1.cr1.fra2.example.net. Codes are only accepted when they match the registry country.
  7. City in the registry record. A city named in the netname or description, only accepted when it matches the registry country.
  8. Cloud provider range lists. AWS, Google Cloud and Oracle publish which region each of their prefixes is used in.
  9. Registered address. The address of the holder organisation, only when it is in the same country as the network. Often the head office, so it is marked as low confidence.
  10. RIPE Atlas measurement. When no source names a city, we ping the block from a few RIPE Atlas anchors in the registry country. The closest anchor gives the location. Used sparingly.
  11. Country only. When nothing better exists we show the registry country and no city.

Every lookup shows which source was used and lists the others, so you can judge the answer yourself.

Run a network?

The best way to get correct locations for your addresses is to publish a geofeed. Add a geofeed: attribute to your inetnum objects or submit your feed to us. If you spot a wrong location, report it.

Licences

Registry data is provided by the RIPE NCC, APNIC, AFRINIC, ARIN and LACNIC under their respective terms. City names and coordinates come from GeoNames, licensed under CC BY 4.0.