Re: [db-wg] Question regarding delta between "delegated-ripencc-extended-latest" and Whois output

[Nick Hilliard <nick@foobar.org>]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

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