На этом занятии вы разберёте, как именно DNS работает в рекурсивном и итеративном режимах, как читать DNS-трафик в Wireshark и чем отличаются утилиты nslookup, host и dig. Мы свяжем логику дерева доменных имён, флаги заголовка DNS и реальные пакеты на проводе.
Практика построена как лабораторная работа: вы по шагам выполните запросы к DNS-серверам, посмотрите ответы
разных типов, научитесь читать секции Question, Answer, Authority,
Additional и потренируетесь находить ключевые поля в захвате трафика. В Wireshark эти секции
видны в среднем окне при раскрытии дерева Domain Name System (query) или
Domain Name System (response), а в dig - в блоках QUESTION SECTION,
ANSWER SECTION, AUTHORITY SECTION, ADDITIONAL SECTION. Файл для сдачи
не нужен - важны выполненные действия и самопроверка.
DNS - это не только база имён и адресов, но и механизм поиска ответа. Один и тот же доменный запрос можно обработать по-разному: либо ближайший резолвер сам пройдёт по дереву DNS и вернёт готовый результат, либо клиенту будут последовательно отдавать адреса следующих серверов, которые знают больше о нужной зоне.
Поэтому в этой теме важно понять не только термины, но и цепочку действий: кто к кому обращается, какие флаги стоят в заголовке, почему появляются авторитетные и неавторитетные ответы, зачем сервер присылает дополнительные записи и как всё это увидеть в Wireshark и утилитах командной строки.
В рекурсивном режиме клиент не хочет сам искать ответ по дереву DNS. Он отправляет запрос
резолверу и просит: «Найди всё сам и верни итог». В заголовке DNS для этого обычно устанавливается флаг
RD (Recursion Desired) - клиент просит выполнить запрос рекурсивно. На практике этот
флаг обычно ставится автоматически, когда вы отправляете обычный запрос через системный резолвер,
nslookup или dig. В dig этим поведением можно управлять явно:
dig example.com +recurse - запрос с рекурсией, dig example.com +norecurse - без
рекурсии.
Резолвер проверяет собственный кэш. Если ответа нет, он обращается к корневым серверам, затем к серверам домена верхнего уровня, затем к авторитетным серверам нужной зоны. После этого он возвращает клиенту IP-адрес или другую запись DNS и обычно кладёт результат в кэш на время TTL.
В итеративном режиме сервер не ищет ответ до конца, если сам не отвечает за нужную зону. Вместо итогового результата он присылает клиенту referral - подсказку, к какому серверу обратиться дальше. То есть клиент получает не сам IP, а адрес следующего DNS-сервера, который знает больше о нужной части дерева.
Такой режим хорошо показывает внутреннюю логику DNS. Например, сначала можно спросить корневой сервер, затем
сервер зоны .ru или .com, потом сервер конкретного домена, и только затем получить
нужную запись типа A (Address), AAAA (IPv6 Address), MX (Mail Exchange), NS
(Name Server) или PTR (Pointer).
Рекурсивный режим удобен клиентам: приложение получает готовый ответ одной командой. Итеративный режим удобен для самой инфраструктуры DNS: он разгружает корневые и промежуточные серверы, потому что они не обязаны выполнять полный поиск за каждого клиента мира.
Именно поэтому корневые и многие авторитетные серверы отвечают итеративно: они дают информацию только о своей зоне и не берут на себя роль рекурсивного резолвера. Это повышает масштабируемость и устойчивость системы.
Когда авторитетный сервер не может или не должен выполнять рекурсию, он часто присылает записи NS в секции Authority. Они показывают, какие серверы обслуживают более точную зону. Чтобы клиенту не пришлось делать ещё один лишний запрос только ради IP этих NS-серверов, в секции Additional могут сразу прийти их A и AAAA записи.
Это очень важный момент при анализе DNS. В ответе может не быть IP нужного сайта, но при этом пакет всё равно полезен: он подсказывает следующий шаг и даёт адреса серверов, к которым нужно обратиться дальше.
При анализе режимов особенно важны флаги RD (Recursion Desired), RA (Recursion Available) и AA (Authoritative Answer). RD показывает, что клиент просит выполнить рекурсию. RA в ответе говорит, что сервер умеет работать как рекурсивный резолвер. AA показывает, что ответ пришёл от авторитетного сервера именно этой зоны.
Если вы обращаетесь к локальному DNS-серверу провайдера, то часто увидите RD=1 и RA=1, но AA=0, потому что сервер отвечает из кэша или сам получил ответ от других серверов. Если обратиться прямо к авторитетному серверу зоны, можно получить AA=1 и отсутствие полноценной рекурсии.
Чтобы анализировать DNS в Wireshark, достаточно запустить захват и применить фильтр dns. После
этого в списке останутся только DNS-запросы и ответы. Это удобно, потому что в фоне система сама генерирует
много служебных запросов, и без фильтра найти нужный пакет сложно.
В Wireshark полезно смотреть сразу в три области: список пакетов, расшифровку полей в среднем окне и байтовое представление справа. Так проще связать понятия из теории с тем, как DNS выглядит на проводе: бинарный заголовок, секции пакета, транспорт UDP или TCP, адрес отправителя и адрес получателя.
В запросе DNS обычно видно имя, тип записи и класс. Например, запрос на hub.com с типом
A означает: «Найди IPv4-адрес этого домена». В заголовке можно увидеть идентификатор транзакции,
по которому потом связывают запрос и ответ, а также флаг RD (Recursion Desired),
если клиент хочет рекурсивный ответ.
На транспортном уровне чаще всего используется UDP с портом назначения 53. Порт источника выбирается операционной системой автоматически. В IP-заголовке видно адрес клиента и адрес DNS-сервера, к которому отправлен запрос.
В ответе снова присутствует тот же идентификатор транзакции, что и в запросе. Это позволяет клиенту и
анализатору понять, какой ответ относится к какому запросу. В заголовке уже меняется флаг QR
(Query/Response) - теперь это ответ, а не запрос. Далее смотрят на количество записей в секциях
Answer, Authority и Additional. В Wireshark они находятся внутри
раскрытого дерева Domain Name System (response): обычно это блоки Answers,
Authoritative nameservers и Additional records.
Если ответ пришёл от рекурсивного резолвера из кэша, он может быть неавторитетным. Если ответ получен напрямую от сервера, который обслуживает нужную зону, вы увидите AA=1. Кроме того, в ответе часто присутствует TTL - время, на которое эту запись можно сохранить в кэше.
Для одного доменного имени может существовать несколько A или AAAA записей. Тогда в ответе Wireshark покажет несколько элементов в секции Answer, а в заголовке поле ANCOUNT будет больше единицы. Это типично для балансировки нагрузки и отказоустойчивости: клиентов можно распределять между несколькими серверами, снижать нагрузку на один узел и сохранять доступность сервиса, если один из серверов временно недоступен.
Например, при запросе www.yandex.ru можно увидеть сразу несколько IPv4-адресов и отдельный ответ
для IPv6. С точки зрения клиента это означает, что у домена несколько точек входа, и приложение может выбрать
любой из предложенных адресов.
Запись типа A отвечает за IPv4, а запись типа AAAA - за IPv6. В Wireshark это удобно сравнивать: имя домена одно и то же, а тип записи другой. Так видно, что система DNS может хранить разные представления одного и того же ресурса для разных версий IP.
При анализе важно не перепутать: если вы запрашиваете A, в ответе не обязательно придёт AAAA, и наоборот. Иногда приложение делает несколько запросов подряд: сначала A, потом AAAA. Поэтому в захвате по одному домену может появиться сразу несколько очень похожих пакетов.
CNAME (Canonical Name) показывает псевдоним доменного имени. MX
(Mail Exchange) указывает почтовые серверы и их приоритет. NS (Name Server)
показывает серверы имён, которые обслуживают зону. PTR (Pointer) используется для
обратного разрешения: по IP-адресу получить доменное имя через зону in-addr.arpa.
В Wireshark эти записи выглядят очень наглядно. Для MX видно числовой приоритет, для NS - имена серверов, а для PTR - доменное имя, соответствующее IP. Именно поэтому захват DNS полезен не только для сетевого анализа, но и для понимания реальной конфигурации домена.
При запросе, например, NS-записей для зоны сервер может сразу приложить в Additional IP-адреса этих NS-серверов. NS-записи вообще нужны затем, чтобы DNS понимал, какие серверы отвечают за конкретную зону и куда нужно идти за авторитетным ответом. Это основа делегирования: без NS нельзя передать обслуживание зоны другим серверам. Секция Additional полезна тем, что сразу даёт IP-адреса этих серверов и экономит один или несколько следующих запросов. Такая информация называется glue или приклеенные записи, если речь идёт о делегировании зоны в родительской зоне.
Для администратора это очень удобно: в выводе dig и в Wireshark сразу видно, и кто обслуживает
зону, и как к этим серверам подключиться по IP. Для анализа отказов это тоже важно - можно быстро проверить,
нет ли несоответствия между NS и их адресами.
nslookup удобна как базовый инструмент и доступна в Windows по умолчанию. host даёт короткий и лаконичный вывод: полезно, если нужно быстро получить адрес или проверить тип записи без лишних деталей. dig показывает гораздо больше информации и поэтому особенно полезна для диагностики и администрирования.
С точки зрения обучения все три утилиты полезны. nslookup помогает освоить общую логику DNS. host показывает, как компактно выглядят результаты запросов. dig почти повторяет внутреннюю структуру DNS-пакета и позволяет видеть секции, TTL, сервер-источник ответа и тип транспорта.
Команда host особенно хороша, когда нужен лаконичный ответ. Она может сразу показать IP-адрес домена, MX-записи, NS-записи или CNAME без длинных пояснений. Это удобно для быстрых проверок и для сценариев, где вывод потом нужно автоматически обработать.
Например, host hub.com выводит адрес и иногда дополнительные важные сведения, а
host -t NS example.com быстро показывает серверы имён. При этом host обычно не рассказывает
столько диагностических деталей, сколько dig, и в этом как раз её плюс.
Команда dig - это почти стандартный инструмент администратора для диагностики DNS. В ответе
она показывает заголовок, флаги, секции QUESTION, ANSWER, AUTHORITY,
ADDITIONAL, время запроса, адрес сервера, от которого пришёл ответ, и используемый транспорт.
Особенно ценен dig при поиске проблем: можно быстро понять, пришёл ли авторитетный ответ, сколько там записей, какие NS-серверы обслуживают зону и были ли приложены дополнительные записи. Поэтому dig часто используется вместе с Wireshark: одна утилита даёт удобный текстовый срез, другая - сам сетевой пакет.
У dig есть удобные режимы. Ключ +short оставляет только полезный краткий результат - удобно для
скриптов. Ключ -t позволяет явно указать тип записи: A, AAAA,
NS, MX, PTR и другие. Можно быстро переключаться между разными
запросами для одного домена.
Например, dig -t NS yandex.ru покажет серверы зоны, а dig +short example.com
выведет только адреса. Если нужен обратный запрос, используют PTR и адрес в специальной форме, либо удобный
ключ -x в некоторых реализациях dig.
Самый полезный учебный приём - сделать один и тот же запрос сразу несколькими способами. Например, сначала
выполнить nslookup example.com, затем dig example.com, а потом посмотреть эту же
транзакцию в Wireshark. Так вы увидите, как один и тот же ответ представляется в разных интерфейсах.
После нескольких таких сравнений становится заметно, что DNS - очень строго структурированный протокол. Одни и те же поля повторяются в разных инструментах: имя, тип записи, TTL, адрес сервера, флаги. Это резко упрощает диагностику и снижает страх перед сетевым анализом.
Анализ DNS нужен не только сетевым инженерам. С ним регулярно сталкиваются администраторы, DevOps-инженеры, разработчики, специалисты по информационной безопасности и техническая поддержка. Типовые задачи: сайт не открывается по имени, почта не доходит, поменяли IP сервера и забыли обновить TTL, публичный домен резолвится по-разному у разных клиентов.
Если вы умеете читать DNS-ответы и понимаете различие между рекурсией и итерацией, то можете намного быстрее локализовать проблему: в приложении ли ошибка, в локальном кэше, у провайдера, в делегировании зоны или на авторитетном сервере.
Перед интерактивами запомните четыре идеи. Первое: рекурсивный резолвер сам ищет ответ по дереву DNS. Второе: авторитетные серверы часто отвечают итеративно и присылают referrals. Третье: Wireshark позволяет увидеть секции пакета и флаги, а dig показывает похожую структуру в текстовом виде. Четвёртое: записи Additional - это дополнительные записи, которые сервер прикладывает к ответу, чаще всего чтобы сразу дать полезные адреса и не заставлять клиента делать лишний запрос.
Сейчас вы закрепите материал короткими заданиями, затем пройдёте тест допуска и выполните 20 пошаговых действий за компьютером: от обычных запросов до анализа DNS в Wireshark и сравнения вывода host и dig.
Выберите верные утверждения.
Какой флаг в DNS-ответе означает, что сервер является авторитетным для зоны?
Выберите корректные элементы, которые реально видны при анализе DNS-пакета.
Для доступа к практике нужно набрать не менее 80% - минимум 7 правильных ответов из 8.
1. В рекурсивном режиме ответ ищет:
2. В итеративном режиме сервер может вернуть:
3. Какой фильтр чаще всего применяют в Wireshark для DNS?
4. Какая утилита обычно даёт самый подробный текстовый вывод?
5. Флаг AA означает:
6. Где часто видны адреса NS-серверов как дополнительная информация?
7. PTR используется для:
8. Ключ dig +short нужен для:
В этой части вы выполните 20 экранов с пошаговыми действиями за компьютером. Основная цель - своими руками увидеть разницу между рекурсией и итерацией, научиться читать секции ответа и сравнить вывод Wireshark, nslookup, host и dig.
nslookup example.com или
nslookup habr.com.Посмотрите, какой DNS-сервер указан в выводе, и запишите IP-адрес домена из ответа.
dns.nslookup example.com или
nslookup habr.com. Вернитесь в Wireshark и найдите пару пакетов: запрос и ответ.Domain Name System (query). Найдите Transaction ID, Flags, Queries, Name, Type и Class.Дополнительно посмотрите поля QR, RA, AA и количество записей в секциях ответа.
Answers и
найдите поле TTL. Сравните его с тем, что ожидали бы от кэшируемой записи.nslookup -type=AAAA example.com или любой домен, у которого есть IPv6.Сравните новый запрос с предыдущим: имя домена может быть тем же, но тип записи изменится на AAAA.
nslookup -type=NS yandex.ru
или nslookup -type=NS example.com.Посмотрите, какие серверы имён обслуживают зону. Если анализируете захват, проверьте, нет ли в ответе секции Additional с их адресами.
nslookup -type=MX gmail.com.
Обратите внимание на приоритеты почтовых серверов. Чем меньше число, тем выше приоритет.
host example.com и затем host -t NS yandex.ru.Сравните вывод host с nslookup: host короче и показывает только самую полезную информацию.
dig example.com или dig habr.com.Найдите в выводе секции QUESTION SECTION, ANSWER SECTION и строку с адресом
DNS-сервера, который ответил.
dig +short example.com.Убедитесь, что теперь вывод содержит только краткий результат - обычно один или несколько адресов без служебных секций.
dig -x 8.8.8.8 или
другой адрес.Найдите запись PTR и имя, которое соответствует этому адресу.
Ответьте себе на вопросы:
Если вы можете осмысленно ответить на эти вопросы, значит вы действительно разобрались в теме режимов работы DNS и анализе пакетов.