DNS

Introduction

DNS (англ. Domain Name System «система доменных имён») — компьютерная распределённая система для получения информации о доменах.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Домен (англ. domain «область») — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имён
  
  Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости):
  
  
  1. вверху находится корневой домен (имеющий идентификатор «.»(точка))
  2. ниже идут домены первого уровня (доменные зоны)
  3. затем — домены второго уровня, третьего и т. д.
  
  
  
  
  Например, для адреса
  
  ru.wikipedia.org.
  
  домен первого уровня — org
  второго — wikipedia
  третьего — ru
  
  DNS позволяет не указывать точку корневого домена.
• Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org).
  
  Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов.
  
  Но на практике регистраторы доменных имён используют более строгие ограничения.
  
  Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
• Ресурсная запись — единица хранения и передачи информации в DNS.
  
  Каждая ресурсная запись имеет имя (то есть привязана к определённому доменному имени, узлу в дереве имён), тип и поле данных, формат и содержание которого зависит от типа.
• Зона — часть дерева доменных имён (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имён (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже).
  
  Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации.
  
  Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имён DNS как структуру из зон, а не отдельных узлов/имён, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчинённых.
  
  На практике большинство зон 0-го и 1-го уровня (, ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчинённых уровней без выделения их в дочерние зоны.
• Делегирование — операция передачи ответственности за часть дерева доменных имён другому лицу или организации. За счёт делегирования в DNS обеспечивается распределённость администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
• DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
• DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
• Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов.
  
  В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
  
  Авторитетный сервер имен-это сервер имен, который дает ответы на DNS-запросы только из данных, настроенных исходным источником, например администратором домена или динамическими методами DNS, в отличие от ответов, полученных с помощью запроса к другому серверу имен, который поддерживает только кэш данных.
  
  Авторитетный сервер имен может быть как основным, так и дополнительным сервером. Исторически термины "ведущий/ведомый" и "первичный/вторичный" иногда использовались взаимозаменяемо, но в настоящее время практика заключается в использовании последней формы.
  
  Основной сервер-это сервер, на котором хранятся исходные копии всех записей зоны. Вторичный сервер использует специальный механизм автоматического обновления в протоколе DNS для связи со своим основным сервером для поддержания идентичной копии первичных записей.
  
  Каждой зоне DNS должен быть назначен набор авторитетных серверов имен. Этот набор серверов хранится в родительской доменной зоне с записями сервера имен (NS).
  
  Авторитетный сервер указывает свой статус предоставления окончательных ответов, которые считаются авторитетными, устанавливая флаг протокола, называемый битом "Авторитетный ответ" (AA) в своих ответах. Этот флаг обычно воспроизводится на видном месте в выходных данных инструментов запросов администрирования DNS, таких как dig, чтобы указать, что отвечающий сервер имен является полномочным органом для рассматриваемого доменного имени.
  
  Когда сервер имен назначен полномочным сервером для доменного имени, для которого у него нет достоверных данных, он выдает ошибку типа "неудачное делегирование" или "неудачный ответ".
• DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).

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

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

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

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.

Рекурсия

Термином рекурсия в DNS обозначают алгоритм поведения DNS-сервера:

«выполнить от имени клиента полный поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам»

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

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

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

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

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

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

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

Предположим, мы набрали в браузере адрес

ru.wikipedia.org.

Браузер ищет соответствие этого адреса IP-адресу в файле hosts. Если файл не содержит соответствия, то далее браузер спрашивает у сервера DNS:

«какой IP-адрес у ru.wikipedia.org»?

Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org.

В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает —

«У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.»

Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает

«У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.»

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

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

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

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

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

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

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

Обратный просмотр DNS (англ. reverse DNS lookup) — обращение к особой доменной зоне для определения имени узла по его IP-адресу c помощью PTR-записи.

Для выполнения запроса адрес узла переводится в обратную нотацию, способ перевода зависит от версии IP:

IPv4-адрес 192.168.0.1 превращается в 1.0.168.192.in-addr.arpa.;
IPv6-адрес 2001:db8::567:89ab — в b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

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

Выполнение обратного запроса

При запросе считывается запись «PTR», содержащая искомое доменное имя. Если запись отсутствует или соответственный поддомен не делегирован, то IP-адрес считается не имеющим обратной записи DNS.

PTR-записи не требуют какой-либо специальной обработки, это простые записи, подобные CNAME, которые определяют псевдонимы.

in-addr.arpa

DNS-запись in-addr.arpa выглядит так:

56.34.12.10.in-addr.arpa. IN PTR host1.example.net.

Это будет означать, что IP-адресу 10.12.34.56 соответствует имя узла host1.example.net.

DNS-запись ip6.arpa выглядит так:

5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host1.example.net.

Это будет означать, что IPv6-адресу 2001:0db8::1:2345 соответствует имя узла host1.example.net.

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

Для решения этой проблемы был создан RFC 2317, описывающий делегирование поддоменов in-addr.arpa в бесклассовой адресации.

Для делегирования диапазонов адресов IPv6 используется доменная зона ip6.arpa.

Related Articles: