Что такое DNS и как доменные имена превращаются в IP-адреса

DNS (Domain Name System) сопоставляет имена вроде example.com с данными, которые нужны клиенту дальше, чаще всего с IP-адресом. Приложения запрашивают имя, DNS возвращает записи. DNS не веб-сервер, не браузер и не слой шифрования: он только отвечает на запросы.

#Если коротко

Когда вы вводите имя в браузере, операционная система или браузер сначала проверяют собственный кеш. Если подходящего ответа там нет, клиент отправляет запрос рекурсивному резолверу. Такой резолвер часто принадлежит интернет-провайдеру, работодателю или публичному сервису вроде 8.8.8.8.

Резолвер отвечает из кеша, когда может. Если не может, он проходит по иерархии DNS. Он спрашивает у корневого сервера, какие серверы обслуживают домен верхнего уровня (например, .com), затем у этого сервера, какие серверы имён использует домен, и наконец запрашивает запись у одного из этих авторитетных серверов имён. Настоящие данные лежат на авторитетном сервере. Резолвер хранит ответ столько, сколько позволяет TTL записи, и возвращает его клиенту.

В реальном трафике шагов больше: цепочки CNAME, проверка DNSSEC, записи в локальном файле hosts, шифрованные транспорты DNS и несколько уровней кеша. Когда DNS отработал, браузеру ещё нужно открыть соединение, согласовать TLS и дождаться ответа сервера.

#Записи, которые встретятся первыми

#Попробуйте на домене, который можно описывать

Используйте домен, которым владеете или управляете. Если нужна только практика, example.com входит в имена, зарезервированные для документации (RFC 2606). Ограничьтесь именами, которые вам разрешено запрашивать, и не сканируйте хосты, на тестирование которых у вас нет разрешения.

На Linux или macOS с установленным dig:

dig example.com A
dig example.com AAAA
dig example.com MX

На Windows nslookup входит в состав операционной системы:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

Вывод ниже получен на машине с Windows 2026-11-08 через nslookup с резолвером по умолчанию (dns.google, 8.8.8.8). Ответ пришёл от этого резолвера, авторитетный сервер домена его не давал. Машина выводила подписи на португальском, здесь они приведены на английском. Значения отражают один момент и будут другими на вашей машине и при последующих запусках.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

Тот же резолвер вернул запись MX для домена:

example.com	MX preference = 0, mail exchanger = (root)

Почтовый обменник (root) означает, что цель — одна точка. Это null MX, который сообщает отправителям, что домен не принимает почту (RFC 7505).

Наконец, запрос TXT для того же имени:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

Вторая строка — политика SPF. -all означает, что ни один сервер не имеет права отправлять почту от имени этого домена, и это согласуется с null MX выше. Первая строка — непрозрачное значение; подобные строки обычно используют, чтобы доказать сервису владение доменом. Как сказано в таблице, запись TXT показывает, что опубликовал владелец, и больше ничего не доказывает.

Две детали этого запуска. Строка Non-authoritative answer подтверждает, что ответ получен из кеша резолвера или через его запрос, собственный сервер домена его не давал. Адреса IPv6 пришли первыми, но полагаться на порядок нельзя: при следующем запуске они могут идти иначе или адреса окажутся другими.

Чтобы понаблюдать за кешированием, используйте dig. Он печатает число TTL перед каждой записью. Выполните один и тот же запрос дважды в пределах окна TTL. Если резолвер закешировал ответ, второе число будет меньше первого.

#Кеширование и почему ответы меняются

У каждой записи есть TTL, время в секундах, в течение которого резолверы могут хранить ответ. Короткий TTL позволяет владельцу быстро перенести сервис, но к авторитетным серверам приходит больше запросов. Длинный TTL снижает нагрузку, но старые ответы могут ещё какое-то время жить после изменения.

Поэтому отдельный ответ отражает один момент. Во время изменения два резолвера могут расходиться, и оба будут правы для своего кеша. Когда нужно узнать, что опубликовал владелец, спросите авторитетный сервер имён напрямую, например dig example.com A @<nameserver> с сервером из записей NS домена, или пройдите по цепочке через dig +trace example.com A.

#DNS, OSINT и безопасность

Запрос публичных записей DNS домена — обычный первый шаг инвентаризации активов. Компания может проверить свои имена, свои почтовые записи и адреса за ними. Исследователи часто объединяют эти данные с журналами certificate transparency и сведениями о владельцах.

Из ответа DNS не следуют две вещи. Во-первых, запись в результатах поиска не даёт разрешения сканировать хост, на который указывает. Во-вторых, IP-адрес не говорит, кто управляет машиной. Из-за хостинг-провайдеров, CDN и общих серверов один адрес может обслуживать множество не связанных между собой сайтов.

Подозрительная запись тоже не доказывает атаку. Ошибки настройки, истёкшие сервисы и заброшенные имена встречаются часто. Прежде чем делать вывод, проверьте авторитетный ответ, историю изменений и владельца домена. Отравление кеша и спуфинг — отдельные проблемы, и улики для них нужны отдельные.

#Типичные ошибки

• Считать один ответ постоянным. Проверьте TTL и повторите запрос позже.
• Принимать CNAME за IP-адрес. Следуйте по псевдониму, пока не дойдёте до записи A или AAAA.
• Считать использованный резолвер авторитетным сервером. В выводе видно, какой сервер ответил.
• Принимать запись TXT за доказательство того, что мера контроля работает.
• Сканировать хост, потому что на него указал DNS. Запрос и сканирование — разные действия с разными разрешениями.

#Что изучать дальше

DNS — один шаг веб-запроса. Дальше разберитесь, как HTTP и TLS обрабатывают то, что происходит после превращения имени в адрес, по RFC и документации из источников. Затем прочитайте следующую статью этого цикла, об OSINT, прежде чем выполнять какие-либо запросы в ходе разведки. Практикуйтесь только на доменах и системах, которыми владеете или на тестирование которых у вас есть письменное разрешение.