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
