3.1.4. Серверы доменных имен и механизм поиска ip-адреса
В данном разделе речь пойдет о программе, которая называется named. Именно она используется в большинстве Unix-систем в качестве реализации Berkeley Internet Name Domain - BIND.
Как и любой другой сервис прикладного уровня, а система доменных имен - это сервис прикладного уровня, программа named использует транспорт TCP и UDP (порты 53). Очень часто пользователи сообщают администратору системы, что та или иная машина системе не известна, хотя вчера с ней можно было работать. При этом, как правило, называют доменные имена компьютеров. Первое, что следует проверить в этой ситуации - реальную доступность к компьютеру по его IP-адресу. Проблема действительно является серьезной, если и по IP-адресу нельзя "достучаться" до удаленной машины, в противном случае следует искать ошибки или отказы в работе сервиса доменных имен.
Сервис BIND строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера, в нашем случае, программа named.
Resolver, собственно, не является какой-либо программой. Это набор процедур из системной библиотеки (libс.a), которые позволяют прикладной программе, отредактированной с ними, получать по доменному имени IP-адрес компьютера или по IP-адресу доменное имя. Сами эти процедуры обращаются к системной компоненте resolver, которая ведет диалог с сервером доменных имен и таким образом обслуживает запросы прикладных программ пользователя.
На запросы описанных выше функций в системах Unix отвечает программа named. Идея этой программы проста - обеспечить как разрешение, так называемых, "прямых" запросов, когда по имени ищут адрес, так и "обратных", когда по адресу ищут имя. Управляется named специальной базой данных, которая состоит из нескольких фалов, и содержит соответствия между адресами и именами, а также адреса других серверов BIND, к которым данный сервер может обращаться в процессе поиска имени или адреса.
Общую схему взаимодействия различных компонентов BIND можно изобразить так, как это представлено на рисунке 3.5.
Рис. 3.5. Нерекурсивная процедура на разрешение имени
Опираясь на схему нерекурсивной процедуры разрешения имени (рисунок 3.5) рассмотрим два способа разрешения запроса на получение IP-адреса по доменному имени.
В первом случае будем рассматривать запрос на получение IP-адреса в рамках зоны ответственности данного местного сервера имен:
-
Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера.
-
Местный сервер сообщает прикладной программе IP-адрес запрошенного имени.
Для того, чтобы еще больше прояснить данную схему взаимодействия рассмотрим несколько примеров, когда появляется запрос на получение IP-адреса по доменному имени.
При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:
/usr/paul>telnet polyn.net.kiae.su
/usr/paul>telnet polyn.net.kiae.su trying
144.206.130.137 ... login: .....
Строчка, в которой указан IP-адрес компьютера
polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно
разрешено сервером доменных имен и прикладная программа, в данном случае telnet
получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли и
до появления IP-адреса на экране монитора прикладная программа осуществила
запрос к серверу доменных имен и получила ответ на него.
Довольно часто можно столкнуться с ситуацией, когда после ввода
команды довольно долго приходиться ждать ответа удаленной машины, но зато после
первого ответа удаленный компьютер начинает реагировать на команды с такой же
скоростью, как и ваш собственный. В данном случае скорее всего в задержке
виноват сервис доменных имен. Наиболее заметно такой эффект проявляется при
использовании программы ftp. Например, при обращении к финскому архиву
ftp.funet.fi, после ввода команды:
/usr/paul>ftp ftp.funet.fi
система долго не отвечает, но затем начинает быстро "сглатывать" и
идентификатор и почтовый адрес, если входят как анонимный пользователь, и другие
FTP-команды.
Другой пример того же сорта - это программа traceroute. Здесь
задержка на запросы к серверу доменных имен проявляется в том, что время ответов
со шлюзов, на которых "умирают" ICMP пакеты, указанное в отчете, маленькое, а
задержки с отображением каждой строчки отчета довольно большие. В системе
Windows 3.1 некоторые программы трассировки, показывают сначала IP-адрес шлюза,
а только потом, после разрешения "обратного" запроса, заменяют его на доменное
имя шлюза. Если сервис доменных имен работает быстро, то эта подмена практически
незаметна, но если сервис работает медленно, то промежутки бывают довольно
значительными.
Если в примере с telnet и ftp мы рассматривали, только "прямые"
запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули
"обратные" запросы. В "прямом" запросе прикладная программа запрашивает у
сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе
прикладная программа запрашивает доменное имя, сообщая серверу доменных имен
IP-адрес.
Следует заметить, что скорость разрешения "прямых" и "обратных"
запросов в общем случае разная. Все зависит от того как описаны "прямые" и
обратные "зоны" в базах данных серверов доменных имен, обслуживающих домен.
Часто прямая зона бывает одна, а вот обратных зон может быть несколько, в силу
того, что домен расположен на физически разных сетях или подсетях. В этом случае
время разрешения "обратных" запросов будет больше времени разрешения "прямых"
запросов. Более подробно этого вопроса мы коснемся при обсуждении файлов
конфигурации программы named.
Процедура разрешения "обратных" запросов точно такая же, как и процедура
разрешения "прямых" запросов, описанная выше.
Рис. 3.6. Нерекурсивный запрос resolver
Собственно нерекурсивным, рассмотренный выше запрос является
только с точки зрения сервера, т.е. программы named. С точки зрения resolver
процедура разрешения запроса является рекурсивной, так как resolver перепоручил
named заниматься поиском нужного сервера доменных имен. Согласно RFC-1035,
resolver и сам может опрашивать удаленные серверы доменных имен и получать от
них ответы на свои запросы. Во многих Unix-системах именно так оно и сделано. В
этом случае resolver обращается к локальному серверу доменных имен, получает от
него адрес одного из серверов домена root, опрашивает сервер домена root,
получает от него адрес удаленного сервера нужной зоны, опрашивает этот удаленный
сервер и получает IP-адрес если он посылал, так называемый "прямой" запрос.
Как видно из этой схемы resolver сам нашел нужный IP-адрес.
Однако чаще всего resolver не порождает нерекурсивных запросов, а
переадресовывает их локальному серверу доменных имен. Кроме этого и локальный
сервер и resolver не все запросы выполняют по указанной процедуре. Дело в том,
что существует кэш, который используется для хранения в нем полученной от
удаленного сервера информации (рисунок 3.7).
Рис. 3.7. Схема разрешения запросов с кэшированием ответов
Если пользователь обращается в течении короткого времени к
одному и том же ресурсу сети, то запрос на удаленный сервер не отправляется, а
информация ищется в кэше. Вообще говоря, прядок обработки запросов можно описать
следующим образом:
-
поиск ответа в локальном кэше;
-
-
поиск ответа на локальном сервере;
-
-
поиск информации в сети.
При чем кэш может быть как у resolver'а, так и у сервера, но чаще всего эти
временные хранилища информации о системе DNS объединяют.
Рассмотрим теперь нерекурсивный запрос прикладной программы к
серверу доменных имен на получение IP-адреса по доменному имени из домена,
который находится в ведении удаленного сервера доменных имен, т.е. сервера
отличного от того, домену которого принадлежит компьютер, осуществляющий запрос.
При рассмотрении этого запроса также будем опираться на схему с рисунка 3.5.
В общем виде такая схема будет выглядеть следующим образом:
-
Прикладная программа обращается к местному серверу доменных имен за
-
IP-адресом, сообщая ему доменное имя.
-
-
Сервер определяет, что адрес не входит в данный домен и обращается за
-
адресом сервера запрашиваемого домена к корневому серверу доменных имен.
-
-
Корневой сервер доменных имен сообщает местному серверу доменных имен адрес
-
сервера доменных имен требуемого домена.
-
-
Местный сервер доменных имен запрашивает удаленный сервер на предмет
-
разрешения запроса своего клиента (прикладной программы)
-
-
Удаленный сервер сообщает IP-адрес местному серверу.
-
-
Местный сервер сообщает IP-адрес прикладной программе.
Среди указанных выше примеров, пример обращения к финскому ftp-архиву как раз
и является иллюстрацией такой много ступенчатой схемы разрешения "прямого"
запроса.
Однако, не всегда при разрешении запросов местный сервер
обращается к корневому серверу. Дело в том, что, как указывает Крэг Ричмонд,
существует разница между доменом и зоной. Домен - это все множество машин,
которые относятся к одному и тому же доменному имени. Например, все машины,
которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Однако,
сам домен разбивается на поддомены или, как их еще называют, зоны. У каждой зоны
может быть свой собственный сервер доменных имен. Разбиение домена на зоны и
организация сервера для каждой из зон называется делегирование прав управления
зоной соответствующему серверу доменных имен, или просто делегированием зоны.
При настройке сервера, в его файлах конфигурации можно
непосредственно прописать адреса серверов зон. В этом случае обращения к
корневому серверу не производятся, т.к. местный сервер сам знает адреса
удаленных серверов зон. Естественно, что все это относится к серверу, который
делегирует права.
Существует еще и другой вариант работы сервера, когда он не
запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен.
Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу
получения IP-адреса по данному доменному имени. Если требуется получить
IP-адрес, то он будет просто извлечен из буфера сервера, т.к. в течении
определенного времени, заданного в конфигурации сервера, этот адрес будет
храниться в cache-сервере. Если нужен адрес из того же домена, который был
указан в одном из имен, которые разрешались до этого, то сервер не будет
обращаться к корневому серверу, т.к. адрес удаленного сервера для этого домена
также хранится в кэше местного сервера.
Вообще говоря, понятия "зона" и "домен" носят локальный
характер и отражают только тот факт, что при настройках и взаимодействии между
собой серверы доменных имен исходят из двухуровневой иерархии. Это значит, что
если в зоне необходимо создать разделение на группы, то зону можно назвать
доменом, и в нем организовать новые зоны. Например, у компании Sun Microsystems
есть зона russia в домене sun.com (russia.sun.com). Так вот, эту зону тоже можно
разбить на зоны, например, info.russia.sun.com и market.russia.sun.com.
Кроме нерекурсивной процедуры разрешения имен возможна еще и
рекурсивная процедура разрешения имен. Ее отличие от описанной выше
нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои
серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим
эти два случая более подробно.
На рисунке 3.8 продемонстрирована нерекурсивная процедура
разрешения IP-адреса по доменному имени. Основная нагрузка в этом случае ложится
на местный сервер доменных имен, который осуществляет опрос всех остальных
серверов. Для того, чтобы сократить число таких обменов, если позволяет объем
оперативной памяти, можно разрешить буферизацию (кэширование) адресов. В этом
случае число обменов с удаленными серверами сократится.
На рисунке 3.9 удаленный сервер домена сам разрешает запрос на получение
IP-адреса хоста своего домена, используя при этом нерекурсивный опрос своих
серверов поддоменов.
Рис. 3.8. Нерекурсивная обработка запроса на получение IP-адреса
Рис. 3.9. Рекурсивная и нерекурсивная процедуры разрешения
адреса по IP-имени
При этом локальный сервер сразу получает от удаленного сервера
адрес хоста, а не адреса серверов поддоменов. Последний способ получения адреса
называют рекурсивным, т.е. локальный и удаленный серверы взаимодействуют по
рекурсивной схеме, а удаленный и серверы поддоменов по нерекурсивной.
Теперь от общих рассуждений перейдем к описанию настроек системы разрешения
доменных имен в BIND.
- Администрирование в информационных системах
- Глава 1. Информационные процессы в системах управления. Цели, задачи и функции администрирования в информационных системах
- Глава 2. Программное и техническое обеспечение современных ис и технологий управления организацией
- Глава 3. Методология построения администрирования и его средства
- Глава 4. Обеспечение иб в администрировании ис
- Глава 5. Управление конфигурацией и ресурсами ис
- Глава 6. Сетевые службы и их мониторинг
- Глава 7. Управление пользователями, сетевыми службами, дисками, службой печати
- 1.Теория администрирования сетей tcp/ip
- 1.1. Организация сети tcp/ip
- 1.2. Межсетевой обмен в сетях tcp/ip
- 1.3. Основные протоколы стека tcp/ip
- IPing - новое поколение протоколов ip
- 1.4. Принципы построения ip-адресов
- 1.5. Подсети
- 1.6.Порты и сокеты
- 1.7.Основные принципы ip-маршрутизации
- 1.8.Информационные сервисы Internet
- 1.9 Система Доменных Имен
- 1.10 Электронная почта в Internet
- 1.11 Взаимодействие отдельных эвм друг с другом
- 1.12 Обмен файлами. Служба ftp
- 2. Администрирование сетей
- 2.1. Учетные записи и группы безопасности
- 2.1.1. Понятие пользовательской учетной записи
- 2.1.2.Встроенные пользовательские учетные записи Windows 2000/xp
- 2.1.3. Группы безопасности
- 2.1.4.Типы учетных записей
- 2.1.5. Встроенные группы безопасности
- 2.2. Администрирование файлов и папок
- 2.2.1. Режимы доступа к папкам
- 2.2.2. Права доступа
- 2.3.3 Права доступа при копировании (перемещении) файлов.
- 2.3. Сервисы сетей ncp/ip
- 2.3.1. Протокол динамической конфигурации клиентских машин
- Администрирование информационных систем Правила эксплуатации и ответственные за их соблюдение
- Проектирование информационных систем и их приемка
- Защита от вредоносного программного обеспечения
- Обслуживание систем
- Сетевое администрирование
- Защита носителей информации
- Обмен данными и программным обеспечением
- Проблема организации администрирования крупных информационных систем.
- Администрирование в информационных системах
- 1. Ведение. Основные проблемы администрирования сетей tcp/ip и информационных технологий Internet
- 1.1. Организация сети tcp/ip
- 1.2. Подключениe локальной или корпоративной сети к Internet
- 1.3. Маршрутизация в сетях tcp/ip
- 1.4. Система доменных имен
- 1.5. Обмен электронной почтой
- 1.6. Организация информационного обслуживания на основе технологий Internet
- 1.7. Проблемы безопасности сетей tcp/ip
- 2. Основы межсетевого обмена в сетях tcp/ip
- 2.1. Структура стека протоколов tcp/ip
- 2.2. Основные протоколы стека tcp/ip
- 2.2.1. Протоколы slip и ppp
- 2.2.2. Протокол arp. Отображение канального уровня на уровень межсетевого обмена
- 2.2.3. Протокол ip
- 2.8. Формат пакета Ipv4
- 2.2.4. IPing - новое поколение протоколов ip
- 2.3. Принципы построения ip-адресов
- 2.4. Подсети
- 2.5. Порты и сокеты
- 2.6. Основные принципы ip-маршрутизации
- 2.7. Настройка операционной системы и сетевые интерфейсы
- 2.8. Настройка сетевых интерфейсов
- 2.8.1. Настройка Ethernet-интерфейса
- 2.8.2. Настройка slip
- 2.8.3. Настройка интерфейса ppp
- 2.9. Маршрутизация, протоколы динамической маршрутизации, средства управления маршрутами
- 2.9.1. Статическая маршрутизация
- 2.9.2. Динамическая маршрутизация
- 2.9.3. Программа routed
- 2.9.4. Программа gated
- 2.10 Анализ и фильтрация tcp/ip пакетов
- 3. Информационные сервисы Internet
- 3.1. Система Доменных Имен
- 3.1.1. Принципы организации dns
- 3.1.3. Регистрация доменных имен
- 3.1.4. Серверы доменных имен и механизм поиска ip-адреса
- 3.1.5. Настройка resolver
- 3.1.6. Программа named
- 3.1.6.1. Файлы настройки named
- 3.1.6.2. Запись "Start Of Authority"
- 3.1.6.3. Запись "Name Server"
- 3.1.6.4. Адресная запись "Address"
- 3.1.6.5. Запись Mail eXchanger
- 3.1.6.6. Запись назначения синонима каноническому имени "Canonical Name"
- 3.1.6.7. Записи типа "Pointer"
- 3.1.6.8. Запись типа hinfo
- 3.1.6.9. Запись определения информационных сервисов "Well Known Services"
- 3.1.6.10. Команды описания зоны
- 3.1.6.11. Файлы описания зоны
- 3.1.7. Примеры настроек программы named и описания зон
- 3.1.7.1. Небольшой поддомен в домене ru
- 3.1.7.2. Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях
- 3.1.7.3. Делегирование поддомена внутри домена
- 3.1.8. Программа nslookup
- 3.1.9. Dns и безопасность
- 3.2. Электронная почта в Internet
- 3.2.1. Принципы организации
- 3.2.2. Формат почтового сообщения (rfc-822)
- 3.2.3. Формат представления почтовых сообщений mime и его влияние на информационные технологии Internet
- 3.2.3.1. Поле версии mime (mime-Version)
- 3.2.3.2. Поле типа содержания тела почтового сообщения (Content-Type)
- 3.2.3.3. Поле типа кодирования почтового сообщения (Content-Transfer-Encoding)
- 3.2.3.4. Дополнительные необязательные поля
- 3.2.4. Протокол обмена почтой smtp (Simple Mail Transfer Protocol)
- 3.2.5. Интерфейс Eudora
- 3.2.6. Системы почтовой рассылки (программа sendmail)
- 3.2.6.1. Принцип работы программы sendmail
- 3.2.7. Настройка программы sendmail
- 3.2.7.1. Тестирование Sendmail и способы запуска
- 3.3. Эмуляция удаленного терминала. Удаленный доступ к ресурсам сети
- 3.3.1. Протокол Telnet
- 3.3.2. Интерфейс пользователя (telnet) и демон (telnetd)
- 3.3.2.1. Программа-сервер (telnetd)
- 3.3.2.2. Программа-клиент (telnet)
- 3.3.3. Организация модемных пулов, настройка оборудования. Квоты пользователей
- 3.4. Обмен файлами. Служба архивов ftp
- 3.4.1. Типы информационных ресурсов
- 3.4.2. Протокол ftp
- 3.4.3. Сервер протокола - программа ftpd
- 3.5. Администрирование серверов World Wide Web
- 3.5.1. История развития, отцы-основатели, современное состояние
- 3.5.2. Понятие гипертекста
- 3.5.3. Основные компоненты технологии World Wide Web
- 3.5.4. Архитектура построения системы
- 3.5.4.1. Язык гипертекстовой разметки html
- 3.5.4.2. Принципы построения и интерпретации html
- 3.5.5. Протокол обмена гипертекстовой информацией (HyperText Transfer Protocol, http 1.0.)
- 3.5.5.1. Форма запроса клиента
- 3.5.5.2. Методы доступа
- 3.5.5.3. Ответ сервера
- 3.5.5.4. Защита сервера от несанкционированного доступа
- 3.5.6. Universal Resource Identifier - универсальный идентификатор. Спецификация универсального адреса информационного ресурса в сети
- 3.5.6.1. Принципы построения адреса www
- 3.5.6.2. Схемы адресации ресурсов Internet
- 3.5.7. Common Gateway Interface - средство расширения возможностей технологии World Wide Web
- 3.5.7.1. Механизмы обмена данными
- 3.5.7.2. Практика применения скриптов cgi
- 3.5.8. Выбор и установка сервера протокола http и другого программного обеспечения базы данных World Wide Web
- 3.5.8.1. Структура базы данных сервера www
- 3.5.8.2. Редакторы html-документов
- 3.5.8.3. Графические редакторы и их особенности
- 3.5.8.4. Серверы протокола http
- 3.5.8.5. Выбор, установка и настройка сервера
- 3.5.8.6. Обслуживание запросов
- 3.5.9. Организация информационной службы на основе технологии World Wide Web
- 3.5.9.1. Статистика доступа к системе и ее анализ
- 3.6. Информационно-поисковые системы Internet
- 3.6.1. Архитектура современных информационно-поисковых систем World Wide Web
- 3.6.2. Информационные ресурсы и их представление в информационно-поисковой системе
- 3.6.3. Информационно-поисковый язык системы
- 3.6.4. Типы информационно-поисковых языков
- 3.6.5. Традиционные информационно-поисковые языки и их модификации
- 3.6.6. Информационно-поисковые языки Internet
- 3.6.7. Интерфейс системы
- 5. Литература
- Администрирование сети и сервисов internet учебное пособие
- Содержание
- Введение в ip-сети
- Принципы построения составных сетей
- Локализация трафика и изоляция сетей
- Согласование протоколов канального уровня
- Маршрутизация в сетях с произвольной топологией
- Сетевой уровень и модель osi
- Функции сетевого уровня
- Протоколы передачи данных и протоколы обмена маршрутной информацией
- Стек протоколов tcp/ip История и перспективы стека tcp/ip
- Структура стека tcp/ip. Краткая характеристика протоколов
- Адресация в ip-сетях Типы адресов: физический (mac-адрес), сетевой (ip-адрес) и символьный (dns-имя)
- Три основных класса ip-адресов
- Соглашения о специальных адресах: broadcast, multicast, loopback
- Отображение физических адресов на ip-адреса: протоколы arp и rarp
- Отображение символьных адресов на ip-адреса: служба dns
- Автоматизация процесса назначения ip-адресов узлам сети - протокол dhcp
- Протокол межсетевого взаимодействия ip
- Формат пакета ip
- Управление фрагментацией
- Маршрутизация с помощью ip-адресов
- Пример взаимодействия узлов с использованием протокола ip
- Структуризация сетей ip с помощью масок
- Протокол доставки пользовательских дейтаграмм udp
- Зарезервированные и доступные порты udp
- Мультиплексирование и демультиплексирование прикладных протоколов с помощью протокола udp
- Формат сообщений udp
- Протокол надежной доставки сообщений tcp
- Сегменты tcp
- Порты и установление tcp-соединений
- Концепция квитирования
- Реализация скользящего окна в протоколе tcp
- Выбор тайм-аута
- Реакция на перегрузку сети
- Формат сообщений tcp
- Протокол обмена управляющими сообщениями icmp Общая характеристика протокола icmp
- Формат сообщений протокола icmp
- Сообщения о недостижимости узла назначения
- Перенаправление маршрута
- Протоколы обмена маршрутной информацией стека tcp/ip
- Дистанционно-векторный протокол rip
- Комбинирование различных протоколов обмена. Протоколы egp и bgp сети Internet
- Протокол состояния связей ospf
- Развитие стека tcp/ip: протокол iPv.6
- Администрирование информационных систем (tcp/ip)
- Преподаватели
- Аннотация
- Знания и умения, полученные в результате обучения
- Зачет и экзамен
- Требования к начальному уровню знаний
- Программа курса
- Полезные Интернет-ссылки