Correggere la geolocalizzazione IPv4 dopo un trasferimento
Risposta rapida: dopo un trasferimento, la geolocalizzazione IPv4 può continuare a mostrare il paese sbagliato (quello precedente), perché la registrazione nel registro, l'annuncio BGP e ogni database GeoIP commerciale sono sistemi separati. Modificare il registro non riscrive i database. Quello che funziona è pubblicare un proprio file di posizione (un geofeed secondo l'RFC 8805), farvi riferimento dal proprio oggetto del RIPE Database e inviare una correzione a ogni fornitore, conservando gli ID dei ticket. Nessun fornitore garantisce una data. Verificato il 2026-10-14. I passaggi lato registro sono nella nostra guida al trasferimento RIPE NCC; questo articolo parte quando il blocco è già vostro.
Quattro registrazioni, quattro domande diverse
| Registrazione | Risponde a | Chi la imposta | Cosa può influenzare |
|---|---|---|---|
| Record RIR (WHOIS) | Chi detiene il blocco | Il titolare, nel registro | L'identità del titolare. country: non è una posizione |
| Origin BGP e ROA | Chi lo annuncia e se è autorizzato | Voi, sui vostri router e in RPKI | Raggiungibilità e validità della rotta, non il paese |
| Geofeed (RFC 8805) | Dove l'operatore dichiara di usare ogni prefisso | Voi, in un file che ospitate | Un suggerimento per i fornitori che lo leggono |
| Database GeoIP commerciale | Dove il fornitore ritiene che sia l'indirizzo | Il fornitore, dalle sue fonti | Ciò che vedono siti e app |
Il quinto elemento, dove sono davvero i vostri server, è ciò che gli altri quattro cercano di modellare. La documentazione del RIPE Database dice che non è mai stato specificato che cosa rappresenti country:, quindi non può essere usato in modo affidabile per associare indirizzi IP a paesi, e il RIPE NCC dichiara di non essere un fornitore di geolocalizzazione. Un blocco può essere registrato a un'azienda di un paese e operare in un altro, ed entrambe le registrazioni sono corrette.
Diagnosi con un elenco e uno script
| Verifica | Comando | Influisce su |
|---|---|---|
| CIDR e record nel registro | whois -h whois.ripe.net -r -T inetnum 192.0.2.0/24 |
Titolare, country:, la riga geofeed: |
| File geofeed | curl -s <URL da geofeed:> |
Il suggerimento di posizione per i fornitori che lo leggono |
| AS di origine e ROA | RIPEstat prefix-overview, rpki-validation |
Instradamento e validità della rotta, non il paese |
| Dati dei fornitori | La pagina pubblica di ricerca del fornitore | Il paese che vedono utenti e partner |
| DNS inverso | dig -x 192.0.2.1 |
Controlli di posta e leggibilità dei log; nessuna fonte verificata lo usa per il paese |
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 e 2001:db8::/32 sono prefissi di documentazione: usateli solo per la sintassi, perché non sono annunciati e la query al RIPE restituisce per essi il blocco padre non RIPE. Per l'output reale usiamo il prefisso proprio di DCXV e AS204057 (eseguito il 2026-10-14; Linux, whois 5.6, jq 1.8; su un sistema senza file services aggiungete -p 43 a whois):
$ whois -h whois.ripe.net -r -T inetnum 178.23.189.0/24 | grep -E '^(inetnum|netname|country|geofeed)'
inetnum: 178.23.189.0 - 178.23.189.255
netname: CY-DCXV-20210903
country: CY
geofeed: https://dcxv.com/geofeed.csv
$ curl -s 'https://stat.ripe.net/data/prefix-overview/data.json?resource=178.23.189.0/24' | jq -c '.data.asns'
[{"asn":204057,"holder":"DCXV-AS DCXV INTERNATIONAL LTD"}]
$ curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=204057&prefix=178.23.189.0/24' | jq -r '.data.status'
valid
Il registro dice CY perché il titolare è un'azienda cipriota, mentre i server sono altrove. AS di origine e ROA sono validi ed è presente un attributo geofeed:. Questa combinazione è normale ed è il motivo per cui un fornitore può mostrare un paese che il registro non indica. DCXV pubblica qui i dati della propria rete. Se detenete un blocco con questo problema, potete inviarci una richiesta sul trasferimento IPv4.
Lo script qui sotto (Python 3.8+, solo libreria standard, testato su 3.14, solo risorse della regione RIPE) stampa l'oggetto del registro, l'AS di origine, lo stato RPKI e la riga di geofeed più specifica per un prefisso, tramite il RIPE Database e RIPEstat. Lo abbiamo eseguito su prefissi DCXV, prefissi di documentazione e casi di errore; la corrispondenza con il feed è stata verificata anche offline su un file di esempio.
#!/usr/bin/env python3
"""geocheck.py PREFIX - registry country, origin ASN, RPKI status and geofeed line for a prefix.
Python 3.8+, standard library only. Data: RIPE Database REST API and RIPEstat (RIPE region only)."""
import csv, io, ipaddress, json, sys, time, urllib.error, urllib.parse, urllib.request
def get(url):
req = urllib.request.Request(url, headers={'Accept': 'application/json', 'User-Agent': 'geocheck/1.0'})
for attempt in range(4):
try:
with urllib.request.urlopen(req, timeout=20) as r:
return r.read(5_000_000).decode('utf-8-sig', 'replace') # cap the read at 5 MB
except OSError as e: # includes HTTP 429 and connection resets
if isinstance(e, urllib.error.HTTPError) and 400 <= e.code < 500 and e.code != 429:
sys.exit('request refused for %s: %s' % (url, e)) # retrying a 4xx will not help
if attempt == 3:
sys.exit('network error for %s: %s' % (url, e))
time.sleep(2 ** attempt)
def stat(call, **q):
return json.loads(get('https://stat.ripe.net/data/%s/data.json?%s' % (call, urllib.parse.urlencode(q))))['data']
def registry(net):
# best match: the most specific inetnum / inet6num that covers the prefix
t = 'inet6num' if net.version == 6 else 'inetnum'
q = urllib.parse.urlencode([('query-string', str(net)), ('source', 'ripe'), ('type-filter', t),
('flags', 'no-referenced'), ('flags', 'no-irt')])
try:
obj = json.loads(get('https://rest.db.ripe.net/search.json?' + q))['objects']['object'][0]
except (ValueError, KeyError, IndexError):
return None
return {a['name']: a['value'] for a in obj['attributes']['attribute']}
def feed_match(url, net):
# most specific feed entry that covers the prefix; RFC 8805 columns: prefix,country,region,city
best = None
for row in csv.reader(io.StringIO(get(url))):
if not row or row[0].lstrip().startswith('#'):
continue
try:
p = ipaddress.ip_network(row[0].strip(), strict=False)
except ValueError:
continue
if p.version == net.version and net.subnet_of(p) and (best is None or p.prefixlen > best[0].prefixlen):
best = (p, row)
return best[1] if best else None
def main(arg):
try:
net = ipaddress.ip_network(arg, strict=False)
except ValueError:
sys.exit('usage: geocheck.py PREFIX (for example 192.0.2.0/24)')
if net.prefixlen == net.max_prefixlen:
sys.exit('give the prefix, not a single address: a /32 or /128 gives a misleading RPKI result')
if net.prefixlen == 0:
sys.exit('give a real prefix, not the default route')
print('prefix ', net)
reg = registry(net)
top = reg and ((reg.get('netname') or '').startswith('NON-RIPE-NCC-MANAGED')
or (reg.get('inetnum') or '').startswith('0.0.0.0 -') or reg.get('inet6num') == '::/0')
if not reg or top:
print('registry object outside the RIPE NCC: query that RIR instead')
else:
print('registry object ', reg.get('inetnum') or reg.get('inet6num'), '| netname', reg.get('netname'), '| status', reg.get('status'))
print('registry country ', reg.get('country'), '(country: is not a location)')
ov = stat('prefix-overview', resource=str(net))
asns = [str(a['asn']) for a in ov.get('asns', [])]
print('origin ASN ', ', '.join('AS' + a for a in asns) or 'not announced (no origin in RIPEstat)')
for a in asns:
print('RPKI AS%-9s' % a, stat('rpki-validation', resource=a, prefix=str(net))['status'])
url = None if top else (reg or {}).get('geofeed')
if not url:
print('geofeed none (no geofeed: attribute on the best-match object)')
return
print('geofeed URL ', url)
if not url.startswith('https://'):
sys.exit('geofeed URL is not https://, not fetched')
row = feed_match(url, net)
print('geofeed line ', ','.join(row[:4]) if row else 'NO entry covers this prefix')
if __name__ == '__main__':
if len(sys.argv) != 2:
sys.exit('usage: geocheck.py PREFIX')
main(sys.argv[1])
Quello che volete vedere è valid e una riga del feed per il vostro prefisso. "NO entry covers this prefix" significa che i fornitori che leggono il vostro feed salteranno il blocco.
Dove inviare le correzioni
Usate il canale attuale di ogni fornitore; correggerne uno non corregge gli altri. Documentazione verificata il 2026-10-14.
| Fornitore | Canale | Cosa dice la documentazione |
|---|---|---|
| MaxMind | Moduli una tantum; GeoIP Exchange per gli operatori | Accetta geofeed RFC 8805 e RFC 9632, rivisti una volta per giorno lavorativo; nessuna data di rilascio |
| IPinfo | Pagina delle correzioni; geofeed | Post nella community (2026-02-05): prima la misurazione, geofeed in modo selettivo |
| DB-IP | Link di segnalazione nel risultato; in blocco tramite il modulo di contatto | Una modifica al WHOIS del RIR di solito avvia l'aggiornamento; un geofeed è un'altra via |
| IP2Location | Contatto e rapporto sull'accuratezza dei dati | Date di rilascio per licenza; nessuna procedura pubblica di correzione né di geofeed |
| Modulo di segnalazione IP nella Guida di Search | Gli aggiornamenti possono richiedere più di un mese ("may take more than a month"); nessun riscontro individuale |
Pubblicare un geofeed e collegarlo
Un geofeed è un file CSV definito dall'RFC 8805: ip_prefix,alpha2code,region,city. I prefissi annidati sono ammessi e prevale il più specifico. L'RFC chiede UTF-8 e interruzioni di riga CRLF, dichiara obsoleto il codice postale (omettetelo) e consente ai consumatori di trattare i dati solo come suggerimento. Un file minimo con prefissi di documentazione:
# prefix,country,region,city
192.0.2.0/24,CZ,CZ-10,Prague
2001:db8::/32,CZ,CZ-10,Prague
Ospitatelo su HTTPS e aggiungete una riga geofeed: https://example.net/geofeed.csv al vostro inetnum o inet6num; l'attributo è opzionale e singolo. L'RFC 9632 indica ai consumatori di usare l'oggetto più specifico che ha un geofeed e poi di ignorare altri indizi come country:. Definisce anche una firma RPKI opzionale per il file; non abbiamo verificato quali fornitori la controllino. Dopo un trasferimento leggete l'oggetto: una riga geofeed: lasciata dal venditore punta a un file che non controllate.
Un piano per il nuovo titolare
- Raccogliete le prove. Il record che vi indica come titolare, l'elenco dei CIDR e la prova di dove girano i server.
- Sistemate la vostra parte. Correggete la riga
geofeed:, pubblicate il file, eseguite lo script. - Inviate a ogni fornitore. Una richiesta ciascuno, con l'URL del feed. Indicate solo la posizione reale: i fornitori possono confrontarla con le proprie misurazioni.
- Tenete un registro. ID del ticket, data, fornitore, prefisso, risposta.
- Ricontrollate più tardi. Nessuno promette una data, quindi non pianificate un lancio su di essa.
Sintomo, causa, verifica, azione
| Sintomo | Causa possibile | Verificare | Azione |
|---|---|---|---|
| Diversi fornitori mostrano il paese precedente | Nessun geofeed, o non ancora letto | Lo script: riga geofeed: e voce corrispondente? |
Pubblicare il feed, poi una correzione per fornitore |
| Un fornitore segue il registro, non il vostro feed | Quel fornitore non usa i feed | La sua documentazione e una ricerca | Inviare una correzione con l'URL del feed |
| Il feed è attivo e restano i vecchi dati | Ritardo di rilascio, errore di download o misurazione discordante | HTTPS raggiungibile, prefisso coperto, nessuna riga annidata in conflitto | Chiedere al fornitore, conservare il ticket, ricontrollare più tardi |
| Sbaglia solo una CDN, banca o servizio di pagamento | Usa dati propri: Cloudflare, ad esempio, aggiorna il database più volte a settimana e non può garantire la coincidenza con altri fornitori; i motori di rischio possono pesare altri segnali | Chiedere quale fonte usa | Correggere quella fonte, poi segnalare al servizio |
| Paese giusto, città sbagliata | Il feed non ha la città o la misurazione differisce | La colonna city del feed | Aggiungere regione e città, poi richiedere di nuovo |
Stimare il rischio prima di comprare
Blacklist e abusi sono nella checklist di due diligence; qui solo la geolocalizzazione. Interrogate il prefisso presso alcuni fornitori ora, leggete il suo inetnum (country: e ogni URL geofeed:) e chiedete chi controlla quel file. Concordate nel contratto che il venditore consegni o rimuova il riferimento al feed alla chiusura.
Prossimo passo
Non sapete dove sia il problema? Inviateci una richiesta sul trasferimento IPv4 oppure scrivete a ipv4@dcxv.com con il prefisso e il sintomo. Non promettiamo quando un fornitore si aggiornerà.
