Dns резолвер что это
Особенности резолвера DNS в Windows 10 и DNS Leak
TL;DR: DNS-резолвер в Windows 10 отправляет запросы на все известные системе адреса DNS-серверов параллельно, привязывая запрос к интерфейсу, и использует тот ответ, который пришел быстрее. В случае, если вы используете DNS-сервер из локального сегмента, такое поведение позволяет вашему провайдеру или злоумышленнику с Wi-Fi-точкой подменять записи DNS, даже если вы используете VPN.
Современные версии Windows добавляют головные боли активным пользователям VPN. DNS-резолвер до Windows 7 включительно имел предсказуемое поведение, совершая запросы к DNS-серверам в порядке очереди и приоритета DNS-серверов, в общем-то, как и все остальные ОС. Это создавало так называемый DNS Leak (утечка DNS-запроса через внешний интерфейс при подключенном VPN) только в том случае, если DNS-сервер внутри VPN-туннеля не ответил вовремя, или ответил ошибкой, и, в целом, не являлось такой уж вопиющей проблемой.
Windows 8
С выходом Windows 8, Microsoft добавила весьма интересную функцию в DNS-резолвер, которая, как я могу судить по Google, осталась совершенно незамеченной: Smart Multi-Homed Name Resolution. Если эта функция включена (а она включена по умолчанию), ОС отправляет запросы на все известные ей DNS-серверы на всех сетевых интерфейсах параллельно, привязывая запрос к интерфейсу. Сделано это было, вероятно, для того, чтобы уменьшить время ожидания ответа от предпочитаемого DNS-сервера в случае, если он по каким-то причинам не может ответить в отведенный ему таймаут (1 секунда по умолчанию), и сразу, по истечении таймаута, отдать ответ от следующего по приоритету сервера. Таким образом, в Windows 8 и 8.1 все ваши DNS-запросы «утекают» через интернет-интерфейс, позволяя вашему провайдеру или владельцу Wi-Fi-точки просматривать, на какие сайты вы заходите, при условии, что ваша таблица маршрутизации позволяет запросы к DNS-серверу через интернет-интерфейс. Чаще всего такая ситуация возникает, если использовать DNS-сервер внутри локального сегмента, такие DNS поднимают 99% домашних роутеров.
Данную функциональность можно отключить, добавив в ветку реестра:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient
Параметр типа DWORD с названием:
DisableSmartNameResolution
и любым значением, отличным от нуля, что возвращало старое поведение резолвера.
Windows 10
Хоть Windows 8 и 8.1 отправляли все ваши запросы без вашего ведома через публичный интерфейс, совершить подмену DNS-ответа таким образом, чтобы перенаправить вас на поддельный сайт, было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера, коим является сервер внутри шифрованного туннеля.
Все изменилось с приходом Windows 10. Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел, что позволяет практически всегда вашему провайдеру перенаправить вас на заглушку о запрещенном сайте или злоумышленнику на поддельный сайт. Более того, способ отключения Smart Multi-Homed Name Resolution, который работал в Windows 8.1, не работает на новой версии.
Единственный приемлемый (хоть и не самый надежный) способ решения проблемы — установить DNS на интернет-интерфейсе вне локального сегмента, например, всем известные 8.8.8.8, однако, он не поможет в случае с OpenVPN. Для OpenVPN единственным (и некрасивым) решением является временное отключение DNS на интернет-интерфейсе скриптами.
UPD: ранее в статье рекомендовалось использовать параметр redirect-gateway без def1 для OpenVPN. Оказывается, Windows возвращает маршрут по умолчанию от DHCP-сервера при каждом обновлении IP-адреса, и через какое-то время весь ваш трафик начинал бы ходить в обход VPN. На данный момент, красивого решения не существует.
UPD3: Windows 10, начиная с Creators Update, теперь отправляет DNS-запросы на все известные адреса DNS-серверов по порядку, а не параллельно, начиная со случайного интерфейса. Чтобы повысить приоритет конкретного DNS, необходимо уменьшить метрику интерфейса. Сделал патч для OpenVPN, надеюсь, его включат в 2.4.2: https://sourceforge.net/p/openvpn/mailman/message/35822231/
UPD4: Обновление вошло в OpenVPN 2.4.2.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Сравнение типов DNS серверов: как выбрать правильную конфигурацию DNS
Введение
DNS, или Система доменных имён, является неотъемлемой частью того, как системы соединяются друг с другом для общения в Интернете. Без DNS компьютеры и люди, которые их используют, должны были бы соединяться, используя только числовые адреса, известные как IP-адреса.
Помимо очевидной проблемы запоминания большого количества сложных чисел для простых задач, связь через IP-адреса также вызывает некоторые дополнительные проблемы. Перемещение вашего сайта на другого хостинг-провайдера или перемещение ваших серверов в разные места потребует от вас информирования каждого клиента о новом местоположении.
DNS-серверы (компьютеры, которые вместе образуют систему, позволяющую нам использовать имена вместо IP адресов), могут обслуживать множество различных функций, каждая из которых может способствовать вашей возможности доступа к серверам по имени.
В предыдущем руководстве мы обсудили некоторые основные термины и понятия системы доменных имён. Предполагается, что вы прочитали предыдущую статью. В этом руководстве мы поговорим о некоторых типах настроек DNS-сервера и о преимуществах, вариантах использования и свойствах каждого из них.
Путь DNS-запроса
Когда клиентская программа хочет получить доступ к серверу по его доменному имени, она должна выяснить, как преобразовать доменное имя в фактический маршрутизируемый адрес, который она может использовать для связи. Необходимо знать эту информацию, чтобы отправлять информацию на сервер и получать от него ответ.
Некоторые приложения, в том числе большинство веб-браузеров, поддерживают внутренний кеш последних запросов. Если в нём есть такая функциональность, то это первое место, где приложение попытается найти IP-адрес домена, к которому нужно подключиться. Если оно не находит ответа на свой вопрос здесь, оно просит системного распознавателя (resolver — резолвер) выяснить, каков адрес доменного имени.
В общем случае распознаватель (resolver) — это любой компонент, который в DNS запросе выступает в роли клиента. Системный распознаватель — это библиотека перевода имён, которую ваша операционная система использует для поиска ответов на DNS-запросы. В целом системные преобразователи, как правило, представляют собой то, что можно назвать заглушкой обработчика, поскольку обычно они способны не более чем на поиск по нескольким статичным файлам в системе (например, в файле /etc/hosts) и пересылки запросов другому преобразователю.
Таким образом, как правило, запрос передаётся из клиентского приложения в системный преобразователь, где он затем передаётся на DNS-сервер, чей адрес указан в настройках системы. Этот DNS-сервер называется рекурсивным DNS-сервером. Рекурсивный сервер — это DNS-сервер, который настроен на выполнение запросов к другим DNS-серверам, пока не найдёт ответ на вопрос. Он вернёт клиенту ответ на его запрос, либо сообщение об ошибке (его получит системный распознаватель, который, в свою очередь, передаст его клиентскому приложению).
Рекурсивные серверы обычно также поддерживают кеш. Сначала сервер проверит этот кеш — есть ли у него ответ на запрос. Если ответа нет, он посмотрит, есть ли у него адрес какого-либо из серверов, которые контролируют компоненты домена верхнего уровня. Поэтому, если запрос относится к www.example.com, и он не может найти этот адрес хоста в своём кэше, он проверит, есть ли у него адрес серверов имён для example.com и, если необходимо, для домена верхнего уровня com. Затем он отправит запрос на сервер имён наиболее конкретного компонента домена, который сможет найти, чтобы запросить дополнительную информацию.
Если сервер не находит адрес ни одному из этих компонентов домена, он должен начать с самой верхней части иерархии, запрашивая корневые серверы имён. Корневые серверы знают адреса всех серверов имён TLD (доменов верхнего уровня), которые контролируют зоны для .com, .net, .org и т. д. Он спросит корневой сервер, знает ли он адрес www.example.com. Корневой сервер направит рекурсивный сервер к серверам имён для домена .com.
Затем рекурсивный сервер следует по пути отсылок к каждому последующему серверу имён, которому делегирована ответственность за компоненты домена, до тех пор, пока он не найдёт конкретный сервер имён, который имеет полный ответ. Он помещает этот ответ в кэш для последующих запросов, а затем возвращает его клиенту.
Как видно из этого примера, существует много разных типов серверов, и каждый из них играет свою роль. Давайте рассмотрим особенности различных типов DNS-серверов.
Пример рекурсивных запросов о домене suip.biz:
Функциональные различия
Некоторые из различий между DNS-серверами являются чисто функциональными. Большинство серверов, участвующих в реализации DNS, специализируются на определённых функциях. Тип DNS-сервера, который вы выберете, будет во многом зависеть от ваших потребностей и типа проблемы, которую вы надеетесь решить.
DNS серверы с только авторитативной функцией (Authoritative-Only)
Authoritative-Only DNS-сервер — это сервер, который заботится только о том, чтобы отвечать на запросы для зон, за которые он отвечает. Поскольку он не помогает разрешать запросы для внешних зон, он, как правило, очень быстрый и может эффективно обрабатывать много запросов.
Серверы с только авторитативной функцией имеют следующие свойства:
Кеширующий DNS-сервер
Кэширующий DNS-сервер — это сервер, который обрабатывает рекурсивные запросы от клиентов. Почти каждый DNS-сервер, с которым свяжется заглушка обработчика операционной системы, будет кэширующим DNS-сервером.
Преимущество кеширующих серверов — способность отвечать на рекурсивные запросы от клиентов. В то время как Authoritative-Only серверы могут быть идеальными для обслуживания информации о конкретной зоне, кэширующие DNS-серверы более полезны с точки зрения клиента. Они делают систему мира DNS доступной для совсем простых клиентских интерфейсов, которым чтобы узнать IP адрес доменного имени достаточно отправить запрос и просто ждать готовый ответ.
Чтобы избежать потери производительности при отправке нескольких итеративных запросов другим DNS-серверам каждый раз, когда он получает рекурсивный запрос, сервер кэширует свои результаты. Это позволяет ему иметь доступ к широкой базе информации DNS (общедоступные DNS всего мира) и совмещать это с очень быстрой обработкой последних запросов.
Кэширующий DNS-сервер имеет следующие свойства:
Перенаправляющие (Forwarding) DNS-сервера
Альтернативный подход к накоплению кеша для клиентских машин — использование перенаправляющего DNS-сервера. Этот подход добавляет ещё одно звено в цепочку разрешения DNS, которым является Forwarding сервер, который просто передаёт все запросы другому DNS-серверу с рекурсивными возможностями (например, кеширующему DNS-серверу).
Преимущество этой системы состоит в том, что она может дать вам преимущество локально доступного кэша, не выполняя рекурсивную работу (что может привести к дополнительному сетевому трафику и может занять значительные ресурсы на серверах с высоким трафиком). Это также может привести к некоторой интересной гибкости в разделении вашего частного и публичного трафика путём пересылки на разные серверы.
Перенаправляющий (Forwarding) 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 запросы (в этом случае нужен кэширующий или перенаправляющий серверы) или же 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 сервер BIND (теория)
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru. будет иметь такой вид:
Регистрация доменных имен
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например nic.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS вашего хостера.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.