Чем рекурсия отличается от итерации dns

Обновлено: 03.07.2024

Ресурсная запись (Resource Record – RR) – единица хранения и передачи информации в DNS. Каждая RR запись имеет имя (то есть привязана к определенному Доменному имени), тип и поле данных. Формат и содержание записи зависят от типа записи.

Зона ответственности – часть дерева доменных имен (включая resource record), размещаемая как единое целое на DNS сервере или серверах, даже если зона разбита на несколько распределенных серверов – логически это по-прежнему единое целое.

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

DNS сервер – связка ПО и компьютера для обработки запросов DNS, может быть ответственен за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.

DNS клиент – специализированная библиотека (или программа) для работы с DNS. Иногда DNS сервер выступает в роли DNS-клиента.

Авторитетность (authoritative) – признак размещения зоны на DNS сервере. Запросы могут быть двух типов:

авторитетные (authoritative) – сервер заявляет, что сам обслуживает запрашиваемый домен в своей зоне;
неавторитетные (non-authoritative) – сервер обрабатывает запрос и выдаёт результат из кэша (хранилище известных серверу DNS имён с привязкой к IP адресу) или от другого сервера.

DNS запрос (DNS query) – запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или итеративным.

Root-Hint – Well-known сервера отвечающие за корневой домен «.» (точка)

Введение

DNS – Domain Name System (Система доменных имён) применяется для преобразования IP адресов в доменные имена, для повышения удобства работы с сетевыми ресурсами, своего рода телефонный справочник интернета.

DNS – иерархичная система, ввиду того, что физически один сервер не может обрабатывать все мировые запросы, их существует множество, где на самой вершине есть корневые сервера, а следом за ними 13 TLD (Top level domain) серверов, для каждого региона.

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

Ключевые характеристики DNS:

Распределенность администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
Распределенность хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделенные как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

Протокол DNS использует для работы TCP/UDP протоколы и порт 53. Как правило запросы и ответы отправляются в виде одной UDP датаграммы. TCP применяется при превышение размера ответа длиною 512 байт и для AFXR запросов.

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

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

Рекурсия и итерация

Рекурсия – алгоритм работы DNS сервера, при котором он выполняет поиск записей от имени клиента во всей системе DNS и гарантирует клиенту либо адрес запрошенного имени, либо ошибку об отсутствии каких-либо записей по этому имени.

Итеративный запрос – запрос, при котором DNS сервер предоставляет либо сразу ответ (в том числе из кэша) либо направляет на другой DNS сервер, который может знать об искомом имени, исходя из искомого имени, либо вернуть отказ, если записей нет.

DNS сервер может выполнять от одних адресов рекурсивные запросы, от других – итеративные.

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

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

Рекурсивный запрос требует больше ресурсов (в отличии от итеративного) от аппаратного обеспечения, соответственно имеет смысл ограничить адреса, для которых выполняется такой алгоритм работы.

Обратный DNS запрос

DNS сервер, получивший обратный запрос, отзеркаливает IP адрес по октетам и добавляет доменное имя – “.in-addr.arpa” (вместо 193.116.70.23 будет 23.70.116.193.in-addr.arpa), запись такого формата говорит о необходимости поиска доменного имени по его адресу. Запись именно такого формата, нужна для одинакового поиска имени как в локальной сети, так и в сети интернет.

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

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:

имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше не ответственного DNS-сервера,
тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети.
длина поля данных (RDLEN),
поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

Записи SOA:

В каждой зоне должна быть только одна запись SOA.

Обозначает начало зоны, которая завершается следующей записью SOA. Состав зоны SOA:

NS (Name server)

Запись NS указывает имя машины, обеспечивающей службу имен для отдельного домена. Имя, связанное с RR, является доменным именем, а в качестве данных для таких записей используется имя хоста, обеспечивающего сервис имен.

A (Adress)

Для записей типа A данными служит IP адрес в десятичном формате с разделением точками.

CNAME (Canonical name)

Запись CNAME используется для псевдонимов (nickname). Имя, связанное с RR является псевдонимом. Поле данных записи содержит официальное имя.

Запись HINFO дает информацию об отдельном хосте. Данные в этом случае представляют собой две фразы, разделенные пробелом. В первой фразе приводится описание оборудования (hardware), а во второй -программ хоста. Описание оборудования обычно включает (имя производителя и модель, разделенные дефисом (-). Вторая фраза обычно содержит название операционной системы хоста. Официальные типы HINFO можно найти в последней версии RFC Assigned Numbers RFC-1700

MX (Mail Exchanger)

Указывает адрес сервера, который отвечает за почтовые сервисы, число в разделе preference – указывает приоритет сервера, где 0 – максимальный, обычно ставиться значение 10 и кратные.

PTR (Pointer)

Обратная запись, записывается в особом формате, пример такой записи:

51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.

Как правило, PTR запись выноситься в отдельную зону, соответственно создается отдельная SOA запись, состав которой дублирует основную, и содержащая под собой только PTR записи, для каждого домена должна быть только одна PTR запись.

Зоны ответственности

Primary (или же master) – мастер зона должна быть единственная на зону ответственности, только в ней допустимо вносить изменения касательно ресурсный записей, как правило мастер зона располагается на непосредственно локальном сервере.
Secondary (или же slave) – подчиненная зона не обязательно должна присутствовать в одном экземпляре, предназначена для избыточности, улучшение производительности, для сокрытия мастер-зоны (защита от атак), а так же для бэкапа. Подчиненная зона не может быть отредактирована.
Stub zone (зона-заглушка) – используется в ОС семейства Windows, работает по принципу slave зоны, но содержит информацию только о доменных серверах (NS записи).

Процесс разрешения имени

Шаг 1. Запрос информации

Обращаясь к какому-либо сетевому ресурсу по имени, клиент сперва пытается найти сопоставления у себя в локальном DNS кэше, или же в файле настроек hosts.

Шаг 2. Соединение с DNS сервером

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

Шаг 3. Поиск

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

Состав DNS запроса и ответа

DNS сервер использует 53-й UDP порт для запросов, обычно ответы идут одной дейтаграммой.

Состав UDP запроса:

Состав UDP ответа:

Детальная структура пакета DNS

Header — Заголовок DNS пакета, состоящий из 12 октет.

Question section — в этой секции DNS-клиент передает запросы DNS-серверу сообщая о том, для какого имени необходимо разрешить (зарезолвить) запись DNS, а также какого типа (NS, A, TXT и т.д.). Сервер при ответе, копирует эту информацию и отдает клиенту обратно в этой же секции.

Authoritative Section — содержит сведения о том, с помощью каких авторитетных серверов было получена информация включенная в секцию DNS-ответа.

Additional Record Section — дополнительные записи, которые относятся к запросу, но не являются строго ответами на вопрос.

Записей в секциях может быть как несколько, так и не быть вообще. Всё определяется заголовком.

Заголовок (Header)

QR (1 бит) — данный бит служит для индентификации того, является ли пакет запросом (QR = 0) или ответом (QR = 1).

Opcode (4 бита) — с помощью данного кода клиент может указать тип запроса, где обычное значение:

0	Запрос (Query)
1	Обратный запрос (IQuery (Inverse Query, OBSOLETE))
2	Статус (Status)
3	Не используется (Unassigned)
4	Уведомление (Notify)
5	Обновление (Update)
6	Статус операции (DNS Stateful Operations (DSO))
7-15	Не используется (Unassigned)

AA (1 бит) — данное поле имеет смысл только в DNS-ответах от сервера и сообщает о том, является ли ответ авторитетным либо нет.

TC (1 бит) — данный флаг устанавливается в пакете ответе в том случае если сервер не смог поместить всю необходимую информацию в пакет из-за существующих ограничений.

RA (1 бит) — отправляется только в ответах, и сообщает о том, что сервер поддерживает рекурсию

Z (3 бита) — являются зарезервированными и всегда равны нулю.

RCODE (4 бита) — это поле служит для уведомления клиентов о том, успешно ли выполнен запрос или с ошибкой:

0	(NoError)
1	(Format Error)
2	(Server Failure)
3	(Non-Existent Domain)
4	(Not Implemented)
5	Query Refused)
6	(Name Exists when it should not)
7	(RR Set Exists when it should not)
8	(RR Set that should exist does not)
9	(Server Not Authoritative for zone)
9	(Not Authorized)
10	(Name not contained in zone)
11	(DSO-TYPE Not Implemented)
12-15	Не используется
16	(Bad OPT Version)
16	(TSIG Signature Failure)
17	(Key not recognized)
18	(Signature out of time window)
19	(Bad TKEY Mode)
20	(Duplicate key name)
21	(Algorithm not supported)
22	(Bad Truncation)
23	(Bad/missing Server Cookie)
24-3840	Не используется
3841-4095	Зарезервировано
4096-65534	Не используется
65535	Зарезервировано

Секция запроса (Question)

QNAME — Каждая запись запроса и ответа начинается с NAME. Это доменное имя, к которому привязана или которому “принадлежит” данная запись. Она закодирована как серия меток.

Так же метка может содержать значение 0x00 (нулевая длина), означает что это корневое доменное имя (root).

Максимальная длина QNAME <= 255.

QTYPE — Тип записи DNS, которую мы ищем (NS, A, TXT и т.д.).

QCLASS — Определяющий класс запроса (IN для Internet).

NAME — такой же формат, что и QNAME в секции запроса.

TYPE — тип ресурсной записи. Определяет формат и назначение данной ресурсной записи.

CLASS — класс ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети. В основном IN для Internet (Код 0x0001)

TTL — (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера.

RDLENGTH — длина поля данных (RDATA).

RDATA — поле данных, формат и содержание которого зависит от типа записи.

Балансировка нагрузки Round Robin

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

5.255.255.70;
77.88.55.55;
77.88.55.70;
5.255.255.5,

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

Отказоустойчивость DNS

Программный вариант

Сделать перекрестное присвоение нескольких IP адресов, одному домену и реплицировать данные записи в вышестоящий DNS сервер(а), таким образом при запросе ищущий DNS сервер разрешит первую найденную(рабочую) запись, если запись не рабочая, то перейдет на следующую.

Главное чтобы все адреса ссылались в итоге на один ресурс.

Аппаратно-программный вариант

Необходимо организовать работу VRRP (Virtual Router Redundancy Protocol), протокол, представляющий объединение нескольких физических серверов в один большой (виртуальный) с общим IP адресом.

Несколько серверов разделяют один общий виртуальный IP (VIP), таким образом, что один является мастер-машиной, а другой бэкапом. Тот сервер, на сетевом интерфейсе в данный момент прописан VIP и является мастер-сервером и принимает запросы клиентов, а второй (бэкап-сервер) следит за первым, и в случае его отказа, подхватывает работу (сам становится мастер-сервером). Реализуется данная методика при помощи утилиты keepalived на Linux.

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

В 70-х — 90-х годах 20 века существовала сеть под названием ARPANET. Это была попытка объединить множество компьютеров министерством обороны США для возможности передачи информации во время войны. Важность такого подхода заключалась в быстрой передаче информации на дальние расстояния. Впоследствии принципы работы ARPANET легли в основу современного интернета.

Изначально вся сеть объединяла компьютеры в четырёх различных институтах США:

Калифорнийский университет в Лос-Анджелесе;
Стэнфордский исследовательский центр;
Университет Юты;
Калифорнийский университет в Санта-Барбаре.

В самом начале компьютеров, подключённых к сети, было несколько десятков, и их идентификаторы было легко запомнить. Можно было записать эти адреса в блокнот и использовать его так же, как и телефонные книги.

Время шло, и уже к середине 80-х годов вместо нескольких десятков компьютеров сеть стала насчитывать несколько тысяч. И каждый из них имел уникальный идентификатор, который становилось всё сложнее учитывать вручную или запоминать. Необходима была система, которая позволит очеловечить имена компьютеров и хранить все адреса в одном месте, чтобы каждый компьютер в сети имел один и тот же набор всех идентификаторов.

Файл hosts — как первый шаг к созданию DNS

Для решения задачи разработчики решили использовать словарь, который связывал уникальное имя и IP-адрес каждого компьютера в сети. Таким словарём стал файл hosts.txt, который и отвечал за привязку IP-адреса к имени компьютера. Файл лежал на сервере Стэнфордского исследовательского института, и пользователи сети регулярно вручную скачивали этот файл на свои компьютеры, чтобы сохранять актуальность словаря, ведь новые компьютеры появлялись в сети почти каждый день.

Выглядел hosts.txt тогда (да и сейчас) таким образом:

При наличии такого файла на компьютере пользователя для связи с компьютером Майка, можно было не запоминать цифры, а использовать понятное латинское имя «MIKE-STRATE-PC».

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

В Unix-системах: /etc/hosts
В Windows-системах: %Путь до папки Windows%/system32/drivers/etc/hosts

Компьютеру с IP-адресом 192.168.10.36, который находится внутри локальной сети мы указали имя «MIKE-STRATE-PC». После чего можно воспользоваться командой ping, которая пошлёт специальный запрос на компьютер Майка и будет ждать от него ответа. Похоже на то, как вы стучитесь в дверь или звоните в звонок, чтобы узнать, «есть ли кто дома?» Такой запрос можно послать на любой компьютер.

По мере развития сети и «обрастания» её новыми клиентами, такой способ становился неудобным. Всем пользователям компьютеров было необходимо всё чаще скачивать свежую версию файла с сервера Стэнфордского исследовательского института, который обновлялся вручную несколько раз в неделю. Для добавлений же новых версий было необходимо связываться с институтом и просить их внести в файл новые значения.

В 1984 году Пол Мокапетрис (Paul Mockapetris) описал новую систему под названием DNS (Domain Name System / Система доменных имён), которая была призвана автоматизировать процессы соотнесения IP-адресов и имён компьютеров, а также процессы обновления имён у пользователей без необходимости ручного скачивания файла со стороннего сервера.

Работа DNS в сети интернет

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

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

Рассмотрим работу DNS и её составных частей поближе.

Терминология

Основными компонентами DNS являются:

Домен (доменное имя) — символьное имя для обозначения сервера в сети интернет. Доменные имена являются иерархической структурой, в которой каждый уровень отделяется точкой. Основными уровнями являются:

DNS-сервер — система, ответственная за хранение и поддержание в актуальном состоянии записей о своих дочерних доменах. Каждый DNS-сервер ответственен только за свою зону, то есть DNS-сервер домена .io знает о том, где расположен домен hexlet, DNS-сервер которого знает о расположении своих поддоменов.

Корневой DNS-сервер — система, знающая расположение (IP-адреса) DNS-серверов доменов верхнего уровня.

Ресурсная запись — единица информации DNS-сервера. Каждая ресурсная запись имеет несколько полей:

Имя (домен, к которому относится запись)
Тип
Параметры
Значение

Подключение

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

Рассмотрим процесс получения IP-адреса по доменному имени на примере домена ru.hexlet.io .

Возможны два варианта событий:

Компьютер посылает запрос на известный ему DNS-сервер. Чаще всего им является DNS-сервер поставщика интернет-услуг (провайдера): какой IP-адрес у домена ru.hexlet.io?. DNS-сервер провайдера находит в своей базе информацию о том, что домен ru.hexlet.io расположен по IP-адресу 104.25.238.104 и возвращает значение нашему компьютеру. Этот процесс похож на то, как использовался файл hosts.txt .

Ближайший известный DNS-сервер не имеет записи о том, по какому IP-адресу располагается домен ru.hexlet.io . В таком случае запускается цепочка процессов, благодаря которым наш компьютер получит IP-адрес домена:

Так как домен является иерархической структурой, и все DNS-сервера знают IP-адреса корневых DNS-серверов, то к ним и происходит запрос на получение IP-адреса домена.

Корневые DNS-сервера, в соответствии со своей зоной ответственности знают о том, где располагаются DNS-сервера доменов верхнего уровня. Эти адреса возвращаются DNS-серверу нашего провайдера, после чего на нужный DNS-сервер (в нашем случае на DNS-сервер домена .io) посылается запрос на получение IP-адреса домена ru.hexlet.

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

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

Рекурсия в DNS

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

При запросах 1 и 2 ближайший сервер будет получать информацию о местонахождении DNS-серверов, которые входят в зону ответственности того сервера, на который был послан запрос. При запросе 3 будут получены необходимые ресурсные записи домена hexlet и его поддоменов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример реальных записей DNS

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

Вывод состоит из нескольких частей:

Шапка
Секция запроса
Секция ответа
Служебная информация

Шапка запроса

Секция запроса

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

Секция ответа

Секция ответа достаточно большая, поэтому для удобства разобьём её по типам ресурсных записей.

Как запись A, так и AAAA-запись указывают на IP-адрес, который привязан к нашему домену. A-запись указывает IP в формате IPv4, а запись AAAA — в формате IPv6.

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

Запись SOA (Start of Authority) указывает на несколько различных параметров:

Сервер с эталонной информацией о текущем домене
Контактную информацию ответственного лица
Различные параметры кеширования записей

Бывают и некоторые более специфичные ресурсные записи, о которых здесь не было речи, но это не значит, что они бесполезны. Полный перечень таких записей всегда можно найти в документации (например по DNS-серверу BIND).

Выводы

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

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

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

Содержание:

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

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

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

Заголовок состоит из следующих полей:

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

Флаги — 16-битовое поле, поделенное на 8 частей:

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

определяются все зоны, которые должны быть загружены;
из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
начинается обработка запросов и удаленных вызовов процедур (RPC);
создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

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

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

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

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

После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.

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

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

Основная концепция преобразования 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)

Если предположить также, что включена DNS рекурсия, то сервер DNS server начинает работать в роли DNS клиента и отправляет серию итерационных запросов на другие сервера DNS. Я объясню разницу между итеративным (iterative) и рекурсивным (recursive) запросом позднее, а сейчас просто представьте, что в целом процесс считается рекурсивным потому, что клиент отправляет лишь один запрос на предпочтительный сервер DNS (preferred DNS server).

Если сервер DNS не поддерживает рекурсивные очереди (recursive queries), то клиент по умолчанию будет выполнять итеративные запросы (iterative queries).

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

Заключение

В этой статье я рассказал о том, как работает рекурсивная очередь DNS (recursive DNS query). Большинство серверов DNS поддерживают, как рекурсивные (recursive), так и итеративные запросы от клиентов. Если вы настроите ваш сервер DNS на поддержку рекурсивных очередей (recursive queries), то в общем сможете добиться лучшей производительности, т.к. благодаря этому можно добиться снижению количества запросов, которые должен совершить сетевой клиент.

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