Какие существуют типы запросов dns

Обновлено: 08.07.2024

Система доменных имен представляет собой организованную компиляцию доменных имен и соответствующего IP-адреса, определяющего узел, с которого размещается веб-сайт. [1] Эта функция очень похожа на директорию, которая позволяет пользователям вводить именованный веб-адрес в браузер вместо указанного IP-адреса для этого сайта. Все пользователи Интернета подключаются к DNS-серверам, которые сопоставляют доменные имена с назначенными IP-адресами с помощью процесса, известного как DNS-разрешение имен. [2] DNS-серверы могут систематически получать такую информацию, поскольку база данных DNS иерархически организована через дерево доменных имен, которые подразделяются на различные зоны. [3]

Cодержание

Доменное имя

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

Домен третьего уровня

Домен второго уровня

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

Домен верхнего уровня

Сокращенно ДВУ означает самый высокий уровень организации в Интернете. На серверах ДВУ размещаются уполномоченные серверы, базирующиеся в этой организации. Можно идентифицировать 2 типа ДВУ:

разрешение DNS

Основываясь на этих частях доменного имени, разрешение DNS также зависит от 4 компонентов системы:

DNS-рекурсор

DNS-рекурсор также называется DNS resolver. Это сервер, который отвечает за прием запросов от клиентских машин через приложения, такие как интернет-браузеры.

Корневой сервер имен

Существует 13 корневых серверов, стратегически распределенных по всему миру. Функция перенаправления DNS-рецидива на сервер имен ДВУ. Это очень похоже на индекс, который работает как ссылка для определения IP-адреса узла сайта.

Сервер имен домена верхнего уровня (ДВУ)

Авторитетный сервер имен

Серверы имен ДВУ имеют уполномоченные серверы имен, которые могут получать определенный IP-адрес для веб-доменов.

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

Пользователь вводит доменное имя в веб-браузер.
Контакты и запросы устройства DNS повторяются. DNS-рецидивы могут иметь IP-адрес сайта, кэшированный в их базе данных.
Если информация еще не попала в их систему, DNS запрашивает корневые DNS-серверы имен, которые, в свою очередь, перенаправляют ее на указанный сервер ДВУ на основе ДВУ веб-сайта.
Каждый ДВУ имеет свой собственный набор серверов имен. Они направляют повторяющиеся запросы на уполномоченный сервер имен, основанный на домене второго уровня, и повторяющиеся запросы на упомянутый уполномоченный сервер имен.
Рекурсор извлечет данные и сохранит запись в локальном кэше. Затем он посылает IP-адрес на ваш компьютер, который считывает и передает IP-адрес вашему браузеру.
Теперь ваш браузер имеет доступ к веб-сайту.

Типы запросов DNS

Есть 2 основных запроса, которые возникают при разрешении DNS.

Рекурсивный запрос

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

Итеративный запрос

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

Типы записей DNS [4]

История

Концепция системы доменных имен возникла в результате развития ARPANET, которая была разработана в 1966 году как эффективный метод передачи данных и информации между исследовательскими центрами по всей Америке. [5] К 1980 году через эту систему было подключено более 300 компьютеров, и было также создано несколько сайтов. Буквенные имена хостов были включены в систему, что устраняет необходимость запоминания пользователями IP-адресов, необходимых для доступа к нужным им серверам.

Однако по мере дальнейшего роста этой системы стала очевидной необходимость в более централизованной системе управления. Пол Мокапетрис, который тогда работал над эффективной системой организации файлов в компьютерах, смог предложить новый метод присвоения имен веб-сайтам с помощью своих коллег Джона Постеля и Зо Синг Су. [6]

Эта номенклатурная система предусматривала использование конкретного названия сайта и названия категории. Имя категории - это то, что мы теперь называем доменным именем верхнего уровня, в то время как конкретное имя сайта относится к доменному имени второго уровня. Разработка системы, которая была запрограммирована на преобразование доменного имени сайта в необходимый IP-адрес, устранила необходимость для пользователей знать IP-адрес сервера, к которому они хотели получить доступ. Эта организованная база данных расширяется и в настоящее время обслуживает более 270 миллионов доменов по состоянию на декабрь 2013 года.

Если вы хоть немного имели дело с интернетом и компьютерными сетями, то наверняка слышали о системе доменных имён (DNS). Прочитав статью узнаете, как это всё работает.

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

Сервер доменных имён — это устройство, которое сопоставляет имя хоста с IP-адресом конкретной машины/железа.

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

DNS-резолвер

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

25–27 ноября, Онлайн, Беcплатно

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

Время, в течение которого запись хранится в резолвере, называется TTL (time to live).

Его можно установить в панели управления сервиса, на котором приобретался домен.

Типы DNS-серверов

Корневой DNS-сервер

Это DNS-сервер, который хранит в себе адреса всех TLD-серверов (TLD — top-level domain, домен верхнего уровня). По пути от имени хоста до IP-адреса запрос сначала попадает на корневой DNS-сервер.

Существует 13 корневых DNS-серверов:

Организации, управляющие корневыми DNS-серверами

Это не означает, что существует только 13 машин, которые обрабатывают все запросы со всего мира — существуют и второстепенные серверы, по которым распределяется трафик.

TLD-серверы

Эти серверы связаны с доменами верхнего уровня (TLD). Обычно они идут после корневых DNS-серверов. В TLD-серверах содержится информация о домене верхнего уровня конкретного хоста.

Теперь возникает вопрос — откуда TLD-серверы знают адрес авторитативных серверов? Ответ прост — после того, как вы покупаете любой домен у регистраторов вроде Godaddy или Namecheap, регистраторы привязывают авторитативные серверы к TLD-серверу.

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

Авторитативный DNS-сервер

Запрос на эти серверы поступает в самую последнюю очередь. Эти серверы хранят фактические записи типа A, NS, CNAME, TXT, и т. п.

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

Типы DNS-запросов

Существует 3 типа DNS-запросов:

Рекурсивный: подобные запросы выполняют пользователи к резолверу. Собственно, это первый запрос, который выполняется в процессе DNS-поиска. Резолвером чаще всего выступает ваш интернет провайдер или сетевой администратор.
Нерекурсивные: в нерекурсивных запросах резолвер сразу возвращает ответ без каких-либо дополнительных запросов на другие сервера имён. Это случается, если в локальном DNS-сервере закэширован необходимый IP-адрес либо если запросы поступают напрямую на авторитативные серверы, что позволяет избежать рекурсивных запросов.
Итеративный: итеративные запросы выполняются, когда резолвер не может вернуть ответ, потому что он не закэширован. Поэтому он выполняет запрос на корневой DNS-сервер. А тот уже знает, где найти фактический TLD-сервер.

Попробуем рассмотреть этот процесс на рисунке:

Разберём рисунок выше:

Что в итоге?

Даже если вы измените запись у регистраторов, внесение изменений на резолверах всего мира займёт какое-то время. Этот процесс может длиться от 24 до 72 часов, но обычно завершается быстрее, т. к. за это время TTL-записи у провайдеров успевает истечь.

Основная цель 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, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги 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)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

Директива 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 не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
Резолверпосылает запрос указанному серверу имен.
Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
и «вложенности» доменных имен.
В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

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

Обратное преобразование имен

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 сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

Сервер доменных имён — это устройство, которое сопоставляет имя хоста с IP-адресом конкретной машины/железа.

DNS-резолвер

Время, в течение которого запись хранится в резолвере, называется TTL (time to live).

Его можно установить в панели управления сервиса, на котором приобретался домен.

Типы DNS-серверов

Корневой DNS-сервер

Существует 13 корневых DNS-серверов:

TLD-серверы

Авторитативный DNS-сервер

Типы DNS-запросов

Существует 3 типа DNS-запросов:

Рекурсивный: подобные запросы выполняют пользователи к резолверу. Собственно, это первый запрос, который выполняется в процессе DNS-поиска. Резолвером чаще всего выступает ваш интернет провайдер или сетевой администратор.
Нерекурсивные: в нерекурсивных запросах резолвер сразу возвращает ответ без каких-либо дополнительных запросов на другие сервера имён. Это случается, если в локальном DNS-сервере закэширован необходимый IP-адрес либо если запросы поступают напрямую на авторитативные серверы, что позволяет избежать рекурсивных запросов.
Итеративный: итеративные запросы выполняются, когда резолвер не может вернуть ответ, потому что он не закэширован. Поэтому он выполняет запрос на корневой DNS-сервер. А тот уже знает, где найти фактический TLD-сервер.

Попробуем рассмотреть этот процесс на рисунке:

Разберём рисунок выше:

Что в итоге?

Систему доменных имен DNS ( Domain Name System ) разработал Пол Мокапетрис (Paul Mokapetris), который на заре интернета (в начале 1980-х) задался вопросом, как работать в системе (она стала со временем называться DNS ), которая преобразует Web- адрес в состоящий из четырех октетов IP- адрес , который используется сетевыми машинами для связи через TCP/IP (см. "Работа в сети с использованием TCP/IP" ). Мокапетрис разработал иерархическое пространство имен , которое позволяло присваивать машинам понятные (дружественные) пользователям имена и связывать эти имена с IP-адресами. Эти группы машин разбивались на домены, и в каждом домене предусматривалось свое собственное управление

DNS можно также использовать для поиска элементов, хранящихся в базе данных LDAP . DNS – это клиент/ серверный процесс , который читает текстовый ("плоский") файл , аналогичный файлам HOSTS, которые вы можете иногда видеть и в настоящее время. В Windows DNS начали применять еще в версии NT4, и служба DNS стала составной частью операционной системы в Windows 2000. Это в основном произошло потому, что Microsoft перешла в используемом по умолчанию методе разрешения имен от имен NetBIOS и службы WINS ( Windows Internet Naming Service ) к полностью уточненным доменным именам FQDN (Fully Qualified Domain Names) и службе DNS . С появлением Active Directory ( AD ) и DNS , согласующейся с документом RFC 2136 (динамическое обновление записей) все изменилось еще больше. Еще больше вещей изменилось (и еще больше изменится) с появлением предложений по таблице для расширений DNSSEC ( RFC 2541). DNS по-прежнему является службой с серверной и клиентской ( resolver ) частями. Взаимодействие между DNS и Active Directory является взаимозависимым, то есть предлагается одна система вместо двух.

Создается впечатление, что эта интеграция с AD является обязательной, но это не так, если вы не планируете создавать домены и леса (более подробно об этом см. в "Описание Active Directory" ). И даже в этом случае она не является обязательной, но вам следует объединить эти два компонента, если вы хотите свести к минимуму администрирование . Возможно, у вас есть UNIX-станции; можно использовать DNS на Microsoft -станциях в стандартной (классической) конфигурации с первичным (primary) и вторичным ( secondary ) серверами DNS , если вам не нужен или вы не хотите использовать домен в своем окружении. Однако предпочтительно использовать конструкции леса/домены с контроллерами доменов через Active Directory .

Цель этой лекции – способствовать пониманию разрешения имен в целом, и, в частности, DNS , с выделением отличий между Windows 2000 и 2003. Вы также узнаете о прежней форме разрешения имен, которая применялась фирмой Microsoft : разрешение имен NetBIOS, которое происходило с помощью службы WINS ( Windows Internet Naming Service ).

Как это начиналось

Вы можете все еще использовать файлы HOSTS; обычно они находятся в подпапке %SYSTEMROOT\system32\drivers\.. . Вы можете редактировать такой файл с помощью Блокнота (Notepad) и добавлять в него любую машину, если у вас есть имя и IP-адрес этой машины, и вы знаете об изменениях в сети, которые могут повлиять на эти записи. Использование файла HOSTS сопряжено с ошибками, например, возможно дублирование имен или адресов. Этот подход не позволяет поддерживать масштабирование; достаточно представить себе, сколько затруднений может вызвать поддержка этих файлов для крупного предприятия. На каждой машине! Без каких-либо средств безопасности!

Разрешение имен в целом

Затем resolver анализирует вашу конфигурацию TCP/IP, определяет, какая машина является предпочтительным сервером DNS, и затем запрашивает этот сервер. Ваши клиенты более ранних версий Windows действуют иным образом; продукты на основе Windows 9x (DOS) сначала выполняют поиск среди имен NetBIOS. Они обращаются к DNS, если не удается поиск NetBIOS, но в некоторых случаях ожидание, пока не истечет период тайм-аута для NetBIOS, может вызывать ощутимую задержку. Причина очевидна: эти системы были созданы для работы в первую очередь с разрешением имен NetBIOS, которое происходило с помощью службы WINS. Со временем появилась DNS, и порядок поиска этих операционных систем теперь устарел, поскольку не отражает разрешение хост-имен сетью TCP/IP.

Напомним, что resolver запрашивает у первичного (primary) сервера DNS, может ли он преобразовать данное имя в IP-адрес. Этот сервер DNS проверяет свою зону и кэш, не находит соответствия и, тем самым, не может выполнить разрешение имени. Затем этот сервер DNS ищет другой сервер DNS и обращается к нему. Сервер DNS обычно устанавливается на "границе" сети компании, и все, что он делает, это пересылка запросов какому-либо серверу DNS снаружи. Этот тип сервера DNS называется сервером перенаправления запросов (forwarder). Внутренний сервер DNS запрашивает сервер перенаправления запросов, который сначала проверяет, может ли он сам выполнить разрешение имени. Если нет, то он передает данный запрос другим серверам DNS в интернете, пока не будет найдено соответствие или не произойдет отказ запроса. Успешно разрешенное имя возвращается в кэш локального сервера DNS, поэтому при повторных попытках посещения вебсайта Skillet разрешение будет происходить быстрее.

Рекурсивный (Recursive). Resolver (клиентский компонент) направляет запрос серверу DNS и не предполагает никакого взаимодействия для попытки найти ответ. Все проведение поиска возлагается на сервер DNS, который начнет использовать другие серверы, будет направлять запросы и действовать как представитель для resolver. Эти дальнейшие запросы называются итеративными.
Итеративный (Iterative). Итеративный запрос является противоположностью рекурсивного запроса (его также называют нерекурсивным); с его помощью у сервера DNS запрашивается наилучший ответ, и он должен отвечать без каких-либо запросов любым другим серверам DNS.
Обратный (Inverse). Этот тип запроса направляется машиной, которая ищет хост имя и отправляет IP-адрес, чтобы получить это хост-имя. Этот запрос необычен в том смысле, что сервер DNS выполняет просмотр только своей собственной зоны. Поиск ограничивается этой зоной при любом исходе – успешном или неудачном. Такой запрос используется редко, и он поддерживается только в Windows DNS для обеспечения обратной совместимости с прежними версиями DNS.
Только кэширующий сервер (Caching-only server). Эта функция DNS не является формально запросом, но она должна использоваться с запросами. Такой сервер не авторизуется и не содержит никакой зоны. Он получает запрос от клиента и передает этот запрос сети DNS для разрешения. Получив результат разрешения, он кэширует его на некоторый период времени на тот случай, если какой-либо другой клиент повторит тот же запрос. Это ускоряет разрешение имен.

Домены

Это обычное пространство DNS , известное как зона прямого поиска ( forward lookup zone ). Существует также зона обратного поиска ( reverse lookup zone ), известная также как in-addr. arpa , что является ее техническим названием. При запросе обратного поиска вместо дружественного для пользователя имени (как это происходит при поиске в зоне прямого поиска) выполняется поиск определенного IP-адреса машины. Записи в зоне обратного поиска содержат IP- адрес и затем имя машины. Resolver может определить, соответствует ли в действительности определенный IP- адрес дружественному имени, которое он указывает. Поскольку IP-адреса регистрируются вместе с доменными имена DNS , поиск по IP-адресу позволяет определить, из какого домена происходит этот IP- адрес . Если он не соответствует тому, что он должен представлять, то это может быть "самозванец".

IP-адреса организованы таким образом, что их "старшинство" повышается слева направо, а в доменных именах "старшинство" снижается слева направо. Но IP-адреса в домене in-addr. arpa (зона обратного поиска) записываются в обратном порядке. В записях-указателях (ptr-записях), которые добавляются в зону обратного поиска, сначала указывается IP- адрес и затем – хост-имя, – в отличие от зоны прямого поиска, где сначала идет хост-имя и затем – IP- адрес . Для выполнения успешного обратного поиска по заданному IP-адресу, например, 121.41.113.10, выполняющий поиск сервер DNS ищет PTR- запись для 10.113.41.121.in-addr. arpa , которая содержит определенное хост-имя и IP- адрес 121.41.113.10.

FQDN (Полностью уточненное доменное имя)

Теперь пришло время поговорить о зонах. Каждый домен является объектом со своей собственной политикой. Если посмотреть, как устроен один из серверов DNS внутри Microsoft, мы увидим в оснастке DNS определенные зоны. Зона может содержать домен, часть домена или ряд доменов; каждый из них может иметь сервер или серверы DNS, отвечающие за эти зоны. Должен существовать хотя бы один сервер DNS, поддерживающий каждую зону. Каждая зона имеет набор записей. Они называются ресурсными записями. Сервер DNS, который работает с определенной зоной, называют "руководящим" ("authority") для этой зоны. Он отвечает на любые запросы по этой зоне. Чтобы понять это, мы рассмотрим существующие виды зоны. Сюда относится их хранение, доступ и репликация, но не их содержимое (то есть записи – мы скоро увидим, как они устроены). Классические зоны DNS в Windows хранились и продолжают храниться в текстовых файлах с расширением .dns.

Первичная зона

Вторичная зона

Вторичная (secondary) зона извлекается из первичной и доступна только по чтению. Соответствующий сервер должен находиться в другой подсети и создается в небольших окружениях для избыточности; в более крупных окружениях это позволяет распространять вторичные серверы DNS в удаленные сайты для повышения производительности.

Зона, интегрированная с Active Directory

Эта версия зоны находится в Active Directory на каждом контроллере домена. Главная копия базы данных DNS реплицируется на каждый контроллер домена, и в нее может вносить изменения каждый контроллер домена (конечно, при соответствующих полномочиях). Нужно следить, сколько записей/зон используется в Active Directory (AD); слишком большое количество может вызывать снижение производительности.

Фиктивная (Stub) зона

Это новый тип зоны, появившийся в Windows 2003. Это копия дочерней зоны с записями, идентифицирующими дочерний сервер имен, который является "руководящим" для этой дочерней зоны. Она содержит SOA-запись, NS-запись и связывающую A-запись. Это известно как делегирование. Сервер родительской зоны может получать обновления от дочерней зоны, которые будут сохраняться в кэше сервера родительской зоны. Записи в такой зоне не изменяются. Ее назначение – это "склеивание" двух пространств имен, чтобы обеспечивать правильность ссылок из родительской зоны в дочернюю зону.

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

Записи

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

Читайте также: