A geofeed is a CSV file in which a network operator states where its IP prefixes are used: one prefix per line, followed by a country, a region and a city. RFC 8805 defines the format, RFC 9632 defines how to find the file from a registry record, and geolocation providers, Ipregistry included, fetch these files to correct their databases. If your customers keep showing up in the wrong country on other people’s websites, publishing one is the most durable fix you have.
Publish a geofeed in five steps
-
Write the file. One line per prefix: the prefix, the two-letter country code, the ISO 3166-2 region code, the city, then an empty field where the deprecated postal code used to go. Save it as UTF-8 text.
198.51.100.0/24,US,US-NJ,Princeton, 2001:db8:100::/48,DE,DE-BE,Berlin, -
Host it. Put it at a stable HTTPS URL that anyone can fetch without logging in, ideally on your own domain, for example
https://acme.com/geofeed.csv. -
Check it. Paste the URL into our geofeed checker, which fetches the file and flags lines that break the format, such as invalid prefixes or country and region codes that do not exist.
-
Point to it from the registry. Add the URL to the record that covers your address space, on every top-level record you hold:
Registry Where What to add RIPE NCC RIPE Database, inetnumorinet6numobjectgeofeed: https://acme.com/geofeed.csvAPNIC MyAPNIC: Resource Manager, Internet Resources, then add a geofeedfieldThe URL ARIN ARIN Online, public comments of the network Geofeed https://acme.com/geofeed.csvAFRINIC AFRINIC database, inetnumorinet6numobjectremarks: Geofeed https://acme.com/geofeed.csvLACNIC MiLACNIC portal Enter the locations in the portal; no file needed -
Keep it current. Update the file whenever a prefix moves. To have a provider pick up a new feed sooner, send it the URL directly (links at the end of this post).
The rest of this post explains each step in detail and measures how widely geofeeds are used. The format started as a Google draft in January 2013, and thirteen years later adoption is still lopsided. At APNIC 62 in Mumbai, held September 4 to 10, 2026, Sid Mathur of Fastah showed that 75.5% of successful geofeed publishers in his sample sat in the RIPE NCC region, 21.6% in ARIN’s and 3.0% in APNIC’s. APNIC published its write-up of the session on September 24. We wanted to see how that holds up against registry data, so we parsed the public database dumps that RIPE NCC, APNIC, AFRINIC and LACNIC published on September 28 and 29, then fetched every geofeed URL they reference. There were 5,688. The results are further down; the format comes first.
One prefix per line: the RFC 8805 format
A geofeed is UTF-8 text with five comma-separated fields per line. Only the first is required.
# prefix,alpha2code,region,city,postal_code
193.0.24.0/21,NL,NL-ZH,Rotterdam,
199.91.192.0/21,MA,MA-07,Marrakech,
2001:67c:1230::/46,SG,SG-01,Singapore,
192.0.2.0/24,,,,The first three lines are the examples RFC 8805 itself uses, taken from the feeds of conference networks (a RIPE meeting, an ICANN meeting and IETF 106). Those prefixes travel from event to event, so their current feeds point elsewhere. The last line uses a documentation prefix.
The prefix is an IPv4 or IPv6 range in CIDR notation, or a single address. The country is a two-letter ISO 3166-1 code, the region is an ISO 3166-2 code such as US-NJ, and the city is free text without commas, ideally the English name. Anything after a # is a comment.
The fifth field is a trap. RFC 8805 kept the postal code column so that old feeds still parse, but marks it deprecated: new feeds “SHOULD NOT include this field due to the granularity of this information”. A postal code can narrow a prefix down to a few buildings, and once a prefix maps to a single household its location starts to look like personal data under the GDPR. Leave the column empty, and only list prefixes that serve a group of users.
The last line of the example leaves every location field blank on purpose. It tells consumers that the prefix should carry no location at all, which is what you want for space that is unallocated, being moved, or announced from several sites at once.
How providers find your feed
Host the file over HTTPS with no authentication, preferably under your company’s domain or a subdomain of it, such as https://acme.com/geofeed.csv, so that anyone reviewing it can tell who publishes it. Then point to the file from the registry, because no provider can guess that the URL exists and there is no authoritative index of feeds.
RFC 9632, which replaced RFC 9092 in August 2024, defines two ways to reference a feed from the inetnum or inet6num object that covers your space:
inetnum: 192.0.2.0 - 192.0.2.255
geofeed: https://acme.com/geofeed.csv
inetnum: 198.51.100.0 - 198.51.100.255
remarks: Geofeed https://acme.com/geofeed.csvUse the geofeed: attribute where the registry has one. RIPE NCC has supported it since December 2021, and APNIC offers it in MyAPNIC. Elsewhere the remarks: form is the fallback. In ARIN Online that means a line in the network’s public comments (suggestion 2024.10, which asks for a real field, is still open), and the AFRINIC and LACNIC dumps we parsed contain remarks only. The token is case sensitive: capital G, one space, then the URL.
Two rules in RFC 9632 matter to publishers. A consumer must use the most specific inetnum that carries a reference, so a customer’s /24 with its own feed overrides the feed on your /16. And when the file is unsigned, as nearly all are, a consumer “MUST ignore data outside the referring inetnum: object’s address range”, so a line for a prefix held under some other object, one that lacks the reference, is supposed to be dropped.
The newest piece is RDAP. RFC 9877, written by Jasdip Singh of ARIN and Tom Harrison of APNIC and published in October 2025, adds a geofeed1 extension: the RDAP response for a network carries a link with "rel": "geofeed" and the media type application/geofeed+csv. We queried all five registries’ RDAP servers on September 29, 2026. Only RIPE NCC’s advertises geofeed1 and returns the link. ARIN, AFRINIC and LACNIC return the URL as a free-text remark. APNIC’s answer for 202.90.240.0/21, a block whose whois record points to Aussie Broadband’s feed through a geofeed: attribute, did not mention the feed at all.
Who publishes geofeeds in 2026
The four dumps hold 7.3 million inetnum and inet6num objects. 87,994 of them reference a geofeed, through 5,688 distinct URLs. We sent one GET to each URL on September 29, 2026 and counted a feed as usable when it answered 200 and contained at least one valid line. 4,818 did, or 84.7%.
Set against Mathur’s figures, the direction matches and the size of the gap depends on the unit. His sample has 25 RIPE publishers for every APNIC one. Counting usable feed URLs, we get 7 to 1. His unit is the network name in a 200,000-row sample, ours is the feed URL, and we have no ARIN column because ARIN hands out bulk whois only under a signed agreement.
Count the lines inside the feeds by the registry that manages each prefix, though, and our crawl lands close to his split. Restricted to the same three registries, 72.4% of lines describe RIPE NCC space, 23.9% ARIN space and 3.7% APNIC space, even with feeds referenced only from ARIN’s database missing. Normalize by registry size and the gap narrows: 1.5% of RIPE objects reference a feed, 1.3% of AFRINIC’s, 0.6% of APNIC’s and 0.1% of LACNIC’s.
Registry is also a poor proxy for geography. 2,068 of the RIPE objects with a feed are registered with country SG and 1,487 with HK, and 105 usable feeds are referenced from both RIPE and APNIC records. Part of Asia Pacific’s geofeed coverage is published through European address space.
The population is more concentrated than the URL count suggests. One file, the feed of the IP leasing marketplace IPXO, is referenced by 14,253 objects, 16.2% of the total. At the other end, 319 URLs point to files on GitHub. After removing identical copies served under different URLs, 4,200 distinct files remain, holding 1,178,436 prefix lines. The median file has four lines and 1,519 files have exactly one, while the ten largest carry 71% of all lines. Hetzner’s is the biggest at 169,849, followed by Deutsche Telekom’s at 148,963.
Why Asia Pacific lags, and what one click would change
The panel’s own numbers agree on the lag. AIORI counted 1,026,544 geofeed prefixes worldwide, 934,528 of them (91%) outside Asia Pacific. A missing feature does not explain it: APNIC has the attribute, and 7,281 of the 8,403 references in its database use it (an object can carry more than one, which is why there are more references than the 8,038 objects counted above).
What the dump shows is publication clustered in a few economies. Objects registered in Australia account for 2,183 of APNIC’s 8,038, and Hong Kong for 1,219. Japan has 601, Korea 46, China 36 and Vietnam 23. Those four have national registries (JPNIC, KRNIC, CNNIC, VNNIC) that sit between APNIC and the operator, and a button in MyAPNIC does nothing for a network that manages its records somewhere else. Treat the four numbers as floors, though: we cannot tell how completely the APNIC dump mirrors records kept by national registries.
Mathur’s request to the registries was blunt: make publishing a geofeed URL “one-click” in their dashboards. An informal poll in an APNIC community WhatsApp group had ranked “unsure how registry can help” as the second biggest barrier.
LACNIC shows where that road leads. Its database references only 57 self-hosted feed URLs, because members have an easier option: they enter locations in the MiLACNIC portal, and LACNIC serves one combined file at milacnic.lacnic.net/lacnic/geofeeds. In June 2020 that file had 1,560 records from 10% of LACNIC’s member organizations. On September 29, 2026 it had 13,545 lines, 5,801 of them for Argentina.
We think the portal model is right, and the crawl gives a reason. Hosting is the fragile part. 639 of the 5,688 URLs failed before we could read a single line: 191 returned a 404, 189 no longer resolve in DNS, and 88 failed the TLS handshake. Another 93 answered with an HTML page. A registry that hosts the file removes that whole class of failure, and what is left is the hard part, keeping the locations true.
Common errors seen in the wild
Of the 4,200 distinct usable files, 872 (20.8%) contain at least one line that breaks the format.
Region codes are the main offender, wrong in 566 files. In 288 of them the code is well formed but does not exist in ISO 3166-2 today, and stale codes are a common way to get there: the standard gets revised, and feeds written once are rarely revisited. PL-MZ became PL-14 when Poland’s codes went numeric, FR-75 is now FR-75C, ZA-GT is ZA-GP, IN-TG is IN-TS. Another 190 files use a bare subdivision such as TX or NY with no country prefix, and 161 put something else in the field, most often a place name like Moscow. Hong Kong has no ISO 3166-2 subdivisions, so HK-HCW is invented, however plausible it looks.
Country codes fail less often, in 93 files. UK for GB appears in 18 and EU in 21. Both are ISO “exceptionally reserved” codes, a set RFC 8805 lets parsers accept, but EU tells a consumer nothing about where the prefix is used.
The rest is housekeeping. 137 files list the same prefix twice, which RFC 8805 tells consumers to treat as an error, and 74 contain prefixes with host bits set, such as a /24 that ends in .1. The postal code column is filled in 1,651 files, 39% of them, six years after it was deprecated.
Staleness is harder to judge from outside. Among the 2,784 files served with a Last-Modified header, 644 had not changed in more than a year and 273 in more than two. To be fair, a feed for a small network that never moves can sit untouched for years and still be correct.
Our geofeed checker runs the same validation engine we use for ingestion. Paste your file or its URL before you publish, and again whenever ISO revises its codes.
How far a provider should trust a geofeed
At APNIC 62, Anand Raje of the AIORI project described IP geolocation as evidence, not certainty, and Shailesh Gupta called geofeeds a best-effort mechanism. A geofeed is a claim made by the operator. It is usually the best-informed claim available, and it is still unverified.
RFC 9632 offers two checks. The registry reference proves that whoever controls the inetnum chose that URL. An optional RPKI signature, appended to the file as comments, proves that the file itself was produced by the holder of the address space. Not one of the 4,818 usable feeds we fetched carried a signature.
The first check is weaker in practice than on paper. Among feed lines for space managed by the four registries, 40% fall outside every registry object that references the file, and a third of the files have at least one such line. Hetzner’s feed is referenced by five RIPE objects that cover 11 of its 169,849 lines. A consumer applying the RFC to the letter would discard nearly all of the largest geofeed in our sample, which is plainly not what Hetzner or its customers want. If you publish a feed, put the reference on every top-level object you hold.
Each provider decides how much of that checking to apply. At Ipregistry we crawl known feeds daily, validate every line before it is used, and let corrections verified by our team take precedence over geofeeds. Some providers, Ipregistry among them, also match every location in a feed against geocoding data and store the place name that data returns, not the raw text.
Propagation is per provider, and nothing pushes your change to anyone. RFC 8805 asks consumers to refresh at least weekly. After that come each provider’s build cycle and, for customers running a downloaded database, their own update schedule. If the registry record is out of your hands, or you want to speed things up, submit the URL directly:
- BigDataCloud
- DB-IP
- Digital Element (contact form)
- IP2Location (contact form)
- ipdata
- IPinfo
- Ipregistry
- MaxMind
Ipregistry merges geofeeds with registry data, other location sources and verified corrections every day, and each API response returns the resulting location together with the connection type and the announced route, so you can judge how much weight it deserves. You can check your own prefixes with 20,000 free lookups to get started.
Frequently asked questions
What is a geofeed?
A geofeed is a CSV file, defined by RFC 8805, in which a network operator lists its IP prefixes with the country, region and city where each one is used. Geolocation providers fetch the file over HTTPS and use it to correct their databases.
Where do I publish my geofeed URL?
Add it to the registry record that covers your address space. RIPE NCC and APNIC support a geofeed attribute on inetnum and inet6num objects. With ARIN and AFRINIC, add a remark or public comment reading "Geofeed" followed by the HTTPS URL. LACNIC members enter locations in the MiLACNIC portal instead of hosting a file.
How long does a geofeed correction take to show up?
It depends on each provider. Ipregistry crawls known geofeeds daily, so a valid change usually reaches our data within a few days. RFC 8805 only asks consumers to refresh at least weekly, and every provider runs its own schedule, so allow a few weeks before a fix is visible everywhere.
Should a geofeed include postal codes?
No. RFC 8805 marks the postal code field as deprecated because it is too precise for privacy. Leave the fifth field empty and keep the trailing comma. In our September 2026 crawl, 39 percent of feeds still filled it in.
Keep users in the loop Ship release notes that get read. Try Noticeable