Как узнать, где хостится сайт (и когда это невозможно)

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

В этой статье метод показан по шагам: что каждый шаг на самом деле доказывает и где публичные данные заканчиваются.

Шаг 1. Разрешите домен в IP-адреса

Всё начинается с записей A (IPv4) и AAAA (IPv6).

$ dig +short A www.example.com
192.0.2.10

$ dig +short AAAA www.example.com
2001:db8::10

В Windows ту же информацию даёт nslookup www.example.com.

Две детали легко упустить:

example.com и www.example.com — разные имена. Часто они указывают в одно место, но не всегда. Одно может быть сервисом редиректа, а другое — настоящим сайтом. Проверяйте то имя хоста, на котором посетители в итоге оказываются.
Между ними может быть CNAME. Если www — псевдоним чего-то вроде example.hosting-platform.example.net, целевое имя уже многое говорит. Имена хостов платформ и CDN обычно узнаваемы.

$ dig +short www.example.com
sites.platform.example.net.
192.0.2.10

Шаг 2. Найдите сеть, которой принадлежит IP

IP-адрес входит в блок, а этот блок анонсирует в интернет автономная система (AS): сеть с собственной политикой маршрутизации и номером вроде AS64500. Хостинг-компании, облачные провайдеры, интернет-провайдеры и крупные предприятия — все они управляют автономными системами.

Сопоставление адреса с его AS даёт:

номер и название AS, например «AS64500 EXAMPLE-HOSTING»;
префикс, в котором маршрутизируется адрес, например 192.0.2.0/24;
страну выделения, зафиксированную региональным интернет-регистратором (RIPE NCC, ARIN, APNIC, LACNIC или AFRINIC).

Для сайта на обычном виртуальном хостинге, VPS или облачном инстансе название AS и есть тот ответ, который нужен большинству. Если сеть принадлежит известной хостинг-компании, сервер обслуживает эта компания.

Вот чего это не доказывает:

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

Шаг 3. Прочитайте обратный DNS

Обратный DNS сопоставляет адрес с именем через PTR-запись.

$ dig +short -x 192.0.2.10
srv-10.fra1.hosting.example.net.

PTR-запись контролирует тот, кто владеет блоком IP-адресов, а не владелец сайта. Именно это делает её полезной. Имена по умолчанию у провайдеров часто содержат их собственный домен, код региона или дата-центра (здесь fra1) и идентификатор сервера. Собственная PTR-запись вроде web01.example.com указывает на выделенный сервер или VPS, чей владелец потрудился её настроить.

Оговорки: у многих адресов PTR-записи нет вовсе, а PTR — всего лишь утверждение владельца блока. Если это важно, проверьте, что имя разрешается обратно в тот же адрес. Подробнее в статье обратный DNS и PTR-записи.

Почему CDN и прокси скрывают исходный сервер

Если шаг 2 возвращает Cloudflare, Fastly, Akamai, Amazon CloudFront или похожую сеть, вы нашли границу (edge), а не хостинг.

CDN с обратным прокси работает так: DNS домена указывает на адреса CDN. Посетители подключаются к ближайшей точке CDN. CDN отдаёт кэшированный контент или передаёт запрос исходному серверу (origin), адрес которого известен только CDN и владельцу сайта.

Из этого следует:

IP-адрес, который вы видите, делят очень много не связанных между собой сайтов.
Обычно это anycast: один и тот же адрес анонсируется сразу из многих городов. Вопрос «в какой он стране» не имеет осмысленного ответа.
Исходный сервер может быть где угодно: облачный инстанс, сервер в офисе, другая хостинг-компания.

Это сделано намеренно. Сокрытие исходного сервера — часть того, как эти сервисы защищают сайты от прямых атак. Для сайта за CDN правильный ответ на вопрос «где он хостится?» такой: за этой CDN; исходный сервер публично не наблюдаем.

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

Что добавляют записи NS и MX

Два других типа записей помогают дополнить картину.

NS-серверы (NS) показывают, кто ведёт DNS домена.

$ dig +short NS example.com
ns1.dns-provider.example.net.
ns2.dns-provider.example.net.

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

Почтовые серверы (MX) показывают, где принимается почта. Нередко это отдельный почтовый провайдер, не связанный с веб-хостингом. Если MX указывает на mail.example.com с адресом рядом с веб-сервером, сайт, вероятно, стоит на классическом хостинг-пакете «всё в одном». SPF-запись иногда перечисляет и другие сервисы, через которые владелец отправляет почту.

Ни один из этих признаков не доказательство. Вместе их обычно хватает для разумного вывода вроде «DNS и CDN у одного провайдера, почта у другого, исходный сервер неизвестен». Что означает каждый тип записи, разобрано в статье типы DNS-записей.

Разбор примера

Допустим, вы проверяете shop.example и находите:

www — CNAME на shops.platform.example.net;
адрес разрешается в сеть, названную по имени крупного облачного провайдера;
обратный DNS показывает типовое облачное имя хоста;
NS-записи указывают на регистратора домена;
MX-записи указывают на хостинговый почтовый сервис.

Разумное прочтение: магазин работает на хостинговой платформе электронной коммерции (её выдаёт CNAME), которая сама работает в крупном облаке. Владелец пользуется DNS регистратора и отдельным почтовым провайдером. У вопроса «кто его хостит?» два честных ответа, платформа и облако под ней, и какой из них вам нужен, зависит от того, зачем вы спрашиваете.

Границы и этика

Ограничивайтесь публичными запросами. DNS-запросы, сопоставление IP с ASN и обычный HTTPS-запрос — это то, что и так делает каждый браузер и резолвер. Сканирование портов, перебор поддоменов и поиск исходных серверов — другая деятельность с другим правовым и этическим весом.
Не вычитывайте из данных лишнего. Название сети идентифицирует инфраструктуру, а не человека, который ведёт сайт. Страна выделения — не установление юрисдикции.
Сообщайте о злоупотреблениях по правильному адресу. Контакт abuse сети (указан в записях RIR), форма abuse у CDN и адрес abuse регистратора — каналы, которые куда-то ведут.
Ожидайте перемен. Сайты переезжают. Ответ — это снимок с отметкой времени.

Проверьте в OrbitProbe

Проверка IP и хостинга в OrbitProbe разрешает домен в его IPv4- и IPv6-адреса и показывает для каждого обратный DNS, ASN, название сети, префикс и страну выделения. Адреса из известных диапазонов CDN и прокси помечаются как граничные, чтобы вы не приняли их за исходный сервер. Чтобы увидеть рядом NS-серверы, MX и регистрационные данные, воспользуйтесь полным отчётом о домене.