Record: block audit and browsable map — 2026-09-11

Outcome

Two things were asked for: a report on inconsistency between the redundant and derived fields of 02_ip_block.json, and browsable maps of what the project has gathered.

Both exist now.

The audit

Every derived field is checked against its source: the end address against start plus size, the prefix against start and size, the UUID against registry+start+size, the assigned flag against the status, the opaque id against the extensions, and each RDAP summary field against the document it was drawn from.

Two defects, both fixed or recorded.

  1. 21 blocks claimed a CIDR they were not. A power-of-two size is not enough; the start address must also be aligned. 13.168.0.0 with 1,048,576 addresses was stored as 13.168.0.0/12, which names 13.160.0.0-13.175.255.255 — a different range. Twenty-one such blocks were repaired to “not a CIDR block”, and the generator now checks alignment.

  2. All 9,200 block UUIDs no longer matched their derivation rule. The namespace string was changed from ip_telescope to IP_telescope on 2026-09-11, after the blocks were written. The data was internally consistent — the probe-to-block file and the characterization referred to the same UUIDs — but re-deriving from today’s code produced a different set, so any join rebuilt today would silently miss.

    Resolved the same day, by the owner’s instruction: the phase 2 files were regenerated, so the UUIDs now match the rule. The regeneration ran in 17 seconds, the RDAP annotations were reapplied from the cache in 4 seconds without asking a registry anything, and the characterization’s block references were remapped (4 block entries, 598 observations, 6 isolation entries; zero stale references). The audit’s namespace note is gone.

After the repair and the regeneration: zero internal contradictions across 9,200 blocks.

The irregularities the audit found (all cross-source, none defects)

Class Blocks What it is
RDAP answered with a parent object 870 The block has no registry object of its own; the answer covers its parent, so the block is inside an allocation rather than being one
The RDAP service is not the delegation registry’s 544 The record is held by one registry while the address space belongs to another: legacy registrations, the classic case being RIPE records for space inside ARIN’s /8s
Delegation country and RDAP country differ 534 The transfer or reassignment the registry has not caught up with
RDAP holds no object at all 27 The registry has nothing for the address
RDAP unanswered 609 AFRINIC was unreachable; the others rate limited the pass
The RDAP object has no name 20 Usually AFRINIC objects, which often carry only a handle

These are the project’s subject matter rather than faults, and the map now shows them per block.

The map

Decision: the registry’s verbatim RDAP answer is not published. It carries registrant contact details — an email address in 6,894 of the documents and a telephone number in 6,576 — so the published pages carry the summary instead, and the verbatim documents stay in the local work product. The map test enforces this, and runs the homelab’s leak-gate pattern over the generated output.

Fields dropped

The owner instructed on 2026-09-11 that the fields below be dropped, and they are gone from the regenerated file: derived.address_end, derived.prefix, derived.opaque_id (the whole derived object), and rdap.query. Readers compute the range and the prefix from the record with the helpers block_address_end and block_prefix_text in ip_block_collect.py.

The reasoning behind each, kept for the record:

Verification

Also in this pass

Commits