WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |
-- [ Страница 1 ] --

DNS and BIND Fourth Edition PaulAlbitz and Cricket Liu O'REILLY DNS и BIND Четвертое издание ПолАльбитц и Крикет Ли Пол Альбитц, Крикет Ли DNS и BIND Перевод М Зислиса Главный редактор А Галунов

Зав. редакцией Н Макарова Научный редактор А Маврин Редактор А Лосев Корректура О Маршкова Верстка Н Гриценко Альбитц П, Ли К DNS и BIND. - Пер. с англ. - СПб. Символ-Плюс, 2002 - 696 с, ил.

ISBN 5 93286-035 9 Книга «DNS и BIND» стала библией для системных администраторов. Она уникальна по полноте изложения материала, что в сочетании с прекрасным авторским стилем делает ее незаменимой и актуальной для каждого, кто хочет наладить эффективную работу DNS. Четвертое издание включает информа цию о версии 9 пакета BIND, в которой реализованы новые и очень важные ме ханизмы, а также о версии 8, входящей в состав большинства действующих коммерческих разработок. Пакеты BIND 8 и 9 позволяют значительно повы сить безопасность служб DNS.

Рассмотрены следующие темы: функциональность и принципы работы DNS;

структура пространства доменных имен, установка и настройка серверов имен;

применение MX записей для маршрутизации почты;

настройка узлов на работу с DNS;

разделение доменов на поддомены;

обеспечение безопасности DNS-сервера;

новые возможности BIND 9;

расширения системы безопасности DNS (DNSSEC) и подписи транзакций (TSIG);

распределение нагрузки между DNS-серверами;

динамические обновления, асинхронные уведомления об из менениях зон, пошаговая передача зон;

устранение неполадок (применение nslookup и dig, чтение отладочного вывода);

DNS-программирование с приме нением библиотеки DNS клиента и модуля Perl Net::DNS.

ISBN 5-93286-035- ISBN 0-596-00158-4 (англ) © Издательство Символ-Плюс, Authorized translation of the English edition © 2001 O'Reilly & Associates Inc This translation is published and sold by permission of O'Reilly & Associates Inc., the own er of all rights to publish and sell the same Все права на данное издание защищены Законодательством РФ, включая право на полное или час тичное воспроизведение в любой форме Все товарные знаки или зарегистрированные товарные зна ки, упоминаемые в настоящем издании являются собственностью соответствующих фирм Издательство «Символ Плюс» 193148, Санкт Петербург, ул Пинегина, 4, тел (812) 324 5353, edit@symbol ru Лицензия ЛП N 000054 от 25 12 Налоговая льгота - общероссийский классификатор продукции ОК 005-93, том 2, 953000 - книги и брошюры Подписано в печать 26 02 2002 Формат 70x10046 Печать офсетная Объем 43,5 печ л Тираж 3000 экз Заказ N i() Отпечатано с диапозитивов в Академической типографии «Наука» РАН 199034, Санкт Петербург, 9 линия, Оглавление Предисловие 1. Основы (Очень) краткая история сети Интернет Интернет и интернет-сети Система доменных имен в двух словах История пакета BIND Надо ли мне использовать DNS? 2. Как работает DNS Пространство доменных имен Пространство доменных имен сети Интернет Делегирование DNS-серверы и зоны Клиенты DNS Разрешение имен Кэширование 3. С чего начать? Приобретение пакета BIND Выбор доменного имени 4. Установка BIND Наша зона Создание данных для зоны Создание файла настройки BIND Сокращения Проверка имени узла (BIND 4.9.4 и более поздние версии) Инструменты Запуск первичного мастер-сервера DNS Запуск вторичного DNS-сервера Добавление зон Что дальше? 6 Оглавление 5. DNS и электронная почта МХ-записи И все-таки, что такое почтовый ретранслятор? МХ-алгоритм 6. Конфигурирование узлов DNS-клиент Примеры настройки DNS-клиента Как упростить себе жизнь Специфика настройки различных систем 7. Работа с BIND Управление DNS-сервером Обновление файлов данных зон Организация файлов Перемещение системных файлов в BIND 8и9 Ведение log-файла в BIND 8и9 Основы благополучия 8. Развитие домена Сколько DNS-серверов? Добавление DNS-серверов Регистрация DNS-серверов Изменение значений TTL Подготовка к бедствиям Борьба с бедствиями 9. Материнство Когда заводить детей Сколько детей? Какие имена давать детям Заводим детей: создание поддоменов Поддомены доменов in-addr.arpa Заботливые родители • Как справиться с переходом к поддоменам Жизнь родителя 10. Дополнительные возможности Списки отбора адресов и управления доступом DNS: динамические обновления DNS NOTIFY (уведомления об изменениях зоны) Оглавление Инкрементальная передача зоны (IXFR) Ретрансляция Виды Round Robin: распределение нагрузки Сортировка адресов DNS-сервером DNS-серверы: предпочтения Нерекурсивный DNS-сервер Борьба с фальшивыми DNS-серверами Настройка системы Совместимость Основы адресации в IPv6. Адреса и порты IPv6: прямое и обратное отображение 11. Безопасность TSIG Обеспечение безопасности DNS-сервера DNS и брандмауэры сети Интернет Расширения системы безопасности DNS 12. nslookup и dig Насколько хорош nslookup? Пакетный или диалоговый? Настройка Как отключить список поиска Основные задачи Прочие задачи Разрешение проблем с nslookup Лучшие в сети Работа с dig 13. Чтение отладочного вывода BIND Уровни отладки Включение отладки Чтение отладочной диагностики Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 8) Алгоритм работы DNS-клиента и отрицательное кэширование (BIND 9) Инструменты 8 Оглавление 14. Разрешение проблем DNS и BIND Виновата ли служба NIS? Инструменты и методы Перечень возможных проблем Проблемы перехода на новую версию Проблемы сосуществования и версий Ошибки TSIG Симптомы проблем 15. Программирование при помощи функций библиотеки DNS-клиента Написание сценариев командного интерпретатора с помощью программы nslookup Программирование на языке С при помощи функций библиотеки DNS-клиента Программирование на языке Perl при помощи модуля Net::DNS 16. Обо всем понемногу Использование CNAME-записей Маски Ограничение МХ-записей Коммутируемые соединения Имена и номера сетей Дополнительные RR-записи DNS и WINS DNS и Windows 2000 A. Формат сообщений DNS и RR-записей B. Таблица совместимости BIND C. Сборка и установка BIND на Linux-системах D. Домены высшего уровня E. Настройка DNS-сервера и клиента BIND Алфавитный указатель Предисловие Возможно, вам не так уж много известно о системе доменных имен (Domain Name System), но работая в Интернете, вы неизбежно ее ис пользуете. Всякий раз, отправляя сообщения электронной почты или исследуя просторы World Wide Web, вы полагаетесь на DNS - систему доменных имен.

Дело в том, что люди предпочитают запоминать имена компьютеров, а компьютерам больше нравится обращаться друг к другу по числовым адресам. В Интернете этот адрес имеет разрядность 32, то есть может быть числом от нуля до четырех с хвостиком миллиардов.1 Компьюте ры с легкостью запоминают такие вещи, потому что обладают больши ми объемами памяти, идеально подходящей для хранения чисел, но для людей эта задача не в пример сложнее. Попробуйте случайным об разом выбрать из телефонной книги десять номеров и запомнить их.

Непросто? Теперь вернитесь к началу телефонной книги и сопоставьте каждому номеру случайный код района. Примерно настолько же сложно будет запомнить 10 произвольных интернет-адресов.

Отчасти именно по этой причине необходима система доменных имен.

DNS занимается двунаправленным отображением имен хостов, подхо дящих для запоминания людьми, и интернет-адресов, с которыми ра ботают компьютеры. По сути дела, DNS в сети Интернет является не только средством работы с адресами, но и стандартным механизмом для предоставления и получения разнообразной информации об узлах сети. DNS нужен практически для каждой программы, обеспечиваю щей сетевое взаимодействие, в том числе программам для работы с электронной почтой, терминальным клиентам (например, telnet), средствам передачи файлов, таким как FTP, и, разумеется, веб-броузе рам, таким как Netscape Navigator и Microsoft Internet Explorer.

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

Более того, DNS позволяет распределять управление информацией о хостах между многочисленными серверами и организациями. Нет необ А в системе IP-адресации версии 6 адреса имеют колоссальную длину 128 бит, что позволяет охватить десятичные числа от нуля до 39-значных.

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

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

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

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

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

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

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

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

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

Когда речь пойдет о программах, обеспечивающих работу DNS, мы практически целиком сконцентрируемся на инструменте под названи ем BIND, Berkeley Internet Name Domain, который является наиболее популярной (и наиболее нами изученной) реализацией спецификаций DNS. Мы старались представить в этой книге выжимку из нашего опыта управления и поддержки зон с помощью BIND. (Так получи лось, что некоторое время одна из наших зон являлась самой большой зоной сети Интернет;

правда, это было очень давно). Где это было воз можно, мы включали реальные программы, используемые нами в ад министрировании;

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

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

Версии Четвертое издание этой книги затрагивает новые версии BIND - 9.1. и 8.2.3, а также более старую версию 4.9. Несмотря на то, что на мо мент написания этой книги версии 9.1.0 и 8.2.3 являются наиболее свежими, они пока не получили широкого распространения в составе Unix-систем, отчасти потому, что обе версии были выпущены недавно, а многие поставщики настороженно относятся к использованию но вых программ. Мы время от времени упоминаем и другие версии BIND, в частности 4.8.3, поскольку многие поставщики продолжают распространять программы, содержащие код, основанный на более старых версиях, в составе своих Unix-разработок. Если определенная возможность доступна только в версии 4.9, 8.2.3 или 9.1.0, либо если существуют различия в поведении версий, мы постараемся четко опре делить, что именно работает и для какой версии BIND.

В наших примерах мы очень часто прибегаем к служебной программе DNS - nslookup. Мы пользуемся nslookup из комплекта поставки BIND версии 8.2.3. Более старые версии nslookup обеспечивают большую часть функциональности (но не всю) nslookup версии 8.2.3.1 В большинстве примеров мы использовали команды, доступные почти во всех версиях nslookup;

случаи, когда это было невозможно, отмече ны отдельно.

Это верно также и для nslookup из комплекта поставки BIND версии 9.1.0.

См. более подробно в главе 12 «nslookup и dig».

12 Предисловие Что нового в четвертом издании?

Текст книги был обновлен, чтобы соответствовать наиболее поздним версиям BIND;

мы также добавили в большом объеме новый материал:

• Более подробное рассмотрение динамических обновлений и меха низма NOTIFY, включая и подписываемые динамические обновле ния (signed dynamic updates), а также описание нового для BIND механизма update-policy - в главе 10.

• Поэтапная передача зоны - также в главе 10.

• Зоны ретрансляции, поддерживающие передачу по условию (condi tional forwarding), - в главе 10.

• Прямое и обратное отображение адресов в контексте технологии IPv6 с использованием записей новых типов А6 и DNAME, а также бит-строковых меток - в конце главы 10.

• Новый механизм подтверждения подлинности транзакций - тран закционные подписи (transaction signatures, известные также как TSIG) - описан в главе 11.

• Более подробное рассмотрение вопросов обеспечения безопасности DNS-серверов - в главе 11.

• Более подробное рассмотрение работы с брандмауэрами в сети Ин тернет - в главе 11.

• Описаны расширения DNS, связанные с безопасностью (DNS Secu rity Extensions или DNSSEC), представляющие собой новый меха низм цифровой подписи зональных данных, - все в той же 11-ой главе.

• Раздел, посвященный совместной работе клиентов, серверов и контроллеров доменов Windows 2000 и BIND, - в главе 16.

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

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

Перечислим темы по главам:

Структура Глава 1 «Основы» описывает исторический фон создания системы, и посвящена проблемам, приведшим к созданию DNS, а также собствен но обзору теории системы доменных имен.

Глава 2 «Как работает DNS» посвящена более подробному рассмотре нию теоретических основ DNS, в частности - организации пространст ва имен в системе DNS, доменов, зон и DNS-серверов. Там же рассмат риваются такие важные понятия, как разрешение адресов и кэширо вание.

Глава 3 «С чего начать?» посвящена вопросам получения пакета BIND в случае его отсутствия, применениям пакета, когда он уже у вас в ру ках, определению и выбору доменного имени, а также установления связи с организацией, которая обладает полномочиями делегировать выбранную зону.

Глава 4 «Установка BIND» - это подробное рассмотрение того, как ус тановить два первых DNS-сервера на основе BIND, включая создание базы данных серверов, запуск и диагностику их работы.

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

Глава 6 «Конфигурирование узлов» рассказывает о том, как настраивать клиентскую часть (resolver) BIND, а также об особенностях реализаций клиента - как в составе распространенных Unix-систем, так и приме няемых на платформах Windows 95/NT/2000.

Глава 7 «Работа с BIND» посвящена регулярным действиям админист ратора, выполнение которых необходимо для поддержания устойчи вой работы зон, находящихся под его началом, в частности - проверке состояния DNS-сервера и вопросов, касающихся авторитативных сер веров зоны.

Глава 8 «Развитие домена» рассказывает о планировании роста и эво люции зон, включая вопросы о том, как вырасти большим, а также о планировании переездов и перебоев в работе.

Глава 9 «Материнство» - о радостях, связанных с обретением потомства.

Мы расскажем, когда имеет смысл заводить детей (создавать поддоме ны), как их называть, как их заводить (!) и как присматривать за ними.

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

Глава 11 «Безопасность» посвящена обеспечению безопасности и тем настройкам DNS-сервера, которые относятся к работе с интернет 14 Предисловие брандмауэрами, а также двум новым технологиям DNS, связанным с безопасностью: DNS Security Extensions и подписям транзакций (Transaction Signatures).

Глава 12 «nslookup и dig» подробно рассказывает о самых популярных инструментах DNS-отладки, и содержит описания способов извлече ния неявной информации из удаленных DNS-серверов.

Глава 13 «Чтение отладочного вывода BIND» - это Розеттский камень отладочной информации BIND. Глава поможет разобраться в таинст венной отладочной информации, создаваемой пакетом BIND, а это, в свою очередь, поможет лучше понять, как работает DNS-сервер Глава 14 «Разрешение проблем DNS и BIND» содержит описания и способы разрешения многих распространенных проблем, связанных с использованием DNS и BIND, а также рассказывает о более редких случаях, связанных с ошибками, диагностика которых может вызы вать затруднения.

Глава 15 «Программирование с использованием библиотечных функ ций» рассказывает о том, как использовать функции библиотеки кли ента BIND для опроса DNS-серверов и получения информации в про грамме на языке С или Perl. Приводится исходный текст полезной (как мы надеемся) программы, которая проверяет работоспособность DNS-серверов и их авторитативность.

Глава 16 «Обо всем понемногу» посвящена незатронутым темам. Она содержит описание использования масок (wildcards) в DNS, принци пов работы с хостами и сетями, не имеющими постоянного подключе ния к сети Интернет, кодировки сетевых имен, экспериментальных типов записей и работы с DNS в Windows 2000.

Приложение А «Формат сообщений DNS и RR-записи (resource re cords)» содержит предельно подробный справочник по форматам, ис пользуемым в запросах и ответах DNS, а также полный перечень опре деленных в настоящее время типов RR-записей.

Приложение В «Таблица совместимости BIND» - это перечисление наиболее важных особенностей самых распространенных версий BIND.

Приложение С «Сборка и установка BIND на Linux-системах» содер жит пошаговые инструкции по сборке BIND версии 8.2.3 в Linux.

Розеттский камень - черная базальтовая плита с трехъязычной надписью на египетском иероглифическом, египетском демотическом (разговорном) и древнегреческом языках, обнаруженная в 1799 г. офицером наполеонов ских войск Бушаром при сооружении форта Сен-Жюльен на берегу Розетт ского рукава Нила. Расшифровка иероглифического текста в 1822 г. стала началом изучения египетской иероглифической письменности. - Примеч.

ред.

Для кого эта книга Приложение D «Домены высшего уровня» - это перечисление сущест вующих в настоящее время доменов высшего уровня сети Интернет.

Приложение Е «Настройка DNS-сервера и клиента BIND» содержит справочник по синтаксису и семантике каждого из существующих па раметров настройки серверов и библиотек клиента.

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

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

Глава 6 объясняет, как настроить хосты для работы с новыми DNS серверами. Несколько позже следует обратиться к главе 7, в которой объясняется, как «подкачать» объем, добавляя серверы и данные в зо ну. Главы 12, 13 и 14 содержат описание инструментов и методов, по могающих в устранении проблем.

Опытным администраторам будет полезно прочитать главу 6, чтобы узнать, как настраивать DNS-клиенты на различных хостах, и главу 7, чтобы получить информацию о том, как грамотно сопровождать зоны.

В главе 8 содержатся инструкции, связанные с планированием роста и развития зоны, которые должны быть особенно полезны людям, заня тым в администрировании больших зон. Глава 9 рассказывает о том, как можно стать родителем - то есть, о создании поддоменов, и явля ется учебником этикета, обязательным к прочтению теми, кто пла нирует совершить этот трудный шаг. В главе 10 рассмотрены многие новые возможности BIND версий 8.2.3 и 9.1.0. Глава 11 посвящена обеспечению безопасности DNS-серверов и для опытных администра торов может представлять особенный интерес. Главы с 12 по 14 содер жат описание действий на случай возникновения проблем и со путствующих инструментов, эти главы могут оказаться занима тельным чтением даже для очень опытных администраторов.

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

Программистам, в целях освоения теории DNS, предлагается прочесть главы 1 и 2, а затем главу 15, в которой содержится подробное рассмот рение программирования при помощи библиотечных функций BIND.

Сетевым администраторам, которые напрямую не вовлечены в про цесс сопровождения зон, рекомендуется прочесть главы 1 и 2, в целях освоения теории DNS, главу 12, чтобы научиться использовать nslook up и dig, а затем главу 14, чтобы узнать о способах разрешения возни кающих сложностей.

Почтовым администраторам следует прочесть главы 1 и 2, в целях освоения теории DNS, главу 5, чтобы узнать, как сосуществуют DNS и электронная почта, и главу 12, в которой описаны инструменты nslo okup и dig, - эта глава научит извлекать информацию о маршрутиза ции почты из пространства доменных имен.

Заинтересованные пользователи могут прочесть главы 1 и 2, в целях освоения теории DNS, а затем - любые главы, по желанию!

Мы предполагаем, что читатель знаком с основами администрирова ния Unix-систем, сетевым взаимодействием TCP/IP, а также програм мированием на уровне простых сценариев командного интерпретатора или языка Perl. При этом никаких других специальных знаний не тре буется. При появлении новых терминов и понятий они насколько воз можно подробно объясняются в тексте книги. По возможности мы ис пользовали аналогии с системами Unix (и реальным миром), чтобы об легчить читателю восприятие новых для него концепций.

Примеры программ Исходные тексты программ-примеров, приводимых в книге, доступны для загрузки по протоколу FTP по следующим адресам:

ftp://ftp.uu.net/ublished/oreilly/nutshell/dnsbind/dns.tar.Z ftp://ftp.oreilly.com/publlshed/oreilly/nutshell/dnsbind/ В обоих случаях извлечь файлы из архива можно командой:

На System V - системах необходимо использовать следующую tar-ко манду:

Если команда zcat недоступна в системе, следует использовать отдель ные команды uncompress и tar.

Как связаться с издательством O'Reilly Если не удается получить тексты примеров напрямую по сети Интер нет, но существует возможность посылать и получать сообщения электронной почты, можно воспользоваться службой ftpmail. Чтобы получить справку по использованию службы ftpmail, необходимо отправить сообщение на адрес ftpmail@online.oreilly.com. Следует оста вить пустым поле темы сообщения;

тело письма должно содержать единственное слово - «help».

Как связаться с издательством O'Reilly Комментарии и вопросы, связанные с этой книгой, можно направлять непосредственно издателю:

O'Reilly & Associates, Inc.

101 Morris Street Sebastopol, CA (800) 998-9938 (в США или Канаде) (707) 829-0515 (международный/местный) (707) 829-0104 (факс) Издательством O'Reilly создана веб-страница, посвященная этой кни ге, на которой доступна информация о найденных ошибках и будут по являться разнообразные дополнительные сведения. Страница доступ на по адресу:

http://www.oreilly.com/catalog/dns Если у вас есть технический вопрос или комментарий, связанный с этой книгой, задайте его, отправив сообщение по адресу:

bookquestions@oreilly.com На веб-сайте издательства O'Reilly доступна дополнительная инфор мация о книгах, конференциях, программном обеспечении, источни ках информации и сети O'Reilly (O'Reilly Network):

http://www.oreilly.com Типографские соглашения Использованы следующие соглашения по шрифту и формату для ко манд, инструментов и системных вызовов Unix:

• Выдержки из сценариев или конфигурационных файлов оформле ны моноширинным шрифтом:

if test -x /usr/sbin/named -a -f /etc/named.conf then /usr/sbin/named fi 18 Предисловие • Примеры диалоговых сеансов, отображающие ввод в командной строке и соответствующую реакцию системы, оформлены непро порциональным шрифтом, причем ввод пользователя отмечен жир ным выделением:

X cat /var/run/named.pid • Если команда должна вводиться суперпользователем (администра тором системы, или пользователем root), она предваряется симво лом диеза (#):

# /usr/sbin/named • Заменяемые элементы кода оформлены моноширинным курсивом.

• Имена доменов, файлов, функций, команд, названия страниц руко водства Unix, фрагменты кода оформлены курсивом, если они рас положены внутри параграфа.

Цитаты Цитаты из Льюиса Кэррола в каждой из глав приводятся по версии 2. издания Millenium Fulcrum электронного текста «Алисы в Стране чу дес» из библиотеки Проекта Гутенберга (Project Gutenberg) и по изда нию 1.7 текста «Алиса в Зазеркалье». Цитаты в главах 1,2,5,5,8и из «Алисы в стране чудес», а цитаты в главах 3, 4, 7, 9, 10, 11, 12, 13, 15 и 16 - из «Алисы в Зазеркалье». Благодарности Авторы выражают благодарность Кену Стоуну (Ken Stone), Джерри МакКоллому (Jerry McCollom), Питеру Джеффу (Peter Jeffe), Хэлу Стерну (Hal Stern), Кристоферу Дарему (Christopher Durham), Биллу Уизнеру (Bill Wisner), Дэйву Керри (Dave Curry), Джеффу Окамото (Jeff Okamoto), Брэду Ноулзу (Brad Knowles), Роберту Эльцу (К. Ro bert Elz), а также Полу Викси (Paul Vixie) за их бесценный вклад в на писание этой книги. Мы также хотели бы поблагодарить наших рецен зентов - Эрика Пирса (Eric Pearce), Джека Репенинга (Jack Repen ning), Эндрю Черенсона (Andrew Cherenson), Дэна Тринкла (Dan Trin kle), Билла Лефевра (Bill LeFebvre) и Джона Секреста (John Sechrest) за их критику и предложения. Без помощи этих людей эта книга была бы совсем не такой (а была бы она гораздо короче!).

За второе издание этой книги авторы выражают благодарность безуп речной команде рецензентов: Дэйву Бэрру (Dave Barr), Найджелу В русском издании для цитат используется перевод Нины Демуровой (М.:, ПРЕССА, 1992). -Примеч.ред.

Благодарности Кэмпбеллу (Nigel Campbell), Биллу Лефевру, Майку Миллигану (Mike Milligan) и Дэну Тринклу.

За третье издание книги авторы отдают честь команде мечты техни ческих рецензентов: Бобу Хэлли (Bob Halley), Барри Марголину (Bar ry Margolin) и Полу Викси.

Долг благодарности за четвертое издание причитается Кевину Данлэ пу (Kevin Dunlap), Эдварду Льюису (Edward Lewis) и Брайану Вел лингтону (Brian Wellington), первоклассной команде рецензентов.

Крикет хотел бы отдельно поблагодарить своего бывшего руководите ля, Рика Норденстена (Rick Nordensten), образцового современного высокопроизводительного менеджера, под присмотром которого была написана первая версия этой книги;

своих соседей, которые терпели его эпизодическую раздражительность в течение многих месяцев, и, конечно же, свою жену Пэйдж за постоянную поддержку и за то, что она мирилась с непрекращающимся, даже во время ее сна, стуком кла виш. Что касается второго издания, Крикет хотел бы добавить слова благодарности в адрес своих бывших руководителей Регины Кершнер (Regina Kershner) и Пола Клоуда (Paul Klouda) за их поддержку рабо ты Крикета с сетью Интернет. За помощь в работе над третьим издани ем Крикет считает своим долгом поблагодарить своего партнера, Мэт та Ларсона (Matt Larson), который участвовал в разработке Acme Ra zor;

за четвертое он благодарит своих преданных пушистиков Дакоту и Энни - за их поцелуи и участие, а также замечательного Уолтера Б.

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

Мы хотим сказать спасибо ребятам из O'Reilly & Associates, за их тя желый труд и терпение. В особенности этой благодарности заслужива ют наши редакторы - Майк Лукидес (Mike Loukides) (издания с перво го по третье) и Дебра Кэмерон (Debra Cameron) (четвертое издание), а также огромное количество других людей, которые работали над раз личными изданиями этой книги: Нэнси Котари (Nancy Kotary), Элл и Фонтэйн Мэйден (Ellie Fountain Maden), Роберт Романо (Robert Roma no), Стивен Абраме (Steven Abrams), Кишмет МакДоноу-Чен (Kismet McDonough-Chan), Сет Мэйслин (Seth Maislin), Элли Катлер (Ellie Cut ler), Майк Сьерра (Mike Sierra), Ленни Мельнер (Lenny Muellner), Крис Райли (Chris Reilley), Эмили Куилл (Emily Quill), Анна-Мария Вадува (Anne-Marie Vaduva) и Брэнда Миллер (Brenda Miller). Также спасибо Джерри Пику (Jerry Peek) за самую разнообразную поддержку, и Тиму О'Рейли за то, что он вдохновил нас на написание этой книги.

И спасибо Эди за сверчка1 на обложке!

Cricket (фамилия одного из авторов) переводится с англ. как «сверчок». Примеч. перев.

• (Очень) краткая история сети Интернет • Интернет и интернет-сети •Система доменных имен в двух словах • История пакета BIND • Надо ли мне использовать DNS?

Основы Кролик надел очки.

- С чего начинать, Ваше Величество? - спросил он.

- Начни с начала, - важно ответил Король, продолжай, пока не дойдешь до конца. Как дойдешь - кончай!

Чтобы понять DNS, необходимо обратиться к истории сети ARPAnet.

Система DNS была создана с целью решения конкретных проблем этой сети, а сеть Интернет, выросшая из ARPAnet, сейчас является глав ным потребителем этих решений.

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

(Очень) краткая история сети Интернет В конце шестидесятых Управление передовых исследований Министер ства обороны США (Department of Defense's Advanced Research Agency, или ARPA) - позднее DARPA- открыло финансирование ARPAnet, экспериментальной глобальной компьютерной сети, объединившей важные исследовательские организации страны. Первоначальной це лью создания этой сети было разделение дорогостоящих или дефицит ных компьютерных ресурсов между государственными подрядчика ми. Но с самого начала пользователи ARPAnet использовали сеть и для совместной работы: они обменивались файлами и программами, сообщениями электронной почты (получившей теперь повсеместное распространение), объединяли усилия по разработке и исследовани ям, используя разделяемые ресурсы компьютеров сети.

Набор протоколов TCP/IP (Transmission Control Protocol/Internet Pro tocol) был разработан в начале восьмидесятых годов и быстро получил Интернет и интернет-сети статус стандарта для сетевого обмена информацией между узлами ARPAnet. Включение этого набора протоколов в популярную операци онную систему BSD Unix, разработанную в Калифорнийском универ ситете Беркли, сыграло определяющую роль в процессе демократиза ции и объединения сетей. Система BSD Unix университетам была до ступна практически бесплатно. Так работа с сетями и доступ к ARPA net стали внезапно доступными и очень дешевыми для большого числа организаций, которые ранее никак не были связаны с ARPAnet. Ма шины, подключавшиеся к ARPAnet, входили также в состав локаль ных сетей, и в итоге это привело к объединению многочисленных раз розненных локальных сетей посредством ARPAnet.

Сеть разрослась с очень небольшого числа узлов до десятков тысяч.

Первоначальная сеть ARPAnet стала основой объединения локальных и региональных сетей, работающих по протоколам TCP/IP. Это объ единение носит название Интернет.

Однако в 1988 году организация DARPA пришла к заключению, что эксперимент окончен. Министерство обороны приступило к демонта жу сети ARPAnet. В этот момент несущим остовом для сети Интернет стала другая сеть, которая финансировалась национальным научным фондом (National Science Foundation) и носила название NSFNET.

Уже не так давно, весной 1995 года, сеть Интернет в очередной раз сменила главную магистраль;

финансируемая обществом NSFNET ус тупила место целому ряду коммерческих магистралей, управляемых операторами дальней связи, такими как MCI и Sprint, а также такими опытными коммерческими сетевыми организациями как PSINet и UUNET.

Сегодня сеть Интернет объединяет миллионы узлов по всему миру.

Большая часть не-РС машин подключена к сети Интернет. Некоторые из новых коммерческих информационных магистралей имеют про пускную способность, измеряемую гигабитами в секунду, что в десят ки тысяч раз превышает пропускную способность когда-то существо вавшей ARPAnet. Ежедневно десятки миллионов людей используют сеть для общения и совместной работы.

Интернет и интернет-сети Следует сказать пару слов об Интернете и интернет-сетях. В тексте различие между названиями кажется незначительным: одно название всегда пишется с прописной буквы, второе всегда нет. Тем не менее, разница в значении - существенна. Интернет с заглавной буквы «И» - обозначение сети, которая началась с ARPAnet и существует се годня, грубо говоря, как объединение всех TCP/IP-сетей, прямо или косвенно связанных с коммерческими информационными магистра лями США. При внимательном рассмотрении - это целый ряд различ 22 Глава 1. Основы ных сетей - коммерческих опорных сетей TCP/IP, корпоративных и правительственных сетей США, а также TCP/IP-сетей других стран.

Сети объединены маршрутизаторами и высокоскоростными цифровы ми каналами.

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

Сеть интернет не всегда связана с сетью Интернет и не обязательно ос нована на сетевых протоколах TCP/IP. Существуют изолированные корпоративные интернет-сети, а также сети на основе протоколов Xe rox XNS или DECnet.

Относительно новый термин «intranet», по сути дела, - это всего лишь рекламное название для интернет-сетей, которое используется, чтобы подчеркнуть применение технологий, обкатанных в Интернете, в рам ках внутренних корпоративных сетей. С другой стороны, extranet сети - это сети интернет, объединяющие сотрудничающие компании, либо компании с их агентами по продаже, поставщиками и клиентами.

История системы доменных имен В семидесятых годах сеть ARPAnet представляла собой тесное сооб щество из нескольких сотен узлов. Всю жизненно-важную информа цию по узлам, в частности, необходимую для взаимных преобразова ний имен и адресов узлов ARPAnet, содержал единственный файл HOSTS.TXT. Известная Unix-таблица узлов, /etc/hosts, - прямо унас ледовала свою структуру от файла HOSTS.TXT (в основном с помо щью удаления ненужных на Unix-системах полей).

За файл HOSTS.TXT отвечал Сетевой информационный центр (NIC, Network Information Center) Стэнфордского исследовательского ин ститута (SRI, Stanford Research Insitute). В тот период времени единст венным источником, распространявшим файл, являлся узел SRI-NIC. Администраторы ARPAnet, как правило, просто посылали изменения электронной почтой в NIC и периодически синхронизировали свои фай лы HOSTS.TXT с копией на узле SRI-NIC с помощью протокола FTP.

Присылаемые ими изменения добавлялись в файл HOSTS.TXT один или два раза в неделю. Однако по мере роста сети ARPAnet эта схема стала неработоспособной. Размер файла рос пропорционально количест ву узлов ARPAnet. Еще быстрее рос информационный поток, связан ный с необходимостью обновления файла на хостах: появление одного нового узла приводило не только к добавлению строки в HOSTS.TXT, Организация SRI International в настоящее время уже не связана жестко со Стэнфордским исследовательским институтом, расположенном в Менло Парк (в Калифорнии);

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

Интернет и интернет-сети но и к потенциальной необходимости синхронизации данных каждого узла с данными SRI-NIC.

После перехода ARPAnet на протоколы TCP/IP рост сети стал взрыв ным. Появился гордиев узел проблем, связанных с файлом HOSTS.TXT:

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

Конфликты имен Никакие два хоста, описанные в файле HOSTS.TXT, не могли но сить одинаковые имена. Организация NIC могла контролировать присваивание адресов способом, гарантирующим их уникальность, но не имела никакого влияния на имена узлов. Не было способа предотвратить добавление узла с уже существующим именем, при том, что такое действие нарушало работу всей схемы. Так, добавле ние узла с именем, идентичным имени одного из крупных почто вых концентраторов, могло привести к нарушению работы почто вых служб большей части сети ARPAnet.

Синхронизация Синхронизация файлов в масштабах быстро растущей сети стано вилась все более сложной задачей. К тому моменту, когда обновлен ный файл HOSTS.TXT достигал самых далеких берегов выросшей ARPAnet, адреса отдельных узлов успевали измениться, а также появлялись новые узлы, доступ к которым был необходим пользо вателям.

Основная проблема заключалась в том, что схема с файлом HOSTS.TXT не поддавалась масштабированию. По иронии судьбы, успех ARPAnet как эксперимента вел к моральному устареванию и провалу механиз ма HOSTS.TXT.

Административные советы ARPAnet начали исследование, которое должно было привести к созданию замены HOSTS.TXT. Целью его было создание системы, которая решила бы проблемы, присущие свод ной таблице узлов. Новая система должна позволять производить ло кальное управление данными, но делать эти данные доступными всем.

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

Ответственным за разработку архитектуры новой системы стал Пол Мокапетрис, работавший тогда в Институте информационных наук (Information Sciences Institute). В 1984 году он издал документы RFC 24 Глава 1. Основы 882 и 883, в которых описывалась система доменных имен (Domain Name System, или DNS). Эти RFC-документы были обновлены доку ментами RFC 1034 и 1035, которые и являются в настоящее время действующей спецификацией DNS.1 RFC 1034 и 1035 к настоящему времени дополняются многими другими подобными документами, в которых описаны потенциальные проблемы DNS с точки зрения сете вой безопасности, возможные трудности реализации, проблемы адми нистративного плана, механизмы динамического обновления DNS-cep веров, обеспечение безопасности зональных данных и многое другое.

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

Серверная часть клиент-серверного механизма DNS представлена про граммами, которые называются DNS-серверами (name servers, дослов но - серверами имен). DNS-серверы владеют информацией о некоторых сегментах базы данных и делают ее доступной клиентам, которые на зываются поисковыми анализаторами (resolvers).2 Как правило, DNS клиент - это просто набор библиотечных функций, которые создают запросы и посылают их по сети серверу имен.

Структура базы данных DNS очень похожа на структуру файловой системы Unix (рис. 1.1). Вся база данных (или файловая система) представлена в виде перевернутого дерева, корень (корневой узел) ко торого расположен на самом верху. Каждый узел дерева имеет при крепленную текстовую метку, которая идентифицирует его относи тельно родительского узла, по аналогии с «относительным путевым именем» в файловой системе (например, bin). Одна из меток, пустая, (она обозначается как "") закреплена за корневым узлом дерева. В тексте корневой узел обозначается точкой (.). В файловой системе Unix корень обозначается символом «слэш» (/).

Каждый узел является корнем новой ветви дерева. Каждая из ветвей (поддеревьев) является разделом базы данных- «каталогом» в ин Документы RFC (Request for Comments, запрос комментариев) являются частью относительно неформальной процедуры введения новых техноло гий в сети Интернет. RFC-документы обычно свободно распространяются и содержат описания технического плана технологий, предназначенные, во многих случаях, для разработчиков.

Далее в тексте будет использоваться как термин «поисковый анализатор», так и «клиентская часть DNS», или просто «DNS-клиент», в зависимости от контекста. - Примеч. науч. ред.

Система доменных имен в двух словах Рис. 1.1. База данных DNS и файловая система Unix терпретации файловой системы Unix, или доменом в интерпретации системы доменных имен. Каждый домен или каталог может быть раз бит на еще более мелкие подразделы, которые в DNS называются под доменами, а в файловых системах- «подкаталогами». Поддомены, как и подкаталоги, изображаются как потомки соответствующих ро дительских доменов.

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

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

рис. 1.2), при этом имена разделяются символом «прямая наклонная черта» («слэш»).

В DNS каждый домен может быть разбит на поддомены, и ответствен ность за эти поддомены может распределяться между различными ор ганизациями. Допустим, компания Network Solutions сопровождает домен edu (educational, то есть образовательный), но делегирует ответ ственность за поддомен berkeley.edu Калифорнийскому университету Беркли (рис. 1.3). это похоже на удаленное монтирование файловой системы: определенные каталоги файловой системы могут в действи 26 Глава 1. Основы Рис. 1.2. Чтение имен DNS и файловой системы Unix тельности являться файловыми системами, расположенными на дру гих узлах и смонтированными удаленно. К примеру, администратор узла winken (рис. 1.3) отвечает за файловую систему, которая на ло кальном узле выглядит как содержимое каталога /usr/nfs/winken.

Делегирование управления поддоменом berkeley.edu Калифорнийско му университету Беркли приводит к созданию новой зоны - независи мо администрируемой части пространства имен. Зона berkeley.edu те перь не зависит от edu и содержит все доменные имена, которые закан чиваются на berkeley.edu. С другой стороны, зона edu содержит только доменные имена, оканчивающиеся на edu, но не входящие в делегиро ванные зоны, такие, например, как berkeley.edu. berkeley.edu может быть поделен на поддомены с именами вроде cs.berkeley.edu, и некото рые из этих поддоменов могут быть выделены в самостоятельные зо ны, если администраторы berkeley.edu делегируют ответственность за них другим организациям. Если cs.berkeley.edu является самосто ятельной зоной, зона berkeley.edu не содержит доменные имена, кото рые заканчиваются на cs.berkeley.edu (рис. 1.4).

Доменные имена используются в качестве индексов базы данных DNS.

Данные DNS можно считать «привязанными» к доменному имени. В файловой системе каталоги содержат файлы и подкаталоги. Анало Система доменных имен в двух словах Рис. 1.3. Удаленное управление доменами разных уровней и файловыми системами гичным образом домены могут содержать узлы и поддомены. Домен включает в себя те узлы и поддомены, доменные имена которых при надлежат этому домену.

У каждого узла в сети есть доменное имя, которое является указате лем на информацию об узле (рис. 1.5). Эта информация может вклю чать IP-адрес, информацию о маршрутизации почтовых сообщений и другие данные. Узел может также иметь один или несколько псевдо нимов доменного имени, которые являются просто указателями на ос 28 Глава 1. Основы Рис. 1.4. Зоны edu, berkeley.edu и cs.berkeley.edu новное (официальное, или каноническое) доменное имя. На рис. 1. mailhub.nv... является псевдонимом канонического имени rin con.ba.ca...

Для чего нужна столь сложная структура? Чтобы решить проблемы, существовавшие при использовании HOSTS.TXT. К примеру, строгая иерархичность доменных имен устраняет угрозу конфликтов имен.

Рис. 1.5. Псевдоним в DNS, ссылающийся на каноническое имя История пакета BIND Рис. 1.6. Решение проблемы конфликтов имен Имя каждого домена уникально, так что организация, управляющая доменом, вольна придумывать имена поддоменов, входящих в этот до мен, самостоятельно. Независимо от выбранных имен, имена эти не будут конфликтовать с другими доменными именами, поскольку за канчиваются уникальным именем домена, сопровождаемого только этой организацией. Так, организация, ответственная за домен hic.com может дать узлу имя puella (рис. 1.6), поскольку известно, что домен ное имя узла будет заканчиваться уникальным доменным именем hic.com.

История пакета BIND Первая реализация системы доменных имен называлась JEEVES, и была разработана самим Полом Мокапетрисом. Более поздняя реали зация носит название BIND, это аббревиатура от Berkeley Internet Na me Domain, и была разработана для операционной системы 4.3 BSD Unix (Беркли) Кевином Данлэпом. В настоящее время развитием и со провождением пакета BIND занимается Internet Software Consortium. На пакете BIND мы и сосредоточимся в данной книге, поскольку именно BIND является сегодня наиболее популярной и распространен ной реализацией DNS. Пакет доступен на большинстве разновиднос тей системы Unix и входит в стандартную конфигурацию систем от большинства поставщиков Unix. BIND также был портирован на плат форму Microsoft Windows NT.

Более подробно об организации Internet Software Consortium и ее разработ ках в области BIND можно узнать по адресу http://www.isc.org/bind.html 30 Глава 1. Основы Надо ли мне использовать DNS?

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

Если вы подключены к сети Интернет...

...DNS является жизненной необходимостью. DNS можно считать общепринятым языком сети Интернет: почти все сетевые службы в Интернете, включая World Wide Web, электронную почту, удален ный терминальный доступ и передачу файлов, используют DNS.

С другой стороны, подключение к сети Интернет вовсе не означает, что не удастся избежать самостоятельной установки и сопровожде ния нужных пользователю зон. В случае ограниченного числа уз лов всегда можно найти уже существующую зону и стать ее частью (подробнее - в главе 3 «С чего начать?»). Как вариант, можно найти кого-то, кто позаботится о размещении зоны. Если пользователь платит интернет-провайдеру за подключение, обычно существует возможность разместить свою зону на технологических мощностях этого провайдера. Существуют также компании, предоставляющие подобную услугу за отдельную плату.

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

Если у вас интернет-сеть на основе протоколов TCP/IP...

...то DNS, вероятно, не помешает. В данном случае под интернет сетью мы не подразумеваем простую сеть из одного сегмента Ether net и нескольких рабочих станций, построенную на протоколах TCP/IP (такой вариант описан в следующем разделе), но достаточно сложную «сеть сетей». Например - множество Appletalk-сегментов плюс несколько сетей Apollo token ring, объединенных вместе.

Если интернет-сеть является преимущественно гомогенной, и узлы не нуждаются в службе DNS (скажем, в случае крупной интернет сети DECnet или OSI), вполне возможно, что можно обойтись без нее. Но в случае разнородных хостов, в особенности, если некото рые из них работают под управлением Unix, DNS пригодится. Сис тема упростит распространение информации об узлах и избавит ад Надо ли мне использовать DNS? министратора от необходимости выдумывания своей схемы рас пространения таблиц хостов.

Если у вас собственная локальная сеть...

...и эта сеть не соединена с большей сетью, вполне возможно обойтись без DNS. Можно попробовать использовать службу Win dows Internet Name Service (WINS) от Microsoft, таблицы хостов, или Network Information Service (NIS) от Sun.

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

• Пространство доменных имен • Пространство доменных имен сети Интернет • Делегирование • DNS-серверы и зоны • DNS-клиенты • Разрешение имен • Кэширование Как работает DNS - Что толку в книжке, - подумала Алиса, если в ней нет ни картинок, ни разговоров?

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

Мы уже рассмотрели некоторые важные аспекты работы DNS, вклю чая архитектуру «клиент-сервер» и структуру базы данных. Однако мы не особенно вдавались в детали и не объясняли работу основных механизмов DNS.

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

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

Пространство доменных имен Распределенная база данных системы доменных имен индексируется по именам узлов. Каждое доменное имя является просто путем в ог Пространство доменных имен ромном перевернутом дереве, которое носит название пространства доменных имен. Иерархическая структура дерева, отображенная на рис. 2.1, похожа на структуру файловой системы Unix. Единственный корень дерева расположен наверху.1 В файловых системах Unix эта точка называется корневым каталогом и представлена символом «слэш» (/). В DNS же это просто «корень» («root»). Как и файловая система, дерево DNS может иметь любое количество ответвлений в лю бой точке пересечения, или узле. Глубина дерева ограничена и может достигать 127 уровней (предел, до которого вы вряд ли когда-нибудь доберетесь).

Рис. 2.1. Структура пространства имен DNS Доменные имена Каждому узлу дерева соответствует текстовая метка, длина которой не может превышать 63 символов, причем использование символа точки недопустимо. Пустая (нулевой длины) метка зарезервирована для кор ня. Полное доменное имя произвольного узла дерева - это последова тельность меток в пути от этого узла до корня. Доменные имена всегда читаются от собственно узла к корню («вверх» по дереву), причем мет ки разделяются точкой.

Если метка корневого узла должна быть отображена в доменном име ни, она записывается как символ точки, например, так: «www.oreil ly.com.». (На самом деле имя заканчивается точкой-разделителем и пустой меткой корневого узла.) Сама по себе метка корневого узла за Понятно, что это дерево компьютерщика, а не ботаника.

34 Глава 2. Как работает DNS писывается исключительно из соображений удобства, как самостоя тельная точка (.)• Как следствие, некоторые программы интерпрети руют имена доменов, заканчивающиеся точкой, как абсолютные. Аб солютное доменное имя записывается относительно корня и однознач но определяет расположение узла в иерархии. Абсолютное доменное имя известно также под названием полного доменного имени, обозна чаемого аббревиатурой FQDN {fully qualified domain name). Имена без за вершающей точки иногда интерпретируются относительно некоторого доменного имени (не обязательно корневого) точно так же, как имена каталогов, не начинающиеся с символа «/» (слэш), часто интерпрети руются относительно текущего каталога.

В DNS «братские» узлы, то есть узлы, имеющие общего родителя, должны иметь разные метки. Такое ограничение гарантирует, что до менное имя единственно возможным образом идентифицирует отдель ный узел дерева. Это ограничение на практике не является ограничени ем, поскольку метки должны быть уникальными только для братских узлов одного уровня, но не для всех узлов дерева. То же ограничение су ществует в файловых системах Unix: двум «единоутробным» катало гам или двум файлам в одном каталоге не могут быть присвоены одина ковые имена. Невозможно создать два узла hobbes.pa.ca.us в простран стве доменных имен, и невозможно создать два каталога /usr/bin (рис. 2.2). Тем не менее, можно создать пару узлов с именами hob bes.pa.ca.us и hobbes.lg.ca.us, точно так же, как можно создать пару ка талогов с именами /bin и /usr/bin.

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

Так, к примеру, вершиной домена purdue.edu является узел с именем purdue.edu (рис. 2.3).

Аналогичным образом, в корне файловой системы /usr мы ожидаем увидеть каталог с именем /usr (рис. 2.4).

Каждое доменное имя в поддереве считается принадлежащим домену.

Поскольку доменное имя может входить в несколько поддеревьев, оно также может входить в несколько доменов. К примеру, доменное имя pa.ca.us входит в домен ca.us и при этом является также частью домена us (рис 2.5).

Так что теоретически домен - это просто сегмент пространства доменных имен. Но если домен состоит только из доменных имен и других доме нов, где узлы сети - хосты? Ведь домены-то — это группы хостов, верно?

Узлы сети, разумеется, присутствуют, и представлены они доменными именами. Следует помнить, что доменные имена являются просто ука зателями в базе данных DNS. «Хосты» - это доменные имена, которые указывают на информацию по каждому конкретному хосту. Домен со Пространство доменных имен Рис. 2.2. Обеспечение уникальности доменных имен и путевых имен в файловых системах Unix держит все узлы сети, доменные имена которых в него входят. Узлы сети связаны логически, зачастую по географическому или организа ционному признаку, и совсем необязательно - сетью, адресом или ти пом используемого оборудования. Десяток узлов, входящих в разные сети, возможно, даже расположенных в разных странах, может при надлежать одному-единственному домену. Доменные имена, соответствующие листьям дерева, как правило, от носятся к отдельным узлам сети и могут указывать на сетевые адреса, Предостережение: не стоит путать домены DNS с доменами в службе NIS, Network Information Service от Sun. Несмотря на то, что домен NIS - это тоже группа узлов, а доменные имена в обеих службах имеют сходную ор ганизацию, концептуальные различия достаточно велики. В NIS использу ется иерархическая организация имен, но иерархия на этом и кончается:

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

36 Глава 2. Как работает DNS Рис. 2.3. Домен purdue.edu информацию об оборудовании и о маршрутизации почты. Доменные имена внутри дерева могут идентифицировать отдельные узлы, а так же могут указывать на информацию об этом домене. Имена доменов внутри дерева не привязаны жестко к тому или другому варианту. Они могут представлять как домен (имени которого соответствуют), так и отдельный узел в сети. Так, hp.com является именем домена компании Hewlett-Packard и доменным именем узлов, на которых расположен главный веб-сервер Hewlett-Packard.

Тип информации, получаемой при использовании доменного имени, за висит от контекста применения имени. Посылка почтовых сообщений кому-то в домен hp.com приводит к получению информации о маршру Рис. 2.4. Каталог /usr Пространство доменных имен Рис. 2.5. Узел, входящий в несколько доменов тизации почты, открытие telnet-сеанса связи с этим доменом приводит к поиску информации об узле (на рис. 2.6, к примеру, это IP-адрес уз ла hp.com).

Домен может содержать несколько поддеревьев, которые носят назва ние поддоменов. Самый простой способ выяснить, является ли домен поддоменом дру гого домена, - сравнить их доменные имена. Доменное имя поддомена заканчивается доменным именем родительского домена. К примеру, Рис. 2.6. Внутренний узел дерева, связанный как с информацией о конкретном узле сети, так и с иерархической Термины домен и поддомен в документации по DNS и BIND зачастую ис пользуются в качестве взаимозаменяемых. В настоящей книге мы исполь зуем термин «поддомен» в качестве относительного: домен является поддо меном другого домена, если корень поддомена принадлежит включающему домену.

38 Глава 2. Как работает DNS домен la.tyrell.com должен являться поддоменом домена tyrell.com, по скольку имя la.tyrell.com заканчивается именем tyrell.com. Аналогич ным образом этот домен является поддоменом домена сот, как и домен tyrell.com.

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

• Домен высшего уровня в качестве непосредственного родителя име ет корневой домен.

• Домен первого уровня в качестве непосредственного родителя (так же) имеет корневой домен (то есть он является доменом высшего уровня).

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

Записи ресурсов Информация, связанная с доменными именами содержится в записях ресурсов (RRs, resource records).1 Записи разделяются на классы, каж дый из которых определяет тип сети или программного обеспечения. В настоящее время существуют классы для интернет-сетей (на основе се мейства протоколов TCP/IP), сетей на основе проколов Chaosnet, a также сетей, которые построены на основе программного обеспечения Hesiod. (Chaosnet - старая сеть, имеющая преимущественно истори ческое значение).

Популярность класса интернет-сетей значительно превосходит попу лярность остальных классов. (Мы не уверены, что где-то до сих пор ис пользуется класс Chaosnet, а использование класса Hesiod в основном ограничивается пределами Массачусетского технологического инсти тута - MIT). В настоящей книге мы сосредоточимся на классе интер нет-сетей.

В пределах класса записи делятся -на типы, которые соответствуют различным видам данных, хранимых в пространстве доменных имен.

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

Пространство доменных имен сети Интернет тип. (Подробно типы и форматы RR-записей для интернет-сетей опи саны в приложении А «Формат сообщений DNS и RR-записей».) Не беспокойтесь, если информация кажется излишне схематичной:

записи класса интернет будут более подробно рассмотрены позже. На иболее часто используемые RR-записи описаны в главе 4 «Установка BIND», а более полный перечень приводится в приложении А.

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

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

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

Домены высшего уровня Изначально домены высшего уровня делили пространство имен сети Интернет на семь доменов:

сот Коммерческие организации, такие как Hewlett-Packard (hp.com), Sun Microsystems (sun.com) или IBM (ibm.com).

edu Образовательные организации, такие как Калифорнийский уни верситет Беркли (berkeley.edu) и университет Пердью (purdue.edu).

gov Правительственные организации, такие как NASA (nasa.gov) и На циональный научный фонд (nsf.gov).

40 Глава 2 Как работает DNS mil Военные организации, такие как армия (army.mil) и флот (navy.mil) США.

net В прошлом организации, обеспечивающие работу сетевой инфра структуры, такие как NSFNET (nsf.net) и UUNET (uu.net). В году домен net, как и сот, стал доступен для всех коммерческих ор ганизаций.

org В прошлом некоммерческие организации, такие как Фонд элект ронной границы (Electronic Frontier Foundation) (eff.org). Как и в случае с доменом net, ограничения были сняты в 1996 году.

int Международные организации, такие как NATO (nato.int).

Существовал еще один домен высшего уровня, который назывался аr pа и использовался в процессе перехода сети ARPAnet от таблиц узлов к системе доменных имен. Изначально все узлы ARPAnet имели до менные имена, принадлежавшие домену аrра, так что их было не сложно отличать. Позже они разбрелись по различным поддоменам организационных доменов высшего уровня. При этом домен аrра все еще используется, и чуть позже мы расскажем, как именно.

Можно заметить некоторую националистическую предрасположен ность в примерах - прежде всего речь идет об организациях США. Это легче понять - и простить - если вспомнить, что сеть Интернет нача лась с сети ARPAnet, исследовательского проекта, который финанси ровался правительством США. Никто и не предполагал, что создание ARPAnet увенчается подобным успехом и что этот успех в итоге при ведет к созданию международной сети Интернет.

В наши дни эти домены называются родовыми доменами высшего уров ня (generic top-level domains или gTLDs). В начале 2001 года их список расширится, и будет включать домены name, biz, info, а также pro, ко торые создаются, чтобы приспособить иерархию к взрывному росту се ти Интернет и удовлетворить потребность в доменном «пространстве».

Организация, ответственная за управление системой доменных имен сети Интернет, - Internet Corporation for Assigned Names and Numbers (ICANN) - утвердила добавление новых gTLD, а также явно конкрети зированных aero, coop и museum в конце 2000 года. Информация о ра боте организации ICANN и новых доменах высшего уровня доступна по адресу http://www.icann.org.

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

Эти доменные суффиксы соответствуют существующему международ ному стандарту ISO 3166.1 Стандарт ISO 3166 определяет официаль ные двухбуквенные сокращения для каждой страны мира. Текущий список доменов высшего уровня приведен в приложении D «Домены высшего уровня ».

По нисходящей В пределах упомянутых доменов верхних уровней существующие тра диции и степень их соблюдения начинает варьироваться. Некоторые из доменов высшего уровня, упомянутых в стандарте ISO 3166, в общем и целом следуют исходной организационной схеме США. К примеру, в домен высшего уровня Австралии, аи, входят такие поддомены, как edu.au и com.au. Некоторые из прочих доменов ISO 3166 следуют при меру домена uk и порождают поддомены организационного деления, например co.uk, для корпоративного использования, а скажем ac.uk для нужд академического сообщества. Тем не менее в большинстве случаев географические домены высшего уровня имеют организаци онное деление.

Однако это не относится к домену высшего уровня us. В домен us вхо дит 50 поддоменов, которые соответствуют - попробуйте угадать! - пя тидесяти штатам.2 Имя каждого из этих поддоменов соответствует стандартному двухбуквенному сокращению названия штата, именно эти сокращения стандартизированы почтовой службой США. В преде лах каждого поддомена деление в основном такое же, географическое:

большинство поддоменов соответствуют отдельным городам. В преде лах поддомена города все прочие поддомены обычно соответствуют от дельным узлам.

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

Попрактикуемся на следующих примерах:

За исключением Великобритании. В соответствии со стандартом ISO 3166 и традициями Интернета доменный суффикс высшего уровня для Велико британии должен быть gb. На деле же большинство организаций Велико британии и Северной Ирландии (то есть Соединенного Королевства) ис пользуют суффикс uk. А еще они ездят по неправильной стороне дороги.

В действительности поддоменов в домене us чуть больше: один для Ва шингтона (округ Колумбия), один для острова Гуам, и т. д.

42 Глава 2. Как работает DNS lithium.cchem.berkeley.edu Здесь у читателей фора, поскольку мы уже упоминали, что berke ley.edu ~ это домен университета Беркли. (Даже если бы мы не рас сказали заранее, можно было бы догадаться, что имя, вероятнее всего, принадлежит одному из университетов США, поскольку принадлежит домену высшего уровня edu.) cchem - поддомен berke ley.edu, принадлежащий факультету химии. И наконец, lithium (литий) - имя конкретного узла в домене, помимо которого в поддо мене есть, вероятно, еще около ста узлов, если под каждый хими ческий элемент выделен отдельный узел.

winnie.corp.hp.com Этот пример посложнее, но ненамного. Домен hp.com, по всей види мости, принадлежит компании Hewlett-Packard (кстати, и об этом мы уже говорили). Поддомен согр, вне всякого сомнения, подразу мевает корпоративную штаб-квартиру. A winnie - вероятно, просто неудачно выбранное имя узла.

fernwood.mpk.ca.us В этом примере придется использовать знания о структуре домена us. ca.us - очевидно, домен штата Калифорния, но mpk может озна чать что угодно. В данном случае очень трудно догадаться, что это доменное имя Менло-Парка, если не знать географию района Сан Франциско. (Нет, это не тот же самый Менло-Парк, в котором жил Эдисон, тот находится в Нью-Джерси.) daphne.ch.apollo.hp.com Этот пример мы приводим для того, чтобы у читателей не появи лось ложного ощущения, будто все доменные имена состоят из че тырех меток, apollo.hp.com - бывший поддомен компании Apollo Computer, принадлежащий домену hp.com. (Когда компания HP приобрела компанию Apollo, то не забыла купить и интернет-домен Apollo, apollo.com, который позже был переименован в apol lo.hp.com.) ch.apollo.hp.com - отделение Apollo в Челмсфорде (штат Массачусетс), daphne - просто узел в Челмсфорде.

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

Аналогичным образом организация, сопровождающая домен, может разделить его на несколько поддоменов, каждый из которых может Делегирование быть делегирован какой-либо другой организации. Организация, по лучившая домен таким путем, несет ответственность за работу с дан ными этого поддомена. Она может свободно изменять эти данные, раз делять поддомен на несколько более мелких поддоменов, а те, в свою очередь, снова делегировать. Родительский домен сохраняет только указатели на источники данных для поддоменов, в целях перенаправ ления запросов по соответствующим адресам. К примеру, домен stan ford.edu, делегирован тем ребятам в Стэнфорде, которые управляют университетскими сетями (рис. 2.7.) Не все организации делегируют домены целиком, как не каждый на чальник делегирует всю свою работу. Домен может иметь несколько делегированных поддоменов, но также включать узлы, которые не принадлежат этим поддоменам. К примеру, корпорация Acme (которая снабжает одного известного койота различными приспособлениями) имеет отделение в городе Рокавей, а ее штаб-квартира расположена в Каламазу, поэтому могут существовать поддомены rockaway.acme.com и kalamazoo.acme.com. Однако несколько узлов, соответствующих от делам сбыта Acme, разбросаны по всей стране и скорее принадлежат собственно домену acme.com, нежели какому-либо из поддоменов. Позже мы расскажем, как создавать и делегировать поддомены.

Сейчас же важно понять, что термин делегирование относится к пере даче ответственности за поддомен сторонней организации.

Рис. 2.7. stanford.edu делегирован Стэнфордскому университету «ACME Co.» - не существующая в действительности корпорация из муль типликационного сериала «Bugs Bunny & Roadrunner». Домен acme.com принадлежит, на самом деле, организации, разрабатывающей программ ное обеспечение для Unix-систем. - Примеч. ред.

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

Разница между зоной и доменом важна, но не очень заметна. Все доме ны высшего уровня и домены уровней от второго и ниже, такие как berkeley.edu и hp.com, разбиваются на более мелкие, легко управляе мые единицы, путем делегирования. Эти единицы называются зонами.

Домен edu (рис. 2.8) разделен на много зон, включая зону berkeley.edu, зону purdue.edu и зону nwu.edu. На вершине домена существует также зона edu. Естественно, что ребята, управляющие edu, разбивают домен edu на более мелкие единицы: в противном случае им пришлось бы са мим сопровождать поддомен berkeley.edu. Гораздо более разумно деле гировать berkeley.edu — Беркли. Что же остается тем, кто управляет edu? Зона edu, которая содержит преимущественно информацию о де легировании для поддоменов, входящих в edu.

Поддомен berkeley.edu, в свою очередь, разбивается на несколько зон путем делегирования (рис. 2.9). Делегированные поддомены носят име Рис. 2.8. Разбивка домена edu на зоны.

DNS серверы и зоны на cc, cs, се, те, и т. д. Каждый из этих поддоменов делегируется ряду серверов имен, некоторые из которых являются компетентными и для berkeley.edu. Тем не менее, зоны живут самостоятельно, и могут иметь совершенно отдельный набор авторитативных DNS-серверов.

Рис. 2.9. Разбивка домена berkeley.edu на зоны Зона и домен могут включать одни и те же доменные имена, но содер жать различные наборы узлов. В частности, зона не содержит никаких узлов, входящих в делегируемые поддомены. Так, домен высшего уровня са (Канада) включает поддомены ab.ca, оп.са и qc.ca, относящи еся к провинциям Альберта, Онтарио и Квебек. Ответственность за со провождение данных в поддоменах ab.ca, оп.са и qc.ca может быть де легирована серверам имен в каждой из этих провинций. Домен са со держит всю информацию для са, а также всю информацию в ab.ca, оп.са и qc.ca. Но зона са содержит данные только для са (рис. 2.10), и эти данные, вероятно, в основном являются указателями на делегиро ванные поддомены. В то же время ab.ca, оп.са и qc.ca являются отдель ными от са зонами.

При этом, если поддомен какого-либо домена не делегирован, зона со держит имена доменов и данные этого поддомена. Так что поддомены Ьс.са и sk.ca (Британская Колумбия и Саскачеван) домена са могут су ществовать, но могут не быть делегированы. (Возможно, власти про винций Б.К. и Саскачеван еще не готовы управлять собственными зо нами, а люди, ответственные за зону высшего уровня са, желают со хранить согласованность пространства имен и немедленно создать поддомены для всех провинций Канады.) В таком случае, зона са бу 46 Глава 2. Как работает DNS Рис. 2.10. Домен са...

дет иметь неровную нижнюю границу, включая bс.са и sk.ca, но не другие поддомены са (рис. 2.11).

Рис. 2.11....и зона са Теперь становится понятно, почему объектом, загружаемым DNS-cep вером, является зона, а не домен: домен может содержать больше ин формации, чем требуется для работы сервера.1 Домен может содер Представьте, что получится, если корневой сервер имен загрузит корневой домен вместо зоны: он загрузит информацию обо всем пространстве имен!

DNS-серверы и зоны жать данные, делегированные другим серверам. Поскольку зоны огра ничиваются делегированием, они никогда не включают делегирован ные данные.

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

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

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

Разновидности DNS-серверов Спецификация DNS определяет два типа DNS-серверов: первичный мастер-сервер (primary master) и дополнительный, или вторичный мастер-сервер (secondary master). Первичный мастер-сервер произво дит загрузку данных для зоны из файла на машине-сервере. Вторич ный мастер-сервер получает данные зоны от другого DNS-сервера, ко торый является авторитативным для этой зоны и называется его мас тером (master server). Довольно часто мастер-сервер является первич ным мастером для зоны, но не обязательно: вторичный мастер-сервер может получать зональные данные и от другого вторичного. Когда за пускается вторичный сервер, он устанавливает связь с мастером и, в случае необходимости, получает зональные данные. Этот процесс на зывается передачей, или трансфером зоны (zone transfer). В наше вре мя предпочтительным термином для вторичного мастер-сервера имен является slave (подчиненный, ведомый)1, хотя многие люди (и многие программы, в частности, Microsoft DNS Manager) все еще пользуются прежним термином.

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

48 Глава 2. Как работает DNS Как первичный, так и вторичный мастер-серверы зоны являются для этой зоны авторитативными. Несмотря на несколько уничижительное название, вторичные, или slave-серверы не являются серверами второ го сорта. Эти два типа серверов предусмотрены в DNS с целью облегче ния администрирования. После создания зональных данных и уста новки первичного мастера можно не беспокоиться о копировании дан ных с узла на узел при создании дополнительных DNS-серверов зоны.

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

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

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

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

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

Файлы данных содержат RR-записи, описывающие зону. RR-записи описывают все узлы сети в зоне и помечают делегирование поддоме нов. В BIND также существуют специальные директивы для включе Клиенты DNS ния содержимого других файлов данных в файл данных зоны анало гично директиве #include языка программирования С.

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

• Опрашивание DNS-серверов.

• Интерпретация полученных ответов (RR-записей или сообщений об ошибках).

• Возврат информации в программу, которая ее запросила.

В пакете BIND клиент - это просто набор библиотечных процедур, ко торые вызываются из программ вроде Telnet и FTP. Клиент - это даже не отдельный процесс. Его хватает ровно на то, чтобы создать запрос, отправить его и ждать ответа, повторно послать запрос, если ответ не получен, но это практически все, на что он способен. Большая часть работы, связанной с поиском ответа на вопрос, ложится на сервер имен. Спецификация DNS называет этот тип анализатора примитив ным (stub resolver).

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

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

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

50 Глава 2. Как работает DNS DNS-серверу с запросом по любому доменному имени пространства до менных имен, после чего получает руководящие указания по продол жению поиска.

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

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

Чтобы исключить подобные ситуации, в сети Интернет существует (на момент написания этой книги) тринадцать корневых серверов, распо ложенных в различных частях сети. Один из них находится в сети PSI Net, коммерческой информационной магистрали Интернета, один в научной сети NASA, два в Европе, а один в Японии.

Корневые серверы находятся под постоянной нагрузкой, поскольку на них направлено огромное число запросов;

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

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

Локальный DNS-сервер запрашивает адрес girigiri.gbrmpa.gov.au у корневого сервера и получает ссылку на DNS-серверы домена аи. Ло кальный сервер повторяет запрос, отправляя его одному из DNS-серве ров аи, и получает ссылку на серверы gov.au. DNS-сервер gov.au отсы лает локальный DNS-сервер к серверам gbrmpa.gov.au. И наконец, ло Разрешение имен Рис. 2.12. Разрешение имени girigiri.gbrmpa.gov.au в сети Интернет кальный DNS-сервер запрашивает DNS-сервер gbrmpa.gov.au и полу чает искомый адрес.

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

Почему локальный DNS-сервер попросту не перенаправил клиент к другому серверу? Потому что примитивный клиент не способен следо вать по таким ссылкам. Каким образом сервер понял, что отвечать 52 Глава 2. Как работает DNS клиенту ссылкой - пустая трата времени? Очень просто: клиент сде лал рекурсивный запрос.

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

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

Если DNS-сервер, получивший запрос, не авторитативен для запраши ваемой информации, ему придется опрашивать другие серверы в поис ках ответа. В этом случае сервер может делать либо рекурсивные за просы, возлагая, таким образом, ответственность за нахождение отве та на опрашиваемые DNS-серверы (и снимая с себя ответственность), либо итеративные запросы, возможно, получая ссылки на DNS-серве ры, расположенные «ближе» к искомому доменному имени. Сущест вующие реализации очень воспитаны и действуют по второму вариан ту, следуя по ссылкам, пока не будет найден ответ. DNS-Сервер, получивший рекурсивный запрос, на который он сам не в состоянии ответить, отправляет запрос «ближайшим известным» сер верам. Ближайшие известные серверы - это те, которые являются ав торитативными для зоны, ближе всего расположенной к доменному имени, о котором идет речь. К примеру, если сервер получает рекур сивный запрос для адреса доменного имени girigiri.gbrmpa.gov.au, он, прежде всего, выяснит, известно ли, какие серверы являются автори тативными для girigiri.gbrmpa.gov.au, и, если это известно, отправит DNS-серверы пакета BIND 8 могут быть настроены таким образом, чтобы игнорировать или отказывать в выполнении рекурсивных запросов;

при чины и способы поступать именно так описаны в главе 11 «Безопасность».

Исключением является DNS-сервер, настроенный таким образом, чтобы передавать все запросы, на которые он не располагает ответом, определен ному DNS-серверу. Сервер, настроенный таким образом, называется ре транслятором (forwarder). Подробно об использовании ретрансляторов рас сказано в главе 10 «Дополнительные возможности».

Разрешение имен запрос одному из них. В противном случае будет произведен аналогич ный поиск DNS-серверов для gbrmpa.gov.au, а затем для gov.au и аи.

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

Использование ближайших известных DNS-серверов позволяет во всех случаях максимально сократить процесс разрешения. Если DNS сервер berkeley.edu получает рекурсивный запрос адреса для wax wing.ce.berkeley.edu, он не будет опрашивать корневые серверы, а ис пользует информацию о делегировании и отправится за данными пря мо к DNS-серверам ce.berkeley.edu. Точно так же сервер, который толь ко что производил поиск адреса для доменного имени в ce.berkeley.edu, не будет начинать поиск с корня, если необходимо повторить процеду ру для ce.berkeley.edu (или для berkeley.edu);

причины этого мы опи шем чуть позже, в разделе «Кэширование».

Сервер DNS, получающий рекурсивный запрос от DNS-клиента, при поиске повторяет этот запрос в точности так, как он получен от клиен та. В случае рекурсивного запроса адреса для waxwing.ce.berkeley.edu сервером никогда не будет отправлен явный запрос на информацию о DNS-серверах ce.berkeley.edu или berkeley.edu, несмотря на то, что эта информация также хранится в пространстве имен. Прямые запросы могут приводить к осложнениям: DNS-серверы ce.berkeley.edu могут не существовать (то есть ce.berkeley.edu может являться частью зоны ber keley.edu). Помимо этого, вполне возможно, что сервер имен edu или berkeley.edu уже знает адрес waxwing.ce.berkeley.edu. Прямой запрос о DNS-серверах berkeley.edu или ce.berkeley.edu не приведет к получению этой информации.

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

54 Глава 2. Как работает DNS Выбор авторитативного DNS-сервера Некоторые из читателей (состоящие в обществе Менса1), возможно, за даются вопросом: каким образом сервер, получивший рекурсивный запрос, выбирает DNS-сервер из списка авторитативных? Мы говори ли о том, что существует 13 корневых DNS-серверов в сети Интернет.

Посылает ли наш DNS-сервер запрос первому из серверов в списке?

Или выбирает позицию в списке случайно?

DNS-серверы BIND используют метрику, называемую временем от клика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. Время отклика определяет задержку, с ко торой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если серверу приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как сервер BIND впервые послал запрос некоему серверу и по лучил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на осно вании замеров. Таким образом, DNS-сервер BIND гарантированно оп росит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основа нии метрики.

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

Картина в целом В итоге мы можем наблюдать процесс разрешения, который в целом выглядит примерно так, как показано на рис. 2.13.

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

Каждый из опрашиваемых серверов-возвращает ссылку на другой сер вер, который является авторитативным для зоны, расположенной ближе к искомому доменному имени и глубже в дереве пространства имен. В итоге локальный сервер посылает запрос тому авторитативно му, который и возвращает ответ. На протяжении всего процесса поис Международное сообщество, объединяющее людей, которые попадают в первые 2% населения по своему IQ. Основали его в 1946 году в Англии ад вокат Роланд Беррилл (Roland Berrill) и доктор Ланс Вэр (Lance Ware), уче ный и юрист. - Примеч. ред.

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

Отображение адресов в имена До сих пор в разговоре о процессе разрешения мы не затрагивали один важный элемент функциональности, а именно - отображение адресов в имена доменов. Отображение адрес-имя необходимо для получения вывода, который легко воспринимается людьми (скажем, при чтении log-файлов). Это отображение также применяется в авторизации. На пример, Unix-узлы преобразуют адреса в доменные имена с целью сравнения их с записями в файлах.rhosts и hosts.equiv. При использо вании таблиц узлов отображение адресов в доменные имена довольно тривиально. Требуется обычный последовательный поиск адреса в таблице узлов. Поиск возвращает указанное в таблице официальное имя узла. Но в DNS преобразование адреса в имя происходит несколь ко сложнее. Данные, в том числе и адреса, которые хранятся в прост ранстве доменных имен, индексируются по именам. Если есть домен ное имя, поиск адреса - процедура относительно простая. Но поиск до 56 Глава 2. Как работает DNS менного имени, которому соответствует заданный адрес, казалось бы, потребует полного перебора данных для всех доменных имен дерева.

На деле же существует другое решение, более разумное и эффективное.

Несложно производить поиск по доменным именам, поскольку они яв ляются своеобразными индексами базы данных, и точно таким же об разом можно создать сектор пространства доменных имен, в котором в качестве меток будут использоваться адреса. В пространстве домен ных имен сети Интернет таким свойством обладает домен in-addr.arpa.

Узлам домена inaddr.arpa в качестве меток присваиваются числа в но тации IP-адреса (dotted octet representation - октеты, разделенные точками, - распространенный метод записи 32-битных IP-адресов в виде четырех чисел, принадлежащих интервалу от 0 до 255 и разделя емых точками). Так, домен in-addr.arpa может содержать до 256 под доменов, каждый из которых будет соответствовать одному из возмож ных значений первого октета IP-адреса. Каждый из этих поддоменов может содержать до 256 собственных поддоменов, каждый из которых будет соответствовать одному из возможных значений второго октета.

Наконец, на четвертом уровне существуют RR-записи, ассоциирован ные с последним октетом, которые содержат полное доменное имя узла по данному IP-адресу. Результатом подобных построений является не вероятно объемный домен: in-addr.arpa, отображенный на рис. 2.14, до статочно вместительный, чтобы охватить все IP-адреса сети Интернет.

Заметим, что при чтении в доменном имени, IP-адрес оказывается за писанным наоборот, поскольку имя читается от листа дерева к корню.

К примеру, если IP-адрес узла winnie.corp.hp.com - 15.16.192.152, со ответствующий узел в домене in-addr.arpa- 152.192.16.15.in-addr.ar ра, который отображается в доменное имя winnie.corp.hp.com.

IP-адреса могли бы быть представлены в пространстве имен другим способом так, чтобы первый октет IP-адреса был дальше от корня до мена in-addr.arpa. Тогда в доменном имени IP-адрес читался бы в «пра вильном» направлении.

Однако IP-адреса, как и доменные имена, образуют иерархию. Сете вые номера выделяются почти так же, как и доменные имена, адми нистраторы вольны разделять «свое» адресное пространство на подсе ти и делегировать нумерацию в сети-другим администраторам. Разни ца заключается в том, что конкретизация узла для IP-адреса возраста ет при чтении слева направо, тогда как для доменных имен - справа налево. Суть этого явления отражена на рис. 2.15.

То, что первые октеты IP-адреса расположены выше в дереве, дает ад министраторам возможность делегировать ответственность за зоны in addr.arpa в соответствии с топологией сети. Возьмем для примера зону 15.in-addr.arpa, которая содержит данные обратного преобразования для всех узлов, адреса которых начинаются с цифры 15: эта зона мо жет быть делегирована администраторам сети 15.0.0.0. Это стало бы Разрешение имен Рис. 2.14. Домен in-addr.arpa невозможным, если бы октеты были расположены в обратном поряд ке. Если бы IP-адреса записывались наоборот (в другом порядке), зона 15.in-addr.arpa включала бы каждый узел, IP-адрес которого заканчи вается цифрой 15, и делегировать эту зону было бы немыслимо.

Рис. 2.15. Иерархия имен и адресов Инверсные запросы Домен in-addr.arpa очевидно полезен только для преобразования IP адресов в доменные имена. Поиск в пространстве доменных имен, ко торые были бы индексированы по некой произвольной информации, чему-нибудь, что не является адресом, потребовал бы другого прост ранства имен, такого же, как in-addr.arpa, либо поиска перебором.

58 Глава 2. Как работает DNS Поиск перебором до некоторой степени является реальностью и носит название инверсных запросов (inverse queries). Инверсный запрос - это поиск доменного имени, индексирующего указанные данные. Такие запросы обрабатываются исключительно DNS-сервером, который их получает. Этот сервер производит поиск в локальных данных, и, если возможно, возвращает искомое доменное имя. В противном случае по иск завершается. Никакого обмена информацией с другими серверами не происходит.

Поскольку любой отдельно взятый сервер владеет информацией лишь о части доменного пространства, нет гарантий, что инверсный запрос приведет к получению ответа. Так, если DNS-сервер получает инверс ный запрос по IP-адресу, о котором ему ничего не известно, то не мо жет вернуть ответ на запрос, но не может также и утверждать, что та кого адреса не существует, поскольку владеет лишь частью базы дан ных DNS. Более того, согласно спецификации системы доменных имен, реализация инверсных запросов является необязательной. В BIND версии 4.9.8 содержится код, реализующий инверсные запросы, но по умолчанию он закомментирован. BIND версий 8 и 9 не включает такого кода вовсе, хотя серверы имен в этих версиях BIND распознают инверсные запросы и могут возвращать поддельные ответы.1 Нас такое положение вещей вполне устраивает, поскольку очень немногие про граммы (скажем, древние версии nslookup) до сих пор пользуются ин версными запросами.

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

Чтобы обработать рекурсивный запрос, DNS-серверу приходится са мостоятельно сделать довольно много запросов. Однако в процессе сер вер получает большое количество информации о пространстве домен ных имен. Каждый раз, получая список DNS-серверов в ссылке, он знакомится с серверами, авторитативными для какой-то зоны, и узна ет адреса этих серверов. Когда завершается процесс разрешения, и не обходимые данные возвращаются клиенту, сделавшему исходный за прос, новые знания могут быть сохранены для последующего ис пользования. В версии BIND 4.9, а также во всех версиях BIND 8 и 9, в серверах имен реализовано даже отрицательное кэширование: если авторитативный сервер возвращает информацию о том, что запрошен ное имя домена или указанный тип данных не существует, локальный Более подробно этот момент описан в разделе «Запрос отвергнут» в главе «nslookup и dig>>.

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

Предположим, наш DNS-сервер уже выяснял адрес для eecs.berke ley.edu. В процессе были кэшированы имена и адреса DNS-серверов eecs.berkeley.edu и berkeley.edu (а также IP-адрес eecs.berkeley.edu). Ес ли теперь клиент пошлет DNS-серверу запрос, касающийся адреса для имени baobab.cs.berkeley.edu, при обработке этого запроса наш сервер сможет пропустить отправку запросов корневым DNS-серверам. Опо знав в berkeley.edu ближайшего предка baobab.cs.berkeley.edu, о кото ром уже что-то известно, наш сервер начнет с запроса к DNS-серверу berkeley.edu (рис. 2.16). С другой стороны, если бы наш DNS-сервер выяснил, что адреса для eecs.berkeley.edu не существует, в следующий раз на подобный запрос он вернул бы соответствующий ответ из кэша.

Помимо ускорения разрешения кэширование устраняет необходимость вовлекать в процесс разрешения корневые DNS-серверы для случаев, Рис. 2.16. Процесс разрешения для baobab.cs.berkeley.edu 60 Глава 2. Как работает DNS когда ответ может быть получен локально. Это означает уменьшение зависимости от корневых серверов и снижение нагрузки на них.

Время жизни Разумеется, DNS-серверы не могут кэшировать данные навсегда. Ина че изменения на авторитативных серверах никогда не распространя лись бы по сети. Удаленные серверы просто продолжали бы использо вать кэшированную информацию. Поэтому администратор зоны, ко торая содержит данные, обычно определяет для этих данных время жизни (time to live, или TTL). Время жизни - это интервал времени, в течение которого произвольному DNS-серверу разрешается пользо ваться кэшированными данными. По окончании этого временного ин тервала сервер обязан удалить кэшированную информацию и полу чить новую от авторитативных DNS-серверов. Это касается также кэ шируемых отрицательных ответов, сервер имен обязан удалять их на случай, если на авторитативных DNS-серверах появилась новая ин формация.

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

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

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

• Приобретение пакета BIND • Выбор доменного имени С чего начать?

- Как тебя зовут? - спросила Лань.

У нее был мягкий и нежный голос.

- Если б я только знала! - подумала бедная Алиса.

Вслух она грустно промолвила:

- Пока никак...

- Постарайся вспомнить, - сказала Лань. - Так нельзя... Алиса постаралась, но все было бесполезно.

- Скажите, а как вас зовут? - робко спросила она.

- Вдруг это мне поможет...

- Отойдем немного, - сказала Лань. - Здесь мне не вспомнить...

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

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

Но все по порядку. Поговорим о том, где можно получить пакет BIND.

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

62 Глава 3. С чего начать?

Большинство коммерческих Unix-систем содержат пакет BIND в сос таве сетевых TCP/IP-приложений, набор которых обычно входит в стандартную поставку, так что пользователи получают BIND бесплат но. Даже в случаях, когда за сетевые приложения взимается отдель ная плата, те из пользователей, кому из-за активной сетевой работы нужен BIND, скорее всего его уже приобрели.

При этом, если не существует готовой версии BIND для конкретной разновидности Unix-системы, но нужна лучшая из последних версий, всегда можно получить исходные тексты пакета. К счастью, они распространяются совершенно свободно. Исходные тексты самых по следних версий BIND (на момент написания книги это BIND 8.2.3 и 9.1.0) доступны для загрузки с публичного FTP-сервера консорциума Internet Software Consortium по адресу ftp.isc.org, файлы называются /isc/bind/src/cur/bind-8/bind-src.tar.gz и /isc/bind9/9.1.0/bind-9.1.0.tar.gz соответственно. Сборка этих двух версий на большинстве распростра ненных Unix-систем - дело достаточно простое.1 Консорциум ISC включает список Unix-подобных операционных систем, на которых собирается и работает BIND, и приводит его в файле src/INSTALL: в список входят версии Linux, Digital Unix и Solaris 2. Присутствует также список других Unix- (и не совсем Unix) операционных систем (кто-нибудь работает на МРЕ?), которые BIND поддерживал в прош лом и для которых сборка последних версий пакета может произво диться без существенных усилий.2 Независимо от того, какая именно операционная система используется, мы настоятельно рекомендуем прочитать все связанные с этой системой разделы файла src /INSTALL.

Мы также включили инструкции по сборке BIND версий 8.2.3 и 9.1. для RedHat Linux 6.2 в виде приложения С «Сборка и установка BIND на Linux-системах». И это поразительно короткое приложение.

У кого-то из читателей, вполне возможно, уже есть версия пакета BIND, которая входила в поставку операционной системы, и они зада ются вопросом, нужна ли самая последняя и самая лучшая версия BIND? Что в ней есть такого, чего нет в более ранних версиях? Пере числим кратко:

Лучшая защищенность Чуть ли не самой важной причиной использовать последнюю вер сию BIND является тот факт, что эта версия наименее уязвима для внешних атак. BIND версий 8.2.3 или 9.1.0 успешно противостоит Сборка более ранних версий BIND 9 (предшествующих версии 9.1.0) может оказаться не столь тривиальной, поскольку этим версиям требуется меха низм pthreads, реализация которого некорректна во многих операционных системах. BIND 9.1.0 и более поздних версий может собираться без pthreads посредством выполнения команды configure -disable-threads.

Достоверно известно, что BIND версии 8.2.3 без проблем собирается на не скольких из этих операционных систем.

Приобретение пакета BIND всем широко известным атакам, a BIND версии 4.9.8 - значитель ному их числу. У более ранних версий BIND много уязвимых мест, известных злоумышленникам. Если DNS-сервер работает в сети Интернет, мы рекомендуем использовать BIND версии 8.2.3 или 9.1.0, в самом крайнем случае - BIND 4.9.8 либо самую последнюю на момент прочтения этой книги версию.

Механизмы, безопасности BIND 8 и 9 поддерживают списки управления доступом для запро сов, передачи зоны, а также динамических обновлений. Серверы BIND 4.9 поддерживают списки управления доступом для запросов и передачи зоны, а более ранние версии не реализуют списки досту па. Определенным DNS-серверам, в особенности тем, которые рабо тают на узлах-бастионах или узлах, на которых предъявляются по вышенные требования к безопасности, может потребоваться ис пользование возможностей списков управления доступом.

Подробно об этом механизме мы расскажем в главе 11 «Безопас ность».

DNS UPDATE BIND 8 и 9 поддерживают стандарт динамических обновлений (Dynamic Update), описанный в документе RFC 2136. Это позволяет уполномоченным агентам обновлять данные зоны путем посылки специальных сообщений обновления, содержащих команды добав ления или удаления записей ресурсов. В серверах BIND 4 механизм динамического обновления не реализован.

Подробно о динамических обновлениях мы расскажем в главе «Дополнительные возможности».

DNS NOTIFY BIND 8 и 9 поддерживают уведомления об изменениях зоны, меха низм, позволяющий первичному мастер-серверу зоны уведомлять вторичные серверы в случае увеличения порядкового номера (serial) зоны. В серверах BIND 4 механизм NOTIFY не реализован.

Подробно мы расскажем о возможностях NOTIFY в главе 10.

Инкрементальная передача зоны BIND версии 8.2.3 и BIND 9 реализуют механизм инкрементальной передачи зоны, позволяющий вторичным DNS-серверам запраши вать у первичных серверов только изменения зональных данных.

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

Синтаксис настройки Синтаксис настройки, используемый в BIND 8 и 9, существенно от личается от используемого в BIND 4. Будучи более гибким и более мощным, он также требует изучения совершенно иной системы на 64 Глава 3. С чего начать?

стройки пакета BIND. Впрочем, для решения этой задачи вполне подойдет настоящая книга.

Синтаксис настройки BIND 8 и 9 будет представлен в главе 4 «Уста- ;

новка BIND» и описан в оставшейся части книги.

Сводку возможностей, реализованных в четырех наиболее распростра ненных версиях BIND (4.9.8, 8.1.2, 8.2.3, 9.1.0), мы включили в кни гу в виде приложения В «Таблица совместимости BIND». В случае на личия сомнений, связанных с выбором версии пакета, либо в случае необходимости использовать экзотическую возможность, про которую неизвестно, поддерживается ли она в BIND 9, следует обратиться к этому приложению.

Если после изучения представленного списка и приложения вы прихо дите к выводу, что нужен BIND 8 или 9, но ни та ни другая версия не входят в состав используемой операционной системы, придется загру зить исходные тексты пакета и собрать его в нужной конфигурации.

Полезные списки рассылки и конференции Usenet Инструкции, касающиеся процесса переноса пакета BIND на произ вольную Unix-систему, могли бы вылиться в еще одну книгу подобно го размера, поэтому за информацией подобного рода мы отсылаем чи тателей к списку рассылки пользователей BIND (blnd-users@isc.org) и соответствующей конференции Usenet (comp.protocols.dns.bind).1 Для BIND 9 существует самостоятельный список рассылки, bind9-us ers@isc.org.2 Люди, которые читают списки рассылки пользователей BIND и делятся в этих списках своими ценными мыслями, могут быть невероятно полезны в плане вопросов, связанных с переносом BIND.

Но прежде чем спрашивать в списке рассылки, существует ли порт BIND для конкретной платформы, не забудьте свериться с результатами поиска по архиву списка рассылки, который доступен по адресу http:// www.isc.org/ml-archives/bind-users. Помимо этого, взгляните на веб страницу ISC, посвященную пакету BIND (http://www.isc.org/pro ducts /BIND), где могут быть доступны примечания и ссылки, непо средственно касающиеся используемой вами операционной системы, а Чтобы задать вопрос в списке рассылки сети Интернет, следует всего лишь отправить сообщение на адрес списка рассылки. Однако прежде следует подписаться на список, послав просьбу о добавлении администратору спис ка. Не следует посылать запросы такого рода непосредственно в список рас сылки, это считается невежливым. По принятой в сети Интернет практике;

с администратором можно связаться по адресу list-request@domain, где list@domain - это адрес списка рассылки. Так, связаться с администрато ром списка рассылки пользователей BIND можно по адресу bind users-re quest@isc.org.

Большинство разработчиков BIND 9 читает исключительно список рассыл ки bind9-users.

Приобретение пакета BIND также на каталог ресурсов DNS Андраса Саламона на предмет поиска собранных пакетов BIND. Каталог содержит краткий перечень собран ных пакетов (http://www.dns.net/dnsrd/bind.html).

Еще один список рассылки, который может оказаться интересным, это namedroppers. Люди, участвующие в списке рассылки namedrop pers, являются членами рабочего комитета организации IETF, кото рый занимается разработкой расширенной спецификации DNS, или DNSEXT. Так, к примеру, обсуждение нового типа записи DNS, скорее всего, будет происходить в списке namedroppers, а не в общем списке рассылки BIND. Более подробная информация о группе DNSEXT до ступна по адресу http://www.ietf.org/html.charters/dnsext-charter.html.

Адрес списка рассылки namedroppers - namedroppers@ops.ietf.org, со ответствующая конференция Интернета называется comp.proto cols.dns.std. Чтобы подписаться на рассылку namedroppers, следует от править почтовое сообщение на адрес namedroppers-request@ops.ietf.org, текст сообщения должен представлять собой строку «subscribe named roppers».

Как узнать IP-адрес Наверное, многие заметили, что мы привели несколько доменных имен FTP-узлов, на которых доступны для скачивания различные про граммы, и что упоминаемые адреса списков рассылки также содержат доменные имена. Этот факт должен подчеркнуть важность DNS: очень много полезных программ и советов доступны с помощью именно DNS.

К сожалению, здесь присутствует проблематика курицы и яйца: не возможно послать электронное сообщение на адрес, который содержит доменное имя, если система DNS еще не установлена, т. е. оказывается невозможным задать в списке рассылки вопрос, касающийся установ ки DNS.

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

Если узел имеет подключение к сети Интернет и программу nslookup, существует возможность получать информацию из пространства имен Интернета. Чтобы получить, к примеру, IP-адрес для ftp.isc.org, мож но воспользоваться такой командой:

% nslookup ftp.i sc.org. 207.69.188. В данном случае программе nslookup предписывается послать запрос DNS-серверу, который работает на узле, имеющем IP-адрес 207.69.188.185, с целью выяснения IP-адреса для ftp.isc.org. Должен получиться примерно такой результат:

Server: ns1.mindspring.com 66 Глава 3. С чего начать?

Address: 207.69.188. Name: isrv4.pa.vix.com Address: 204.152.184. Aliases: ftp.isc.org Теперь можно использовать IP-адрес узла ftp.isc.org (204.152.184.27) для проведения FTP-сеанса.

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

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

Получив рабочую версию пакета BIND, можно начинать думать о вы боре доменного имени.

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

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

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

Помните, чтобы узнать, как выглядит пространство доменных имен сети Интернет (не считая того, о чем мы уже рассказали), понадобится доступ к сети Интернет. Необязательно иметь доступ к узлу с работаю щими службами DNS, но это не будет лишним. Если доступа к такому узлу нет, придется «позаимствовать» услуги службы DNS у других DNS-серверов (как в примере с именем ftp.isc.org), чтобы начать работу.

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

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

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

Компания Network Solutions Inc. является эксклюзивным регистром и регистратором для доменов высшего уровня com, net, org и edu. А те перь вернемся к нашим задачам.

Где мое место?

Если ваша организация подключена к сети Интернет вне США, преж де всего необходимо решить, в каком из доменов высшего уровня зап рашивать поддомен - в одном из родовых, таких как com, net, либо org, либо в домене высшего уровня, соответствующем конкретной стране. Родовые домены высшего уровня вовсе не отведены исключи тельно под организации США. Для компании, которая является мульти- или транснациональной, и для которой не подходит домен высшего уровня какой-то конкретной страны, либо в случае, когда ро довой домен просто более предпочтителен, имеет смысл регистрация в одном из родовых доменов. Выбрав такой путь регистрации, читатели могут перейти к разделу «Родовые домены высшего уровня».

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

Если необходимо уточнить имя домена высшего уровня для страны, обращайтесь к приложению D «Домены высшего уровня».

В доменах высшего уровня некоторых стран, таких как Новая Зелан дия (nz), Австралия (аи) и Великобритания (uk), существует организа ционное деление для доменов второго уровня. То есть имена доменов 68 Глава 3. С чего начать?

второго уровня, скажем, со или сот для коммерческих сущностей, от ражают принадлежность организации. Домены других стран, скажем, Франции (fr) или Дании (dk) делятся на множество поддоменов, кото рые управляются отдельными университетами и компаниями;

домен Университета Сент-Этьена носит название univ-st-etienne.fr, а домен датской группы пользователей Unix-систем - dkuug.dk. Для многих доменов высшего уровня существуют веб-страницы, описывающие их структуру. Если вы не знаете URL веб-страницы домена высшего уров ня конкретной страны, сверьтесь с каталогом ссылок на подобные страницы, расположенным по адресу http://www.allwhois.com.

В случае отсутствия подобной веб-страницы для домена высшего уров ня, возможно, придется воспользоваться инструментом вроде nslook up, чтобы покопаться в пространстве доменных имен и оценить струк туру поддоменов. (Те из читателей, кто чувствует дискомфорт при ис пользовании еще не изученного средства, могут на время отвлечься на прочтение главы 12 «nslookup и dig».) Вот так, к примеру, с помощью nslookup можно получить список поддоменов домена аи:

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

Если по именам поддоменов невозможно определить, какому сектору должен принадлежать ваш будущий домен, всегда можно найти кон тактную информацию для соответствующей зоны и отправить свой вежливый вопрос электронной почтой в службу технической поддерж 70 Глава 3. С чего начать?

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

Чтобы узнать, к кому обращаться с вопросами по конкретному поддо мену, придется найти соответствующую зоне RR-запись типа SOA (start of authority, начало авторитативности). В SOA-записи каждой зоны существует поле, содержащее адрес электронной почты лица, от вечающего за техническую поддержку зоны.1 (Остальные поля SOA записи содержат общую информацию о зоне, чуть позже мы обсудим их более подробно.) SOA-запись зоны также можно просмотреть с по мощью программы nslookup.

К примеру, если бы мы хотели узнать о назначении поддомена csiro, то могли бы узнать, кто за него отвечает из содержимого SOA-записи для csiro.au:

Поле mail addr содержит интернет-адрес контактного лица csiro.au.

Чтобы преобразовать этот адрес в формат электронного адреса сети Интернет, следует заменить первый символ «.» в адресе на символ @». Так, hostmaster.csiro.au превращается в hostmaster@csiro.au. Поддомен и зона идентифицируются одним и тем же доменным именем, но SOA-запись в действительности принадлежит зоне, а не поддомену. Чело век, адрес которого указан в SOA-записи, возможно, не отвечает за весь поддомен (поскольку он может содержать делегированные поддомены), но совершенно определенно знает, каково предназначение этого поддомена.

Такая форма почтового адреса Интернет является наследием двух некогда существовавших типов записей DNS, MB и MG. Записи MB (mailbox, почто вый ящик) и MG (mail group, почтовая группа) определяли почтовые ящи ки и почтовые группы (списки) сети Интернет как поддомены соответству ющих доменов. Записи и MB и MG не получили широкого распростране ния, но формат адреса, который ими предлагался, используется в SOA-за писях, возможно, из соображений сентиментальности.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.