Кратко

  • По сообщению APNIC, инцидент продолжался 18 часов: с 15:45 27 января до 09:45 28 января 2026 года по времени UTC+10.
  • Непреднамеренный эффект изменения конфигурации Cloudflare включил более строгую проверку целостности браузера. Было заблокировано примерно 10% RDAP-запросов, User-Agent которых не соответствовал распространённым браузерным строкам.
  • Защита от DDoS и ботов необходима. Но внешний вид User-Agent говорит о программном продукте, а не доказывает полномочия, цель или допустимость клиента реестра.
  • Четыре малочастотные проверки в сентябре — без явно заданного User-Agent, с именем автоматизации, с curl и с браузерной строкой — вернули одинаковый RDAP JSON. Это снимок одного момента, а не доказательство для всех клиентов и маршрутов.
  • APNIC может не раскрывать правила WAF и всё же вести проверяемую квитанцию: категории контрольных клиентов, отдельные решения периферии и источника, машинно читаемый результат, границы изменения и время отката.

Сбой был неравномерным — и потому особенно полезным

В объявлении APNIC о состоянии сервиса есть редкая для краткого сообщения конкретика. RDAP был затронут с 15:45 вторника 27 января 2026 года до 09:45 среды 28 января; обе отметки приведены в UTC+10. Итого — 18 часов. Причиной названо изменение конфигурации Cloudflare, непреднамеренно применившее более строгие проверки Browser Integrity Check.

APNIC также указала масштаб: около 10% запросов с User-Agent, не похожим на строки распространённых браузеров, были заблокированы. Эта формулировка не означает, что отказали все программные клиенты. Она не называет число пользователей или организаций, абсолютное количество запросов, конкретные инструменты, точки присутствия либо последствия для сетевых решений. Нет и опубликованного перечня кодов ответа или страниц блокировки.

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

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

За периферийной защитой стоит сильный аргумент

Публичный сервис реестра нельзя эксплуатировать так, будто враждебного трафика не существует. Автоматизация законна и ожидаема, но тот же интерфейс можно нагружать агрессивными сборщиками, ботами и DDoS. Обязанность APNIC поддерживать доступность включает фильтрацию и распределение нагрузки; стандарт протокола не превращает происхождение каждого пакета в безусловное право на ресурсы источника.

Архитектурная статья APNIC 2020 года описывает путь rdap.apnic.net и сервисов RDAP национальных интернет-реестров через Cloudflare. Там выполняются балансировка и защита от DDoS, а затем запросы проксируются к инфраструктуре в Google Cloud. Следовательно, пограничный поставщик — часть производственной цепочки APNIC, а не постороннее обстоятельство, которое можно вычеркнуть из оценки сервиса.

Документация Cloudflare также объясняет нормальную цель Browser Integrity Check. Функция оценивает HTTP-заголовки, часто связанные с вредоносным трафиком, и способна предъявить проверку запросам с отсутствующим или нестандартным User-Agent. Одновременно Cloudflare документирует правила, с помощью которых эту проверку можно выборочно пропустить или отключить. Механизм допускает контекст и границы применения.

Поэтому разумный вывод не состоит в том, чтобы убрать Cloudflare, выключить защиту от ботов, опубликовать чувствительные пороги или разрешить неограниченный поток. Вопрос должен быть точнее: какая настройка защищает машинный интерфейс, не принимая веб-браузер за образец легитимности, и какой тест доказывает это после каждого изменения?

HTTP не превращает RDAP в обычный сайт

В материале APNIC 2021 года RDAP описан как структурированный JSON, передаваемый по HTTP или HTTPS. Ответ предназначен для машинного разбора. Унифицированный клиент может работать с большинством RDAP-сервисов, тогда как исторические форматы WHOIS различались. HTTP-кэширование помогает эффективно повторять получение данных. Это описание предполагает программы без графического интерфейса как штатных участников.

RFC 9082 задаёт единообразные REST-подобные пути для запросов о доменах, серверах имён, сущностях, IP-сетях и автономных системах. RFC 7480 связывает RDAP с HTTP. Браузерные приложения возможны и учтены — в том числе через правила межсайтового доступа, — но браузер не получает статус эталонного клиента. Библиотека, командный инструмент, система инвентаризации, служба реагирования на злоупотребления или межреестровый процесс не обязаны имитировать интерактивную страницу.

Здесь и возникло несовпадение моделей. Browser Integrity Check исходит из обычной формы веб-трафика и использует отклонение от неё как сигнал риска. Обычная форма RDAP включает автономные программы. При переносе первой модели на вторую честное описание клиента может стать причиной блокировки, хотя протокольный запрос корректен.

Сам по себе сигнал необязательно бесполезен. Он может дополнять скорость, репутацию, поведение, аутентификацию и другие признаки. Проблема появляется, когда слабое свидетельство получает полномочия окончательного шлюза. Тогда периферия отвечает на другой вопрос, чем приложение: «похож ли этот HTTP-клиент на браузер?» вместо «какой RDAP-результат положен этому запросу?»

User-Agent нельзя повысить до удостоверения личности

RFC 9110 определяет User-Agent как сведения о программном обеспечении, сформировавшем запрос. Поле содержит идентификаторы продуктов и комментарии, помогает диагностировать совместимость и иногда подбирать ответ. Его пишет сам клиент. Строка может быть краткой, отсутствовать в некоторых обстоятельствах или маскироваться под другой продукт.

Ни одна синтаксическая часть User-Agent не подтверждает оператора. Она не свидетельствует о членстве в APNIC, цели исследования, роли дежурной команды, договорном доступе, законности запроса или допустимой частоте. Знакомый префикс браузера не создаёт такие полномочия; имя небольшого скрипта их не отменяет.

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

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

Ограничение частоты должно говорить на языке машины

RDAP не обещает безграничной доступности. RFC 7481 прямо относит устойчивость к отказу в обслуживании к вопросам безопасности. Поставщик может ограничивать скорость, вводить аутентификацию для расширенного доступа и обеспечивать справедливое использование общего ресурса. Такие меры совместимы с назначением протокола, если клиент способен понять результат.

RFC 7480 рекомендует HTTP 429 для ограничения частоты. Retry-After, когда он присутствует, даёт программе осмысленный срок следующей попытки. Это лучше, чем неясная классификация по браузерному сходству: ответ объясняет непосредственную причину и позволяет клиенту снизить нагрузку. Аутентификация, в свою очередь, может опираться на реальное различие полномочий, а не на косметику заголовка.

Из этого не следует, что все январские блокировки обязаны были возвращать 429. Проверка бота и rate limit — разные механизмы, а объявление APNIC не раскрывает деталей, достаточных для переклассификации каждого ответа. Нельзя задним числом придумывать коды, которых нет в источнике.

Практический критерий другой: оператор должен видеть судьбу валидной машинной проверки по категориям. Дошла ли она до источника? Получила ли RDAP JSON? Была ли ограничена по частоте, встретила проверку или окончательный блок? Если пограничный ответ является HTML-страницей или непрозрачным отказом, монитор не должен засчитывать его как полезный ответ реестра.

Четыре одинаковых ответа в сентябре

5 сентября 2026 года четыре малочастотных GET-запроса были отправлены на https://rdap.apnic.net/ip/202.12.29.0. Каждый запрашивал application/rdap+json. Первый не задавал User-Agent явно. Второй использовал User-Agent автоматизации с обозначенной целью. Третий использовал curl/8.7.1. Четвёртый содержал строку в стиле Mozilla и Safari.

Все четыре раза сервер вернул HTTP 200 и application/rdap+json. Размер каждого тела составил 3857 байт, а SHA-256 был одинаковым: d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. Заголовки показывали присутствие Cloudflare на пути.

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

Но четыре запроса не доказывают глобальное исправление. Они не воспроизвели январскую конфигурацию, не проверили все адреса, методы, географии, сети источника, периферийные узлы и режимы нагрузки. Совпадение тел не гарантирует, что другая политика никогда не разделит клиентов. И оно не устанавливает историческую причину независимо от официального сообщения APNIC.

Канарейка ценна именно как ограниченное свидетельство. Её нужно датировать, привязывать к пути и повторять. Один запуск отвечает на вопрос «что произошло здесь сейчас?». Последовательность запусков показывает момент расхождения и связь с изменением. Превращать единичный успех в бессрочный сертификат означало бы повторить ту же ошибку слишком узкой метрики.

Минимальная квитанция от периферии до источника

Проверяемость не требует раскрыть выражение WAF, пороги репутации или признаки, пригодные для обхода. APNIC может владеть четырьмя контрольными клиентами: без User-Agent, с ясно названной автоматизацией, с распространённым командным клиентом и с браузером. Все они должны проходить через настоящий производственный край, а не только напрямую проверять приложение.

Запись по каждому запуску может быть небольшой. Нужны категория клиента, время, endpoint, класс HTTP-статуса, тип содержимого, класс тела и задержка. Решение периферии и факт поступления на источник следует хранить раздельно. Если действует именно ограничение частоты, фиксируется наличие машинно читаемого указания о повторе. Секретное правило остаётся секретным; его внешний эффект становится измеримым.

Рядом требуется происхождение изменения: идентификатор конфигурации, область хоста или пути, владелец, проверяющий, время поэтапного включения, результат контрольных клиентов и время отката. Публичная версия может агрегировать долю блокировок по поддерживаемым классам и не выдавать атакующему порог. Главная задача — не дать отказам на краю исчезнуть из статистики здорового источника.

У APNIC уже есть близкая основа. В отчёте о доступности реестровых сервисов за второй квартал 2025 года RDAP-тест считался успешным, когда менее чем за пять секунд получал неошибочный HTTP-ответ. Доступность рассчитывалась как доля успешных тестов. Если добавить категорию клиента и отделить решение края от результата источника, пользовательская перспектива станет шире, а сама формула сохранится.

В отчёте секретариата за первый квартал 2026 года APNIC заявила, что все основные реестровые сервисы достигли не менее 99,99% доступности. Краткое сообщение не даёт знаменателя и полной методики, поэтому его нельзя честно согласовать или противопоставить 18-часовому событию, затронувшему приблизительную долю запросов. Утверждать, что показатель ложен, оснований нет. Полезнее опубликовать соединение данных: какие клиентские классы, интервалы и периферийные исходы включены в число.

Чего инцидент не доказывает

Доступные материалы не показывают, что RDAP APNIC не работает сейчас. Они не доказывают блокировку каждого машинного клиента, не называют пострадавших операторов и не измеряют конкретный ущерб. Нет точных страниц ответа, списка User-Agent или набора правил. Сентябрьская проверка не восполняет эти неизвестные.

Источники также не устанавливают, что APNIC или Cloudflare нарушили RFC. Стандарты задают протокольные свойства и полезные HTTP-сигналы; защита рабочей инфраструктуры требует локальных решений вокруг них. Официально признанный дефект — непреднамеренное действие конфигурации. Поэтому проверяемый вопрос касается области, наблюдаемости и предотвращения повторения, а не выдуманного обвинения.

Наконец, доля в 10% относится к запросам за указанный период, а не к десяти процентам пользователей, программ или адресного пространства. Любое преобразование этого знаменателя без исходных данных создало бы ложную точность. Сила эпизода не в величине потенциального вреда, которой мы не знаем, а в ясно названном механизме классификации.

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

Источники

  1. APNIC, объявление о сервисе от 28 января 2026 года
  2. Блог APNIC, A new infrastructure to serve RDAP
  3. Блог APNIC, Is RDAP ready to replace whois?
  4. Блог APNIC, APNIC registry services availability during Q2 2025
  5. Блог APNIC, APNIC Secretariat Q1 2026 update
  6. Документация Cloudflare, Browser Integrity Check
  7. RFC 7480, применение HTTP в RDAP
  8. RFC 7481, сервисы безопасности RDAP
  9. RFC 9082, формат запросов RDAP
  10. RFC 9110, семантика HTTP