Система dns

Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. На раннем этапе развития Internet на каждом хосте вручную создавался текстовый файл с известным именем hosts. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару «IP-адрес — доменное имя», например 102.54.94.97 — rhino.acme.com.

По мере роста Internet файлы hosts также росли, и создание масштабируемого решения для разрешения имен стало необходимостью.

Таким решением стала специальная служба — система доменных имен (Domain Name System, DNS). DNS — это централизованная служба, основанная на распределенной базе отображений «доменное имя — IP-адрес». Служба DNS использует в своей работе протокол типа «клиент-сервер». В нем определены DNS-серверы и DNS-кли-енты. DNS-серверы поддерживают распределенную базу отображений, а DNS-клиен-ты обращаются к серверам с запросами о разрешении доменного имени в IP-адрес.

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

Для каждого домена имен создается свой DNS-сервер. Этот сервер может хранить отображения «доменное имя — IP-адрес» для всего домена, включая все его поддомены. Однако при этом решение оказывается плохо масштабируемым, так как при добавлении новых поддоменов нагрузка на этот сервер может превысить его возможности. Чаще сервер домена хранит только имена, которые заканчиваются на следующем ниже уровне иерархии по сравнению с именем домена. (Аналогично каталогу файловой системы, который содержит записи о файлах и подкаталогах, непосредственно в него «входящих».) Именно при такой организации службы DNS нагрузка по разрешению имен распределяется более-менее равномерно между всеми DNS-серверами сети. Например, в первом случае DNS-сервер домена mmtru будет хранить отображения для всех имен, заканчивающихся на mmt.ru: wwwl.zil.mmt.ru, ftp.zil.mmt.ru, mail.mmt.ru и т. д. Во втором случае этот сервер хранит отображения только имен типа mail.mmt.ru, www.mmt.ru, а все остальные отображения должны храниться на DNS-сервере поддомена zil.

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

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

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

Существуют две основные схемы разрешения DNS-имен. В первом варианте работу по поиску IP-адреса координирует DNS-клиент:

• DNS-клиент обращается к корневому DNS-серверу с указанием полного доменного имени;

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

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

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

Во втором варианте реализуется рекурсивная процедура:

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

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

• если же локальный сервер не знает ответ, то он выполняет итеративные запросы к корневому серверу и т. д. точно так же, как это делал клиент в первом варианте; получив ответ, он передает его клиенту, который все это время просто ждал его от своего локального DNS-сервера.

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

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

Выводы

• В стеке TCP/IP используются три типа адресов: локальные (называемые также аппаратными), IP-адреса и символьные доменные имена. Все эти типы адресов присваиваются узлам составной сети независимо друг от друга.

• IP-адрес имеет длину 4 байта и состоит из номера сети и номера узла. Для определения границы, отделяющей номер сети от номера узла, реализуются два подхода. Первый основан на понятии класса адреса, второй — на использовании масок.

• Класс адреса определяется значениями нескольких первых бит адреса. В адресах класса А под номер сети отводится один байт, а остальные три байта — под номер узла, поэтому они используются в самых больших сетях. Для небольших сетей больше подходят адреса класса С, в которых номер сети занимает три байта, а для нумерации узлов может быть использован только один байт. Промежуточное положение занимают адреса класса В.

  
  

• Другой способ определения, какая часть адреса является номером сети, а какая номером узла, основан на использовании маски. Маска — это число, которое используется в паре с IP-адресом; двоичная запись маски содержит единицы в тех разрядах, которые в IP-адресе должны интерпретироваться как номер сети.

• Номера сетей назначаются либо централизованно, если сеть является частью Internet, либо произвольно, если сеть работает автономно.

• Процесс распределения IP-адресов по узлам сети может быть автоматизирован с помощью протокола DHCP.

• Установление соответствия между IP-адресом и аппаратным адресом (чаще всего МАС — адресом) осуществляется протоколом разрешения адресов ARP, который для этой цели просматривает ARP-таблицы. Если нужный адрес отсутствует, то выполняется широковещательный ARP-запрос.

• В стеке TCP/IP применяется доменная система символьных имен, которая имеет иерархическую древовидную структуру, допускающую использование в имени произвольного количества составных частей. Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен. Доменные имена назначаются централизованно, если сеть является частью Internet, в противном случае — локально.

• Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста с использованием файла hosts, так и с помощью централизованной службы DNS, основанной на распределенной базе отображений «доменное имя — IP-адрес».

Выводы

• Протокол IP решает задачу доставки сообщений между узлами составной сети. Протокол IP относится к протоколам без установления соединений, поэтому он не дает никаких гарантий надежной доставки сообщений. Все вопросы обеспечения надежности доставки данных в составной сети в стеке TCP/IP решает протокол TCP, основанный на установлении логических соединений между взаимодействующими процессами.

• IP-пакет состоит из заголовка и поля данных. Максимальная длина пакета 65 535 байт, Заголовок обычно имеет длину 20 байт и содержит информацию о сетевых адресах отправителя и получателя, о параметрах фрагментации, о времени жизни пакета, о контрольной сумме и некоторых других. В поле данных IP-пакета находятся сообщения более высокого уровня, например TCP или UDP.

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

• Существует несколько источников, поставляющих записи в таблицу маршрутизации. Во-первых, при инициализации программное обеспечение стека TCP/ IP заносит в таблицу записи о непосредственно подключенных сетях и маршрутизаторах по умолчанию, а также записи об особых адресах типа 127.0.0.0. Во-вторых, администратор вручную заносит статические записи о специфичных маршрутах или о маршрутизаторе по умолчанию. В-третьих, протоколы маршрутизации автоматически заносят в таблицу динамические записи о имеющихся маршрутах.

  
  

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

• Значительная роль в будущем IP-сетей отводится технологии бесклассовой междоменной маршрутизации (CIDR), которая решает две основные задачи. Первая состоит в более экономном расходование адресного пространства — благодаря CIDR поставщики услуг получают возможность «нарезать» блоки разных размеров из выделенного им адресного пространства в точном соответствии с требованиями каждого клиента. Вторая задача заключается в уменьшении числа записей в таблицах маршрутизации за счет объединения маршрутов — одна запись в таблице маршрутизации может представлять большое количество сетей с общим префиксом.

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

studfiles.net

Зачем нужны DNS-сервера и что это такое?

Когда интернет только формировался, то было решено внедрить такую вещь, как домены. Фактически, это имя для узла сети (компьютера, сервера или в более общем смысле слова — хоста).

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

Система же доменных имен оперирует уже полноценными именами (буквы латиницы, цифры, тире и нижнее подчеркивание допускается при их формировании). Их гораздо легче запомнить, они несут смысловую нагрузку (доменное имя моего блога ktonanovenkogo.ru о чем-то уже говорит, а реальный его АйПи 109.120.169.66 малоинформативен) и ими проще оперировать.

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

Вот именно на этих ДНС-серверах (иногда их еще называют NS от Name Server, т.е server имен) и держится весь интернет (как плоский мир на трех китах, стоящих на черепахе). Сервер, если вы помните, это просто служебный компьютер не требующий непосредственного участия человека в своей работе (настроили его — он и пашет в режиме 24 на 7). И таких DNS-серверов в сети очень много.

Как работает DNS и причем тут файл Hosts?

На заре интернета ДНС вообще не существовало. Но как же тогда работала сеть? Как браузер понимал, что ktonanovenkogo.ru — это то же самое, что IP адрес 109.120.169.66? За это дело тогда (да и сейчас тоже) отвечал так называемый файл Hosts, где были прописаны все хосты тогда еще маленького интернета.

Такой файл находился (и сейчас находится) на каждом компьютере пользователя (на вашем тоже он есть) подключенного к сети (как его найти смотрите по приведенной выше ссылке).

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

109.120.169.66 ktonanovenkogo.ru

Любой браузер (что это такое?) на любом компьютере (даже сейчас) при вводе в адресную строку УРЛа (что это такое?) прежде всего обращается к файлу Hosts на предмет поиска там введенного доменного имени, и лишь не найдя там нужной записи обращается за этой информацией к ближайшему DNS-серверу (как правило, это сервак вашего интернет-провайдера).

Сейчас файл Hosts стал рудиментом (пережитком прошлого) и там обычно есть только одна запись (127.0.0.1 localhost) означающая, что локальным хостом нужно считать данный компьютер.

Правда иногда его используют вирусы и другие зловреды, чтобы вместо одного сайта вы попадали на другой (про фишинг слышали?) — ведь для этого достаточно добавить всего одну строчку в файл Hosts (можете сами прописать в нем, например, «109.120.169.66 yandex.ru» и вместо Яндекса браузер вам будет упорно открывать мой блог). Вот именно поэтому его целостность охраняют большинство антивирусов.

Как ДНС-сервера помогают браузеру ориентироваться в сети?

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

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

Еще раз поясню цепочку «метаний» браузера при вводе в него Урл адреса сайта. Итак, сначала он обращается к файлу Hosts, потом к ближайшему ДНС-серваку. Он же в ответ передает нужную информацию (о том, какой именно IP адрес соответствует данному домену) нашему браузеру или запрашивает ее у вышестоящего NS-сервера, если такой информации у себя он не находит.

И лишь только после этого браузер обращается к самому сайту по только что узнанному IP адресу. Долго, правда? Но что делать? Иначе никак.

Правда браузер «хитрит» и сохраняет всю полученную от ДНС серверов информацию в свой кеш, чтобы потом не терять время на эти запросы по поводу IP адреса сайта. Естественно, что кеш хранится не вечно, но часто посещаемые пользователем сайты благодаря этому в браузере будут открываться быстрее (кэш — это вообще вещь!).

Какую роль играют NS-сервера хостинга в DNS системе?

На приведенном выше рисунке показана сильно упрощенная схема, по которой не очень понятна роль отдельных уровней ДНС-серверов. Чуть ниже приведена более развернутая схема (хотя и опять же очень упрощенная).

Если вы владелец сайта, то знаете, что при покупке хостинга (или получении его бесплатно) вам выдают адреса NS-серверов (обычно их два), которые нужно будет прописать у вашего регистратора доменных (как это сделать описано чуть ниже). Например, мой хостер Инфобокс выдал мне два адреса (ns1.pa.infobox.ru и ns2.pa.infobox.ru).

Вопрос, как эти адреса NS участвуют в схеме определения IP-адреса по имени домена. Собственно, это показано на приведенном выше рисунке, но я все же поясню:

1. Как я уже писал выше, ваш компьютер при вводе в адресной строке Урла типа «ktonanovenkogo.ru» в первую очередь связывается с DNS-серверами вашего интернет-провайдера. Если в их кэше имеется IP адрес соответствующий данному домену, то он незамедлительно будет выдан браузеру и все на этом закончится. В смысле, браузер используя полученный АйПи обратится к моему блогу и откроет запрашиваемую вами страницу.
2. Если у вашего интернет-провайдера этой информации не найдется, то он обратится к одному из корневых ДНС-серваков (их не так уж и много и информация на них обновляется не часто — от одного до нескольких раз в сутки).
3. Корневые серваки не могут дать вам сразу пару «домен — IP», но зато могут сказать, где эту информацию наверняка можно найти. Т.е. они выдают интернет-провайдеру адреса тех ДНС-серверов, в которых прописана искомая информация об интересующем домене. В нашем случае это будут как раз те самые адреса NS хостера, где физически в данный момент расположены файлы сайта (ns1.pa.infobox.ru и ns2.pa.infobox.ru в моем случае).
4. Получив эту информацию ваш интернет-провайдер обратится по одному из полученных NS-адресов и найдет там информацию о том, какой АйПи-адрес на данный момент соответствует домену «ktonanovenkogo.ru».
5. ДНС-server вашего интернет-провайдера запомнит эту информацию в свой кэш (чтобы при следующих обращения не повторять всю приведенную выше цепочку запросов) и незамедлительно передаст искомый IP вашему браузеру.
6. И только после этого браузер сможет обратиться к виртуальному серваку моего хостинга, где расположен блог https://ktonanovenkogo.ru. В результате на экране вашего компьютера откроется одна из страниц моего сайта.

ktonanovenkogo.ru

Ключевые характеристики DNS[править | править код]

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

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

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

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

Дополнительные возможности[править | править код]

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

История[править | править код]

Использование более простого и запоминающегося имени вместо числового адреса хоста относится к эпохе ARPANET. Стэнфордский исследовательский институт (теперь SRI International) поддерживал текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPANET. Поддержание числовых адресов, называемых списком присвоенных номеров, было обработано Джоном Постелем в Институте информационных наук Университета Южной Калифорнии (ISI), команда которого тесно сотрудничала с НИИ.^[1]

Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с сетевым информационным центром (NIC) SRI, руководимым Элизабет Фейнлер, по телефону в рабочее время.

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

Рабочая группа IETF опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года.

В 1984 году четыре студента UC Berkeley, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонгниан Чжоу, написали первую версию сервера имен BIND (Berkeley Internet Name Daemon). В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карел, Фил Альмквист и Пол Викси поддерживали BIND с тех пор. В начале 1990-х годов BIND был перенесен на платформу Windows NT. Он широко распространен, особенно в Unix-системах, и по-прежнему является наиболее широко используемым программным обеспечением DNS в Интернете.

В ноябре 1987 года были приняты спецификации DNS — RFC 1034 и RFC 1035. После этого были приняты сотни RFC, изменяющих и дополняющих DNS.

Проблемы с безопасностью[править | править код]

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

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

DNS-ответы ранее не имели криптографической подписи, что давало возможность для множества вариантов атаки. Современные расширения системы безопасности доменных имен (DNSSEC) изменяют DNS, чтобы добавить поддержку криптографически подписанных ответов. Другие расширения, такие как TSIG, добавляют поддержку криптографической аутентификации между доверенными одноранговыми узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.

Некоторые доменные имена могут использоваться для достижения эффектов спуфинга. Например, paypal.com и paypa1.com — это разные имена, но пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя. Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, которые поддерживают интернационализированные доменные имена, поскольку многие коды символов в ISO 10646 могут отображаться на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге.

Для подтверждения результатов DNS также могут использоваться такие методы, как обратный DNS с подтверждением прямых записей, но криптографически достоверными они не являются; при этом не учитывается вариант подмены маршрутной информации (англ. BGP hijacking).

Терминология и принципы работы[править | править код]

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

• Доме́н (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имён. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (имеющий идентификатор «.»(точка)), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго — wikipedia, третьего — ru).
• Поддомен (англ. 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 query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).

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

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

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

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

Рекурсия[править | править код]

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

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

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

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

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

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

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера 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 используется в первую очередь для преобразования символьных имён в 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. Каждая ресурсная запись состоит из следующих полей^[3]:

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

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

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (pointer^[5][6]) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Зарезервированные доменные имена[править | править код]

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена[править | править код]

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

Программное обеспечение DNS[править | править код]

Серверы имен:

• BIND (Berkeley Internet Name Domain) [1]
• djbdns (Daniel J. Bernstein’s DNS) [2]
• Dnsmasq [3]
• MaraDNS [4]
• NSD (Name Server Daemon) [5]
• PowerDNS [6]
• OpenDNS [7]
• Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
• MyDNS [8]

См. также[править | править код]

• Атака Каминского
• Альтернативные корневые серверы DNS
• OpenDNS
• Google Public DNS
• Яндекс.DNS
• Киберсквоттинг
• Тайпсквоттинг
• Динамический DNS
• Round robin DNS — распределение нагрузки между одинаковыми серверами.
• ICANN
• DNSSEC
• DNS-клиент
• DNS-сервер
• Nslookup

Ссылки[править | править код]

• DNS Resources Directory  (англ.)
• Ресурсы, посвящённые DNS & BIND  (англ.)
• Общество CircleID DNS  (англ.)
• Повышение безопасности DNS (DNSSEC)  (англ.)
• Рабочий комитет IETF занимающийся разработкой расширенной спецификации DNS (DNSEXT)  (англ.)
• Сайт корневых DNS-серверов  (англ.)
• Просмотр DNS-записей домена
• Веб-инструменты для DNS, каталог на сайте dmoz.org  (англ.)

Статьи[править | править код]

• Обзор схем и типов DNS-атак

ru.wikipedia.org

Что такое ДНС (DNS)?

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

Для того, чтобы не запоминать числовой адрес компьютера, была создана система DNS. Система Доменных Имен или DNS (Domain Names System), связывает имена, подобные www.htmlweb.ru c цифровыми адресами(127.0.0.1), которые используют компьютеры, чтобы связываться друг с другом.

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

ns1.yourhosting.ru
ns2.yourhosting.ru

Есть три пути настроки DNS:

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

Как указать (изменить) DNS-сервера для домена?

Для указания/изменения DNS-сервера у домена, то Вам необходимо:

1. зарегистрироваться у регистратора домменых имен;
2. Найти нужный домен и выбрать там «Управление DNS-серверами / Делегирование»
3. В открывшейся форме укажите нужные DNS-сервера (IP можно не указывать). или установите галочку «Использовать DNS-сервера регистратора».
4. Нажмите на кнопку «Сохранить».

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

Настрока DNS-записей.

Для внесения/изменения записей на DNS сервере Вам необходимо сделать следующее:

1. Авторизуйтесь в панели управления Вашего хостинга DNS Найдите нужный домен и выберите там «Управление зоной DNS»
2. В открывшейся форме Вы можете вносить записи типа A, CNAME и другие в зоны DNS.
3. После внесения записей нажмите на кнопку «Сохранить/Добавить».

Пример внесения записей в DNS:

Предположим, вы зарегистрировали домен mydomain.ru и IP-адрес web-сервера, на котором будет расположен сайт — 195.128.128.26. В этом случае Вам потребуется создать минимум две записи типа «A» для Вашего домена (чтобы связать mydomain.ru и www.mydomain.ru с адресом 195.128.128.26). Для этого в форме добавления записей «A» в поле «Имя поддомена» укажите «@» для первой записи и «www» для второй записи, а в поле «Данные» укажите 195.128.128.26 (для обоих записей).

Чтобы сделать пересылку всех поддоменов на IP адрес, нужно в качестве «Имени поддомена» указать *

Пример 2: Вы хотите, чтобы адрес mail.mydomain.ru указывал на тот же хост, что и адрес relay.highway.ru. Для этого необходимо в поле ‘Имя поддомена’ указать «mail», выбрать ‘Тип записи’ CNAME, а в поле ‘Данные’ указать «relay.highway.ru.».

Пример DNS-записей для зоны mydomain.ru:

 @ A 195.161.114.80 @ MX 10 relay.highway.ru. www A 195.161.114.80 ctrl CNAME ctrl.muse.highway.ru. ftp CNAME ftp.muse.highway.ru. mail CNAME relay.highway.ru. ssh CNAME ssh.muse.highway.ru. 

Смотрите также: настрока Яндекс-почты для домена.

Инструкции по смене DNS-серверов

1. Если вы указываете у домена RU, SU, РФ DNS-сервера, которые расположены в этом же домене (т.е. «свои» DNS), например, для домена testsite.ru вы указываете DNS-сервера ns1.testsite.ru и ns2.testsite.ru, то обязательно необходимо указать для каждого DNS-сервера его IP адрес.
2. Если вы указываете у любого домена DNS-сервера, которые расположены в другом домене, например, для домена testsite.ru вы указываете DNS-сервера ns1.abrakadabra.ru и ns2.abrakadabra.ru, то указывать для каждого DNS-сервера IP адреса не нужно.
3. IP адреса у DNS-серверов (в случае необходимости их указания, см. выше) для доменов RU, SU, РФ должны отличаться хотя бы на одну цифру! Одинаковые IP для всех DNS не допустимы.
4. Для международных доменов (com, net, org, info и т.п.) DNS-сервера, которые вы указываете у домена, должны быть обязательно зарегистрированы в международной базе NSI Registry. Если они там не зарегистрированы, то указать их нельзя. Для международных доменов IP адреса у DNS-серверов указывать не нужно. Они указываются при регистрации DNS в базе NSI Registry

Как прикрепить домен к IP адресу?

Для того, чтобы прикрепить домен к IP адресу, Вам необходимо:

1. зайти в настроку dns-записей и внести в зону DNS три записи:
   • Для первой в качестве поддомена укажите www, выберите тип записи А, в качестве данных укажите IP адрес, к которому нужно прикрепить домен.
   • Для второй записи укажите знак @ (собака) в качестве поддомена и так же выберите тип А и укажите тот же IP.
   • Для третьей записи в качестве поддомена укажите знак * (звёздочку) и так же выберите тип А и укажите тот же IP.
2. Нажмите «Добавить/Сохранить»

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

Как долго происходит изменение DNS?

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

htmlweb.ru

Что такое DNS-серверы

«DNS-сервер» — это «программа», которая хранит таблицу соответствий вида «имя домена» — «IP-адрес», примерно так:

На самом деле, на DNS-серверах хранится не только IP-адрес сервера, но и другие данные, такие как ресурсные DNS-записи «MX», «TXT», «A», «CNAME», «SOA». Что такое «Ресурсные записи DNS»

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

Зачем прописывать DNS-серверы для домена

Когда вы регистрируете новый домен, ни один DNS-сервер в Интернет о нём не знает. И пока на DNS-серверах Интернета не появится информация о вашем домене, ни сайт, ни почта, никакие другие сервисы работать не будут.

Чтобы DNS-серверы в Интернет узнали о вашем домене, им это должен кто-то рассказать, и этот кто-то — DNS-сервер, который вы прописываете для своего домена. Он играет роль «глашатая», который всегда хранит самую свежую информацию о вашем домене. Например, DNS-серверы хостинга ns1.hosting.reg.ru и ns2.hosting.reg.ru хранят информацию о доменах, которые подключены к хостингу REG.RU.

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

Схема определения IP-адреса по имени домена

На данной схеме коротко объясняется, что происходит, когда вы хотите зайти на тот или иной сайт.

Итак:

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

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

www.reg.ru

Уровни DNS

Дерево DNS принято делить по уровням: первый, второй, третий и так далее. При этом начинается система с единственного корневого домена (нулевой уровень). Интересно, что про существование корневого домена сейчас помнят только специалисты, благодаря тому, что современная DNS позволяет не указывать этот домен в адресной строке. Впрочем, его можно и указать. Адресная строка с указанием корневого домена выглядит, например, так: «site.test.ru.» – здесь корневой домен отделен последней, крайней справа, точкой. Как несложно догадаться, адреса с использованием DNS записываются в виде последовательности, отражающей иерархию имен. Чем «выше» уровень домена, тем правее он записывается в строке адреса. Разделяются домены точками. Разберем, например, строку www.site.nic.ru. Здесь домен www – это домен четвертого уровня, а другие упомянутые в этой строке домены расположены в домене первого уровня RU. Например, site.nic.ru – это домен третьего уровня. Очень важно понимать, что привычный адрес веб-сайта, скажем, www.test.ru, обозначает домен третьего уровня (www), расположенный внутри домена второго уровня test.ru.

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

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

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

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

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

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

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Рассмотрим на примере работу всей системы. Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер знает только IP-адрес сервера DNS, обычно это один из серверов интернет-провайдера. Он спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org?». Сервер DNS обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 поддерживает доменную зону org.» Браузер направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 поддерживает доменную зону wikipedia.org.» Наконец, браузер отправляет свой запрос к третьему DNS-серверу (который является авторизированным сервером для домена wikipedia.org), и получает ответ — IP-адрес. Этот процесс называется рекурсивным поиском.

Имя хоста и IP-адрес не тождественны — хост с одним IP может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки. Запрос на определение имени обычно не идёт дальше кэша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Обычно вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше. Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе. Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Записи DNS

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

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

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

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (point to reverse) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

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

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

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

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

Программное обеспечение DNS

Серверы имен:

• BIND (Berkeley Internet Name Domain)
• djbdns (Daniel J. Bernstein’s DNS)
• MaraDNS
• NSD (Name Server Daemon)
• PowerDNS
• OpenDNS
• Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
• MyDNS

Примечания

1. Текущая версия корневой зоны всегда находится по адресу: ftp://ftp.internic.net/domain/named.root
2. RFC 5395 — Domain Name System (DNS) IANA Considerations
3. Детали по возможным значениям поля: http://tools.ietf.org/html/rfc5395#section-3.2

Документы RFC

• RFC 1034 — Domain Names — Concepts and Facilities
• RFC 1035 — Domain Names — Implementation and Specification
• RFC 1912 — Common DNS Operational and Configuration Errors
• RFC 1591 — Domain Name System Structure and Delegation
• RFC 1713 — Tools for DNS Debugging
• RFC 2606 — Reserved Top Level DNS Names

Интересное

• Домен.РФ – советы по регистрации от профессионалов
• DNS безалаберность Вконтакте и других компаний
• Установка и настройка авторитетного DNS сервера на основе решения PowerDNS
• Как улучшить анализ и управление сетевым трафиком, наблюдая за DNS

ru.bmstu.wiki