Укрощаем DNS в Wireshark. Часть 2
В предыдущей статье мы начали рассматривать использование анализатора пакетов Wireshark для работы с DNS. В этой мы продолжим рассмотрение данной темы и поговорим о рекурсии DNS. Здесь принцип обмена пакетами будет немного сложнее, потому что помимо обмена DNS пакетами между клиентом и сервером будет также обмен с авторитетным DNS сервером.
Система разрешения доменных имен имеет иерархическую структуру и все DNS-cepвepы должны быть в состоянии связываться друг с другом, чтобы получать ответы на запросы, отправляемые клиентами. И совершенно очевидно, что локальный DNS сервер не может знать информацию об узлах во всех доменных зонах. Тогда в дело вступает рекурсивный DNS сервер.
Если по-простому
Рекурсивный DNS-сервер расположен между авторитетным DNS-сервером (то есть отвечающим непосредственно за конкретные зоны DNS) и конечными пользователями, которые инициируют запросы DNS. Таким образом, каждый раз, когда пользователь желает посетить определенный веб-сайт и изучить его, он вводит доменное имя, например, в адресную строку браузера. Оттуда рекурсивный DNS-сервер получает запрос и начинает поиск IP-адреса (IPv4 или IPv6), соответствующего доменному имени. Вскоре после того, как требуемый IP-адрес найден, DNS-ответ возвращается на устройство пользователя и предоставляет необходимую информацию. Затем браузер на устройстве пользователя может подключиться и загрузить нужный веб-сайт.
По сути, рекурсивный DNS сервер это как правило, тот самый DNS который мы можем видеть в своих настройках сетевого подключения.
Итак, что же происходит, когда нашему DNS не удалось найти в своем кэше запрашиваемый ресурс?
Когда одному DNS-cepвepy требуется найти IР-адрес, он запрашивает авторитетный DNS-cepвep от имени клиента, делающего первоначальный запрос, действуя, по существу, как клиент. И этот процесс называется рекурсией.
Авторитетный DNS возвращает искомый IP адрес запросившему его серверу, который затем пересылает эти данные клиенту.
Давайте посмотрим дамп трафика, в котором присутствует рекурсивный запрос DNS. На стороне клиента мы увидим всего два пакета.
Первый пакет содержит первоначальный запрос, отправленный DNS-клиентом, находящимся по адресу 172.16.0.8, DNS-cepвepy, расположенному по адресу 172.16.0.102.
Развернув часть данного пакета, относящуюся к протоколу DNS, вы увидите, что это стандартный запрос записи типа А о DNS-имени издательства www.nostarch.com.
Далее, давайте развернем раздел Flags, где указано, что требуется рекурсия.
Для клиента все выглядит аналогично простому DNS запросу — отправили два пакета, в первом мы сделали запрос к DNS серверу и в ответе от сервера мы получили необходимую информацию об IP адресе издательства. Поскольку ошибки отсутствуют, то в конечном итоге клиент получает запись ресурсов типа А, связанную с доменным именем www.nostarch.com.
Но на самом деле процесс разрешения доменного имени был несколько сложнее и ответе на запрос был получен посредством рекурсии. И для того, чтобы в этом убедиться рассмотрим сетевой трафик, перехваченный на локальном DNS-cepвepe, когда был инициирован запрос.
Здесь мы видим уже четыре пакета, из которых первый и последний нам уже знакомы. Первый это запрос от клиента к DNS серверу, а последний это собственно полученный клиентом ответ. После получения первого пакета DNS-cepвep получил запрос, проверил свою локальную базу данных и кэш, и выяснил, что он не знает ответа на запрос, какой именно IР-адрес соответствует DNS-имени www.nostarch.com. Но поскольку исходный пакет был имеет флаг Recursion Desired, то DNS-cepвep обратился к другому DNS-cepвepу с соответствующим запросом, как следует из содержимого второго пакета.
Во втором пакете DNS-cepвep, находящийся по адресу 172.16.0.102, передает новый запрос серверу, расположенному по адресу 4.2.2.10. Первый из них настроен на пересылку запросов, которые он не может разрешить самостоятельно, вышестоящему серверу DNS. Данный запрос зеркально отображает первоначальный запрос, по существу, превращая посылающий его DNS-cepвep в клиента. В то же время можно сказать, что это новый запрос, поскольку идентификационный номер транзакции (Transaction ID) здесь отличается от идентификационного номера в предыдущем файле перехвата.
Как только данный пакет будет принят сервером, находящимся по адресу 4.2.2.1, локальный DNS-cepвep получит от него ответ. Получив этот ответ, локальный DNS-cepвep передаст четвертый пакет DNS-клиенту с запрашиваемой информацией.
В данном примере демонстрируется лишь один уровень рекурсии, но она может происходить неоднократно по единственному DNS-зaпpocy. И хотя здесь получен ответ от DNS-cepвepa, находящегося по адресу 4.2.2.1, этот сервер мог бы рекурсивно переслать запрос еще одному серверу, чтобы найти ответ на запрос. Простой запрос может распространиться по всему миру, прежде чем удастся найти правильный ответ на него.
Для анализа и траблшутинга рекурсивных DNS запросов с помощью Wireshark необходимо перехватывать трафик на стороне DNS сервера, на который клиент изначально отправляет свой запрос.
Заключение
В этой статье мы рассмотрели работу рекурсивных запросов в DNS и анализ таких запросов с помощью Wireshark. Данный инструмент может быть очень полезен при решении проблем с протоколом DNS.
А больше практических инструментов вы может изучить в рамках онлайн-курсов от OTUS. С полным каталогом курсов можно ознакомиться по ссылке.
