Кратко

  • Стандартные файлы статистики делегирования AFRINIC с датами 10, 11 и 12 сентября 2026 года полностью совпадают. Внутренний номер и конец периода во всех случаях — 20260910. Расширенные файлы повторяют эту картину.
  • Совпадение не доказывает сбой или отсутствие новых событий в реестре. Краткая запись о выпуске могла бы отделить новую проверку без изменений от повторной выдачи старого результата, не раскрывая документы участников.

Три календарные даты могут обозначать один набор данных. В публичном архиве AFRINIC это не предположение, а результат сравнения: при сборе 14 сентября по календарю Asia/Shanghai стандартные файлы с именами за 10, 11 и 12 сентября содержали по 491 382 байта. Их общий SHA-256 — 54b0cfb6c962fe41815728ef9bff5950cece5fcdd7ab17b94cc3875e68378e07.

В каждой первой строке внутренний номер равен 20260910, заявлено 9 947 записей, а период заканчивается 10 сентября. Это доказывает тождество полученного содержимого. Почему оно появилось под более поздними именами, сравнение не устанавливает. В этом и состоит пробел публичной поверхности выпуска.

У дат разные обязанности

Опубликованный в каталоге AFRINIC RIR Statistics Exchange Format предусматривает ежедневное создание файлов. Дата в имени delegated-<registry>-yyyymmdd определяется как местный день производства файла. Поле serial отдельно обозначает номер файла в последовательности создающего RIR. Конец периода — ещё одно поле. При обновлении имя latest должно указывать на самый новый файл.

Время изменения на веб-сервере не заменяет эти определения. Каталог за 2026 год показывает для имени 10 сентября изменение 11 сентября, для имени 11 — 12-го, для имени 12 — 13-го. HTTP-ответы также содержат разные метаданные изменения. Они описывают выдаваемые объекты, но не удостоверяют запуск генератора или границу состояния источника, которую он проверил.

В корневом каталоге есть имя delegated-afrinic-20260913, которому сопоставлено изменение 10 сентября. Его содержимое совпадает с тремя архивными файлами и текущим стандартным псевдонимом. Более позднее имя, более позднее серверное время и более новая внутренняя версия в этой выборке не следуют друг за другом.

Проверка байтов не объясняет выпуск

Результат касается не только заголовка. Расширенные файлы за 10, 11 и 12 сентября и их текущий псевдоним имеют по 992 722 байта и SHA-256 66f1d06b8f272cbb3f2da3260b73a63cb7b1cd132ad770851dc2e2864ac9eb75. Номер и конец периода остаются 20260910, заявленное количество записей — 19 651. Расширенный формат добавляет состояния ресурсов и сведения о держателях, но не описание этого события публикации.

Три сопутствующих файла MD5 тоже совпадают. Независимый расчёт стандартного содержимого подтверждает опубликованное значение 568a689f01216f94af0b174514fd3903. Три объекта отделённой подписи OpenPGP также побайтно одинаковы. Локальная проверка этих подписей здесь не заявляется.

Совпадение контрольной суммы полезно: оно ограничивает вопрос о повреждении при передаче относительно опубликованного значения. Но даже математически проверенная подпись связала бы байты с ключом, а не с новой ежедневной проверкой. Подлинность содержимого не равнозначна свежести наблюдения.

Для контроля есть стандартный файл за 9 сентября. Размер и заявленное число записей такие же, но хеш другой, а внутренний номер относится к 9 сентября. Стабильный итог не доказывает стабильность строк. Полное совпадение байтов доказывает одинаковость полученного содержимого — и только её.

«Без изменений» тоже должно иметь дату проверки

У реестра может не быть новых сведений за день. Он может сознательно повторно выпустить проверенный результат. Само по себе повторение не подозрительно. Для потребителя важна другая граница: источник проверен до нового момента и изменений не найдено, либо прежняя выдача просто предоставлена снова.

В публичных файлах нет идентификатора запуска, границы источника, класса повторного выпуска или состояния ожидаемой корректировки. Они не позволяют отличить эти ситуации от остановившегося генератора или задержанного источника. Объявить сбой было бы таким же выходом за пределы доказательств, как признать новое имя свидетельством свежей проверки.

Сборщики могут ошибиться в обе стороны. Если единственный ключ — URL, три пути превращаются в три якобы независимых ежедневных наблюдения одного набора. Если ключ — только внутренний номер, удаление дублей может стереть историю более поздних публикаций. Версия данных и событие выдачи должны храниться отдельно.

Потребитель уже может сохранить запрошенный URL, время получения, метаданные ответа, номер, конец периода и хеш. AFRINIC мог бы добавить запись о выпуске с идентификатором, временем публикации, фактически проверенной границей источника, результатом проверки и общим основанием для неизменного содержимого. Заявления участников и закрытые обращения поддержки для этого не нужны.

Пределы доказательств и источники

Материал сравнивает зафиксированные публичные файлы, а не внутренние журналы. Он доказывает совпадение загруженных объектов и описывает норму и серверные метаданные. Он не доказывает пропущенные выделения ресурсов, ошибку реестра, сбой, подмену дат, манипуляцию или ущерб маршрутизации и RPKI. Последующее исправление должно сохранять связь с прежним состоянием.