Как узнать IP-адрес домена

Чтобы узнать IP-адрес домена, разрешите его DNS-записи, а не угадывайте по названию хостинга сайта и не копируйте адрес с постороннего сайта. DNS может публиковать A-запись для IPv4 и AAAA-запись для IPv6, и эти ответы независимы. Домен может вернуть один адрес, несколько адресов, только одно семейство адресов или CNAME-псевдоним, ведущий к другому имени хоста. Правильный результат — публичный DNS-ответ, который видел запрошенный вами резолвер в тот момент. Он может представлять CDN или балансировщик нагрузки, и его не следует автоматически называть адресом исходного сервера.

Используйте поиск для точного имени хоста

Начните с выяснения, нужен ли вам корневой домен, например example.com, или поддомен вроде www.example.com. DNS считает их разными именами, поэтому у них могут быть разные конфигурации записей. Используйте инструмент поиска IP по домену, DNS-утилиту вашей операционной системы или запрос из командной строки, чтобы получить данные A и AAAA. Если у вас URL вида https://www.example.com/products, имя хоста — www.example.com; протокол, путь и название страницы в DNS-запрос не входят. Не вводите учётные данные и закрытые URL ни в какие публичные формы поиска.

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

Когда имя разрешается через псевдоним

Запись CNAME говорит, что одно DNS-имя является псевдонимом другого. Первый ответ сам по себе не IP-адрес: резолвер идёт по псевдониму и запрашивает адресные записи цели. Такая косвенность позволяет хостинг-провайдеру управлять меняющейся инфраструктурой за стабильным именем хоста. Это также означает, что на итоговый результат влияет DNS-конфигурация цели CNAME. Проверка, которая показывает только первый псевдоним, может выглядеть так, будто адреса нет, хотя цепочка разрешения в итоге даёт записи A или AAAA. Проходите по цепочке сознательно, а не считайте псевдоним неудавшимся запросом.

• Запрашивайте A и AAAA независимо: одна запись может существовать без другой.
• Записывайте имя хоста-цели, если присутствует CNAME.
• Сравнивайте с авторитативными серверами имён, если есть сомнения в закешированных ответах.
• Не считайте, что DNS указывает прямо на физический сервер или исходный сервер.
• При сбое сервиса проверяйте доступность сети и HTTPS отдельно от DNS.

Используйте адрес с осторожностью

Разрешённый адрес — не постоянный идентификатор. IP-адреса могут переназначаться, anycast-адреса могут вести на разные площадки, а виртуальный хостинг может размещать множество доменов за одним адресом. Точно так же то, что вы видите IP облачного провайдера или CDN, не устанавливает, где работает исходное приложение. Если вы обновляете список разрешённых адресов файрвола или интеграцию, проверяйте документированные диапазоны адресов провайдера и порядок их изменения, а не копируйте разовый результат запроса. Для общей диагностики поиск IP по домену покажет публичные ответы IPv4 и IPv6, а в статье как узнать IP-адрес сайта описаны смежные методы и их ограничения.

Главное — подобрать запрос под вашу цель. Разработчику, отлаживающему новую DNS-запись, нужны точное имя хоста и тип записи. Владельцу сайта, проверяющему миграцию, нужно сравнение до и после и учёт кеширования по TTL. Посетителю, диагностирующему сбой, нужно отличить разрешение имени от связности и ответа приложения. Это связанные, но разные вопросы, и один IP-результат не ответит на все. Считайте DNS одним из уровней на пути от имени к работающему сервису, а затем проверяйте следующий уровень, соответствующий наблюдаемому сбою.

Когда поиска по домену недостаточно

Для некоторых задач нужна информация сверх публичного ответа с адресом. Для изменения файрвола может понадобиться официальный диапазон облачного провайдера, а не один DNS-ответ, потому что провайдер может менять или расширять конечные точки. Для разбора сбоя приложения после успешного разрешения может потребоваться HTTPS-запрос, проверка сертификата или панель хостинга. Обратный запрос иногда возвращает для адреса имя PTR, но им управляет оператор адреса, и оно может отсутствовать или быть обобщённым. Решите, что вам нужно, прежде чем использовать результат: текущее DNS-соответствие, владелец сети, примерное местоположение или фактическое состояние сервиса — для каждого нужен свой источник. Формулируйте выводы узко и указывайте резолвер и время. Это особенно полезно, когда домен использует CDN, поскольку краевой адрес — это публичная точка входа, а не обязательно бэкенд, генерирующий содержимое сайта.