Summary

  • ARIN’s statistics root listed the correct delegated-arin-extended-20260829 data and checksum files, but also exposed current-period artifacts at delegated-arin-extended-20231018 and delegated-arin-extended-20231008.md5.
  • The extra data path carried a header whose enddate was 20260829. The extra checksum path was byte-identical to the correct checksum manifest and named delegated-arin-extended-20260829 as its target.
  • Five sampled ranges matched between the correct 2026 data path and the extra 2023 data path. That supports a duplicate-artifact reading, but it is not a full-file identity proof and says nothing about the correctness of individual resource records.
  • ARIN’s own exchange format requires the dated filename, internal header and matching detached checksum to work together. A release monitor should validate that identity tuple before publication and preserve any correction.

The directory told three different dates

The first clue was not inside an address record. It sat in ARIN’s public statistics directory.

The ordinary 29 August release was present under the expected names: delegated-arin-extended-20260829 and delegated-arin-extended-20260829.md5. The persistent latest data and checksum paths were there too. Those are the paths an automated consumer would normally expect to find.

Two extra entries appeared near the top of the same directory. One was a 12,774,921-byte data object called delegated-arin-extended-20231018. The other was a 67-byte checksum object called delegated-arin-extended-20231008.md5. Both carried 29 August 2026 modification times in the directory listing.

That is already a broken pair. A data file dated 18 October 2023 would ordinarily be paired with a checksum carrying the same date plus .md5. Here the apparent companion used 8 October instead. More importantly, neither object described a 2023 release when opened.

The version line captured from the extra data path was:

2.3|arin|1788008421241|202440|19700101|20260829|-0400

The same line appeared at the head of the correctly named 20260829 object. Under ARIN’s published RIR Statistics Exchange Format, the fields are version, registry, serial, record count, start date, end date and UTC offset. The internal period therefore ended on 29 August 2026. The path said 2023; the header said 2026.

The checksum did not validate the path that served it

The extra checksum object is even clearer because the whole 67-byte file was captured. It contained the same line as the correctly named 20260829 checksum file:

6e57e7c85222c5ff9c1549d1ff8ea52c delegated-arin-extended-20260829

The manifest did not name delegated-arin-extended-20231008. It did not name the extra data path ending in 20231018. It named the correct current-period file.

That distinction matters to ordinary checksum tooling. A detached checksum file is not merely a digest written in isolation; it usually contains the target filename. Running a conventional verification command against the extra manifest would direct the tool to the correctly named 20260829 object. A successful result would establish that the bytes at that declared target matched ARIN’s published MD5 value. It would not prove that the URL used to fetch the manifest had the correct name.

ARIN’s format specification already separates these controls. It says the data file is named delegated-<registry>-yyyymmdd, with the date representing the local day on which the file was produced. It says the MD5 checksum is published under a matching name with .md5 appended. Its validation section expressly calls for checking the filename against the contents as well as using the detached checksum.

The observed extra paths fail that combined test. The bytes may be perfectly good current bytes. The artifact identity is still inconsistent.

What the samples establish—and what they do not

The correct 20260829 data path and the extra 20231018 path each advertised a length of 12,774,921 bytes. Five 65,536-byte ranges were captured from each object: the opening range and ranges beginning at offsets 1,048,576, 4,194,304, 8,388,608 and 12,000,000. Every paired range produced the same SHA-256 value.

This is useful corroboration. The matches span the beginning, middle and later portion of the objects, and the first range includes the identical 20260829 header. Together with equal lengths and the contemporaneous listing, the evidence strongly supports the view that a current data artifact was exposed through the old-looking path.

It is still sampling. A full byte-for-byte identity claim would require a complete strong digest of both 12.7 MB responses. The public finding does not need that stronger claim. The path/header mismatch is visible in the first line, and the checksum manifest’s target is visible in its complete 67 bytes.

The same discipline applies to the data’s substance. The evidence does not show that one ASN, IPv4 range or IPv6 prefix is wrong. It does not show a transfer error, a route leak, an invalid ROA, a changed holder or a damaged serial. The correctly named current pair remained available. No consumer impact has been identified.

This is a publication-identity fault, not a resource-integrity verdict.

Machines treat filenames as data

It is tempting to dismiss the extra objects as harmless directory debris. That may be the right operational conclusion. Yet dated registry files are designed for automation, and automation often treats the path itself as a field.

A collection job may construct yesterday’s URL from a calendar, download the corresponding .md5, verify it and index the result under that date. A mirror may retain everything it sees in the root. A researcher may use the filename as the edition key without parsing the internal header. A cache may preserve a path long after the publisher cleans it up.

In the observed case, those shortcuts can disagree. A consumer asking for the apparent 18 October 2023 data path receives a header ending in August 2026. A consumer asking for the apparent 8 October 2023 checksum path receives a manifest that points to the August 2026 filename. If the verifier follows the manifest target, the check can pass while the surrounding catalogue still associates the retrieval with 2023.

There is no evidence that any consumer did this. The point is that the public interface admits the ambiguity. File integrity and catalogue identity are different properties.

That difference is familiar in software supply chains. A content digest can identify a blob, but a version tag tells a consumer where the blob belongs. A correct blob under the wrong tag can be more dangerous to reproducibility than a failed digest, because the verification looks reassuring. Registry statistics deserve the same modest discipline, precisely because they are routinely mirrored, counted and compared over time.

The strongest benign reading

The evidence supports a calm explanation. The correct 20260829 pair was present. The latest paths were present. The two extra objects may be aliases, temporary publishing residue or an accidental copy whose contents still point clearly to the current release. Five data samples agreed, and the checksum manifests were identical.

Nothing suggests an intrusion or an attempt to rewrite resource history. The public 2023 archive separately lists compressed historical entries. This review does not audit those objects and does not claim that an old file was destroyed or replaced.

ARIN also has historical precedent for correcting the publication layer. Its 2013 extended-statistics advisory says affected files were removed after technical issues and correct publication resumed. That older episode involved corrupted and incomplete data; the present evidence does not. The relevant precedent is only procedural: a public statistics surface can be repaired without converting a file problem into a claim about registry authority or network operation.

The proportionate action today would be smaller. ARIN can remove the unintended paths, or declare them intentional aliases if they are deliberate. It can retain an internal receipt of what changed and publish a short correction if caches or mirrors may have copied them. The correct current release does not need to be withdrawn merely because extra names appeared.

One identity tuple for each release

The format already supplies most of the necessary fields. A publication gate should turn them into one machine-tested identity tuple before a release or alias becomes public.

The tuple begins with the canonical path and any intentional aliases. It adds the parsed registry, serial, record count, start date, end date and UTC offset from the header. It records byte length and a modern strong digest of the data object. It then parses the detached checksum or signature artifact, records its algorithm and target filename, and verifies that target against the canonical path.

Three equality tests should be routine:

  1. the date in the canonical path equals the header’s end date;
  2. the checksum path is the canonical data path plus the expected suffix;
  3. the target written inside the checksum manifest equals the canonical data filename.

An intentional alias can be allowed, but it should be declared as an alias to a canonical receipt rather than masquerading as another dated edition. An unexplained mismatch should be quarantined before it reaches the public directory. If one escapes, the correction should preserve the previous receipt hash, the time, a reason category and the new state.

This control remains deliberately thin. ARIN decides how to generate and host its files. Consumers decide how to analyse them. The common requirement is that a public recordkeeper make the identity of its own publication unambiguous.

The 29 August bytes may be sound. The checksum may be sound. The two 2023 paths were still wrong for what they served. A registry file is not identified by its digest alone. Its path, header and verification target must tell the same date.

Sources