Summary

  • A 12 September capture of LACNIC’s public zones directory contained 150 reverse-DNS data filenames arranged as 75 matched naming pairs, plus 150 detached signatures and an adjacent public key.
  • The sampled pair was byte-identical and its published MD5 matched the captured bytes. Those are useful file-level controls; no listed manifest identified the expected members of one complete generation.
  • The gap proves no missing file, invalid signature or DNS failure. It does justify a signed batch receipt for consumers that need to reproduce the directory as a whole.

The useful thing in LACNIC’s download directory is not difficult to see. Beside 002-LACNIC sits a detached OpenPGP signature and an MD5 line. The same pattern repeats across the listing. There is also a public-key file. This is a much better starting point than a pile of anonymous files.

The missing thing is visible only when the unit of analysis changes. An operator fetching one known file can ask whether those bytes match the checksum and, with an accepted key and a working verifier, whether the signature covers them. An operator mirroring the directory needs another answer: which files did LACNIC intend to publish together?

At 15:21 UTC on 12 September, the captured index contained 150 data files. Seventy-five used a three-digit form such as 002-LACNIC; 75 used the corresponding DNS form such as 2.in-addr.arpa-LACNIC. Every three-digit name had a numeric counterpart. The index also exposed 150 .asc entries, 151 .md5 entries and PUBLIC_KEY. The extra checksum entry was the zero-byte wildcard-named *-LACNIC.md5 shown in the listing.

No listed filename contained README, manifest, SHA-256 index or release marker. That is an observation about one timestamped directory view, not a verdict on LACNIC’s internal generation process.

A good file is not a complete batch

The sampled naming pair makes the distinction concrete. 002-LACNIC and 2.in-addr.arpa-LACNIC were both 2,222 bytes and had the same SHA-256 digest. The published MD5 value for the first name matched those bytes. Their HTTP modification times differed by one second.

None of those facts is suspicious. Two names may exist for compatibility. Independent writes may naturally acquire adjacent timestamps. A checksum can catch an accidental transfer error. A detached signature can bind a signer’s key to one external file when the verifier trusts the key and actually performs the check.

But file evidence does not enumerate its neighbours. The signature for 002-LACNIC cannot say whether 45 other files, 149 other files or no other files were meant to be part of the same generation. A web index shows what a server returned at one moment; its HTTP metadata is not the signed release identity.

This is the difference between integrity and completeness. Integrity asks whether an object changed. Provenance asks which key signed it and whether that key is accepted for the purpose. Completeness asks whether every expected object arrived. Atomicity asks whether the objects represent one coherent publication state rather than a mixture seen during an update. The present directory gives material help with the first two questions, file by file. It does not expose a signed answer to the last two.

The strongest case for the existing design

A public file directory does not have to be a transaction log. LACNIC may expect consumers to request a specific reverse-DNS fragment by a known name, not to treat all 150 files as a database snapshot. For that use, independent files are convenient: one can be refreshed or cached without forcing every consumer to download the rest.

The signatures also matter. This article did not validate them because an OpenPGP verifier was unavailable in the research environment, so it makes no claim about their validity or the trust status of the adjacent key. The point is architectural: LACNIC publishes the material needed for a file-level verification workflow. That is a real control worth preserving.

MD5 should be kept in its proper lane. RFC 6151 says it is no longer acceptable where collision resistance is required, while recognizing bounded uses aimed only at protecting against errors. The detached signature, not the MD5 line, is the candidate authentication control. Neither becomes a batch manifest merely by appearing in the same directory.

One small receipt closes the larger question

A manifest need not turn the directory into a heavy platform. One signed file per generation could carry a version, batch identifier, generation and completion times, and the exact ordered filename set. Each row could include the pair identifier, filename role, byte length, SHA-256 digest and signature filename. The manifest should also name the accepted signing-key fingerprint and the preceding batch.

The completion field matters. A consumer that arrives while files are being replaced should be able to distinguish “generation still publishing” from “generation complete”. A later correction should create a new manifest that points to the superseded one rather than silently erasing the history.

This design does not assert that all 75 pairs are always identical. It would state the role of each name and allow any intentional difference to be visible. Nor would it prove that a downloadable file equals the live authoritative DNS state. The captured sample contains NS delegation rows, not a live query transcript. File publication, authoritative loading and resolver observation are different stages.

The directory already answers “what did I receive?” better than many bulk-data surfaces. A signed manifest would add “what was I supposed to receive, together, and when was that set complete?” That is a narrower claim—and the one a whole-directory consumer cannot reconstruct from 150 independent seals.

Sources