Authoritative dns server что это

Обновлено: 07.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.

Основная цель 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, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста(компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

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

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

Начиная с 2010 года, в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.

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

DNS обладает следующими характеристиками:

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности

поддержка динамических обновлений
защита данных (DNSSEC) и транзакций (TSIG)
поддержка различных типов информации

Терминология и принципы работы

Ключевыми понятиями DNS являются:

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

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

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

Рекурсия

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

Аналогично, DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.

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

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

Рассмотрим на примере работу всей системы.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

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

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

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

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS

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

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

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

Порядок разрешения имен и поправки связанные с кэшированием

При запросе имени происходит несколько важных процедур, которые необходимо учитывать. Во первых это данные о связке имя — IP адрес может храниться в нескольких местах ( Hosts, DNS Cash, Lmhosts, DNS Server и др). Для того что бы полностью понимать принцип работы — нужно знать порядок в котором Windows пытается разрешить любое имя.

При разрешении имени сверяется с локальным именем компьютера.
Если локальное имя не совпадает с запрашиваемым, то выполнятся поиск в DNS Cash. ВАЖНО: в DNS кэш динамически загружаются данные из файла HOSTS ( поэтому поиск по файлу hosts не происходит, его данные всегда в памяти ПК, что ускоряет обработку ). Файл Hosts расположен в%systemroot%\System32\Drivers\Etc
Если имя не разрешилось в IP адрес, то пересылается на DNS сервер, который задан в сетевых настройках.
Если имя сервера плоское ( к примеру: server1 ) и не может быть разрешено с помощью DNS, то имя конвертируется в NetBIOS имя и ищется в локальном кэше
Если имя не может разрешиться, то ищется на WINS серверах
Если имя не может быть определено и на WINS сервере, то ищется с помощью BROADCAST запроса в локальной подсети
Если имя не определилось, то ищется в файле LMHOSTS

На данном рисунке показывается все пункты:

Порядок разрешения имен и поправки связанные с кэшированием

Поиск по всем 7-ми шагам прекращается как только находится первое вхождение, удовлетворяющие условиям.

Примечание:
-Посмотреть DNS кэш можно по команде c:\>ipconfig /displaydns

Windows IP Configuration

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 72.233.56.138

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 67.19.16.228

-Очистить DNS кэш можно по команде ipconfig /flushdns
c:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Как можно самому посмотреть ответы на запросы?

Отличной утилитой для диагностики DNS является NSLookup.exe
На какие ключи я бы обратил внимание:

LServer — Можно принудительно подключиться к определенному DNS серверу
set type=** для выбора параметров, которые мы хотим получить, к примеру set type=mx

Состав UDP пакета

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

Состав UDP пакета-01

Состав UDP пакета-02

Зарезервированные доменные имена

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

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