Peter Müller via db-wg wrote on 29/06/2020 18:30:
While the RIPE Whois server returned "NL" as the country of that subnet [1], the "delegated-ripencc-extended-latest" file available at ftp.ripe.net [2] only contains 51.15.0.0/16, which points to "FR".
Since the first one result contains the correct country code of that IP network, I would like to ask why "delegated-ripencc-extended-latest" does not include subnets like this, and where the Whois server fetches his answer from.
The entirety of this /16 is assigned to a single organisation (Online.net), which is why there's a /16 in delegated-ripencc-extended-latest. This file contains only supernets and nothing more granular.
Online.net created an inetnum object for 51.15.0.0/17 which sets the country to be NL. This is why the RIPE DB returns NL for that particular block.
Incidentally, IP address allocation queries in the RIPE Database now return the country where the holder of the block is legally resident, not where the IP address is actually used. The situation with 51.15.0.0/17 and 51.15.0.0/16 is only the tip of a gigantic iceberg of quirks and anomalies, not just because you have inconsistent statements about the country, but also because this is legacy (i.e. pre-RIPE) address space and there can be multiple inetnum entries in the ripedb which may be fully inconsistent with each other and where all, some or none of the inetnum records may be an accurate reflection of reality.
I.e. if you're planning to use either the RIPE DB or any other whois db for the ipfire geoip blocking mechanism, you may want to consider putting up very large and obtrusive warnings about how thoroughly inaccurate geoblocking may end up being in practice.
Nick