Понятие протокола, и связанные с ним понятия
| Вид материала | Документы |
- Программа курса лекций, 33.31kb.
- А, а также связанные с этим сервисы, частично или полностью через пакетные сети, 211.32kb.
- Тема Основные понятия о правовых явлениях, 165.32kb.
- Контрольная работа по предмету «Логика», 57.32kb.
- Понятия налоги и налогообложение. Налоговая система понятие налога и сбора. Принципы, 2182.16kb.
- Задачи: Продолжить формирование понятия о внутренней среде и ее компонентах. Раскрыть, 161.91kb.
- Естественные науки 14 апреля с 10. 00 до 17., 82.95kb.
- Словари профессий, 47.56kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 114.5kb.
- Программа форума «служба протокола» день первый (02. 06. 2011г., четверг), 107.69kb.
Система назначения и разрешения доменных имен DNS.
Принципы назначения символьных имен. Альтернативные DNS варианты: WINS, NetBIOS-имена.
До сих пор мы рассматривали только взаимодействие технических средств между собой. Для технической реализации, безусловно, сетевые адреса постоянного размера с относительно простой структурой предпочтительнее символьных, имеющих переменную длину и, в общем случае, достаточно сложную структуру.
Но для пользователя-человека символьные имена, безусловно, удобнее для запоминания, поскольку могут нести лексическую смысловую нагрузку. Internet Explorer не только безразлично, наберете ли вы www.kaspersky.ru или 81.176.69.78 в окне Адрес, он даже быстрее доберется до нужного вам сервера, поскольку ему не понадобится обращаться к серверу DNS за IP-адресом. Задержка при работе любой сетевой службы от ввода имени узла до сообщения «соединение с узлом» связанно с работой как раз DNS-сервиса.Но попробуйте запомнить одно и второе!
Кроме того, не исключено, что завтра или через месяц господин Касперский по тем или иным причинам решит сменить провайдера, и принадлежавший его серверу IP-адрес 81.176.69.78 либо вообще перестанет существовать, либо перейдет к другому клиенту.
В этом смысле www.kaspersky.ru предпочтительнее, поскольку он связан с определенной услугой или комплексом услуг, а не с принадлежностью сетевого интерфейса компьютера определенной сети (как IP-адрес), или даже с конкретной сетевой платой, установленной в этот компьютер (как MAC, а с ним и IPX-адрес).
Поэтому все сетевые технологии операционных систем поддерживают присвоение компьютерам пользователей (в действительности, конечно, их сетевым интерфейсам) символьных имен, а в случаях, когда возможно использование наряду с символьным именем сетевого или аппаратного адреса, пользователям рекомендуется выбирать первое, либо даже избегать использования сетевых или аппаратных адресов, если это вообще возможно.
В случае небольших изолированных друг от друга сетей форма таких символьных имен могла быть вполне произвольна. Это может быть любая последовательность допустимых по алфавиту символов, выражающая принадлежность соответствующего компьютера, например, фамилию пользователя (КОРОВЬЕВ В.А., Alan_M_Jakson, Kirill), функциональную нагрузку данного компьютера (СТУДЕНТЫ, Main_Sales_Server), или вообще что-то, понятное одному только его автору (ВЗБЗДН, LVB_1861, LNT_1828-1910) – лишь бы имя было уникальным в своей области применения и удобным для запоминания теми, кто им пользуется. Такие имена часто называют плоскими, имея в виду отсутствие иерархической структуры (которая создавала бы «вертикаль», а значит, «объем»).
Удобство запоминания обеспечивают те, кто назначает имена, обычно администратор сети, на нем же лежит ответственность за уникальность имен.
Одним из первых вариантов такой плоской системы имен, до сих пор широко применяемой являются так называемые NetBIOS–имена. В протоколе NetBIOS имя включает до 16 произвольных символов (фактически – ровно 16, т.к. более короткие имена дополняются нулями до 16), каждый сетевой интерфейс имеет имя по умолчанию – дополненный десятью нулями MAC-адрес, и может иметь еще одно или несколько назначенных имен, присваиваемых динамически. Уникальность имени при назначении и соответствие имен MAC-адресам устанавливается посредством широковещательных запросов, наподобие протокола ARP.
К сожалению, такой способ разрешения имен эффективен только в относительно небольших локальных сетях. В больших корпоративных сетях, не говоря уже об Internet, требуется некая централизованная служба, которая занималась бы поддержанием баз данных о соответствии имен сетевым и локальным адресам, разрешением конфликтов имен, и другими связанными с этим вопросами.
Однако плоские имена для такой службы неудобны, поскольку нет формальных признаков, по которым можно было бы распределить ответственность за части этой базы между администраторами или группами администраторов. Хотя подобная служба под названием WINS (Windows Name Service) существует в ОС Windows (95, 98, NT), которая справляется с задачей поддержания соответствия адресов NetBIOS–именам в любой точке Internet, лишь бы система работала под управлением ОС Windows. Но эта система достаточно сложна, и не поддерживается другими ОС. В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service, RFC-2136).
Иерархическая структура имен значительно лучше соответствует потребностям системы управления именованием, которая сама в сложной системе по необходимости имеет иерархическую структуру, так же, как и иерархическая структура сетевых адресов <сеть><узел>, или телефонных номеров <страна><город><АТС><абонент>.
Иерархическая организация доменных имен.
Принятая в IP-сетях структура имен имеет переменное число уровней, но обычно не более 5 (впрочем, число уровней никаким стандартом не ограниченно – просто более 5 уровней обычно уже трудны для запоминания). Имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 байт, включая байт длины. Анализ имени производится справа налево.
Самая правая (старшая) секция имени (обычно двух- или трехсимвольная) характеризует страну, или характер организации (образовательная, коммерческая, правительственная и т.д.). Следующие (обычно 3-х символьные коды) Internet-имени означают функциональную принадлежность узла.
.aero – Фирма или организация, относящаяся к сфере авиации;
.biz – Организация, относящаяся к сфере бизнеса;
.com – Коммерческая организация;
.coop – Кооперативная организация;
.gov – Государственное учреждение (США);
.org – Бесприбыльная организация;
.edu – Учебное заведение;
.mil – Военное предприятие или организация (США);
.museum – Имя домена музея
.name – Имя домена частного лица
.net – Большая сеть;
.pro – Профессионал, достойный доверия. Управляется RegistryPro (ro/);
.int – Международная организация;
.arpa –Специальный домен, используемый для преобразования ip-адреса в имя
Когда организация присоединяется к Internet, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.
Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет байт IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса “задом наперед” диктуется общими принципами записи имен доменов (корневая часть имени находится справа).
Имена, начинающиеся с .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Опускание кода страны в случае, когда страна – США – дань истории Internet.
Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена Internet Института Теоретической и Экспериментальной физики, Москва. cl.itep.ru – имя mvax-кластера в ИТЭФ, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ.
На приведенной схеме, отражающей фрагмент системы доменных имен и обслуживающей их системы DNS-серверов, каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна – существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен.
Система назначения и администрирования доменных имен DNS.
За всю систему доменных имен в целом отвечают службы Internet IANA и InterNIC, расположенные в США.
Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах.
Список корневых серверов можно получить с помощью анонимного ftp по адресам: ссылка скрыта или ссылка скрыта . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня.
Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй – адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее – в вашем сервере копится информация об адресах серверов имен. Неудивительно, что для разрешения имен применяются оба. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).
Формат DNS-сообщений
Обычно для запросов и откликов используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами.
Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так число вопросов задает число записей в секции вопросов, где записаны запросы, требующие ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены ниже. Разряды пронумерованы слева направо, начиная с нуля.
Код поля флаги Описание
0 (QR) Операция: 0 – Запрос 1 – Отклик
1…4 Тип запроса (opcode): 0=стандартный 1=инверсный 2=запрос состояния сервера
5 (AA) 1 при ответе от сервера, в ведении которого находится искомый домен.
6 (TC) 1 при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 байт, но прислано только первые 512.
7 (RD) 1, если для получения ответа желательна рекурсия.
8 (RA) 1, если рекурсия для запрашиваемого сервера доступна.
9…11 Зарезервировано на будущее. Должны равняться нулю.
12…15 Тип отклика (rcode): 0=нет ошибки, 1=ошибка в формате запроса, 2=сбой в сервере, 3=имени не существует.
Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой байты длины):
Байт длины субполя может иметь два старших бита равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти придумано для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса
Тип запроса Код запроса Описание
A 1 IP-адрес
NS 2 Сервер имен.
CNAME 5 Каноническое имя.
SOA 6 Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.
MB 7 Имя домена почтового ящика.
WKS 11 well-known service - стандартная услуга.
PTR 12 Запись указателя.
HINFO 13 Информация об ЭВМ.
MINFO 14 Информация о почтовом ящике или списке почтовых адресов.
MX 15 Запись о почтовом сервере.
TXT 16 Не интерпретируемая строка ASCII символов.
AXFR 252 Запрос зонного обмена
* или ANY 255 Запрос всех записей.
Формат секции вопросов DNS-запроса.
Имя домена в этой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 – это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера.
База данных имен может содержать и другую информацию. В особенности это относится к WINS, а среди доменов Internet – к домену IN_ADR.ARPA, поскольку им приходится как-то структурировать неструктурированную по природе своей информацию. Так что когда продвинутый искатель (чаще всего такие встраиваются в системы безопасности, для идентификации узлов, выполняющих недружественные действия), выдает, например, MAC-адрес узла, находящегося на другом конце света – скорее всего, он использовал данные из баз WINS. В ряде версий Unix-совместимых операционных систем имеется команда host или подобная ей, позволяющая по запросам к серверам доменных имен получить эту дополнительную информацию.
Неразрешенной до конца проблемой является взаимодействие DNS с системами, использующими протоколы динамического конфигурирования, например DHCP, или трансляцию адресов(Network address translation – NAT). Если IP-адрес узла определяется динамически, а необходимо обеспечить доступ к нему по доменному имени, то как информировать DNS-серверы о новом значении IP-адреса? В настоящее время эта проблема решается сочетанием статического и динамического назначения адресов, т.е. те узлы, к которым необходим доступ извне по доменным именам, получают неизменные IP-адреса, а для остальных адреса назначаются динамически.