Что такое рекурсивный запрос dns
Понятие DNS рекурсии
Основная концепция преобразования DNS названий достаточно проста. Каждому веб сайту присваивается уникальный IP адрес. Для доступа к веб сайту клиенту необходимо знать этот IP адрес сайта. Конечно, пользователь обычно не вводит IP адрес в своем браузере Web browser, а вместо этого вводит название домена сайта (domain name). Для доступа к запрашиваемому веб сайту браузер (Web browser) должен уметь преобразовывать название домена сайта (domain name) в соответствующий ему IP адрес. В этом месте в игру вступает DNS. На клиентском компьютере настроен адрес предпочтительного сервера DNS (preferred DNS server). Запрашиваемый URL передается на сервер DNS, а сервер DNS возвращает IP адрес для запрашиваемого веб сайта. После этого клиент может обратиться к запрашиваемому сайту.
Как вы можете увидеть, процесс преобразования название в адрес достаточно краток. Однако, по всему миру существует огромное множество веб сайтов, и новые сайты создаются каждый день. Ваш сервер DNS просто не в состоянии знать IP адрес каждого отдельного веб сайта. Если сервер DNS не знает адрес запрашиваемого сайта, то он использует один из двух методов для определения IP адреса сайта.
Предпочтительный метод преобразования имени в адрес называется рекурсией (recursion). Если говорить в общем, то рекурсия это процесс, при котором сам сервер DNS отправляет запросы на другие сервера DNS, для того чтобы затем по обратной цепочке передать ответ клиенту, который совершил запрос. В общем, DNS сервер становится DNS клиентом. Некоторые администраторы предпочитают отключить рекурсию в целях увеличения производительности. Если рекурсия отключена, то сервер DNS использует процесс, называемый итерация (iteration), для обработки запроса.
Root Hints
Если сервер DNS не знает адрес запрашиваемого сайта, то он передает запрос другому серверу DNS. Для этого сервер DNS server должен знать IP адрес другого сервера DNS, которому он может передать запрос. Это задача корневых подсказок (root hints). Корневые подсказки предоставляют список IP адресов DNS серверов, которые находятся на корневом уровне (root level) иерархии DNS.
Хорошая новость заключается в том, что корневые подсказки (root hints) заранее настроены на DNS серверах, работающих под управлением операционной системы Windows Server 2003. Корневые подсказки (root hints) хранятся в файл под названием CACHE.DNS, который находится в папке \Windows\System32\Dns. Если вы хотите узнать, как выглядят корневые подсказки, то вы можете открыть этот файл в блокноте (Notepad). Как вы можете увидеть на рисунке A, файл с корневыми подсказками представляет собой ничто иное, чем обыкновенный текстовый файл, в котором попарно расположены DNS сервера и их IP адреса.
Рисунок A : Корневые подсказки соответствуют DNS серверам корневого уровня и их IP адресам
Теперь давайте поговорим о том, что такое корневые подсказки, что они делают, а также рассмотрим процесс рекурсии (recursion process) в действии. Диаграмма, изображенная на рисунке B иллюстрирует пример, о котором я хочу вам рассказать.
Рисунок B : Так работает DNS рекурсия (recursion)
Процесс начинается с того, что пользователь вводит URL в своем браузере (Web browser). В нашем примере давайте предположим, что пользователь ввел в качестве URL следующий адрес www.contoso.com. После этого запрос на преобразование названия домена Contoso.com в IP адрес передается на предпочтительный сервер DNS (preferred DNS server), который задан на рабочей станции. Очень часто в КЭШе предпочтительного сервера DNS (preferred DNS server) уже содержится запрашиваемая запись, но в этом примере давайте предположим, что на нашем предпочтительно сервере DNS нет информации относительно сайта CONTOSO.COM.
Если предположить также, что включена DNS рекурсия, то сервер DNS server начинает работать в роли DNS клиента и отправляет серию итерационных запросов на другие сервера DNS. Я объясню разницу между итеративным (iterative) и рекурсивным (recursive) запросом позднее, а сейчас просто представьте, что в целом процесс считается рекурсивным потому, что клиент отправляет лишь один запрос на предпочтительный сервер DNS (preferred DNS server).
В любом случае, предпочтительный сервер DNS на рабочей станции не знает IP адреса веб сайта www.contoso.com, и не знает IP адрес сервера DNS, которые отвечает за домен Contoso.com (а поэтому знает IP адрес сайта www.contoso.com). Все что знает DNS сервер, лишь IP адрес DNS сервера корневого уровня (благодаря файлу с корневыми подсказками). Поэтому предпочтительный сервер DNS (preferred DNS server) передает запрос корневому серверу DNS (root DNS server).
В этом примере необходимо обратить внимание на две вещи. Во-первых, как я уже объяснял ранее, клиент совершает лишь один запрос DNS. Он абсолютно ничего не знает об итеративных запросах сервер DNS. Во-вторых, сервер DNS, который отвечает за домен CONTOSO.COM вовсе не обязательно принадлежит Contoso. Обычно, этот сервер DNS принадлежит компании, занимающейся веб хостингом (Web hosting company) и отвечает за все сайты, принадлежащие этой компании. Именно поэтому предпочтительный сервер DNS (preferred DNS server) не может пропустить один шаг и сразу передать клиенту адрес DNS сервера, который отвечает за домен, по крайней мере не в нашем случае.
Если сервер DNS не поддерживает рекурсивные очереди (recursive queries), то клиент по умолчанию будет выполнять итеративные запросы (iterative queries).
Если вы заинтересованы в достижении лучшей производительности, то должны разрешить вашему серверу DNS отправлять рекурсивные запросы. Причина для этого заключается в том, что если клиенты вынуждены совершать итеративные запросы, то они могут потенциально отправлять три или четыре запроса на сервер DNS в рамках каждого запроса на преобразование имени в IP адрес. Сервер DNS должен обработать все эти запросы рекурсивные или итеративные, но если используется рекурсия (recursion), то большинство запросов на преобразование имен обрабатывается вашим сервером DNS и происходят вдали от вашей сети. В результате этого снижается трафик и улучшается производительность.
Заключение
В этой статье я рассказал о том, как работает рекурсивная очередь DNS (recursive DNS query). Большинство серверов DNS поддерживают, как рекурсивные (recursive), так и итеративные запросы от клиентов. Если вы настроите ваш сервер DNS на поддержку рекурсивных очередей (recursive queries), то в общем сможете добиться лучшей производительности, т.к. благодаря этому можно добиться снижению количества запросов, которые должен совершить сетевой клиент.
Domain Name System
DNS (Domain Name System – система доменных имен) – иерархическая система имен, основанная на распределенной системе базы данных, служащая для разрешения символьных имен в IP-адреса.
Служба DNS применятся для облегчения обмена данными между компьютерами в сети, связывая имена компьютеров с их IP-адресами.
Становление DNS
На заре становления Интернета (тогда еще он назывался ARPANET), проблема разрешения (трансляции) доменных имен в IP-адреса решалась ведением длинных списков, в которых символьное имя соответствовало IP-адресу. Пережиток этого метода мы можем наблюдать в файле «hosts», который расположен в папке %SystemRoot%\system32\drivers\etc.
Со временем, сопровождать такие списки имен становилось все труднее и труднее. Такие файлы требовалось часто синхронизировать, не говоря уже об их внушительных размерах.
В итоге, в 1983 году Джоном Постелом (Jon Postel) и Полом Мокапетрисом (Paul Mockapetris) была разработана система доменных имен (Domain Name System). Актуальную на данный момент спецификацию DNS можно найти в документах RFC 1034 и RFC 1035, которые датируются 1987 годом.
Терминологический минимум
Домен (Domain – область) – именованная область пространства иерархических имен.
Различают домены первого, второго, третьего и далее уровней, однако корневым доменом всей иерархии является точка «.», которая ставится в конце DNS имени. После корневого домена следует домен первого уровня, который может быть организован географически, по типу организации или по своему назначению. Затем следует домен второго уровня, третьего и т.д.
Домен нулевого уровня находится в основе DNS-иерархии и зачастую называется корневым доменом.
Следует помнить, что уровни домена считаются справа налево.
Поддомен (Subdomain) – дочерний домен, являющийся частью родительского домена.
Допускается деление поддоменов на 127 уровней, при этом каждая DNS метка не должна превышать 63 символа. Такое деление на поддомены возможно до тех пор, пока полное имя домена не будет превышать длину в 255 символов.
Resolver – это набор программного обеспечения, используемое для разрешения доменных имен.
Функционирование DNS
В качестве примера рассмотрим домен www.volokh.info.
Отметим, что в конце символьного имени ставится точка, которую зачастую опускают, но иногда она требуется в описаниях DNS.
При запросе адреса www.volokh.info., браузер обращается к локальному DNS-серверу, IP-адрес которого зачастую прописан в свойствах подключения Интернет сети. У DNS-сервера запрашивается информация о соответствии символьного имени домена www.volokh.info. IP-адресу. Получив запрос, DNS-сервер проверяет локальный кэш и, в случае отсутствия данных о требуемом домене, сообщает клиенту IP-адрес корневого домена, например 198.41.0.4.
В случае если у корневого DNS-сервера не имеется требуемой информации по домену info., то корневой DNS-сервер сообщает IP-адрес DNS-сервера, ответственного за домен первого уровня. Таким образом, запрос начинает спускаться вниз по иерархии уровней доменов, до тех пор, пока не будет найден DNS-сервер, ответственной за домен www.volokh.info.
Найденный DNS-сервер сообщает клиенту IP-адрес требуемого домена, и клиент подключается к серверу по IP-адресу 50.6.23.170.
Рекурсивный и итеративный запрос
DNS-запрос может быть рекурсивным и итеративным.
Рекурсивный запрос – это такой DNS-запрос, при котором DNS-сервер выступает в качестве клиента, от имени которого запрашиваются данные, и опрашивает другие сервера в поиске IP-адреса для определенного домена.
Рекурсивный метод запроса справедлив том случае, когда браузер запрашивает у DNS-сервера IP-адрес домена «www.volokh.info.»
1. DNS-сервер, не найдя записей в локальном кэше, обращается к корневому домену «.»;
2. Корневой домен, в свою очередь, сообщает IP-адрес DNS-сервера, ответственного за домен «info.» и DNS-сервер опрашивает уже его;
3. Ответственный сервер за домен «info.» сообщает DNS-серверу IP-адрес сервера, который может сообщить IP-адрес для домена «volokh.info»;
4. DNS-сервер, запросивший IP-адрес домена, опрашивает сервер, ответственный за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;
5. DNS-сервер возвращает IP-адрес клиенту, после чего происходит подключение к серверу по имени 50.6.23.170.
Итеративный метод запроса – это такой DNS-запрос, при котором DNS-клиент самостоятельно отслеживает отсылки к другим DNS-серверам и самостоятельно опрашивает их в поиске IP-адреса для определенного домена.
Для наглядности, на рис. 1 приведены оба метода запросов:
Итеративный метод запроса справедлив том случае, когда:
1. Resolver, для разрешения символьного имени «www.volokh.info.», посылает запрос на свой DNS-сервер;
2. DNS-сервер, получив запрос, отсылает в ответ IP-адрес корневого домена;
3. Resolver посылает запрос разрешения имени корневому DNS-серверу и получает в ответ адрес сервера, ответственного за зону «info.»;
4. Получив адрес DNS-сервера, ответственного за зону «info.», resolver отправляет DNS-запрос этому серверу;
5. DNS-сервер, получив запрос разрешения имени, сообщает адрес сервера, ответственного за домен «volokh.info.»;
6. Resolver посылает запрос серверу, ответственному за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;
7. Resolver, получив IP-адрес для домена «www.volokh.info.», осуществляет подключение к серверу по имени 50.6.23.170.
В случае рекурсивного запроса, DNS-сервер может не опрашивать другие DNS-сервера при условии, если у него в кэше есть информация о требуемом домене.
Зарезервированные доменные имена
Спецификация DNS предусматривает список зарезервированных доменов первого уровня, которые можно использовать в качестве примеров в документации или для тестирования локальных DNS-серверов.
Список зарезервированных доменов верхнего уровня (top-level domain) состоит из четырех имен: «.test», «.example», «.invalid» и «.localhost».
Помимо перечисленных выше доменов верхнего уровня, зарезервированы доменные имена второго уровня: «example.com», «example.net» и «example.org».
Использование зарезервированных доменных имен позволит избежать конфликтов с существующими доменными именами.
Технические детали DNS
BIND (Berkeley Internet Name Domain) – является самой распространенной реализацией DNS-сервера и используется практически всеми корневыми DNS-серверами.
Другие реализации серверов менее распространенны и в основном используются внутри крупных предприятий.
Для ответов на запросы, протокол DNS использует 53 порт протокола UDP (User Datagram Protocol). TCP (Transmission Control Protocol) используется в том случае, когда размер получаемых данных от DNS-сервера превышает 512 байт. При этом, данные также передаются через 53 порт протокола TCP.
Выводы
DNS (Domain Name System) – является признанным механизмом разрешения имен. Ключевым фактором в работе DNS является возможность разбиения разрешения имен по доменам, что позволяет обеспечить общедоступность каждого сервера в отдельности. В случае сбоя одного из DNS-серверов, функционирование всей иерархии системы имен не прерывается, так как в работу включается резервный сервер. Это позволяет обеспечивать сохранность данных и продолжение работы системы доменных имен в случае выхода из строя одного из узлов системы.
Вся структура Domain Name System является иерархической. Существуют домены первого, второго, третьего и т.д. уровней.
Для повышения эффективности работы DNS, DNS-серверы кэшируют полученные DNS-ответы.
Таким образом, 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, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.