Система доменных имен

Для идентификации объекта протоколы используют IP-адреса, которые уникально идентифицирует соединения хоста с Интернетом. Однако люди предпочитают имена адресам. Поэтому нам необходима система, которая сопоставляет имя с адресом или адрес к имени.

Когда Интернет имел небольшой объем, сопоставление делал хост-файл. Хост-файл имел только две колонки, включающие в себя имя и адрес. Когда программа или пользователь хотели сопоставить имя и адрес, хост обращался к хост-файлу и находил отображение.

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

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

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

Пространство имен

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

Плоское пространство имен

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

Иерархическое пространство имен

В иерархическом пространстве имен каждое имя составлено из нескольких частей. Первая часть может определять природу организации, вторая часть — имя организации, третья часть — департаменты в организации, и так далее. В этом случае полномочия и управление пространством имен может быть децентрализовано. Центральные полномочия могут назначаться согласно той части имени, которое определяет природу организации и имя организации. Полномочия, определяемые остальной частью имени, определяются самой организацией. Организация может добавить к имени суффикс или префикс, определяющие ресурсы ее хоста. Управлению организации не нужно беспокоиться, что префикс, выбранный для хоста, взят другой организацией, потому что даже если часть адреса одна и та же, полный адрес различается. Например, предположим, два университета и компания назвали один из их компьютеров kafedra. Первый университет дает имени центральные полномочия, такие как gut.edu, второй дает имя mtusy.edu, и компания дает имя loniis.ru. Когда каждая из этих организаций добавляет имя кафедра к имени, они уже дают в конечном результате три отличающихся имени: kafedra.gut.edu, kafedra.mtusy.edu и kafedra.loniis.ru.

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

Пространство доменных имен

Иерархическое пространство доменных имен назначается. При этом назначении имя определяется структурой инвертированного дерева с корнем в вершине. Дерево может иметь 128 уровней: от уровня 0 (корень) до уровня 127. Принимая во внимание, что корень скрепляет целое дерево вместе, каждый уровень дерева определяет иерархический уровень.

Метка

Каждый узел дерева имеет метку. Она отображается строчкой из символов с максимальным числом 63. Метка корня – нулевая строчка (пустая строчка). DNS требует, чтобы "дети" узла (узлы, которые являются ветками от того же узла) имели различные метки, которые гарантируют уникальность доменного имени.

Доменное имя

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

Последняя метка — это метка-корень (нуль). Это означает, что полное доменное имя всегда оканчивается нулевой отметкой, которую означает последний символ – точка, потому нулевая строка ничего не обозначает.

Полностью определенное доменное имя

Если метка завершается нулевой строкой, это называется "полностью определенное доменное имя" (FQDN — Fully Qualified Domain Name). FQDN – имя хоста, которое содержит полное имя хоста. Оно включает в себя все метки, от наиболее специфичной до наиболее общей, которые уникально определяют имя хоста. Например, доменное имя

kafedra.gut.edu.

Это FQDN компьютера, названного kafedra и установленного в Государственном университете телекоммуникаций. Заметим, что имя должно заканчиваться нулевым ярлыком, но поскольку он ничего не обозначает, метка заканчивается точкой (.).

Частично определенное имя домена

Если метка не заканчивается нулевой строкой, это называется "частично определенным доменными именем" (PQDN — Partially Qualified Domain Name). PQDN начинается от узла, но не достигает корня. Оно используется, если в компьютере будет отмечено, что имя принадлежит тому же самому сайту, что и клиент. Здесь компьютер может заменить отсутствующую часть так называемым суффиксом, который создает FQDN. Например, если пользователь сайта sut.edu. хочет иметь IP-адрес компьютера "kafedra", он может определить частичное имя

kafedra

DNS клиента добавляет суффикс sut.edu перед тем, как передать адрес к DNS-серверу.

DNS клиента обычно имеет список суффиксов. Символы могут определяться списком сервера университета. Нулевой суффикс ничего не определяет. Этот суффикс добавляется, когда имя пользователя полностью определено в виде FQDN.

Домен

Домен — это фрагмент дерева в пространстве доменных имен. Имя домена – это доменное имя узла на вершине поддерева.

Распределение имен

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

Иерархия серверов имен

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

Зона

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

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

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

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

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

Первичные и вторичные серверы

DNS определяет два типа серверов: первичные и вторичные. Первичный сервер — это сервер, накапливающий файл о зоне, на которую он имеет полномочия. Он несет ответственность за создание, эксплуатацию и изменения зонового файла. Зоновый файл накапливается на локальном диске.

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

DNS в Интернете

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

Родовой домен

Родовой домен определяет регистрацию хоста (generic domain) в соответствии с его родовой природой. Эти уровни связаны с типами организаций, как это, например, приведено для США в табл. 3.1 [5].

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

В таблице первый уровень в секции родового домена позволяет семь возможных трехсимвольных уровней. Эти уровни соотнесены с типами организаций так, как перечислено в табл. 3.1 [5].

Домены страны

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

Инверсный домен

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

Этот тип запроса называется инверсным запросом, или запросом указателя. Для того чтобы обработать запрос указателя, инверсный домен добавляет к пространству доменных имен узел первого уровня, называемый arpa (по историческим причинам). Второй уровень также именует одиночный узел in-addr (для инверсного адреса). Остаток домена определяет IP-адреса.

По договоренности следует читать метки инверсного домена от основания к вершине. Например, такой IP-адрес, как 132.34.45.121, читается как 121.45.34.132.in-addr.arpa.

Сервер, который обрабатывает инверсный домен, — также иерархический. Это означает, что часть адреса, содержащая сетевой номер (netid), должна быть более высокого уровня (в данном примере это 132), чем часть адреса подсети (subnetid), в данном примере 45; а часть адреса подсети должна быть более высокого уровня, чем адрес хоста (hostid). Такая конфигурация делает вид домена инверсным, если сравнивать с родовым доменом и доменом страны.

Распознавание имен

Отображение имени в адрес или адреса в имя называется "распознавание имя-адрес".

Распознаватель (resolver)

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

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

Отображение имен в адреса

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

Если имя домена от родовой секции, распознаватель получает доменное имя, такое как kafedra.gut.edu. Запрос посылается распознавателем к местному DNS-серверу для распознавания. Если местный сервер не распознает запроса, он либо отсылает распознаватель к другому серверу, либо запрашивает другой сервер напрямую.

Если имя домена из секции доменов стран, распознаватель получает доменное имя, такое как kafedra.gut.spb.ru. Процедура та же самая.

Отображение адресов в имена

Клиент может послать IP-адрес на сервер для того, чтобы отобразить доменное имя. Это называется PTR-запрос. Для подобного запроса DNS использует инверсный домен. Однако IP-адрес запроса должен быть реверсирован, и должны быть прикреплены две метки, in-addr или arpa, чтобы создать доступный домен с помощью инверсной доменной секции. Например, если распознаватель получил IP-адрес 132.34.45.121, распознаватель вначале инвертирует адрес, а затем добавляет две метки перед посылкой. Посылаемое имя домена — 121.45.34.132.in-addr.arpa. Оно получается с помощью локальной DNS и распознается.

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

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

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

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

Кэширование

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

Кэширование ускоряет распознавание, но может и создать проблемы. Если сервер кэширует отображение за долгое время, он может послать клиенту устаревшее отображение. Чтобы противостоять этому, используются два метода.

При первом из них полномочный сервер всегда добавляет кусок информации для отображения так называемого "времени жизни" (TTL – time to live). Оно определяет время в секундах, в течение которого принимающий сервер может кэшировать информацию. После истечения этого времени отображение недействительно, и любой запрос может быть опять послан к полномочному серверу.

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

DNS-сообщения

DNS имеет два типа сообщения: запрос и отклик. Оба типа имеют один и тот же формат. Сообщение запроса содержит заголовок, запись запроса, ответную запись, запись полномочий и дополнительные записи (рис. 3.1).

Заголовок

Оба сообщения, запрос и отклик, имеют один и тот же формат заголовка с несколькими полями с установленными нулями для сообщений отклика. Заголовок 12 байт и его формат показан в (табл. 3.2).

Поля заголовков – следующие:

Короткое описание субполей каждого флага дано ниже.

Имеются следующие типы секций.

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

Это секция, содержащая одну или более записей. Она содержит оба сообщения: и запрос, и ответ. Мы обсудим вопрос записи в следующем разделе.

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

Это секция, содержащая одну или более записей. Она представляет только сообщения ответа. Секция включает ответ от сервера к клиенту (сообщение распознавателя).

Секция полномочий

Это секция, содержащая одно или более сообщений источника. Она представлена только в ответном сообщении. Секция дает информацию (имя домена) об одном или более полномочном сервере для запроса.

Секция дополнительной информации

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

Типы записей

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

Запись запроса

Запись запроса используется клиентом, чтобы иметь информацию от сервера. Она содержит доменное имя. Рисунок 3.3 показывает формат записи запроса. Список, приведенный ниже, дает описание полей записи запроса.

Запись ресурса

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

Сжатие

Когда имя домена повторяется, DNS требует, чтобы оно заменялось указателем сдвига. Например, запись ресурса имени домена обычно повторяет имя домена в запросе. Для того чтобы избежать дублирования, DNS определяет двухбайтовый указатель сдвига, который указывает на предыдущее вхождение имени в домен или часть его. Формат поля показан на Рис. 3.6

Первые два старших разряда — это две единицы, необходимые для того, чтобы отличить точку-указатель сдвига от информации "длина поля".) Другие 14 бит представляют число, которое указывает на соответствующий байт номера сообщения. Этот байт отсчитывается от начального сообщения с первым байтом, который считается нулевым. Например, если указатель сдвига указывает на байт 12 (тринадцатый байт) сообщения, значение должно быть 1100000000001100. Здесь 2 наибольших левых разряда определяют поле как указатель ответвления, а другие биты определяют десятичное число 12. Мы покажем, как используются указатели сдвига на следующих примерах.

Примеры

В этом разделе мы рассмотрим некоторые примеры DNS-запросов и ответов.

Пример 1

Распознаватель посылает запрос к локальному серверу для нахождения IP-адреса для хоста kafedra.gut.spb.ru.

Сообщение запроса. Рис. 3.7 показывает сообщение запроса, посылаемое распознавателем. Первые два байта показывают идентификатор в шестнадцатеричном исчислении ( 1444 ). Он используется как последовательный номер и относится к отклику на запрос. Поскольку распознаватель может послать только один запрос одному и тому же серверу, идентификатор помогает сортировать ответы, которые прибывают в любом порядке. Следующие байты содержат флаг с шестнадцатеричным значением 0100. В двоичной системе это 0000 0001 0000 0000, но более понятно флаг показан ниже.

Бит QR определяет сообщение как запрос. OpCode 0000 означает стандартный запрос. Рекурсия желательна, бит RD установлен (см. рис. 3.3, описания полей флага).

Сообщение содержит только одну запись запроса. Имя домена — kafedra.gut.spb.ru. Следующие два байта определяют тип запроса как IP-адрес; последние два байта определяют класс Интернета.

Ответное сообщение. Рис. 3.8 показывает ответ сервера. Ответ похож на запрос, за исключением того, что различаются флаги и число ответных записей одно и то же. Значение флага — 8180 в шестнадцатеричном исчислении. В двоичном исчислении он равен 1000 0001 1000 0000, но мы снова разделим это представление по полям, как это показано ниже.

Бит QR определяет сообщение как ответ. OpCode 0000 означает стандартный запрос. Рекурсия возможна (RA=1), и RD-бит установлен в состояние 1. Сообщение содержит одну запись запроса и одну запись ответа. Запись запроса повторяет сообщение запроса. Запись ответа имеет шестнадцатеричный указатель ( C00C ), разбитый на две линии, который ссылается на запись запроса вместо того, чтобы повторять имя домена. Следующее поле определяет тип домена (адрес), после которого определяется класс (Интернет). Поле со значением 12000 – TTL (время жизни равно 12000 с.). Следующее поле — это длина ресурсов данных, которая и есть IP-адрес ( 153.18.8.105 ).

Пример 2

FTP-сервер получил пакет от FTP-клиента с IP-адресом 153.2.7.9. Этот FTP-сервер может запросить файл, содержащий списки полномочных клиентов. Однако файл содержит только имена доменов. FTP-сервер имеет только IP-адрес запрашиваемого клиента, который располагает источником IP-адресов в полученной дейтаграмме. FTP-сервер запрашивает распознаватель (DNS клиента), чтобы получить обратный запрос к DNS и запросить имя FTP-клиента. Мы обсудим сообщение запроса и ответа отдельно.

Сообщение запроса. На табл. 3.6 приведено сообщение запроса, посланное от распознавателя к серверу. Первые 2 байта показывают идентификатор 1200. Значение флага — 0900 в шестнадцатеричном представлении. В двоичном представлении он равен 0000 1001 0000 0000 0000, и мы разделим его по полям, как показано ниже.

OpCode 0001 – означает инверсный запрос. Сообщение содержит только одну запись запроса

1 9 1 7 1 2 3 153 7 in-addr 4 arpa.

Следующие два байта определяют тип запроса (PTR)и последние два байта класс Интернета

Инверсный ответ. Табл. 3.7 показывает ответ. Сообщение содержит одну запись запроса и одну запись ответа. Запись запроса повторяет сообщение запроса. Запись ответа имеет указатель 0xC00C, который ссылается на запись запроса вместо повторения имени домена. Следующее поле определяет тип домена (PTR). Следующее поле определяет класс Интернет, а после этого определяется время жизни (TTL) – 24000 c. Следующее поле – это длина данных источника (10). Последнее поле – это имя домена: 7kafedra3gut3spb2ru0.

DDNS

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

DNS-мастер-файл должен быть скорректирован динамически. Поэтому была изобретена динамическая система доменных имен (DDNS – Dynamic Domain Name System). В DDNS, когда связь между именем и адресом определена, информация посылается обычно с помощью действий по протоколу динамической реконфигурации хостов (DHCP — Dynamic Host Configuration Protocol) к первичному DNS-серверу. Первичный сервер модернизирует зону. Вторичные серверы уведомляются либо активно, либо пассивно. При активном уведомлении первичный сервер посылает сообщение вторичным серверам об изменениях в зоне, в то время как при пассивном уведомлении вторичные серверы периодически проверяются на любые изменения. В любом случае, после осуществления уведомления об изменении вторичные серверы запрашивают информацию об изменениях во всей зоне (зоновая передача), чтобы обеспечить безопасность. Для предотвращения неполномочных изменений DNS-записей DDNS может использовать полномочный механизм.

Инкапсуляция

DNS может использовать UDP или TCP. В обоих случаях сервером задействуется закрепленный порт – 53. UDP применяется, когда размер сообщения ответа меньше чем 512 байт, потому что большинство пакетов UDP имеют ограничение на размер пакета 512 байт. Если размер сообщения ответа больше чем 512 байт, должно использоваться соединение TCP. В этом случае может возникнуть один из двух сценариев:

Краткие итоги

Задачи и упражнения

Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.