Как узнать историю сайта: домен, старые страницы, владельцы и смена тематики

Сайт меняет тематику, дизайн и владельца, а домен часто продолжает жить дальше - просто с другой историей внутри. Задача восстановить эту историю возникает по десяткам поводов: проверить, кто на самом деле стоит за интернет-магазином перед оплатой, понять, не тот же ли это ресурс, что три года назад публиковал совсем другой контент, или просто закрыть вопрос «а это вообще давний проект или домен купили на прошлой неделе». Метод существует и работает без подписок на дорогие сервисы, но у каждого источника свой набор ограничений: часть данных, которая ещё десять лет назад лежала в открытом WHOIS, сегодня закрыта GDPR.

Ниже - рабочая последовательность: RDAP и WHOIS для регистрационных данных домена, архив Wayback Machine для содержимого страниц, DNS и Certificate Transparency для технических следов смены инфраструктуры. В конце - сквозной пример на реальном домене x.com, который за свою историю сменил владельца, тематику и даже название компании, и все команды из примера можно повторить самостоятельно.

RDAP и WHOIS: с чего начать и куда делся port 43

WHOIS - протокол 1982 года, который отдаёт регистрационные данные домена произвольным текстом: у каждого реестра и регистратора свой формат, и разбирать его приходится вручную или скриптом под конкретный источник. RDAP (Registration Data Access Protocol) - его замена: структурированный JSON по стандарту IETF, единый для всех регистраторов. С 28 января 2025 года у реестров и регистраторов общих доменов (gTLD) больше нет контрактной обязанности перед ICANN поддерживать WHOIS по порту 43 и веб-WHOIS: это установлено глобальными поправками к базовому соглашению реестра, которые совет директоров ICANN одобрил 30 апреля 2023 года, с отключением через 18 месяцев. Часть регистраторов веб-WHOIS ещё держит по инерции, но гарантированно доступен теперь только RDAP.

Формат RDAP описывают три документа IETF: RFC 9224 - как найти нужный RDAP-сервер для конкретного домена (bootstrap-сервис), RFC 9082 - формат самого запроса, RFC 9083 - структура JSON-ответа. Проще всего не разбираться в bootstrap руками, а обратиться к готовому редиректору about.rdap.org, который сам определит нужный реестр по домену:

curl https://rdap.org/domain/example.com

Либо сразу к RDAP-серверу реестра: для зон .com и .net это rdap.verisign.com, для большинства остальных зон свой адрес несложно найти в справочнике IANA RDAP Bootstrap Registry.

В ответе важны прежде всего четыре поля. Событие registration - дата, когда домен впервые появился в реестре. Expiration - до какого числа он оплачен. Last changed - последнее изменение записи, необязательно смену владельца: это могут быть и технические правки. Nameservers - на чьих серверах имён домен обслуживается сейчас. Отдельно посмотрите на статусы вроде clientTransferProhibited или serverDeleteProhibited: расшифровка этих кодов есть на icann.org/epp, и они означают защитные блокировки, а не проблему с доменом.

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

Что RDAP реально скрывает

До 2018 года публичный WHOIS у большинства доменов показывал имя, email, телефон и почтовый адрес регистранта без ограничений. 17 мая 2018 года совет директоров ICANN принял Временную спецификацию (Temporary Specification) для регистрационных данных gTLD - реакцию на вступление в силу европейского GDPR. С этого момента персональные контактные данные физического лица-регистранта редактируются в публичном выводе, если регистрант, регистратор или обработчик данных связаны с ЕС, а на практике почти все регистраторы стали применять правило глобально: разделять базы по юрисдикции регистранта сложнее и дороже, чем скрыть данные у всех подряд.

Временная спецификация была рассчитана максимум на год и позже превратилась в постоянную Registration Data Policy, которая в полную силу вступила 21 августа 2025 года после переходного периода, начавшегося в августе 2024-го. Итог для практики: у обычного физического лица в RDAP почти всегда будет «REDACTED FOR PRIVACY» вместо имени и адреса, иногда - форма связи или email через прокси регистратора. У компании поле organization может остаться видимым, но не гарантированно. У доменов в зонах, отличных от gTLD (.ru, .de, .uk и другие ccTLD), действуют собственные правила конкретного национального реестра, а не решения ICANN. Их нужно проверять отдельно для каждой зоны.

Отсюда практический вывод, о котором легко забыть: приватная защита WHOIS сама по себе ничего не доказывает. Её ставят и мошеннические сайты, и рядовые владельцы блогов, которые просто не хотят получать спам на домашний адрес. Не стоит делать вывод «раз скрыто - значит, есть что скрывать»: гораздо чаще это просто настройка регистратора по умолчанию.

Wayback Machine: как поднять старые версии страницы

web.archive.org хранит копии страниц с 1996 года, а календарь на web.archive.org/web/*/domain.com показывает даты доступных снимков. Для точечной проверки удобнее CDX API: он одним запросом отдаёт список всех сохранённых версий без интерфейса.

curl "https://web.archive.org/cdx/search/cdx?url=example.com&output=json&collapse=timestamp:8"

Параметр collapse=timestamp:8 схлопывает снимки по дню, иначе для активно архивируемого домена ответ растянется на тысячи строк. В каждой строке - таймстамп, код ответа сервера на момент архивации и digest, по которому легко увидеть, менялась ли страница на самом деле: одинаковый digest у соседних снимков означает, что краулер просто зашёл ещё раз, а контент не менялся.

Если нужной страницы в архиве ещё нет, Save Page Now на web.archive.org/save архивирует её прямо сейчас. Это не способ получить прошлое: он не восстанавливает то, что не сохранилось раньше.

У метода три реальных ограничения. Во-первых, Wayback Machine не архивирует то, что закрыто логином, платным доступом или явно запрещено в robots.txt. Хотя после 2017 года Internet Archive объявил, что меньше полагается на robots.txt именно при решении, архивировать ли страницу вперёд, старые исключения и запросы на удаление уже сохранённых копий продолжают действовать. Во-вторых, частота обхода привязана к посещаемости: у популярного домена снимки идут через день, у нишевого - раз в несколько месяцев или лет, так что отсутствие изменений между двумя капчурами не всегда значит, что страница не менялась в промежутке. В-третьих, отсутствие капчуры не доказывает, что версии страницы не существовало: её могли удалить по запросу правообладателя, или она просто не попала в обход краулера.

DNS и nameservers как технический след

Текущие nameservers показывают, кто технически обслуживает домен сейчас: dig NS example.com. Дефолтные серверы имён регистратора вроде ns1.registrar-servers.com говорят, что домен просто припаркован или обслуживается «из коробки»; смена на собственные NS вида ns1.company.com или на инфраструктуру конкретного хостера или CDN - сигнал, что за доменом стоит отдельная техническая команда, а смена таких записей во времени часто совпадает со сменой хостинг-провайдера или собственника проекта.

MX-записи (dig MX example.com) показывают, где принимается почта: в Google Workspace, Microsoft 365 или на собственном сервере. Это полезный, хоть и не решающий сигнал при проверке контрагента: корпоративная почта на стороннем провайдере - нормальная практика, а вот у компании, которая заявляет о себе как о крупной, но не имеет вообще настроенной MX-записи, стоит присмотреться внимательнее.

Важная оговорка: A-запись домена сама по себе почти бесполезна для атрибуции, если сайт стоит за Cloudflare, AWS CloudFront или любым другим общим CDN: тысячи не связанных друг с другом доменов резолвятся в один и тот же диапазон IP-адресов. Совпадение IP не значит совпадение владельца. Историю смены DNS-записей в прошлом бесплатные источники системно не хранят: это делают платные сервисы вроде SecurityTrails или DNSDB, и рассчитывать на бесплатный аналог не стоит.

Certificate Transparency и старые поддомены

С 2013 года действует механизм Certificate Transparency (RFC 6962, обновлён в декабре 2021 года как RFC 9162): публичные, дополняемые только в конец журналы, куда удостоверяющие центры обязаны отправлять каждый выданный TLS-сертификат. С 2018 года крупные браузеры отказываются доверять сертификату, если он не залогирован, то есть практически любой публичный HTTPS-сертификат последних лет отражён в CT-логах, включая те, что были выпущены на поддомены, впоследствии закрытые или забытые.

Самый простой публичный интерфейс к этим логам - crt.sh, который поддерживает Роб Стрэдлинг из Sectigo. Запрос crt.sh/?q=%.example.com&output=json выводит все сертификаты, когда-либо выпущенные на домен и его поддомены, а дата not before у каждого сертификата - примерная дата, когда поддомен впервые обзавёлся HTTPS. Полезно для поиска забытых staging- и admin-поддоменов, которые до сих пор резолвятся, но никогда не были на виду.

Честное предупреждение из личного опыта: пока писалась эта статья, crt.sh несколько раз подряд отвечал ошибкой 502. Сервис периодически перегружен и не гарантирует стабильную доступность - это не признак того, что метод не работает, а просто разовая перегрузка. Попробуйте запрос позже или возьмите альтернативу вроде Censys или merklemap.com. И ограничение по сути самого метода: в CT попадают только имена, явно указанные в выпущенном сертификате. Поддомен, годами работавший за wildcard-сертификатом *.example.com, отдельной строкой в логах не покажется.

Сквозной пример: как менялся x.com

x.com - редкий случай: почти весь путь домена задокументирован открыто, а не восстанавливается по крупицам. Часть истории Илон Маск рассказал сам публично, остальное подтверждается RDAP и архивом. Ниже - реальные данные, полученные по описанным выше методам 26 августа 2026 года; их можно повторить самостоятельно и увидеть то же самое, с поправкой на то, что поле last changed продолжит меняться.

RDAP-запрос к rdap.verisign.com/com/v1/domain/x.com даёт: регистрация - 2 апреля 1993 года; срок действия - до 20 октября 2034-го; регистратор - GoDaddy; статусы clientTransferProhibited и ещё три защитные блокировки; nameservers - восемь серверов вида a.r10.twtrdns.net и a.u10.twtrdns.net. Дата регистрации 1993 год не значит, что тогда уже существовал будущий сервис Маска. Это просто подтверждает правило из первого раздела: запись домена в реестре может быть в разы старше любого из проектов, которые на нём когда-либо работали.

Для сравнения: у twitter.com в RDAP регистрация - 21 января 2000 года, регистратор - CSC Corporate Domains, специализированный регистратор для корпоративных брендов, а не розничный GoDaddy. Формально это два разных домена с независимыми историями в реестре, хотя сегодня они принадлежат одной компании, и уже сам факт разных регистраторов намекает на разную историю приобретения.

Дальше - публично известная канва, которую легко свести в таблицу дат. Март 1999 года - Маск основал X.com как онлайн-банк. Март 2000-го - слияние с Confinity, создателем PayPal. 2001 год - объединённая компания переименована в PayPal, а домен x.com со временем стал просто редиректом на paypal.com. 2002 год - eBay покупает PayPal вместе с доменом, и на следующие пятнадцать с лишним лет x.com превращается в обычный редирект на paypal.com. В июле 2017 года Маск выкупил x.com обратно у PayPal - по его собственным словам, «из сентиментальных соображений». Сумму сделки не раскрыли, но независимые наблюдатели из сферы доменной торговли заметили и подтвердили её раньше официальных комментариев - именно потому, что домен сменил регистратора с корпоративного MarkMonitor на розничный GoDaddy. Тот же сигнал мы разбирали в разделе про DNS, только там он был про nameservers, а не про самого регистратора.

После покупки в 2017-м в CDX Wayback Machine (web.archive.org/cdx/search/cdx?url=x.com) виден многолетний период, когда домен отдаёт короткие технические страницы весом около 500 байт - судя по всему, редирект-заглушку. Первый же сохранённый снимок домена датирован 19 декабря 1996 года, заметно позже даты регистрации 1993 года, и это тоже ожидаемо: краулер начал заходить на домен только тогда, когда на нём появилось хоть что-то, а первые годы после регистрации записи в реестре домен вполне мог просто простаивать. Дальше в данных виден резкий и точно датированный перелом: 23 июля 2023 года в CDX внезапно появляются ответы с кодами 301 и 302 вместо привычных 200. Именно в этот день Маск публично объявил о ребрендинге Twitter в X и смене логотипа. Эта дата не восстановлена по пресс-релизам. Она видна прямо в технических метаданных архива.

Здесь же скрыт нюанс, который легко упустить, если верить только заголовкам новостей: летом 2023-го именно x.com стал перенаправлять на twitter.com, а не наоборот - старый бренд Twitter формально оставался основным ещё почти год. Twitter.com начал перенаправлять на x.com только в мае 2024 года, когда компания окончательно убрала последние следы прежнего названия. Разница между «объявили ребрендинг» и «домен стал основным» - почти год. Без проверки дат по CDX этот разрыв легко не заметить.

Картина по DNS похожая, но не идентичная: у x.com и twitter.com разные наборы nameservers (a.r10.twtrdns.net против a.r06.twtrdns.net), но оба используют одну и ту же собственную DNS-инфраструктуру twtrdns.net. То есть за обоими доменами технически стоит одна и та же компания, а не просто похожий тёзка. При этом почта x.com настроена через MX-записи Google Workspace (aspmx.l.google.com), а не через собственный почтовый сервер. Мелочь, которая при обычной проверке контрагента выглядела бы небольшим красным флагом, но для компании с такой историей - обычная практика.

Итог примера: ни один источник по отдельности не рассказал бы всю историю целиком. RDAP дал даты регистрации и текущих регистраторов. Wayback показал переломные точки в поведении сайта, включая точную дату ребрендинга, которую не пришлось искать в новостях. А единственный пробел, который OSINT принципиально не восстанавливает без первоисточника - мотив («сентиментальная ценность»), закрыли только публичные слова самого Маска. Это иллюстрирует общее правило: технические источники надёжно показывают, что и когда произошло. Зачем - обычно можно узнать, только если кто-то сам об этом сказал.

Как сопоставлять источники и не наврать себе

Главное правило - не делать вывод по одному сигналу. Смена nameservers может значить смену хостинга, а не владельца. Приватная защита WHOIS ничего не доказывает сама по себе. Редизайн сайта в Wayback Machine может быть просто плановым ребрендингом той же команды, а не сменой владельца. Каждая находка - это гипотеза, которую подтверждает только совпадение двух-трёх независимых источников.

Полезная дисциплина - до всяких выводов свести находки в простую хронологию: дата, источник, что именно он показал. Регистрационные события (создание домена, смена регистратора, истечение) - одна ось. Контентные события (смена дизайна, темы, контактов на странице) - другая, и совпадают они далеко не всегда, как в примере с x.com выше. Если нужно установить, кто именно стоит за доменом как юридическое лицо, а не только когда менялась его техническая история, дальше имеет смысл перейти к проверке компании по государственным реестрам и открытым базам: домен и юрлицо - разные объекты проверки, и RDAP не заменяет ни один из корпоративных реестров.

Что реально нельзя узнать легально

Настоящее имя и адрес физического лица за приватной защитой WHOIS не достаются никакими открытыми трюками: RDAP отдаёт «REDACTED FOR PRIVACY», и для гражданского OSINT-расследования это тупик, а не головоломка с решением. Легальные пути только формальные: Registrar Request Service ICANN (посредническая передача запроса регистратору без гарантии ответа), судебный запрос, процедура UDRP при споре о товарном знаке или обращение правоохранительных органов. Все они требуют официального статуса запроса, а не навыка поиска.

Полной истории DNS-записей в прошлом бесплатно нигде не существует: есть только то, что случайно попало в Wayback Machine или CT-логи. Отсутствие капчуры или сертификата не доказывает, что чего-то не было - только то, что это не сохранилось в конкретном источнике на момент проверки.

И последнее: методы этой статьи - про сайты, компании и публичный контент, а не про поиск конкретного человека. Если задача - проверить, не тот же ли продавец скрывается за новым объявлением, для этого есть отдельная методика в гайде про проверку объявлений перед сделкой. А деанонимизация частного лица через доменные записи, которые он сознательно защитил приватностью, - это не то, для чего задуманы инструменты из этой статьи.

Практический чек-лист

1. Запросите RDAP по домену (через rdap.org или RDAP-сервер конкретного реестра) и зафиксируйте дату регистрации, регистратора, статусы и nameservers.
2. Не путайте дату регистрации записи в реестре с датой запуска сайта или сменой владельца: она не сбрасывается при передаче домена.
3. Проверьте, не скрыты ли контактные данные регистранта приватностью, и не считайте это само по себе подозрительным.
4. Поднимите календарь снимков в Wayback Machine, при необходимости точечно через CDX API со схлопыванием по дню.
5. Сравните digest соседних капчур, чтобы отличить реальное изменение страницы от повторного архивирования того же контента.
6. Сверьте текущие nameservers и MX-записи, ищите смену технической инфраструктуры, но не делайте вывод по совпадению IP на общем хостинге.
7. Прогоните домен и маску %.domain через crt.sh или альтернативный CT-поисковик: так находятся забытые поддомены; при ошибке сервиса повторите запрос позже.
8. Сведите все находки в единую хронологию с указанием источника на каждую дату, прежде чем делать вывод.
9. Если нужно установить юридическое лицо за доменом, а не только его техническую историю, переходите к проверке по корпоративным реестрам отдельно.
10. Если ключевые данные закрыты приватностью или недоступны бесплатно, зафиксируйте это как ограничение проверки, а не пытайтесь обойти защиту.