Привет, Хабр! На связи Сергей Бровкин, руководитель SOC в Рунити. Больше 15 лет я занимаюсь практической информационной безопасностью — расследованием атак, реагированием на инциденты и всем, что происходит вокруг доменов и инфраструктуры клиентов.
Одна из наиболее спорных тем в этой работе — abuse‑запросы. Формально всё просто: поступает жалоба на фишинг, вредоносное ПО или взломанный ресурс — ее проверяют и принимают меры. На практике от качества самой жалобы зависит и результат, и скорость реакции.
По статистике за последние несколько лет, Руцентр, Рег.ру и R01 — все они входят в группу Рунити — получали в месяц около 4.5 тысяч abuse запросов от Компетентных организаций по зонам.ru и.рф через сервис Доменный патруль. И только 99% из них завершались блокировкой. Казалось бы, процент достаточно велик, но, учитывая количество поступающих обращений, цифра получается немаленькая. А если учесть, что статусом Компетентной организации до 1 сентября 2026 года обладали ключевые игроки рынка ИБ в стране (с перечнем можно ознакомиться на портале Доменного патруля), то каждый ресурс, на который готовилась жалоба, должен был быть тщательным образом проверен и соответствующее обращение должно было быть должным образом подготовлено и действительно содержать информацию о существенном нарушении со стороны наших клиентов.
Однако на практике мы видим, что даже с такими доверенными и проверенными многолетней практикой компаниями это не всегда так. А более 500 доменов, жалобы на которые были отклонены — это не просто цифра или злодеи. Это множество цифровых сервисов, которые могли быть заблокированы и прекратить работу по ложному обвинению.
Статистика обработки обращений обычных пользователей по другим зонам значительно более грустная — только 50% жалоб приводит к блокировке.
По большей части все обращающиеся на наши abuse‑линии допускают одни и те же ошибки. Кто‑то по незнанию, а кто‑то в том числе и вполне осознанно. И речь тут идет не о формальной стороне вопроса, шрифтах, отступах или каких‑либо реверансах, а о фактуре, которая прикладывается к жалобе и сути жалобы в принципе.
Давайте разберем, как всё это работает, где чаще всего ошибаются заявители и как составить abuse‑запрос так, чтобы его можно было быстро и корректно отработать.
Навигация по тексту:
Как устроена работа с доменами: регистратор, реестр, ICANN, ccTLD
Куда писать: регистратор, реестр, ICANN, ccTLD и как устроена эскалация
Как устроена работа с доменами: регистратор, реестр, ICANN, ccTLD
Когда речь заходит об abuse‑запросах, часто кажется, что всё просто: увидел вредоносный ресурс → направил жалобу → домен заблокировали. На практике цепочка значительно сложнее.
Кто управляет доменами?
Экосистема строится на нескольких уровнях:
ICANN. Некоммерческая организация, которая координирует работу глобальной системы доменных имен, а также определяет правила функционирование общих доменов верхнего уровня (gTLD) вроде.com,.org и других. Но: ICANN не регулирует ccTLD — национальные домены. Для России это.ru,.рф. и.su
Реестр. Владельцы/координаторы доменной зоны. Они решают, как управлять главной базой данных доменов зоны, и заключают соглашение с регистраторами по управлению доменами (RRA). Для.ru/.рф/.su — Координационный центр доменов.RU/.РФ.
Регистратор. Компания, которая работает с клиентами, регистрирует домены и в том числе обрабатывает abuse‑запросы. Регистратор подчиняется законодательству своей страны, соглашению с реестром, соглашению с ICANN по работе с международными доменами. Например, Руцентр, Рег.ру и R01 являются аккредитованными регистраторами как при реестрах.ru,.рф,.su, так и при ICANN и многих доменах верхнего уровня.
Реселлеры. Это компании дополнительного уровня взаимодействия — например, хостинг‑провайдеры или конструкторы сайтов, которые регистрируют и продают домены от имени аккредитованного регистратора.
Процесс работы регистратора с abuse‑жалобами регламентирован соглашениями ICANN (RAA — Registrar Accreditation Agreement) для международных доменов, договорами регистратора с реестрами (RRA — Registry‑Registrar Agreement) для конкретных зон, политиками каждого реестра в отдельности и национальным законодательством страны регистратора. Все эти документы определяют, на что регистратор обязан реагировать, в какие сроки, по каким каналам и при наличии какой фактуры.
Отдельный важный момент — в ICANN определена такая сущность, какпрограмма DNS Abuse Mitigation. Эта программа описывает категории нарушений и содержит их исчерпывающее описание. Рекомендуется ориентироваться именно на нее при определении наличия нарушения и его описания. Все регистраторы так или иначе подчиняются правилам этой программы в части gTLD, а ccTLD с ней очень хорошо коррелируют, так что точно не ошибетесь. Однако не стоит забывать и про правила для отдельных национальных доменов, так как в них могут упоминаться дополнительные категории или другие каналы подачи жалоб.
Abuse в цифрах: что происходит на практике
Чтобы понять масштаб — несколько цифр. Координационный центр доменов.RU/.РФ регулярно публикует данные по зонам.ru и.рф, и они хорошо показывают, как выглядит поток жалоб у крупного регистратора. Это лишь небольшая часть поступающих обращений по нескольким доменным зонам, хотя и весьма популярным, но открытая общая статистика делает ее более наглядной.
За предыдущий год регистраторы Рунити получили около 63 000 обращений по доменным зонам.ru и.рф через сервис «Доменный патруль». В среднем — 4 500 обращений в месяц.
В первом полугодии 2026 года через «Доменный патруль» всем регистраторам поступило 26 572 обращения — на 22,8% больше, чем за тот же период годом ранее. Изменилась и структура нарушений: на первое место вышло распространение вредоносного ПО — 12 611 обращений, или 47,5% от общего числа. На фишинг пришлось 36,8% обращений.
[1] В первом полугодии эти обращения еще обрабатывались по прежним правилам, в которых ключевую роль играли компетентные организации.
«Доменный патруль» — это специализированный сервис Координационного центра, через который компетентные организации передают регистраторам сведения о возможных нарушениях. Среди таких организаций — CERT‑центры (Computer Emergency Response Team — команды реагирования на компьютерные инциденты), профильные ведомства (например, НКЦКИ), крупные ИБ‑компании. У каждой компетентной организации есть свой статус и регламент проверки.
По старым правилам регистрации отечественных доменных зон запросы на блокировку доменов принимались исключительно от Компетентных организаций и Доменный патруль в том числе выступал связующим звеном между ними и пользователями сети — на его ресурсе располагается форма для подачи обращения к любой из Компетентных организаций. Любая жалоба, поданная напрямую, не могла привести к блокировке в наших национальных доменах. Регистраторы даже не могли самостоятельно заблокировать домены, используемые для фишинга под самого регистратора — в правилах не было определено таких полномочий.
С 1 сентября 2026 вступило в силу Постановление правительства № 1119 от 31 августа 2026 г., определяющее новый порядок регистрации доменных имен для зон.RU/.РФ/.SU. Новые правила не содержат такого понятия, как Компетентная организация, и эту роль теперь выполняет только НКЦКИ.
При этом сам факт обращения не означает автоматическую блокировку: регистратору всё равно нужно воспроизвести нарушение и проверить основания для применения мер. Другой исход обращения не обязательно означает ошибку заявителя — например, нарушение может быть устранено до завершения проверки или ресурс к этому моменту перестанет быть доступен.
[2] Главный вывод из цифр простой: содержание жалобы критически влияет на скорость и результат ее обработки. Даже профильному специалисту важно дать регистратору фактуру, которую можно воспроизвести и проверить.
Главный месседж: домен = клиент
Многие об этом не задумываются, и зря: за каждым доменом стоит клиент, заключивший договор с регистратором.
Это значит, что регистратор связан условиями договора с владельцем домена так же, как с любым другим клиентом по любому другому договору. Неправомерная блокировка — это не только репутационный удар и потеря клиента: это нарушение договорных обязательств и действующего законодательства РФ, которое влечет реальную ответственность регистратора.
Отсюда несколько практических следствий, которые стоит держать в голове, когда садишься писать жалобу:
регистратор не блокирует домен «потому что вы попросили», даже если жалоба выглядит убедительно;
регистратор не реагирует на угрозы вроде «иначе пожалуюсь в Роскомнадзор / ICANN / президенту»: каждое такое обращение пойдет по своему каналу и будет обработано отдельно;
чтобы регистратор применил меры, нужна фактура, которую он может технически проверить и юридически подтвердить.
Корректная жалоба → блокировка. Некорректная жалоба → отказ. Это та база, на которой стоит вся abuse‑процедура.
Типовые ошибки в abuse‑обращениях
Половина пользовательских жалоб не приводит к блокировке именно из‑за содержания. Не потому, что нарушения нет, а потому, что регистратор не может его подтвердить на основании предоставленной заявителем информации. Те же ошибки регулярно встречаются у крупных ИБ‑команд — никто не застрахован.
1. «Всё сразу»
В одной жалобе заявитель перечисляет все возможные категории нарушения: фишинг, вредоносное ПО, копирование бренда, мошенничество, уход от налогов. Часто с оговоркой «может» — «может быть фишинг», «может распространять вредоносное ПО», «может еще что‑то».
У крупного регистратора обращений поступает огромное количество, из которых существенная часть не содержит признаков нарушения. Поэтому задача регистратора — проверить основания жалобы и убедиться, что меры в отношении домена действительно обоснованы. Домен для регистратора — это в первую очередь клиент, исполнение договора с которым является безусловным приоритетом. Однако это не означает, что регистратор закрывает глаза на вредоносную активность.
При разборе жалобы регистратор проверяет фактуру и характер нарушения, и при большом количестве обращений этот процесс может работать только в режиме четко выстроенного конвейера, в том числе используя средства автоматизации — иначе любая команда захлебнется в открытых тикетах.
Как правильно?
Определить одну основную категорию нарушения и описать ее конкретно. Если кейсов несколько и они принципиально разные — например, фишинг плюс использование чужого товарного знака, — оформлять их разными обращениями в разные адресаты: фишинг идет в abuse‑контакт регистратора, товарный знак — правообладателю и его юристам.
2. Только домен без URL
Заявитель указывает голый домен и рассчитывает, что регистратор сам найдет нарушение где‑то на ресурсе. Иногда — даже аккуратно «обезвреживает» домен квадратными скобками, потому что в теме разбирается, понимает риск случайного клика, но всё равно ограничивается доменом без конкретной ссылки.
В чем подвох?
Регистратор не обязан изучать весь ресурс в поисках того, на что жалуется заявитель. Злоумышленники часто прячут вредоносные страницы по прямым ссылкам, на которые не попасть с главной. Главная при этом может быть совершенно безобидной, и проверяющий увидит чистую страницу.
Как правильно?
Прикладывать полный URL страницы с нарушением: протокол, домен, путь, параметры. В обезвреженном виде, со снятой кликабельностью. Если нарушение появляется после цепочки редиректов — фиксировать конечный URL и описывать всю цепочку.
3. Жалоба «всем сразу»
В получателях письма — пачка адресатов: регистратор, хостер, Роскомнадзор, CERT, банк, иногда «обратная связь» из подвала сайта министерства. Заявитель считает, что чем больше копий, тем выше шанс на ответ хоть откуда‑то.
В чем подвох?
Если в адресатах больше одного получателя, регистратор имеет полное право не обрабатывать такое обращение: формально оно направлено не ему, а всем сразу. И пожаловаться на отсутствие ответа уже не выйдет — письмо законно отнесено к категории «для информации».
Как правильно?
Жалуетесь регистратору — пишите регистратору в его abuse‑контакт. Нужно уведомить регулятора или банк — отправляйте им отдельные обращения по их каналам, не одним массовым письмом.
4. «Там мошенничество, заблокируйте»
Заявитель столкнулся с мошенничеством — заказал товар и не получил, перевел деньги и потерял — и пишет регистратору с требованием срочно заблокировать ресурс.
В чем подвох?
Регистратор — не правоохранительный орган. Установить факт мошенничества может только следствие и суд. Регистратор не имеет ни полномочий, ни инструментов, чтобы провести такую проверку по обращению гражданина: всё, что есть у заявителя, — это его слова, а они со стороны регистратора не проверяемы.
Это не значит, что регистратор «отгораживается». Если у ресурса есть параллельные признаки, например входящие в перечень DNS Abuse ICANN — скажем, он одновременно работает как фишинговая площадка, — регистратор разберется по своей линии. Но в общем случае путь такой: сначала заявление в полицию, оттуда — официальный запрос регистратору, далее регистратор работает по этому запросу в правовом поле.
Манипуляции, с которыми регистратор сталкивается каждый день
Часть жалоб — это сознательные попытки усилить обращение и подтолкнуть регистратора к более быстрой блокировке. На практике эффект обратный: жалоба теряет доверие, проверка усложняется, шансы на блокировку падают.
1. Подмена категории
Заявитель находит на чужом ресурсе свой логотип, фрагмент дизайна или название продукта и пишет «это фишинг, заблокируйте». Хотя кейс на самом деле относится к использованию товарного знака.
Так часто поступают, например, владельцы брендов в спорах с арбитражниками трафика. Арбитражники регистрируют домен, делают страничку «про авиабилеты», встраивают фрейм известного агрегатора, монетизируются через партнерку — всё легально с точки зрения DNS Abuse, но раздражает владельца бренда.
Что происходит. Жалоба уходит в команду по фишингу, та проверяет признаки фишинга, не находит и закрывает обращение как неподтвержденное. Если бы заявитель сразу указал нарушение товарного знака, обращение пошло бы в нужную команду и было бы корректно обработано по соответствующим правилам.
Вывод: не пытайтесь подменить категорию — проще писать честно.
2. Ссылки на репутационные сервисы
Очень частая история — приложить скриншот из Google Safe Browsing, Яндекс Safe Browsing, VirusTotal или другого репутационного сервиса и считать, что любая красная плашка автоматически делает ресурс вредоносным.
Не делает. Качество проверок в этих сервисах разное. В черные списки регулярно попадают чистые ресурсы — особенно в ситуациях, когда на ресурс целенаправленно жалуются ради давления (классический пример — те же истории с товарными знаками: жалуются и регистратору, и в браузеры, а в браузерах ресурс залетает в черные списки). В VirusTotal заявитель может опираться на красный вердикт одного движка из десятков и игнорировать, что остальные считают ресурс чистым. Доходило и до случаев, когда регистратору эскалировали жалобу из‑за подсветки «not‑a-virus» — то есть из‑за движка, который явно сообщает, что объект известный, но не вредоносный.
Регистратор не считает вердикт стороннего сервиса доказательством — никакой компетентный регистратор такому скрину не верит. Работаем только с тем, что можно проверить самостоятельно.
При этом сами репутационные сервисы — хороший канал, но в другом сценарии: пожаловаться в них, если ресурс реально опасен. Пусть браузер защищает пользователей. А вот использовать их вердикт в жалобе регистратору бесполезно.
3. Угрозы регуляторами
«Не заблокируете — пожалуюсь в Роскомнадзор. В НКЦКИ (Национальный координационный центр по компьютерным инцидентам). В прокуратуру. В ICANN». Иногда — те же ведомства в копии письма.
Главное, что стоит знать: жалуйтесь. Серьезно, без шуток.
Взаимодействие регистратора с регуляторами и компетентными органами регламентировано, идет ежедневно и в обычном рабочем режиме. Регистратор с регуляторами сотрудничает, а не противостоит им. Угроза «пожаловаться» ничего не ускоряет и не пугает — каждое такое обращение пойдет по своему каналу и будет обработано отдельно.
Если уверены в нарушении и в том, что регистратор не отреагирует, — спокойно подавайте параллельные обращения в регуляторы. Если не уверены — корректно оформите жалобу самому регистратору и подождите ответа. Угрозами добиться блокировки нельзя.
4. «Самодельные доказательства»
С хайпом генеративных моделей у каждой второй ИБ‑команды появился свой движок, скорящий домены и разделяющий их на «плохие» и «хорошие». Заявитель присылает отчет такого движка и считает, что вопрос закрыт: «наш движок сказал, что это фишинг, значит, фишинг, блокируйте».
В abuse‑обработке такая логика не работает. Доказательная сила любого стороннего скоринга заканчивается ровно там, где заканчиваются возможности регистратора это перепроверить. Красные буквы капсом «MALICIOUS» — не пруф.
Регистратор будет рассматривать ровно то, что:
можно проверить вручную;
воспроизводится по прямому URL;
укладывается в одну из категорий DNS Abuse ICANN.
Самодельные отчеты этим критериям не соответствуют.
Жалуемся правильно: чек‑лист
Хорошо оформленная жалоба — это набор данных, по которому регистратор за минимально возможное время воспроизводит нарушение и принимает меры. Логика проверки одна: либо у регистратора есть всё, чтобы подтвердить нарушение, либо проверка останавливается.
Скорость решает
Фишинговые ресурсы живут недолго — иногда часы. Если отложить жалобу «на после выходных», к моменту проверки контент успеет исчезнуть, и регистратор просто не сможет ничего подтвердить, даже если нарушение было настоящим. Даже к недобросовестному клиенту регистратор не сможет применить меры по договору, потому что подтвердить нарушение постфактум, без сохраненной фактуры, невозможно.
Поэтому не задерживайте. Чем раньше отправлена жалоба, тем выше шанс, что регистратор увидит ту же страницу, что видели вы.
Базовый набор для любой жалобы по DNS Abuse
Корректная категория. Используйте категории из программы DNS Abuse Mitigation от ICANN: фишинг, вредоносное ПО, ботнет, фарминг, спам как канал доставки этих активностей. Точные формулировки и нюансы — там же; их стоит изучить отдельно, потому что у каждой категории есть свои критерии.
Полный URL страницы с нарушением: протокол, домен, путь, параметры. Не голый корневой домен.
Обезвреженная ссылка: точки заменены, кликабельность снята. Эту меру стоит соблюдать всегда, даже зная, что у нормальных регистраторов процесс обработки исключает случайные клики со стороны специалиста.
Скриншот страницы с полностью видимой адресной строкой, на котором видно само нарушение.
Условия воспроизведения, если они важны: с какого региона и IP, на каком устройстве, в каком браузере открыто. Это критично в случаях, когда злоумышленник фильтрует трафик (см. ниже).
Геолокация: почему ее обязательно указывать
Злоумышленники нередко отдают вредоносный контент только определенным регионам — например, только Юго‑Восточной Азии или только определенному диапазону IP. Если регистратор из России идет проверять прямой URL без учета этого фильтра, он увидит пустую или безобидную страницу и закроет жалобу как неподтвержденную. Нарушение было, а фактуры нет.
Поэтому в жалобе указывайте регион и параметры подключения, с которых видели нарушение. Если фильтрация еще более узкая — например, по корпоративным IP, — потребуются дополнительные доказательства: записи трафика, логи, прокси‑параметры.
Цепочка редиректов
Если контент с нарушением открывается только в конце цепочки переадресаций, жалуйтесь на конечный домен в цепочке. Стартовый домен без вредоносного контента регистратор не заблокирует — он формально чист. В описании зафиксируйте всю цепочку и явно укажите конечный URL.
Для фишинга — два URL
Если жалоба о фишинге, обязательно укажите два URL:
ссылку на вредоносную страницу;
ссылку на оригинальный ресурс или бренд, который копируется.
Регистратор не обязан догадываться, чей именно бренд имитируется. Если копируются не страница целиком, а отдельные элементы — логотипы, форма входа, цветовая схема, — опишите словами, что именно скопировано, и подсветите эти элементы на скриншотах. Это сильно ускоряет проверку и повышает шансы, что жалоба будет подтверждена.
Для вредоносного ПО — URL, хеш, тип
Если жалоба касается вредоносного ПО, в обращение должно попасть следующее:
полный URL файла, обезвреженный;
хеш файла: предпочтительно SHA-256, в крайнем случае MD5;
тип ВПО: троян, загрузчик, кейлоггер, стилер и тому подобное
И отдельный важный момент: если вы не занимаетесь анализом ВПО, не скачивайте файл. Без квалификации это просто опасно. В таком случае пришлите URL и тип нарушения — остальное соберет регистратор.
Если у вас есть ссылка на отчет по анализу этого вредоносного ПО на VirusTotal или публичного sandbox, приложите ссылку. Как я писал выше, это не является самостоятельным аргументом, но она полезна при анализе и просто ускорит обработку жалобы.
Подробный гайд по составлению abuse‑обращений рекомендован ICANN — там разобраны нюансы по каждой категории.
Куда писать: регистратор, реестр, ICANN, ccTLD и как устроена эскалация
Один из самых частых вопросов, который возникает после первых попыток отправить abuse‑запрос: «Куда вообще правильно жаловаться? В регистратора? В реестр? В ICANN? В Роскомнадзор?»
Ответ зависит от того, в какой доменной зоне зарегистрирован домен, и что именно не выполняет регистратор. Разберем устройство всей цепочки и порядок действий.
1. Куда жаловаться по предмету обращения
Иерархия сторон в доменной экосистеме разобрана в начале статьи. Здесь — короткая шпаргалка: кто берет на себя какой тип обращения.
Регистратор — нарушения по категориям DNS Abuse (фишинг, вредоносное ПО, ботнеты, фарминг, спам как канал) на конкретных доменах. Это основной адресат большинства abuse‑жалоб.
Реестр — жалобы на бездействие регистратора (если он не реагирует на корректно оформленное обращение по своему профилю), а также нарушения политик зоны.
ICANN — только в двух случаях и только по gTLD: регистратор вообще не ответил на abuse‑обращение (нарушение RAA) или не реагирует на подтвержденное нарушение DNS Abuse. По ccTLD (.ru,.рф и др.) ICANN жалобы не принимает.
Реселлеры — на практике как адресат не используются. Ответственность перед реестром и ICANN несет головной регистратор, обращайтесь сразу к нему.
Правообладатели и их юристы — нарушение товарного знака, использование бренда, авторское право.
Правоохранительные органы — мошенничество, угрозы, преступления против личности и собственности. Регистратор подключается только по официальному запросу следствия.
Хостинг‑провайдер — параллельный канал к обращению регистратору. Даже Cloudflare принимает жалобы и передает их дальше хостерам.
Репутационные сервисы (Google Safe Browsing, Yandex Safe Browsing и др.) — не для эскалации к регистратору, а для защиты пользователей. Пожалуйтесь туда напрямую, чтобы браузеры подсветили ресурс как опасный.[1] [2] [3]
2. Важное различие: gTLD vs ccTLD
Вот ключевая формула: ICANN НЕ регулирует национальные домены (ccTLD).
Это значит:
Если домен в зоне.ru или.рф и др.
ICANN не принимает жалобы на такие домены;
политика ICANN (RAA/RA) не распространяется;
действуют правила реестра и законодательства РФ.
А если домен в зоне.com/.org/.net и др.
ICANN регулирует деятельность регистратора;
нарушение RAA может привести к страйкам вплоть до потери аккредитации.
Это нужно понимать, чтобы не тратить время на эскалации, которые по определению не работают (например, жалобы на.ru в ICANN).
Универсальное мнемоническое правило, которое следует запомнить — если домен из 2х букв, он национальный.
3. Сценарии эскалации: что делать, если регистратор не ответил или отказался реагировать
Важно: автоответ о регистрации обращения считается ответом. Если автоответ получен, ICANN жалобу не примет.
Эскалация зависит от того, что именно происходит.
Ситуация 1. Регистратор вообще не ответил на abuse‑запрос
Это нарушение RAA (для gTLD).
В этом случае можно подавать жалобу в ICANN:
ICANN принимает жалобу на отсутствие ответа.
Автоответ о регистрации обращения считается ответом.
Важно: если автоответ получен, ICANN жалобу не примет.
Ситуация 2. Регистратор ответил, но отказывается реагировать
Дальнейшие действия делятся по типу зоны.
Если это gTLD (.com/.org/.net), можно обратиться в реестр или подать жалобу в ICANN на отсутствие реакции (но только если речь идет о категориях нарушений, упомянутых в DNS Abuse ICANN).
Если это ccTLD, эскалация идет через: реестр. ICANN здесь не участвует.
Важно: жалоба в ICANN — это эскалация конфликта. Если вы рассчитываете на дальнейшее продуктивное взаимодействие с регистратором, до обращения в ICANN имеет смысл попробовать решить вопрос напрямую. После жалобы в ICANN отношения, как правило, портятся.
Ситуация 3. Нарушение очевидно, но регистратор отказывается принимать меры
В этом случае:
можно жаловаться на хостинг — у него тоже есть abuse‑контакты;
иногда помогает обращение в международные ассоциации FIRST/CSIRT;
в крайнем случае — юристы в стране регистратора и обращение в локальные правоохранительные органы.
4. Особый случай: зоны.ru/.рф и сервис «Доменный патруль»
Для национальных доменов до недавнего времени России единственным работающий каналом было — обратиться к Компетентной организации через сервис «Доменный патруль». Он предоставляет:
перечень компетентных организаций;
описание зоны экспертизы компетентной организации;
правила регистрации в зонах.ru/.рф;
выделенный канал доставки обращений регистраторам.
В настоящий момент с 01.09.2026 в новой редакции порядка регистрации доменных имен для зон.RU/.РФ/.SU понятие «Компетентной организации» ликвидировано и фактически единственной компетентной организацией определен НКЦКИ. Однако Доменный патруль — это, пожалуй, всё еще наиболее удобная форма подачи обращения на горячую линию.
Итоги: что важно помнить
Abuse‑запросы часто воспринимают как простой инструмент: отправил письмо — домен заблокировали. Но в реальности это строго регламентированный процесс, который работает только при соблюдении нескольких условий: корректная категория, проверяемые доказательства, воспроизводимость нарушения и точные формулировки.
Давайте подведем основные выводы.
1. Некорректная жалоба = отсутствие результата
Текст «там фишинг, срочно блокируйте» не дает регистратору оснований для действий.
Чтобы жалоба сработала, в ней должен быть полный набор данных: URL, скриншоты, параметры окружения, описание нарушения.
2. Домен = клиент
Домен — это онлайн‑актив, зарегистрированный по договору. Неправомерная блокировка — нарушение закона и условий соглашения. Регистратор не может «верить на слово» — только проверять факты.
3. Регистратор ≠ полиция
Регистратор не устанавливает факт мошенничества и не расследует преступления. Если вы стали жертвой мошенников — путь один: правоохранительные органы. Регистратор подключается тогда, когда от них поступает официальное обращение.
4. ccTLD имеют собственные правила
Домены в национальных зонах, включая.ru и.рф не регулируются ICANN. Единственный путь эскалации — через соответствующий реестр, если иное не определено в правилах регистрации соответствующей зоны и национальном законодательстве.
5. Рекомендации для зон.ru,.рф и.su
Жалобы на них нужно направлять через НКЦКИ (через контакты, указанные на сайте НКЦКИ или через «Доменный патруль»).
6. У хостинга тоже есть abuse
Иногда эффективнее жаловаться хостинг‑провайдеру, чем регистратору. Даже Cloudflare передает жалобы дальше конечным хостинг провайдерам — это рабочий канал и его можно использовать.
Ключевой вывод
Хорошее взаимодействие с регистраторами — это совместная работа. Проверяемые жалобы, корректная категория, отсутствие манипуляций — всё это снимает большую часть трений еще до того, как они появятся.
Регистраторы со своей стороны открыты к диалогу и готовы разбирать спорные кейсы вручную — главное, чтобы было с чем работать. Если подходить к оформлению abuse‑обращений системно, шансы заблокировать реально вредоносный ресурс заметно растут, а отношения с регистратором остаются рабочими в долгую.