WHOIS и RDAP: что сегодня показывают данные о домене

Если вы последний раз проверяли WHOIS домена лет десять назад, то помните длинную простыню текста: имя, почтовый адрес, телефон, электронная почта. Сегодня почти ничего этого нет. Запись стала короче, в половине полей стоит «REDACTED», а сервис, которым вы пользуетесь, возможно, вообще уже не говорит по протоколу WHOIS.

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

Что запись WHOIS показывает до сих пор

Публичные регистрационные данные обычного общего домена верхнего уровня (.com, .net, .org, .app и так далее) надёжно содержат:

регистратора, который обслуживает домен, и его идентификатор IANA;
даты создания, последнего изменения и окончания регистрации;
один или несколько кодов статуса;
NS-серверы, на которые делегирован домен;
сведения о том, подписан ли домен DNSSEC;
контакт регистратора для жалоб (abuse).

Для большинства практических вопросов этого хватает. Не истекает ли домен на днях? В какую компанию обращаться, чтобы это исправить? Менялись ли NS-серверы на прошлой неделе? Стоит ли блокировка переноса?

Чего в записи обычно нет, так это личности регистранта, то есть администратора домена.

Почему данные владельца скрыты

До мая 2018 года договоры с ICANN обязывали регистраторов публиковать полные контактные данные каждого регистранта в зонах gTLD. Когда в ЕС начал действовать Общий регламент по защите данных (GDPR), у публикации таких персональных данных любому желающему не осталось убедительного правового основания. ICANN ответила Временной спецификацией (Temporary Specification), которая разрешила реестрам и регистраторам не показывать персональные поля в публичной выдаче. Пришедшая ей на смену постоянная политика регистрационных данных (Registration Data Policy) сохранила тот же принцип.

Что из этого следует на практике:

Данные часто скрывают у всех подряд. Многие регистраторы применяют это правило к каждому клиенту: сортировать регистрантов по тому, под какой закон о защите данных они подпадают, слишком ненадёжно.
Организации могут оставаться видимыми. Юридическое лицо вправе согласиться на публикацию названия организации, и некоторые так и делают.
Сервисы приватности и прокси — это отдельный слой. Они подменяют данные регистранта собственными. Появились они задолго до 2018 года и распространены до сих пор.
Для обоснованных запросов путь есть. Регистратор обязан дать способ связаться с регистрантом, не раскрывая его адреса (обычно это веб-форма или пересылка почты), и обязан рассматривать запросы на раскрытие, например от правоохранительных органов или правообладателей товарных знаков.

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

Чем плох протокол WHOIS

WHOIS родом из начала 1980-х. Клиент открывает TCP-соединение с портом 43, отправляет доменное имя и перевод строки, в ответ получает произвольный текст. Это весь протокол. Отсюда и проблемы:

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

RDAP: замена WHOIS

Протокол RDAP (Registration Data Access Protocol) IETF стандартизировала в 2015 году именно для того, чтобы устранить эти недостатки. Это API поверх HTTPS, который отвечает в JSON:

Определённая структура. Даты передаются как events с действием вроде registration или expiration. Контакты — это entities с ролями, например registrar или abuse. Значения статуса берутся из фиксированного списка.
Настоящая обработка ошибок. Для несуществующего домена возвращается HTTP 404, при превышении лимита запросов — 429.
Обнаружение через bootstrap. IANA публикует машиночитаемый файл, в котором каждой зоне сопоставлен базовый URL её RDAP-сервиса, так что клиент всегда знает, куда обращаться.
Ссылки на другие серверы. Ответ реестра может вести на RDAP-сервер регистратора, у которого бывает больше подробностей.
Возможность разграничить доступ. Поскольку всё работает по HTTPS, сервер может аутентифицировать запрашивающего и отдать больше полей тем, кто имеет на это право.

Попробовать можно с одним только curl. В сокращённом виде ответ выглядит так:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

ICANN требует от реестров и регистраторов gTLD поддерживать RDAP с августа 2019 года. В январе 2025 года договорная обязанность держать для gTLD сервис WHOIS на порту 43 прекратилась, и авторитетным источником стал RDAP. Люди по-прежнему говорят «проверить WHOIS», и как название задачи это вполне годится, но сами данные всё чаще приходят по RDAP.

С национальными доменами (ccTLD) дело обстоит иначе: правила они устанавливают сами. У многих RDAP есть, у некоторых до сих пор только WHOIS или веб-форма, а кое-кто публикует совсем мало.

Как читать коды статуса

Коды статуса пришли из EPP, протокола обмена между регистраторами и реестрами. RDAP пишет их через пробел («client transfer prohibited»), а в выдаче WHOIS используется camelCase. Префикс показывает, кто установил код: client — регистратор, server — реестр. Краткая справка по всем значениям есть в глоссарии: EPP-коды статуса.

Повседневные коды

ok / active: ограничений нет, ничего не заблокировано.
clientTransferProhibited: блокировка переноса на стороне регистратора. Для ваших собственных доменов это нормальное и желательное состояние.
clientUpdateProhibited, clientDeleteProhibited: блокировка изменений или удаления на стороне регистратора. Часто встречается у ценных имён.
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited: блокировки на уровне реестра. Встречаются у услуг типа registry lock и во время споров.

Коды, при которых домен не работает

clientHold: регистратор убрал домен из зоны. Типичные причины: неоплаченное продление, неподтверждённый контактный адрес, разбирательство по жалобе.
serverHold: то же самое сделал реестр. Обычно это вопрос права или политики реестра.
inactive: NS-серверы не заданы, публиковать нечего.

Коды жизненного цикла

addPeriod: домен только что зарегистрирован. Регистратор ещё может удалить его с возвратом платы, обычно в течение пяти дней.
autoRenewPeriod: по окончании срока реестр продлил домен автоматически. Регистратор ещё может это отменить, как правило в течение 45 дней.
transferPeriod, renewPeriod: короткие льготные периоды после переноса или явного продления.
pendingTransfer: идёт перенос к другому регистратору.
redemptionPeriod: домен удалён. Прежний регистрант может его восстановить, обычно в течение 30 дней и за ощутимую плату.
pendingDelete: восстановление уже невозможно. Примерно через пять дней имя освобождается.

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

Дата окончания: у реестра и у регистратора

На этом месте ошибаются чаще всего.

Когда у домена в зоне gTLD наступает дата окончания регистрации, большинство реестров его не удаляют. Они автоматически продлевают его на год, выставляют счёт регистратору и переводят домен в autoRenewPeriod. Если клиент так и не заплатит, регистратор в пределах льготного периода удалит домен и получит плату назад.

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

В некоторых записях видны оба значения:

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

Если они расходятся, останется ли ваш сервис в строю, решает дата регистратора. Практические правила:

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

Возраст домена

Дату создания часто используют как грубый признак того, насколько домен «устоялся». Помните об одной оговорке: если имя было удалено и зарегистрировано заново, дата создания обнуляется. Она говорит о том, когда началась текущая регистрация, а не о том, когда именем начали пользоваться впервые.

Проверьте в OrbitProbe

Проверка WHOIS в OrbitProbe обращается напрямую к RDAP и показывает регистратора, даты, коды статуса, NS-серверы и состояние DNSSEC с указанием сервера-источника и времени запроса. Скрытые поля так и отображаются: как скрытые. Если доменов у вас несколько, портфель в рабочем пространстве держит даты окончания в одном списке и присылает напоминания о продлении. А если вы собираетесь сменить регистратора, начните со статьи как перенести домен к другому регистратору.