Принцип работы dns, основные типы записей и настройка

Ресурсные записи DNS

Современный интернет подразумевает не только получение IP-адреса по доменному имени, но и пересылку электронной почты, подключение дополнительных сервисов аналитики к сайту, настройку защищённого протокола HTTPS. Это чаще всего делается с помощью ресурсных записей DNS.

Рассмотрим, какие ресурсные записи используются, и на что они указывают. Основными ресурсными записями DNS являются:

A-запись — одна из самых важных записей. Именно эта запись указывает на IP-адрес сервера, который привязан к доменному имени.

MX-запись — указывает на сервер, который будет использован при отсылке доменной электронной почты.

NS-запись — указывает на DNS-сервер домена.

CNAME-запись — позволяет одному из поддоменов дублировать DNS-записи своего родителя. Делается это для того, чтобы перенаправить запрос с одного домена на другой (чаще всего для перенаправления домена с поддоменом www на домен без такого поддомена).

TXT-запись — в этой записи хранится текстовая информация о домене. Часто используется для подтверждения прав на владение доменом, посредством добавления определённой строки, которую присылает нам интернет-сервис.

Ресурсные записи почти всегда одинаковые, но для некоторых записей могут появляться другие поля, например в MX-записях также присутствует значение приоритета. В основном ресурсные записи имеют следующую структуру:

Разберём подробнее:

Имя записи — указывается домен, которому принадлежит данная ресурсная запись.

TTL (time to live / время жизни) — время в секундах, на которое будет закешировано значение ресурсной записи. Это необходимо для разгрузки DNS-серверов. Благодаря кешированию и возможна ситуация, что ближайший DNS-сервер знает IP-адрес запрашиваемого домена.

Класс — предполагалось, что DNS может работать не только в сети интернет, поэтому в записи указывается и её класс. На сегодняшний день поддерживается только одно значение — IN (Internet).

Тип — указывает тип ресурсной записи, основные из которых были разобраны выше.

Значение — непосредственно значение ресурсной записи. В зависимости от типа ресурсной записи значения могут быть представлены в разном виде.

Посмотрим, в каком виде эти записи хранятся на DNS-серверах на примере домена ya.ru. Для этого воспользуемся утилитой dig, которая получает все доступные ресурсные DNS-записи от DNS-сервера и выводит их пользователю.

Утилита dig является DNS-клиентом и входит в состав одного из самых распространённых DNS-серверов BIND.

Настройка DNS на маршрутизаторе

Этот пример описывает настройки DNS Relay для межсетевых экранов. Все межсетевые экраны DFL (DFL-210/800/1600/2500) поддерживают эту функцию, начиная с прошивок v2.04 и более поздних.

Примечание: Что касается этой функции, она обеспечивает только передачу/пересылку DNS пакетов, т.к. D-Link DFL межсетевые экраны не имеют встроенного DNS-сервера в ядро операционной системы. Таким образом, они не могут заменить реальный DNS сервер для обеспечения конвертации доменных имен и относительной функциональности.

• LAN IP на межсетевом экране: 192.168.1.1 (с функцией DNS relay)
• Lannet на межсетевом экране: 192.168.1.0/24
• DNS Сервер в Интернет: 12.0.0.1

1. Настройка адресов

Зайдите Objects -> Address book -> Interface Addresses

Создайте IP Address с именем dns_server с адресом 12.0.0.1

2. Создайте IP правила для перенаправления DNS пакетов в Интернет.

Зайдите Rules -> IP Rules

Создайте новое правило IP Rule с действием SAT.

Во вкладке General:

General:

Name: SAT_DNS_Relay Action: SAT Service: dns_all

Address Filter:

Source Interface: lan Source Network: lannet Destination Interface: core Destination Network: lan_ip

Во вкладке SAT:

General:

Translate the: Destination IP Address New IP Address: dns_server

Нажмите Ok.

Создайте аналогичное правило IP Rule с действием NAT. Если среда не NAT, создайте вместо этого правило ALLOW.

Во вкладке General:

Name: Allow_DNS_Relay Action: NAT Service: dns_all

Address Filter:

Source Interface: lan Source Network: lannet Destination Interface: core Destination Network: lan_ip

Нажмите Ok.

Убедитесь, что два этих правила находятся перед другими правилами (т.е. allow_standard правилами).

И также, установите все персональные компьютеры PC, чтобы иметь firewall lan_ip (192.168.1.1) в качестве DNS сервера.

Сохраните и активизируйте конфигурацию межсетевого экрана.

Proxy:

Прокси для пентестера представляет из себя небольшой прокси сервер на python3.

В параметрах нужно указать IP DNS-сервера, порт, куда коннектиться на сервере, опция —clients возвращает список зарегистрированных клиентов, , , — id клиента, с которым мы будем работать (видно после исполнения ), — таймаут для отправки сообщений от приложения.

При запуске с параметром , прокси посылает серверу запрос в формате .
В случае, когда мы начинаем работу, при подключении посылаем сообщение в формате для сброса предыдущего подключения. После мы посылаем информацию о нашей цели:
Далее, при отправке сообщений к клиенту, мы отправляем байты в формате , а приложению пересылаем просто сырые байты.
Также прокси поддерживает режим SOCKS5.

DoH — DNS поверх HTTPS

Wireshark

DNS-фильтрация — это распространенный способ фильтрации веб-трафика для защиты пользователей от фишинговых атак, сайтов, распространяющих вредоносные программы, или другой потенциально опасной интернет-активности в корпоративной сети. Протокол DoH обходит эти фильтры, потенциально подвергая пользователей и сеть более высокому риску.
В текущей модели преобразования имен каждое устройство в сети в той или иной степени получает DNS-запросы из одного и того же места (из указанного DNS-сервера). DoH и, в частности, его реализация от Firefox показывают, что в будущем это может измениться. Каждое приложение на компьютере может получать данные из разных источников DNS, что значительно усложняет поиск и устранение проблем, обеспечение безопасности и моделирование рисков.

www.varonis.com/blog/what-is-powershell

Что это значит

DNS PROBE FINISHED NXDOMAIN — это ошибка вызванная невозможностью системы доменных имён (Domain Name System, DNS) преобразовать URL-адрес сайта в IP-адрес, что не даёт браузеру связаться с ним.

NXDOMAIN в тексте ошибки расшифровывается как Non-Existing Domain и переводится как «несуществующий домен». Перевод всей фразы можно озвучить как «DNS опрос завершён, домен не существует”. Простым языком это означает, что на сервере ДНС отсутствуют данные о домене. Из-за этого сайт, который пытается загрузить пользователь не открывается.

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

Каждый DNS-сервер хранит информацию только по делегированным ему доменам. О других доменах он ничего не знает.

С этой ошибкой сталкиваются как пользователи самого популярного браузера Google Chrome, так и его аналогов на движке Chromium (Microsoft Edge, Yandex Browser и другие). Владельцы Mozilla Firefox и Safari видят ошибку ненамного реже.

Проблема в том, что причина ошибки далеко не всегда зависит от ответа сервера DNS, и может находиться как на стороне сайта, так и на вашем компьютере.

XSS-инжекты через DNS

Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг на угловые <script>):

и там, где веб-приложение показывает эту запись, скрипт выполнится. Разумеется, если не фильтруются спецсимволы в пользовательских данных.

«А что тут такого?» — подумал я. У меня XSS-вектор в домене висит полдесятка лет (еще Agava не может ее нормально пофиксить, алерт вылезает прямо в кабинете), ведь завести подобную запись можно в любой панели управления. А как насчет других записей?

Сказано — сделано. В первую очередь я запилил сервер и завел NS-запись на hack.bo0om.ru, который будет обслуживаться моим сервером. Для упрощения создания конфигурации я воспользовался моим любимым Python-скриптом DNSChef. Это DNS-proxy, который может логировать запросы к нему, а еще и удобненько настраивать.

Вот что отдавал мой DNS-сервер
Другие статьи в выпуске:

Xakep #213. FUCK UAC

Содержание выпуска
Подписка на «Хакер»-60%

Самое смешное, что в самом начале теста я завел запись

(IP-адрес ns.hack нужно получить у домена ns.hack). И попробовал посовать этот домен во всякие формы сайтов. Ну и что ты думаешь?

Часть DNS-клиентов стала рекурсивно запрашивать у меня записи, а когда лог достиг сотни мегабайт, эксперимент пришлось прервать. Технологии используются несколько десятков лет, а поломать все можно логической ловушкой, ну офигеть теперь!

Ну ладно, продолжим. Открываем dnschef.ini, пишем туда следующий конфиг (опять же, не забудь заменить скобки для ):

Звездочка возвращает ответ на любой запрос. В качестве имени параметра я узнаю, какая запись спровоцировала загрузку JS-скрипта с моей стороны, а на hi.bo0om.ru/js выдается скрипт, который делает нужное нам действие. Это может быть классический alert(), но лично я брал текущую ссылку и собирал весь текст страницы, где заинжектился скрипт, и отправлял себе.

Вот тут-то и выяснилось, что большинство интернет-сервисов, которые показывают информацию о записях DNS, вовсе не ожидают, что в качестве NS или того же MX придет атакующий вектор. Фильтрует одно — проверяем другое.

Инжект на Who.isИнжект на DNSqueries.com

Но профита от этого мало, правда? Ради эксперимента я решил попробовать атаковать уже серверную часть. Какие есть пейлоады с выполнением произвольного кода в bash? Я выделил

Также на сервере может быть закрыт доступ на 80/443-й порт, а DNS обычно открыт. Используя все эти трюки, я составил такой RCE-полиглот:

Команда ping выполнится на один из моих доменных имен, но, чтобы узнать, какой IP у домена, он придет ко мне — тут-то я и увижу, что выполнение произвольного кода сработало. Иду в конфиг, делаю так:

Ну и что? А ничего. Посовал на всяких сайтах домен, а отстука о выполнении произвольного кода нет. Не было. Где-то неделю. А потом та-да-ам!

Логи запросов с сервера

Действительно, кто-то собирал соответствие домен — запись и недостаточным образом фильтровал данные от DNS-сервера. Так может, таким образом можно и Shodan хакнуть?

Общие сведения

Named – это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен. Демон named может реализовывать функции серверов любого типа: master, slave, cache. На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND. Бинарник, который выполняет основную работу, расположен в /usr/sbin/named. Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind. В основном конфиге описывается рабочий каталог асервера, зачастую это каталог /var/cache/bind, в котором лежат файлы описания зон и другие служебные файлы. Соответствиеназвания зоны и файла описания зоны задает раздел zone с параметром file. Раздел zoneтак же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).

Эта общая схема работы, которая поможет в дальнейшем не запутаться, при рассмотрении конкретных конфигураций.

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Основные типы DNS записей

Ниже опишу основные типы частоиспользуемых записей DNS. Остальные типы записей можно посмотреть на странице в Википедии. В примерах буду использовать упрощенную запись поля хоста.

Важно: если для поддомена создана отдельная зона DNS, то записи для этого поддомена в зоне основного домена будут проигнорированы

NS-запись

NS-запись (Authoritative name server) необходима для указания DNS-сервера / DNS-серверов, которые будут отвечать за доменную зону (делегирование домена). Именно эта запись необходима для функционирования механизма DNS. Обычно у регистраторов и хостингов она находится отдельно от остальных записей домена.

Чаще всего хостинги и DNS-провайдеры предоставляется несколько равнозначных серверов DNS-серверов, чтобы записи были актуальны при выходе из строя одного из них. Желательно прописать их все.

A-запись

A-запись (Address) необходима, чтобы прописать IP адрес сервера, к которому нужно привязать домен или поддомен.

Пример 1:

У нас есть домен и место на хостинге с IP адресом . Нам нужно привязать наш домен к этому IP адресу. Для этого в зоне DNS домена добавляем запись с таким содержимым:

хост — ;
тип записи — ;
значение записи — .

Пример 2:

У нас есть домен , поддомен и место на хостинге с IP адресом . Нам нужно привязать поддомен к этому IP адресу. Для этого в зоне DNS домена добавляем запись с таким содержимым:

хост — ;
тип записи — ;
значение записи — .

Пример 3:

У нас есть домен , поддомены , , , место на хостинге с IP адресом и место на на другом хостинге с другим IP адресом для третьего поддомена. Нам нужно привязать первые два поддомена к первому IP адресу, а третий поддомен ко второму IP адресу. При этом планируется добавление дополнительных поддоменов и привязка их к первому IP адресу, но добавлять каждый поддомен в DNS не хочется. Для этого в зоне DNS домена прописываем 2 записи:

хост — ;
тип записи — ;
значение записи — .

хост — ;
тип записи — ;
значение записи — .

MX-запись

MX-запись (Mail Exchanger) необходима для указания адреса почтового сервера, который обслуживает доменую почту. Сервер-отправитель обращается к этой записи для получения адреса почтового сервера, куда нужно направить почту.

Запись состоит из двух частей:

адрес почтового сервера;
приоритет (MX preference). Чем меньше число, тем запись выше в приоритете. Если указана только одна запись, то любое произвольное число (по-умолчанию — ).

Пример:

Нам нужно, чтобы доменной почтой основного домена управлял почтовый сервер . Добавляем следующую запись в зону нашего домена:

хост — ;
тип записи — ;
значение записи — ;
приоритет — .

Подобных записей может быть несколько, если домен обслуживают несколько почтовых серверов. В этом случае отправляющий сервер устанавливает SMTP соединение с указанными почтовыми серверами в порядке указанного приоритета, пока успешно не отправит почту. Если у нескольких записей будет одинаковый приоритет, то будет производится соединение сразу со всеми.

TXT-запись

TXT-запись (Text string) — это универсальная запись для указания различной текстовой информации, для которых нет отдельных типов DNS записей. Например, SPF, DKIM, подтверждение владением домена на различных ресурсах и т.д.

Подробнее о настройке текстовых записей SPF, DKIM, DMARC, ADSP можно прочитать в соседней статье.

CNAME-запись

CNAME-запись (Canonical name) позволяет сделать для поддомена ссылку на любой другой домен. Запись полезна, когда Вы хотите, чтобы для определенного поддомена были актуальны все записи от основного, либо чтобы при переходе на поддомен отображалось содержимое другого ресурса (например, интерфейс стороннего почтового сервиса на поддомене Вашего домена).

Важно: в значении записи точка на конце адреса обязательна, но некоторые панели ставят ее автоматически. Пример 1:

Пример 1:

У нас есть основной домен и поддомен . Нам необходимо, чтобы все записи основного домена были актуальны для поддомена. Создаем запись в зоне домена со следующими параметрами:

хост — ;
тип записи — ;
значение записи — (точка на конце обязательна).

Пример 2:

У нас есть домен . Нам необходимо на поддомене открывать веб-интерфейс почтового сервиса нашей доменной почты . Создаем запись в зоне домена со следующими параметрами:

хост — ;
тип записи — ;
значение записи — (точка на конце обязательна).

Важно: если для поддомена задана CNAME запись, то больше никаких записей не должно быть для этого поддомена

PTR-запись

PTR-запись (pointer) предназначена для обратного преобразования IP в доменное имя. Сама запись прописывается не в DNS домена, а на той стороне, кто выдает Вам IP адрес (хостинг). Подробнее о записи и ее настройке можно почитать в этом посте.

Делегирование домена

Делегирование домена — это передача прав на управление записями домена (доменной зоной).

Делегирование домена доступно сразу после покупки домена у регистратора. Большинство регистраторов помимо делегирования поддерживают управление DNS записями домена. Часть из них предоставляют это как отдельную услугу, а некоторые предоставляют это только при использовании их услуг, например, хостинга. Изначально домен делегирован на DNS-сервера регистратора и припаркован к их стандартной странице.

Также поддерживается переделегирование домена между разными DNS-серверами хостингов и DNS-провайдеров, но управлять записями будет именно тот DNS-сервер, который находится в конце этой цепочки, и редактировать записи нужно именно там. Записи в других DNS-серверах будут неактуальны.

Как делегировать домен

Рассмотрим простой пример. Вы купили домен, но хотите управлять записями домена на хостинге hosting.com. Для этого необходимо узнать у хостинга адреса их DNS-серверов. Обычно эти адреса указаны в панели хостинга или в документации хостинга. К примеру, адреса могут быть такими:

Идем в панель регистратора, ищем соответствующий раздел (обычно называется «DNS-сервера», «NS-сервера», делегирование и т.д.) и прописываем в полях все предоставленные адреса (необходимо указывать адреса с точкой на конце).

Куда лучше делегировать домен

Часто слышу этот вопрос, но четкого ответа на него нет. Все зависит от Ваших предпочтений, удобства панелей, функционала редактора DNS записей, количества регистраторов и хостингов. Если у Вас хостинг является и регистратором, то ответ очевиден. Никуда делегировать не нужно. Если же у Вас много хостингов и доменов, зарегистрированных у разных регистраторов, то логичнее их все делегировать в одно место, чтобы не запутаться и чтобы было удобнее управлять ими и редактировать в одном месте (например, Яндекс.Коннект).

В общем, делегируйте туда, где Вам удобнее управлять DNS записями, но не забывайте, что излишнее переделегирование может потом встать боком, если какое-то звено из этой цепочки выпадет, а информация о домене уйдет в никуда. Часто встречался с таким, что домен изначально был делегирован на один хостинг. Затем сайт переехал на другой. При этом делегирование было сделано со старого хостинга на новый. При истечении баланса на старом хостинге или при закрытии учетки услуга управления DNS закрывалась, а все DNS записи удалялись, в том числе и NS, где были прописаны NS записи нового хостинга. Результат — простой сайта, поиск причины и ожидание смены DNS. А еще будет печальнее, если домен был куплен лет на 10, потеряли все доступы, забыли, кто регистратор, и регистратор еще реселлер другого реселлера.

Проверка проблем рекурсии

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

Время ожидания запроса истекает до того, как запрос будет выполнен.
Сервер, используемый во время запроса, не отвечает.
Сервер, используемый во время запроса, предоставляет неверные данные.

Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы другому серверу, проверив вкладку Серверы пересылки в свойствах сервера в консоли DNS. Если установлен флажок Включить серверы пересылки и указан один или несколько серверов, этот сервер перенаправит запросы.

Если этот сервер перенаправит запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который этот сервер пересылает запросы. Сведения о том, как проверить наличие проблем, см. в разделе . Если в этом разделе показано, как выполнить задачу на клиенте, выполните ее на сервере.

Если сервер работоспособен и может пересылать запросы, повторите этот шаг и проверьте сервер, на который этот сервер пересылает запросы.

Если этот сервер не перенаправит запросы другому серверу, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:

Если сопоставитель возвращает IP-адрес корневого сервера, вероятно, у вас неработает делегирование между корневым сервером и именем или IP-адресом, которые вы пытаетесь разрешить. Выполните процедуру , чтобы определить, где неработает делегирование.
Если сопоставитель возвращает ответ «Истекло время ожидания запроса к серверу», проверьте, указывают ли корневые указания на функционируют корневые серверы. Для этого используйте процедуру . Если корневые указания указывают на работающие корневые серверы, может возникнуть проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет сопоставителям запрашивать сервер, как описано в разделе . Также возможно, что рекурсивное время ожидания по умолчанию слишком короткое.

Тестирование неработаемого делегирования

Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Тест позволит выполнить запрос ко всем DNS-серверам от корневого до сервера, на который вы тестируете неработающее делегирование.

В командной строке на тестируемом сервере введите следующее:

Примечание

Тип записи ресурса — это тип записи ресурса, которую вы запрашивали в исходном запросе, а полное доменное имя — это полное доменное имя, для которого вы запрашивали (завершается точкой).
Если ответ содержит список записей ресурсов «NS» и «A» для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов «A» в качестве IP-адреса сервера.
- Если ответ не содержит записи ресурса «NS», делегирование нарушено.
- Если ответ содержит записи ресурсов «NS», но нет записей ресурсов «A», введите set recursion и запросите по отдельности записи ресурсов «A» серверов, перечисленных в записях «NS». Если вы не нашли хотя бы один допустимый IP-адрес записи ресурса «A» для каждой записи ресурса NS в зоне, делегирование будет нарушено.
Если вы определили, что делегирование нарушено, исправьте его, добавив или обновив запись ресурса «A» в родительской зоне, используя допустимый IP-адрес для правильного DNS-сервера для делегированной зоны.

Просмотр текущих корневых подсказок

Запустите консоль DNS.
Добавьте DNS-сервер, на который не удалось выполнить рекурсивный запрос, или подключитесь к нему.
Щелкните правой кнопкой мыши сервер и выберите Свойства.
Щелкните Корневые подсказки.

Проверьте базовое подключение к корневым серверам.

Если корневые указания настроены правильно, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибкой, может проверить связь между корневыми серверами по IP-адресу.
Если корневые серверы не отвечают на связь по IP-адресу, ВОЗМОЖНО, IP-адреса корневых серверов изменились. Однако нечасто можно увидеть перенастройку корневых серверов.

Настройка DNS на компьютере

1 Нажмите правой кнопкой мыши по значку сети в панели задач.

2 Выберите Центр управления сетями и общим доступом:

3 Нажмите на ссылку, соответствующую нужному сетевому подключению:

4 Нажмите кнопку Свойства:

5 Найдите в списке пункт Протокол Интернета версии 4 (TCP/IPv4) и выделите его левой кнопкой мыши.

6 Нажмите кнопку Свойства:

7 Установите переключатель в положение Получить адрес DNS-сервера автоматически если в вашей сети работает DHCP-сервер.

В противном случае, установите переключатель в положение Использовать следующие адреса DNS-серверов и укажите адреса серверов.

8 Нажмите OK:

9 Нажмите кнопку Закрыть в окне Ethernet:Свойства для применения настроек:

10 Нажмите кнопку Закрыть в окне Состояние — Ethernet:

Что такое обратный DNS (rDNS)?

Мы все знаем, что такое DNS и как он работает. Но даже некоторые IT-ботаники иногда забывают о rDNS, а третьи, которые только что присоединились к клубу, никогда даже не слышали о нем.

На простом языке обратный DNS или rDNS делает противоположное традиционному DNS. То есть, вместо преобразования доменного имени на IP, он преобразует IP к имени хоста.

Разрешение rDNS – это совершенно отдельный механизм от обычного разрешения DNS. Например, если домен “yourcompany.com” указывает на IP 1.2.3.4 (фиктивный IP-адрес), это не обязательно означает, что обратное разрешение для IP является 1.2.3.4.

Для хранения записей rDNS существует определенный тип записи DNS, называемый записью PTR. Эта запись также известна как ”запись ресурсов” (RR) и задает IP-адреса всех систем, используя инвертированную нотацию.

Эта конфигурация rDNS позволяет выполнять поиск IP-адреса в DNS, так как inaddr.arpa домен добавляется в инвертированную нотацию IP, превращая IP в доменное имя.

Например: чтобы преобразовать IP-адрес 1.2.3.4 в PTR-запись, нам нужно инвертировать IP и добавить домен inaddr.arpa в результате чего получается следующая запись: 4.3.2.1.in-addr.arpa.

Классическая работа системы DNS заключается в преобразовании или разрешении IP-адресов в имена, но некоторые сценарии требуют обратного, и это означает, что имена подключенных к интернету устройств переводятся с их IP-адресов. Это то, что называется rDNS, или обратное разрешение.

Поддерживают ли все типы IP-адресов rDNS? Безусловно, и IPv4 и IPv6 поддерживают поиск rDNS. В случае адресов на основе IPv4 поисковые запросы используют специальный домен in-addr.arpa, в то время как для IPv6 rDNS поиск специального домена ip6.arpa используется.

Powershell клиент:

Так как нам была нужна полная интерпретируемость и работа на большинстве актуальных систем, основу клиента для Windows составляют стандартная утилита nslookup для связи через DNS и объект System.Net.Sockets.TcpClient для установления соединения во внутренней сети.

Работает все также очень просто. Каждая итерация цикла представляет собой вызов команды nslookup по протоколу, описанному ранее.

Например, для регистрации выполняем команду:
Если возникают ошибки, то мы их не показываем, отправляя в $null значения дескриптора ошибок.

nslookup возвращает нам подобный ответ:

После чего нам нужно вытянуть все строчки в кавычках, для чего проходимся по ним регуляркой:

Теперь можно выполнять обработку полученных команд.
Каждый раз, когда меняется IP-адрес “жертвы”, выполняется создание TCP-клиента, устанавливается соединение и начинает выполняться передача данных. От DNS сервера информация base64-декодируется, и байты отправляются на жертву. Если “жертва” что-то ответила, то кодируем, делим на части и выполняем запросы nslookup согласно протоколу. Всё.
При нажатии Ctrl+C выполняется запрос на удаление клиента.

Создание файла зоны DNS

Дальнейшие примеры будут для Ubuntu/Debian, но также подходят и для Centos/RedHat, только директория с настройками зон в CentOS будет находиться в , а основной файл конфигурации . Для начала нам потребуется создать новый файл зоны для домена itproffi.ru. Перейдите в директорию . создайте в ней поддиректорию и перейдите в нее, выполнив следующую последовательность команд:

cd /etc/bind
mkdir -p zones/master
cd zones/master/

Директория будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:

;
; Файл данных BIND для itproffi.ru
;
$TTL 3h
@ IN SOA ns1.itproffi.ru. admin.itproffi.ru. (
1 ; серийный номер
3h ; обновление каждые 3 часа
1h ; повторная попытка через час
1w ; срок годности – 1 неделя
1h ) ; хранение кэша отказов 1 час;
@ IN NS ns1.itproffi.ru.
@ IN NS ns2.itproffi.ru.

itproffi.ru. IN MX 10 mail.itproffi.ru.
itproffi.ru. IN A 172.31.1.10
ns1 IN A 172.31.1.10
ns2 IN A 172.31.1.11
www IN CNAME itproffi.ru.
mail IN A 172.31.1.10
ftp IN CNAME itproffi.ru.

Рассмотрим ключевые строки этого файла:

Запись SOA: авторитативный сервер имен для itproffi.ru – это ns1.itproffi.ru, адрес ответственного за зону DNS администратора – admin@itproffi.ru
Записи NS: два сервера имен для зоны itproffi.ru – ns.itproffi.ru
Запись MX: почтовый сервер для itproffi.ru. Число 10 означает уровень приоритета
Записи A: A означает «адрес» (address). Другими словами, ns1 в зоне itproffi.ru будет иметь адрес 172.31.1.10
Запись CNAME (Canonical Name – каноническое имя): привязывает одно доменное имя к другому (каноническому), например, устанавливает соответствие mail.itproffi.ru и itproffi.ru.

Итог:

Давайте подведем небольшой итог. Какие особенности у данной разработки и почему мы советуем использовать ее?

Интерпретируемые клиенты на Bash и Powershell: никаких EXE-шников и ELF-ов, которые бывает проблематично запустить.
Стабильность соединения: в тестах наша утилита вела себя гораздо стабильнее, а если и случались какие-то баги, то можно было просто переподключиться, при этом клиент не падал, как в случае с dnscat2, например.
Достаточно высокая скорость для DNS-туннеля: конечно, скорость не дотягивает до iodine, но там гораздо более низкоуровневое компилируемое решение.
Не требуется прав администратора: клиент Bash работает без прав администратора железно, а Powershell-скрипты иногда запрещены политиками безопасности, но это довольно просто обходится.
Есть режим socks5 прокси, что позволяет делать так или запускать nmap на всей внутренней сети.