{"id":18767,"date":"2026-05-25T21:16:55","date_gmt":"2026-05-25T21:16:55","guid":{"rendered":"https:\/\/made4it.com.br\/blog\/how-to-configure-geofeed-on-registro-br\/"},"modified":"2026-06-29T19:45:31","modified_gmt":"2026-06-29T19:45:31","slug":"how-to-configure-geofeed-on-registro-br","status":"publish","type":"post","link":"https:\/\/made4it.com.br\/en\/blog\/how-to-configure-geofeed-on-registro-br\/","title":{"rendered":"How to Configure Geofeed on Registro.br"},"content":{"rendered":"\n

In the previous article, we discussed Geofeed, RFC 8805, RFC 9632, RDAP, and why this matters to service providers.<\/p>\n\n

Now let’s move on to the practical part.<\/p>\n\n

The idea here is to set up a simple example of a geofeed publication using Registro.br, with a CSV file published over HTTPS and validation via WHOIS and RDAP.<\/p>\n\n

To avoid using any actual blocks, the examples below use blocks reserved for testing and documentation. In production, of course, you should replace them with the actual ASN blocks. <\/p>\n\n

Example Scenario<\/h2>\n\n

Let’s imagine that the provider has an IPv4 block \/22<\/code> and uses each \/24<\/code> in a different city.<\/p>\n\n

For the IPv4 example, let’s use:<\/p>\n\n

198.18.0.0\/22<\/code><\/pre>\n\n
This block is part of a space reserved for testing and benchmarking. It should not be used in production on the Internet. Here, it serves only to make the example look like a real-world operation, without exposing the prefix.  <\/p>\n\n
<\/a>  The operational breakdown would be:<\/p>\n\n
198.18.0.0\/24      Apucarana - PR\n198.18.1.0\/24      Londrina - PR\n198.18.2.0\/24      Sao Paulo - SP\n198.18.3.0\/24      Porto Alegre - RS<\/code><\/pre>\n\n
For IPv6, we’ll use the documentation block:<\/p>\n\n
2001:db8::\/32<\/code><\/pre>\n\n
And break it down into \/40<\/code>:<\/p>\n\n
2001:db8:0000::\/40   Apucarana - PR\n2001:db8:0100::\/40   Londrina - PR\n2001:db8:0200::\/40   Sao Paulo - SP\n2001:db8:0300::\/40   Porto Alegre - RS<\/code><\/pre>\n\n
This approach is closer to the real world: a larger registered block, with divisions by city or region within it.<\/p>\n\n
One file per block<\/h2>\n\n
For now, Registro.br maintains a more restrictive policy regarding the publication of geofeeds.<\/p>\n\n
In practice, the safest approach is to work with one file per registered block<\/strong>, containing only that block or its subblocks.<\/p>\n\n
<\/a>  So, if the registered block is:<\/p>\n\n
198.18.0.0\/22<\/code><\/pre>\n\n
It makes sense to have a single file for this \/22<\/code>, containing the internal \/24<\/code>:<\/p>\n\n
geofeeds_198.18.0.0_22.csv<\/code><\/pre>\n\n
Contents:<\/p>\n\n
198.18.0.0\/24,BR,BR-PR,Apucarana,\n198.18.1.0\/24,BR,BR-PR,Londrina,\n198.18.2.0\/24,BR,BR-SP,Sao Paulo,\n198.18.3.0\/24,BR,BR-RS,Porto Alegre,<\/code><\/pre>\n\n
Note the key point: all the lines are inside the ` 198.18.0.0\/22<\/code>` block.<\/p>\n\n
This is different from combining independent blocks into the same file.<\/p>\n\n
<\/a>  For example, if you had two different blocks registered with Registro.br, such as:<\/p>\n\n
198.18.0.0\/22\n198.18.8.0\/22<\/code><\/pre>\n\n
It wouldn’t be a good idea to put everything in the same CSV file right now. The safest approach would be to create a separate file for each block. <\/p>\n\n
IPv6 Archive<\/h2>\n\n
<\/a>  For IPv6, following the same logic, the registered block would be:<\/p>\n\n
2001:db8::\/32<\/code><\/pre>\n\n
The file could be named:<\/p>\n\n
geofeeds_2001-db8_32.csv<\/code><\/pre>\n\n
Contents:<\/p>\n\n
2001:db8:0000::\/40,BR,BR-PR,Apucarana,\n2001:db8:0100::\/40,BR,BR-PR,Londrina,\n2001:db8:0200::\/40,BR,BR-SP,Sao Paulo,\n2001:db8:0300::\/40,BR,BR-RS,Porto Alegre,<\/code><\/pre>\n\n
The same rule applies here as well: the \/40<\/code> are located within \/32<\/code>.<\/p>\n\n
With a real provider, the granularity may vary. You can use \/40<\/code>, \/44<\/code>, \/48<\/code>, or another size, depending on how IPv6 was designed. The important thing is that the geofeed represents the operation consistently and does not attempt to be more precise than the network actually allows.  <\/p>\n\n
Correct CSV Format<\/h2>\n\n
<\/a>  RFC 8805 defines the base format of the geofeed [1]:<\/p>\n\n
ip_prefix,alpha2code,region,city,postal_code<\/code><\/pre>\n\n
But in a published file, you usually don’t include a header.<\/p>\n\n
<\/a>  So don’t do it this way:<\/p>\n\n
ip_prefix,alpha2code,region,city,postal_code\n198.18.0.0\/24,BR,BR-PR,Apucarana,<\/code><\/pre>\n\n
Here’s how to do it:<\/p>\n\n
198.18.0.0\/24,BR,BR-PR,Apucarana,<\/code><\/pre>\n\n
Some important details:<\/p>\n\n
The file must be in UTF-8.<\/p>\n\n
The prefix must be in CIDR format.<\/p>\n\n
The country of Brazil is BR<\/code>.<\/p>\n\n
The state must comply with ISO 3166-2. Paran\u00e1 is BR-PR<\/code>, S\u00e3o Paulo is BR-SP<\/code>, and Rio Grande do Sul is BR-RS<\/code>. <\/p>\n\n
The city name should not contain a comma.<\/p>\n\n
The ZIP code field should be left blank, but the final comma should remain.<\/p>\n\n
Where to find state codes<\/h2>\n\n
For the region field, use ISO 3166-2.<\/p>\n\n
<\/a>  Some examples:<\/p>\n\n
BR-PR  Paran\u00e1\nBR-SP  S\u00e3o Paulo\nBR-RS  Rio Grande do Sul\nBR-SC  Santa Catarina\nBR-MG  Minas Gerais\nBR-RJ  Rio de Janeiro\nBR-DF  Distrito Federal<\/code><\/pre>\n\n
The official source is the ISO Online Browsing Platform [4].<\/p>\n\n
For quick reference, the ISO 3166-2:BR page also lists the codes for Brazilian states [5].<\/p>\n\n
Publishing the file<\/h2>\n\n
You can publish the CSV on the provider’s website, on a web server, in a public bucket, or using GitHub Pages.<\/p>\n\n
The main point is that the URL needs to download the file directly.<\/p>\n\n
Example for IPv4:<\/p>\n\n
https://geo.seuprovedor.com.br\/geofeeds_198.18.0.0_22.csv<\/code><\/pre>\n\n
Example for IPv6:<\/p>\n\n
https://geo.seuprovedor.com.br\/geofeeds_2001-db8_32.csv<\/code><\/pre>\n\n
Or, using GitHub Pages:<\/p>\n\n
https://usuario.github.io\/geofeeds\/geofeeds_198.18.0.0_22.csv\nhttps:\/\/usuario.github.io\/geofeeds\/geofeeds_2001-db8_32.csv<\/code><\/pre>\n\n
Be careful with links like these:<\/p>\n\n
https://github.com\/usuario\/geofeeds\/blob\/main\/geofeeds_198.18.0.0_22.csv<\/code><\/pre>\n\n
For Registro.br, the URL must serve the CSV file directly.<\/p>\n\n
Example using GitHub Pages<\/h2>\n\n
A simple option for labs or small providers is to use GitHub Pages.<\/p>\n\n
The flow is:<\/p>\n\n
    \n
  1. create a GitHub account;<\/li>\n\n\n\n
  2. create a repository named geofeeds<\/code>;<\/li>\n\n\n\n
  3. Create the file ` geofeeds_198.18.0.0_22.csv<\/code>`;<\/li>\n\n\n\n
  4. put the CSV content into it;<\/li>\n\n\n\n
  5. enable GitHub Pages in the repository;<\/li>\n\n\n\n
  6. Access the generated public URL.<\/li>\n<\/ol>\n\n
    <\/a>  The IPv4 file would look like this:<\/p>\n\n
    198.18.0.0\/24,BR,BR-PR,Apucarana,\n198.18.1.0\/24,BR,BR-PR,Londrina,\n198.18.2.0\/24,BR,BR-SP,Sao Paulo,\n198.18.3.0\/24,BR,BR-RS,Porto Alegre,<\/code><\/pre>\n\n
    The final URL could look like this:<\/p>\n\n
    https://usuario.github.io\/geofeeds\/geofeeds_198.18.0.0_22.csv<\/code><\/pre>\n\n
    If, when you open this URL, the browser downloads or displays only the CSV content, you’re on the right track.<\/p>\n\n
    If you open a GitHub page with a layout, buttons, a menu, and a preview, that’s wrong.<\/p>\n\n
    Content-Type<\/h2>\n\n
    Registro.br can validate the type of content published.<\/p>\n\n
    Ideally, the server should respond with:<\/a><\/p>\n\n
    Content-Type: text\/csv<\/code><\/pre>\n\n
    or:<\/p>\n\n
    Content-Type: application\/geofeed+csv<\/code><\/pre>\n\n
    RFC 9877 defines the ” application\/geofeed+csv<\/code> ” type for geofeed files [3].<\/p>\n\n
    <\/a>  To validate:<\/p>\n\n
    curl -I https:\/\/usuario.github.io\/geofeeds\/geofeeds_198.18.0.0_22.csv<\/code><\/pre>\n\n
    Example of an expected answer:<\/p>\n\n
    HTTP\/2 200\ncontent-type: text\/csv<\/code><\/pre>\n\n
    or:<\/p>\n\n
    HTTP\/2 200\ncontent-type: application\/geofeed+csv<\/code><\/pre>\n\n
    Validating the syntax<\/h2>\n\n
    Before registering with Registro.br, it’s a good idea to run the file through a validator.<\/p>\n\n
    <\/a>  A practical option is:<\/p>\n\n
    https://opengeofeed.org\/validator<\/code><\/pre>\n\n
    It helps catch silly mistakes, such as:<\/p>\n\n