Een landlabel is zo oud als de database die het gaf

Waar een landlabel eigenlijk vandaan komt¶

Als ik schrijf dat een ontvanger een server in de Verenigde Staten heeft, heb ik daar niets aan gezien. Ik heb een IP-adres opgezocht in een bestand.

Dat bestand is een offline database die IP-blokken aan landen koppelt. Het is een momentopname van wie welk blok gebruikte op de dag dat het bestand werd samengesteld. IP-blokken verhuizen. Ze worden verkocht, opnieuw uitgegeven, doorverhuurd aan een andere hoster in een ander land. Een database die dat bijhoudt, is dus een aflopende zaak vanaf het moment dat hij klaar is.

Daarmee is een landlabel geen waarneming. Het is een opzoeking, en de kwaliteit ervan is precies zo goed als de dag waarop de tabel voor het laatst is bijgewerkt. Zie Label elke bevinding op bewijsniveau.

Wat er misgaat als je dat vergeet¶

Een verouderd landlabel faalt op de vervelendste manier die er is: het geeft een antwoord. Er komt geen foutmelding, geen lege waarde, geen waarschuwing. Er komt een tweeletterige landcode terug die er precies zo uitziet als een goede.

En de fout is niet willekeurig. Ze concentreert zich bij hosters die veel blokken doorverhandelen, dus juist bij de partijen waar advertentietechniek graag zit. De kans dat een verkeerd label uitgerekend op een dragende claim valt, is daarmee groter dan toeval.

Het gevolg is dat een landlabel de zwaarste juridische kwalificatie in een dossier kan dragen zonder de zwaarste onderbouwing te hebben. Doorgifte naar een derde land is hoofdstuk V van de AVG. Dat is de kwalificatie waar een organisatie het hardst op zal duwen bij wederhoor, en dus de laatste plek waar je op een opzoektabel wilt leunen. Zie Waar het pakket landt en wie het kan vorderen zijn twee assen en In Europa gehost is geen vrijwaring.

Het geval: een Iraanse server die in Duitsland stond¶

In juli 2026 draaide mijn scanner met de landendatabase die op de machine stond. Die dateerde van 17 december 2019. Alle 685 landtoewijzingen in de entiteitdossiers waren daarmee berekend op een tabel van ruim zes jaar oud, en elk dossier droeg dezelfde standaardzin: de landtoewijzing is waarschijnlijk en niet vers bevestigd.

Die zin was er niet voor niets. Eerder was er al een vals Iran-label uit die database gekomen, op een server die in werkelijkheid bij Hetzner in Duitsland stond. Iran in een privacydossier over Nederlandse sites is geen detail. Dat is een kop, een Kamervraag en een reputatieprobleem, en het klopte niet.

Wat het extra ongemakkelijk maakt: in de scan van 14 juli 2026 over 1.718 overheidssites staat Iran met drie hosts nog gewoon in de landenverdeling. De verdeling daar loopt van 2.100 hosts in de Verenigde Staten, 713 in België, 391 in Nederland, via 110 in Duitsland en 65 in Ierland, tot een staart met drie in Iran, twee in Denemarken, twee op de Britse Maagdeneilanden en twee in Tsjechië. Diezelfde verdeling zet 41 hosts in Mexico, wat bij een set Nederlandse overheidssites hard om herverificatie vraagt. Zolang die staart op een tabel van 2019 rust, is elk getal erin een aanwijzing en geen bevinding.

De herberekening van 18 juli¶

De fix zelf was klein. De database is vervangen door een verse landentabel van juli 2026, die op dezelfde machine al maandelijks binnenkwam voor een heel ander doel. De oude tabel is bewaard onder een eigen naam, zodat oude uitkomsten reproduceerbaar blijven. De nieuwe is gecontroleerd met twee opzoekingen waarvan het antwoord vaststaat.

Het werk zat in wat erna kwam. Een verse database repareert geen enkel dossier dat al geschreven is. Dus zijn alle 2.152 unieke server-IP's uit de vier dragende runs opnieuw opgezocht, en daarna zijn de dragende adressen nog een keer langs de officiële registratie gehaald.

De uitkomst in drie regels:

endpoints in CN, IL, RU, TR of IR na herberekening      0
kernclaim "geen adversarieel endpoint"                  houdt stand, nu hard
detailclaims die moesten worden gecorrigeerd            2

De nulbevinding werd door de correctie dus sterker in plaats van zwakker. Dat is het patroon dat ik vaker zie: wie zijn eigen instrument nakijkt, verliest zelden de hoofdlijn en wint bijna altijd de houdbaarheid.

Wat de herberekening opleverde¶

De kernvraag was of er endpoints in de landen zaten waar het onderzoek om draaide. Na herberekening op de verse database was dat antwoord nul. Die nulbevinding werd door de controle harder, want hij staat nu op actuele gegevens in plaats van op een database van jaren terug.

Wat ook bleek: een handvol toewijzingen op detailniveau klopte niet meer. Een adres dat als Iraans werd gelabeld, draaide in werkelijkheid bij een Duitse aanbieder. Zulke labels gaan over de herkomst van een enkel adres en niet over de conclusie, maar ze horen wel te kloppen voordat je ze opschrijft.

endpoints in de onderzochte landen na herberekening    0
kernclaim                                              houdt stand
labels op detailniveau die niet meer klopten           2

Dat is de reden dat de landbepaling bij mij een houdbaarheidsdatum heeft en niet een eigenschap is. De database is een momentopname van een wereld die verandert.

Hoe ik het sindsdien vastleg¶

Drie dingen, en ze kosten samen minder tijd dan één correctie achteraf.

Ten eerste staat de datum van de landentabel in elk dossier waarin een landlabel voorkomt. Niet in de methodologiebijlage, maar in het dossier zelf, naast het label.

Ten tweede krijgt elk landlabel dat een claim draagt een tweede bron. De officiële registratie van het IP-blok is daarvoor het geschiktste, omdat die de houder noemt en niet een geschatte locatie.

Ten derde ververst de tabel zichzelf. De verversing draait maandelijks op de achtste, met een controle-opzoeking erachteraan die logt of het resultaat nog klopt. Een handmatige stap die je jezelf voorneemt, is een stap die je een keer overslaat.

En er blijft een open eindje, want dat hoort erbij. De stadstabel op diezelfde machine dateert nog steeds van 2019. Die wordt door de scanner niet gebruikt, en zodra dat verandert is het opnieuw een probleem.

Wat je hiermee doet als je zelf meet¶

Behandel elk landlabel als een claim met een houdbaarheidsdatum. Schrijf de datum van je tabel op voordat je de eerste lookup doet. Markeer landen die in jouw context vreemd zijn als herverificatiepunt in plaats van als vondst. En bewaar de ruwe IP-adressen, want een label kun je herberekenen en een verloren IP-adres niet.

Dat laatste is de reden dat de herberekening van 18 juli überhaupt kon. De adressen stonden vastgelegd. Was alleen het label bewaard, dan had ik voor elke correctie opnieuw moeten meten, en dan was de oude meting niet meer te reproduceren geweest. Zie Hoe mijn scanner werkt, van bezoek tot bewijsstuk en corrigeer nooit stil.

Werkregel. Zet bij elk landlabel de datum van de database die het gaf, bewaar het ruwe IP-adres zodat je kunt herberekenen, en geef geen landlabel een dragende rol in een claim voordat een tweede bron het die dag heeft bevestigd.