Dns форвардинг что это
Обновлено: 04.07.2024
Этичный хакинг и тестирование на проникновение, информационная безопасность
Введение
DNS, или Система доменных имён, является неотъемлемой частью того, как системы соединяются друг с другом для общения в Интернете. Без DNS компьютеры и люди, которые их используют, должны были бы соединяться, используя только числовые адреса, известные как IP-адреса.
Помимо очевидной проблемы запоминания большого количества сложных чисел для простых задач, связь через IP-адреса также вызывает некоторые дополнительные проблемы. Перемещение вашего сайта на другого хостинг-провайдера или перемещение ваших серверов в разные места потребует от вас информирования каждого клиента о новом местоположении.
DNS-серверы (компьютеры, которые вместе образуют систему, позволяющую нам использовать имена вместо IP адресов), могут обслуживать множество различных функций, каждая из которых может способствовать вашей возможности доступа к серверам по имени.
В предыдущем руководстве мы обсудили некоторые основные термины и понятия системы доменных имён. Предполагается, что вы прочитали предыдущую статью. В этом руководстве мы поговорим о некоторых типах настроек DNS-сервера и о преимуществах, вариантах использования и свойствах каждого из них.
Путь DNS-запроса
Когда клиентская программа хочет получить доступ к серверу по его доменному имени, она должна выяснить, как преобразовать доменное имя в фактический маршрутизируемый адрес, который она может использовать для связи. Необходимо знать эту информацию, чтобы отправлять информацию на сервер и получать от него ответ.
Некоторые приложения, в том числе большинство веб-браузеров, поддерживают внутренний кеш последних запросов. Если в нём есть такая функциональность, то это первое место, где приложение попытается найти IP-адрес домена, к которому нужно подключиться. Если оно не находит ответа на свой вопрос здесь, оно просит системного распознавателя (resolver — резолвер) выяснить, каков адрес доменного имени.
Затем рекурсивный сервер следует по пути отсылок к каждому последующему серверу имён, которому делегирована ответственность за компоненты домена, до тех пор, пока он не найдёт конкретный сервер имён, который имеет полный ответ. Он помещает этот ответ в кэш для последующих запросов, а затем возвращает его клиенту.
Как видно из этого примера, существует много разных типов серверов, и каждый из них играет свою роль. Давайте рассмотрим особенности различных типов DNS-серверов.
Функциональные различия
Некоторые из различий между DNS-серверами являются чисто функциональными. Большинство серверов, участвующих в реализации DNS, специализируются на определённых функциях. Тип DNS-сервера, который вы выберете, будет во многом зависеть от ваших потребностей и типа проблемы, которую вы надеетесь решить.
DNS серверы с только авторитативной функцией (Authoritative-Only)
Authoritative-Only DNS-сервер — это сервер, который заботится только о том, чтобы отвечать на запросы для зон, за которые он отвечает. Поскольку он не помогает разрешать запросы для внешних зон, он, как правило, очень быстрый и может эффективно обрабатывать много запросов.
Серверы с только авторитативной функцией имеют следующие свойства:
- Очень быстро реагирует на запросы для зон, которые он контролирует. Сервер с только авторитативной функцией будет иметь всю информацию о домене, за который он отвечает, или справочную информацию для зон в домене, которые были делегированы другим серверам имён.
- Не будет отвечать на рекурсивные запросы. Серверы с только авторитативной функцией по своему понятию не предназначены отвечать на них. Это делает его только сервером, а не клиентом в системе DNS. Любой запрос, достигающий Authoritative-Only сервера, обычно поступает от распознавателя (резолвера), получившего ссылку на него, а это означает, что Authoritative-Only сервер либо имеет полный ответ, либо сможет передать новую ссылку на сервер имён, которому была делегирована соответствующая ответственность.
- Не кеширует результаты запроса. Поскольку сервер authoritative-only никогда не запрашивает информацию на других серверах для обработки запроса, то ему просто нечего кэшировать. Вся информация, которую он знает, уже находится в его системе.
Кеширующий DNS-сервер
Кэширующий DNS-сервер — это сервер, который обрабатывает рекурсивные запросы от клиентов. Почти каждый DNS-сервер, с которым свяжется заглушка обработчика операционной системы, будет кэширующим DNS-сервером.
Чтобы избежать потери производительности при отправке нескольких итеративных запросов другим DNS-серверам каждый раз, когда он получает рекурсивный запрос, сервер кэширует свои результаты. Это позволяет ему иметь доступ к широкой базе информации DNS (общедоступные DNS всего мира) и совмещать это с очень быстрой обработкой последних запросов.
Кэширующий DNS-сервер имеет следующие свойства:
Перенаправляющие (Forwarding) DNS-сервера
Альтернативный подход к накоплению кеша для клиентских машин — использование перенаправляющего DNS-сервера. Этот подход добавляет ещё одно звено в цепочку разрешения DNS, которым является Forwarding сервер, который просто передаёт все запросы другому DNS-серверу с рекурсивными возможностями (например, кеширующему DNS-серверу).
Преимущество этой системы состоит в том, что она может дать вам преимущество локально доступного кэша, не выполняя рекурсивную работу (что может привести к дополнительному сетевому трафику и может занять значительные ресурсы на серверах с высоким трафиком). Это также может привести к некоторой интересной гибкости в разделении вашего частного и публичного трафика путём пересылки на разные серверы.
Перенаправляющий (Forwarding) DNS-сервер имеет следующие свойства:
- Способность обрабатывать рекурсивные запросы без выполнения самой рекурсии. Наиболее фундаментальным свойством сервера пересылки DNS является то, что он передаёт запросы другому агенту для разрешения. Сервер пересылки может иметь минимальные ресурсы и при этом эффективно использовать свою кеш-память.
- Предоставлять локальный кеш в ближайшем сетевом расположении. В частности, если вы не хотите создавать, поддерживать и защищать полноценное рекурсивное DNS-решение, сервер пересылки может использовать общедоступные рекурсивные DNS-серверы. Он может использовать эти серверы, перемещая основное место кэширования очень близко к клиентским машинам. Это может уменьшить время ответа.
- Увеличивает гибкость в определении локального доменного пространства. Передавая запросы на разные серверы в зависимости от определённых условий, перенаправляющий сервер может гарантировать, что внутренние запросы обслуживаются приватными серверами, в то время как внешние запросы используют общедоступный DNS.
Комбинированные решения
Несмотря на то, что вышеупомянутые решения построены с очень конкретными целями, часто возникает желание настроить DNS-сервер так, чтобы сочетать преимущества каждого из них.
DNS-сервер может быть настроен для работы в качестве рекурсивного сервера кэширования для выбранного количества локальных клиентов, отвечая только на итеративные, авторитетные запросы от других клиентов. Это обычная конфигурация, поскольку она позволяет вам отвечать на глобальные запросы для вашего домена, а также позволяет вашим локальным клиентам использовать сервер для рекурсивного разрешения.
Хотя соответствующее программное обеспечение DNS специально разработано для выполнения одной конкретной роли, такие приложения, как Bind, невероятно гибки и могут использоваться в качестве гибридных решений. Хотя в некоторых случаях попытка предоставить слишком много услуг на одном сервере может привести к снижению производительности, во многих случаях, особенно в случае небольшой инфраструктуры, наиболее целесообразно поддерживать единое решение «все в одном».
Различия в отношениях
Хотя, вероятно, функциональными различия являются наиболее очевидные между конфигурациями DNS-серверов, реляционные различия также чрезвычайно важны.
Основной (Primary) и подчинённый (Slave) серверы
Учитывая важность DNS в обеспечении доступности служб и целых сетей, большинство DNS-серверов, которые являются авторитативными для зоны, будут иметь встроенную избыточность. Существуют различные термины для отношений между этими серверами, но в целом сервер может быть главным (Primary) или подчиненным (Slave) в своей конфигурации.
И главный, и подчинённый серверы являются авторитативными для зон, с которыми они работают. Главный (master) не имеет больше власти над зонами, чем Slave. Единственный различающий фактор между главным и подчиненным серверами — это то, откуда они читают свои файлы зон.
Главный сервер считывает файлы своей зоны из файлов на системном диске, обычно здесь администратор зоны добавляет, редактирует или передаёт исходные файлы зоны.
Подчинённый сервер получает зоны, для которых он является полномочным, посредством передачи зоны от одного из главных серверов для зоны. Как только он получает эти зоны, он помещает их в кеш. Если он должен перезапуститься, он сначала проверяет свой кэш, чтобы увидеть, обновлены ли зоны внутри. Если нет, он запрашивает обновлённую информацию с главного сервера.
Серверы не обязательно должны относиться только к master или только к slave для всех зон, с которыми они работают. Главный или подчинённый статус присваивается по зонам, поэтому сервер может быть ведущим для некоторых зон и ведомым для других.
DNS-зоны обычно имеют как минимум два сервера имён. Любая зона, отвечающая за маршрутизируемую зону Интернета, должна иметь как минимум два сервера имён. Часто для обслуживания повышенной нагрузки и увеличения избыточности используется гораздо больше серверов имён.
Публичные и частные серверы
Часто организации используют DNS как снаружи, так и внутри. Однако информация, которая должна быть доступна в обеих из этих сфер, часто существенно отличается.
Организация может поддерживать доступными из вне DNS серверы с только авторитативной функцией (Authoritative-Only) для обработки публичных DNS-запросов для доменов и зон, которые относятся к их «юрисдикции». Для своих внутренних пользователей организация может запустить отдельный DNS-сервер, который содержит публичную информацию, предоставляемую общедоступным DNS, а также дополнительную информацию о внутренних хостах и службах. Он также может предоставлять дополнительные функции, такие как рекурсия и кэширование для своих внутренних клиентов.
Хотя выше мы упомянули о возможности иметь один сервер для выполнения всех этих задач на «комбинированном» сервере, есть определённые преимущества для разделения рабочей нагрузки. На самом деле, поддержание совершенно отдельных серверов (внутренних и внешних), которые не знают друг друга, обычно является более предпочтительным вариантом. С точки зрения безопасности особенно важно, чтобы на общедоступном сервере не было приватных записей. Это означает не перечислять ваши частные серверы имён с записями NS в публичных файлах зон.
Есть некоторые дополнительные соображения, которые следует иметь в виду. Хотя может быть проще, если ваши общедоступные и частные серверы будут совместно использовать данные зон, которые у них общие, и находится в традиционных отношениях главный-подчиненный (master-slave), это может привести к утечке информации о вашей частной инфраструктуре.
Кроме того, что ваши приватные сервера не должны попадать в сами файлы зон (то есть не должны быть доступны для публичного поиска), также неплохо удалить любые ссылки на приватные сервера в файлах конфигурации публичного сервера. Это означает удаление передачи, уведомлений и сведений о конфигурации, чтобы компрометация общедоступного сервера не означала, что ваши внутренние серверы имён внезапно становятся доступными.
Это означает поддержание отдельных файлов зон для каждого, что может быть дополнительной работой. Однако это может быть необходимо для абсолютного разделения и безопасности.
Заключение
Итак, теперь мы знаем, что если возникла необходимость настроить свой DNS сервер, то нужно определиться — какой именно DNS сервер нам нужен, поскольку существуют различные варианты.
Перенаправляющий/кэширующий DNS-сервер можно настроить даже на домашнем компьютере Linux. Такой сервер может полностью заменить файл /etc/hosts для обращения к ресурсам локальной сети. А при поступлении запросов для получения IP доменных имён, этот сервер будет получать данные от внешнего кэширующего сервера (например, 8.8.8.8 и 8.8.4.4 — DNS-серверы от Google) и сохранять полученные ответы в своём кэше — это в том случае, если вы настроили перенаправляющий DNS-сервер. Если же вы выберите рекурсивный кэширующий DNS-сервер, то он будет делать несколько запросов, начиная с корневых DNS-серверов и получать в конечном счёте ответы исключительно от авторитативных DNS-серверов (а не от сторонних кэширующих серверов, как это обычно происходит). Полученные данные также будут храниться в кэше. В случае повторных запросов этих имён, локальный DNS сервер их будет брать из кэша, что может немного ускорить работу сети.
В наших следующих руководствах (смотрите ссылки ниже) мы покажем, как начать работу с некоторыми из этих конфигураций. Мы начнём с обучения настройке кэширующего и перенаправляющего DNS-сервера. Позже мы расскажем о том, как обслуживать ваши домены, настроив пару DNS серверов с только авторитативной функцией (Authoritative-Only).
Продолжение и дополнительный материал
Для продолжения знакомства с DNS рекомендуются следующие статьи:
[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]
В этой статье будет описано как правильно настроить работу DNS.
Служба DNS расшифровывается как "система доменных имен", которая сопоставляет URL'у IP-адреса серверов указанного ресурса во внешней сети. После этого трафик направляется на указанные адреса.
Прежде чем выбрать путь настройки, убедитесь, что на машине с UserGate на интерфейсе, который смотрит во внешнюю сеть (WAN), имеются DNS провайдера или внешние крупные DNS, на интерфейсе, который смотрит в локальную сеть (LAN), отсутствует шлюз и DNS (прописаны только адрес и маска). Внимание! Убедитесь, что на внешнем интерфейсе прописано не более трех DNS-адресов, иначе могут быть вызваны ошибки с обработкой запроса и страницы в браузере могут открываться долго . Если все так, тогда можно идти дальше.
Существуют четыре основных пути настройки DNS:
1. В локальной сети отсутствует DNS-сервер на машине с контроллером домена.
В этом случае настройка производится следующим образом:
- Включить DNS-форвардинг на использование системных настроек в консоли администратора во вкладке Настройка DNS.
- *На клиентских компьютерах требуется прописать в качестве шлюза и DNS LAN-интерфейс машины с UserGate.
2. В локальной сети присутствует DNS-сервер на машине с контроллером домена - отдельная машина в локальной сети.
В данном случае нужно настраивать DNS следующим образом:
- Включить DNS-форвардинг на использование системных настроек в консоли администратора во вкладке Настройка DNS.
- На DNS-сервере сделать Направление (Forward) на LAN-интерфейс UserGate, спустя некоторое время в данной настройке должно будет распознано приблизительное как имя "entensys.dns-forwarding". Делается это следующим образом: заходите на контроллер домена, выбираете роль DNS-сервера, заходите в DNS, выбираете текущую машину, правой кнопкой мыши по нему, Свойства (Properties), вкладка Направление (Forwarders), нажмите Редактировать (Edit), добавьте локальный адрес машины с UserGate.
- *На клиентских компьютерах требуется прописать в качестве шлюза LAN-интерфейс машины с UserGate, а в качестве DNS - интерфейс машины с DNS-сервером.
3. В локальной сети присутствует DNS-сервер на машине с контроллером домена и это та же машина, на которой стоит UserGate.
Такая конфигурация считается не самой лучшей в плане нагрузки на сервер, однако для нее тоже есть конфигурация, и делается она следующим образом:
- Отключить DNS-форвардинг в консоли администратора во вкладке Настройка DNS.
- *На клиентских компьютерах требуется прописать в качестве шлюза и DNS LAN-интерфейс машины с UserGate.
4. Машины из локальной сети имеют шлюзом отличную от машины с UserGate машину (например RRAS сервер, поднятый в Windows Server ****).
В этом случае в браузере клиента требуется прописать локальный адрес машины с UserGate, а в таком случае прокси сам распознает DNS-адреса через DNS-форвардинг. Поэтому последовательность действия следующая:
- Включить DNS-форвардинг на использование DNS-адресов из списка в консоли администратора во вкладке Настройка DNS, где в списке надо прописать DNS провайдера или любой крупный внешний интерфейс.
* - приоритетным вариантом считается использование нашего DHCP-сервера, или DHCP-сервера от Windows Server.
В самом DNS-форвардинге имеется возможность поменять порт (по умолчанию стоит 5458, однако лучше без крайней необходимости этого не делать), изменить тайм-аут DNS-запроса (по умолчанию 7000, который тоже не рекомендуется менять, если нет представления о том, как это работает), включить/отключить кэш DNS-записей и изменить их число при включенном кэш. Кэш снижает нагрузку на сервер, благодаря тому, что ответ на запрос берется из кэша, если данный адрес уже вызывался.
Если после корректной настройки согласно данной статье у вас появляется в браузере ошибка 10065, то обратитесь к данной статье.
В этой статье мы рассмотрим два способа организации условного разрешения имен в DNS сервере на Windows Server 2016: DNS conditional forwarding и DNS policy. Эти технологии позволяют настроить условное разрешение DNS имен в зависимости от запрошенного имени, IP адреса и местоположения клиента, времени суток и т.д.
Настройка DNS Conditional Forwarder в Windows Server
- Запустите консоль управления DNS ( dnsmgmt.msc );
- Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
- В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
- В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
- Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
- Выберите правило репликации записи conditional forwarding (All DNS servers in this forest, All DNS servers in this domain или All domain controllers in this domain).
Настройка DNS Conditional Forwarding с помощью PowerShell
Вы можете создать правило Conditional Forward для определенной DNS зоны с помощью PowerShell. Воспользуйтесь командлетом Add-DnsServerConditionalForwarderZone:
Чтобы вывести список DNS Conditional Forwarders на определенном сервере, выполните следующий PowerShell скрипт:
$DNSServer = "DC01"
$Zones = Get-WMIObject -Computer $DNSServer -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Zone"
$Zones | Select-Object Name,MasterServers,DsIntegrated,ZoneType | where | ft -AutoSize
Фильтрация запросов DNS, политики разрешения имен в Windows Server 2016
В Windows Server 2016 появилась новая фича в службе DNS сервера – DNS политики. DNS политики позволяют настроить DNS сервер так, чтобы он возвращал различные ответы на DNS запросы в зависимости от местоположения клиента (с какого IP адреса или подсети пришел запрос), интерфейса DNS сервера, времени суток, типа запрошенной записи (A, CNAME, PTR, MX) и т.д. DNS политики в Windows Server 2016 позволяют реализовать сценарии балансировки нагрузки, фильтрации DNS трафика, возврата DNS записей в зависимости от геолокации (IP адреса клиента) и многие другие сложные сценарии.
Вы можете создать политику как на уровне DNS сервера, так и на уровне всей зоны. Настройка DNS политик в Windows Server 2016 возможна только из командной строки PowerShell.
Я создал 3 подсети для разных офисов компании:
Add-DnsServerClientSubnet -Name "MSK_DNS_Subnet" -IPv4Subnet "192.168.1.0/24"
Add-DnsServerClientSubnet -Name "EKB_DNS_Subnet" -IPv4Subnet "192.168.11.0/24"
Add-DnsServerClientSubnet -Name "SPB_DNS_Subnet" -IPv4Subnet "192.168.21.0/24"
Чтобы вывести список всех IP подсетей клиентов, выполните:
Теперь нужно для каждого офиса создать отдельную DNS область:
Следующие команды добавят 3 DNS записи с одним именем, но указывающие на разные IP адреса в разных областях DNS:
Вы можете вывести все ресурсные DNS записи для области с помощью команды:
Теперь нужно создать DNS политики, которые свяжут IP подсети, DNS области и A записи.
- -Action ALLOW
- -Action DENY
- -Action IGNORE
Можно использовать следующие параметры в фильтре DNS:
-InternetProtocol "EQ,IPv4,NE,IPv6"
-TransportProtocol "EQ,UDP,TCP"
-ServerInterfaceIP "EQ,192.168.1.21"
-QType "EQ,A,AAAA,NE,PTR"
-TimeOfDay "EQ,9:00-18:00"
Вывести список всех DNS политик для DNS зоны на сервере можно так:
Теперь с устройств из различных офисов проверьте, что DNS сервер на один и тот же запрос возвращает различные IP адреса прокси:
Можно запретить DNS серверу возвращать DNS адреса для определенного пространства имен (домена):
Форвард зоны на другой сервер, ждали, ждали и дождались
В логах беты версии 6.47 увидел что есть изменения в работе DNS сервера на MikroTik.
Ну что-же интересно, необходимо проверить, работу и посмотреть что к чему.
Решил не использовать GNS, а взял с полки специально для тестов HAP ac2 и естественно обновил на последнюю beta версию.
IP адрес маршрутизатора с бета версией 172.20.17.100
Естественно по наитию пошли смотреть в /ip dns static
И видим нововведения, ну что же надо разобраться и проверить.
Не только A но и другие типы записей.
Раньше нем было доступно только A и AAAA записи для IPv4 и соответственно IPv6, как видим сейчас стало значительно больше.
Ну что-же давайте проверим все эти записи.
Проверять мы будет работу с помощью nsloopkup .
CNAME
Тип ссылки, когда мы говорим, что для данной записи ищи значение в другой записи.
Записи MX необходимы для корректной работы, а точнее поиска сервера для получения почты по протоколу SMTP.
Создадим две записи для вымышленного домена, с разными весами.
Когда вам надо сообщить, что за конкретное доменное имя отвечает другой сервер, вы должны использовать запись типа NS.
Вы можете сохранять произвольное значение, частно используется для того чтобы проходить валидация SPF для перечисления записей разрешённых хостов для отправки почты. Также при использовании DKIM подписи.
И ещё мы написали программку knockme которая также может использовать TXT для получения параметров knock-a.
Многие сервисы могут использовать для автоматического получения списка серверов например SIP, XMPP, LDAP и прочее.
Ну что же вроде всё работает.
И самая долгожданная штука это так называемый SPLIT DNS.
MikroTik Split DNS
Для начало, для чего он нужен.
Данный режим ещё называется forward zone
Представим себе ваш MikroTik выступает в роли маршрутизатора удалённого филиала. На нём поднимается VPN до центрального филиала прописываются маршруты и прочее. У вас доменная авторизация все компьютеры в домене, естественно хорошей практикой на компьютерах прописать DNS сервера который обслуживают Active Directory службы. Но в таком случае если туннель по какой-то причине упадёт ваш филиал останется без интернета, а ведь интернета может не быть в центральном филиале. Да перестанут работать различные шары и прочее, конечно для этих целей существует как минимум RODC, но навсегда есть возможность установить подобный сервис в филиале ввиду множества различных проблем.
Представим что наш dns suffix равен mycom.loc
Соответственно, а что если мы на компьютерах припишем DNS сервер адрес MikroTik, а на MikroTik укажем, что если запрос содержит mycom.loc то перенаправлять такие запросы на сервера DNS AD, а все остальные запросы перенаправлять допустим на 8.8.8.8.
Установим на MikroTik сервер DNS 8.8.8.8
и настроим forwarding зоны
Обратите внимания что мы используем регулярное вырожение.
Давайте проверим. Я решил взять реальный прод, поэтому DNS суффикс скрыл, не переживайте всё по подобию.
И так в скриншотах, с замазанным суффиксом.
И немного логов.
Настоятельно рекомендую пока данный функционал не использовать в проде, так как это всё ещё бета версия.
Читайте также: