Кратко

  • Первоначальный отчёт PDP 1 предлагает обязать регистратора проводить Associated Domain Check, когда у него есть пригодные к действию доказательства использования нескомпрометированного имени для определённого в RAA злоупотребления DNS. Документ обсуждается и пока не создаёт обязанности.
  • Рекомендация 8 требует доказуемого соблюдения, но называет шесть элементов лишь возможными и запрещает предписанный формат. Минимальная защищённая схема дела сохранит местное усмотрение и сделает исполнение сопоставимым.

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

Предлагаемый Associated Domain Check, или ADC, начинается не с прогноза, а с actionable evidence. Регистратор должен разумно определить, что зарегистрированное имя используется для фишинга, вредоносного ПО, ботнета, фарминга либо спама как средства доставки этих форм. Затем он ищет разумно связанные имена в собственной базе.

Границы существенны. Проверка не распространяется между регистраторами и не требует просматривать весь портфель в каждом случае. Общий nameserver, реселлер или privacy-сервис сам по себе не доказывает общего злоумышленника. Связь также не является готовым выводом о злоупотреблении и не предписывает одинаковую меру.

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

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

Но разнообразие методов создаёт второй вопрос: как доказать, что одна общая обязанность прошла через сравнимые этапы?

Внутренний файл можно проверить, но трудно сложить с другим

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

Затем текст запрещает политике предписывать формат. Внутреннее описание процедуры должно существовать и предоставляться ICANN по запросу.

Отдельное дело остаётся проверяемым. Contractual Compliance может прочитать исходный журнал, запросить материалы и понять контекст. Поэтому свободный формат не равен отсутствию доказательств.

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

Рекомендация 7 предусматривает оценку через два года после реализации. ICANN org и будущая IRT должны определить небольшой набор агрегатов и базовую линию. Отчёт правильно предупреждает: общий объём злоупотреблений не доказывает причинность отдельной политики. Но и механизм нельзя оценить, если одинаковые слова обозначают разные состояния.

Общая квитанция без общей машины наблюдения

Достаточно двух уровней.

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

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

Публичный уровень содержит только безопасные агрегаты: сколько действительных запусков привело к ADC, классы завершения, случаи законно недоступных данных, широкие интервалы времени и исправления. Малые ячейки скрываются. Рейтинг без знаменателей и описания состава дел недопустим. Такой слой не должен стать публичным реестром подозрений или межрегистраторской базой персональных данных.

Детали нужны Contractual Compliance, агрегаты — двухлетнему обзору. Расследование остаётся у того, кто имеет законный доступ и ответственность.

Что показывают нынешние отчёты

Глобальные поправки апреля 2024 года уже требуют своевременных и уместных мер против хорошо доказанного злоупотребления DNS. Advisory ICANN допускает поэлементный запрос документов. Ежемесячные панели агрегируют жалобы, уведомления и причины закрытия.

Панель июня 2026 года не измеряет ADC: предлагаемой обязанности ещё не было. Она не является аргументом за или против её эффективности. Она показывает лишь готовую публичную поверхность для будущих показателей.

Первоначальный отчёт также не изменил договор. Комментарии принимаются до 28 сентября, затем нужны итоговый отчёт, решения Совета GNSO и Совета директоров и реализация. Статус Full Consensus рекомендации 8 описывает процедуру рабочей группы, а не принятую политику.

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

Распределённая работа требует точных стыков

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

Инструменты, люди и законные сигналы остаются местными. Центр получает только минимальный язык для атрибуции общей обязанности. Недостающий элемент — не огромная база, а переносимая грамматика доказательства.

Источники

  1. Процедура публичного комментария ICANN
  2. Объявление ICANN
  3. Первоначальный отчёт DNSAM PDP 1 от 18 августа 2026 года
  4. Страница проекта DNS Abuse Mitigation PDP 1
  5. Устав DNS Abuse Mitigation PDP 1
  6. Глобальные поправки ICANN 2024 года
  7. Advisory ICANN об обязанностях по злоупотреблениям DNS
  8. Панель правоприменения по злоупотреблениям DNS, июнь 2026 года
  9. Программа ICANN по противодействию злоупотреблениям DNS
  10. Обзор процесса разработки политики GNSO
  11. Действующие процедуры Совета GNSO