Руководство системного администратора • третье издание { h h y с п п т п р



Pdf просмотр
страница36/82
Дата12.11.2016
Размер7.94 Mb.
Просмотров13852
Скачиваний0
ТипРуководство
1   ...   32   33   34   35   36   37   38   39   ...   82
Домен Для кого предназначен
com Коммерческие компании edu Учебные заведения gov Правительственные учреждения mil Военные учреждения net Поставщики сетевых услуг org Некоммерческие организации int Международные организации aipa Верхний элемент дерева адресов Для большинства доменов вне США используются двухбуквенные коды стран, принятые организацией ISO. Эти домены называются географическими
Домены обоих типов сосуществуют водном глобальном пространстве имен Некоторые коды стран приведены в табл. 16.3.
Тоблицо 16.3. Коды строи Коя
CrpOHQ fill Австралия са Канада br Бразилия de Германия fi Финляндия fr Франция
JP Япония se Швеция ch Швейцария hu Венгрии ua Украина ru Россия Во многих странах организационная структура строится на базе домен- второго уровня, прн этом правила именования могут быть разными Например, научные учреждения в США относятся к домену "edu". a i Японии — к домену ac.jp.
420
Чость II. Робота в cv
В Соединенных Штатах домен верхнего уровня "us" используется чаще всего в сочетании с региональными доменами например, bvsd.kl2.co.us — домен школьного округа города Боулдер, штат Колорадо. Домен "us" никогда не объединяется с организационными доменами, те. домена edu.us нет (пока. Преимущество домена "us" заключается в том, что регистрация имен в нем бесплатна или стоит очень недорого за подробностями обратитесь на узел www.nic.us. Торговцы доменами иногда выкупают пространства имен целых стран. Например, домен республики Молдова, "md", в настоящее время продается медицинским заведениями резидентам штата Мэриленд (MD), США. Другой пример — островное государство Тувалу, код страны которого — "tv". Первая сделка такого рода коснулась королевства Тонга (домен "to"). В настоящее время активнее всего распродается домен острова-колонии Ниуэ ("nu"), а одним из самых привлекательных является домен Туркменистана ("tm"). Иногда подобные сделки были выгодны этим странам, иногда — нет. Широко практикуется также самовольный захват доменных имен. Предприимчивые дельцы регистрируют имена, которые, по их мнению, обязательно будут востребованы в будущем. Через некоторое время какая-нибудь ничего не подозревающая компания пытается зарегистрировать аналогичное имя и с удивлением обнаруживает, что оно занято. Ей приходится выкупать имя у предусмотрительного владельца. Много лет назад один бизнесмен зарегистрировал доменные имена всех лыжных курортоа Колорадо и заработал большие деньги, продавая имена по мере того, как администрации лыжных курортов осваивали глобальную сеть. Стоимость хорошего имени в домене "com" колеблется от нескольких тысяч до нескольких миллионов долларов. Недавно домен business,com был продан за 3,5 млн. долларов. Нам предложили за домен admin.com, который мы зарегистрировали несколько лет назад после того, как оказалось, что домен sysadmin.com уже занят журналом "/Sys/Admin". В именах доменов не учитывается регистр. В контексте DNS домен "Colorado" идентичен "Colorado" и "COLORADO". В текущих реализациях протокол DNS должен игнорировать регистр при сравнении именно распространять имена в том регистре, в котором они указаны. Раньше принято было домены верхнего уровня обозначать прописными буквами и начинать с прописной буквы домены второго уровня. Сегодня пальцы очень устают от работы с клавиатурой, и нормой стали строчные буквы. Два новых свойства DNS — интернационализация имени спецификация
DNSSEC — конфликтуют сточки зрения регистра символов. В международных доменных именах регистр важен и должен быть сохранена в DNSSEC все имена переводятся в нижний регистр перед вычислением сигнатур. Очевидно, в DNS вскоре будет официально принят нижний регистр для внутренних криптографических вычислений, но фактические данные будут рассылаться с учетом регистра. Потребуется разработать правила преобразования имен из международных кодировок во внутреннее представление. Надеемся, что организация IETF сумеет разобраться в этих вопросах до того, как новые технологии получат широкое распространение. Полностью определенное нмя компьютера, подключенного к I me met, формируется путем прибавления имени домена к имени машины. Например, boulder.colorado.edu — полное имя узла boulder, находящегося в университете штата Колорадо. Другие организации могут использовать имя boulder не спрашивая на то разрешения, потому что полностью определенные имена их компьютеров все равно будут другими.
Глово 16. Системо доменных имен
421
В DNS полные имена заканчиваются точкой, например "boulder.colo- rado.edu.". Отсутствие завершающей точки свидетельствует об относительном адресе. В зависимости от контекста, в котором используется относительный адрес, к нему мог>т присоединяться различные дополнительные компоненты. Пользователи DNS обычно не подозревают о существовании хвостовой точки Более того, некоторые системы (например, электронная почта) неправильно проинтерпретируют адрес, если в конце него указать точку. Компьютеры часто имеют несколько имен К примеру, узлу boulder.colo- rado.edu можно также дать имя www.colorado.edu или flp.cotorado.edu, если в названии требуется отразить предоставляемый сервис Вообще это достаточно распространенная практика — делать "сервисные" имена (в частности, те, что начинаются с "www") мобильными, те. серверы можно переносить с одного компьютера на другой, не меняя основное имя компьютера Когда нам выделили домен colorado.edu, мы получили гарантию того, что имя "Colorado" уникально в пределах домена "edu". Мы разделили этот домен на поддомены в соответствии со списком факультетов нашего университета Например, машина anchor на факультете вычислительной техники носит имя anchor.cs.colorado.edu. Создание каждого нового поддомена необходимо согласовывать с администраторами домена, чтобы гарантировать уникальность имени. Записи в конфигурационном файле родительского домена делегируют поддомену полномочия по управлению пространством имен Хозяева своих доменов Управление доменами верхнего уровня " c o m " , "ОГЕ". "net" и "edu"' раньше осуществляла компания Network Solutions, Inc., по контракту с Национальным научным фондом США. Теперь ян монополия ушла в прошлое, и другие организации получили разрешение регистрировать доменные имена в общих доменах. Что касается географических доменов, то ими управляют региональные организации. Были различные предложения по поводу того, чтобы разрешить частным компаниям управлять своими собственными доменами верхнего уровня, поэтому вполне вероятно, что в ближайшем будущем такие домены появятся. Самую последнюю информацию можно получить на узле. Большинство провайдеров Internet прелостаачяст платные услуги по регистрации доменных имен В ответ на поступивший запрос они связываются с адресными канцеляриями верхнего уровня и настраивают свои серверы на поиск имен в пределах нового домена. Конечно, можно сократить прямые затраты, самостоятельно связавшись с адресной канцелярией и организовав собственный сервер, но вряд ли это приведет к общей экономии денег. Лучше поручить решение организационных вопросов провайдерам, хотя в таком случае теряется прямой административный контроль над доменом Даже если организация хочет запустить собственный сервер. она все равно должна связаться с провайдером, так как па его сервере осуществляется обратное преобразование адресов в доменные имена в рамках блоков. Нужно убедиться, что провайдер отключил этот сервис лля запрашиваемого блока адресов и передал организации соответствующие полномочия.
О протоколе CIDR рассказываюсь в параграфе 13.4.
422
Чость II. Роботов сетях
Прямые и обратные преобразования по возможности должны осуществляться водном месте. Некоторые провайдеры с удовольствием отдают контроль над прямым преобразованием, но отказываются делать тоже самое в случае обратного преобразования. Подобное разделение обязанностей ведет к проблемам синхронизации. В параграфе 16.11 описан красивый прием, позволяющий посредством записей CNAME управлять делегированием даже крошечных фрагментов адресного пространства. Домены DNS должны (более того, обязаны см. RPC 1219) обслуживаться как минимум двумя серверами. Чаще всего в организации функционирует главный сервера серверы провайдера являются резервными. После того как система сконфигурирована, серверы провайдера автоматически загружают информацию из главного сервера организации. Изменения в конфигурации
DNS отражаются на резервных серверах, не требуя вмешательства администраторов любой из сторон. Выбор имени домена Некоторые имена запрещены. Это. в частности, относится к уже используемым именам. Ряд имен, выбор которых ранее был запретен, теперь доступен таковыми являются комбинации имен доменов верхнего уровня например, edu.com"). а также имена, содержащие повторяющиеся компоненты (например, х.х.сот"). В предыдущем издании книги мы советовали выбирать имена так. чтобы они были короткими, удобными для ввода и идентифицировали использующую их организацию. Сегодняшняя действительность такова, что все хорошие, короткие имена заняты, по крайней мере в домене "com" Часть из них предусмотрительно скуплена дельцами, нов основном все они используются реальными лицами. Документ RFC 1032 рекомендует, чтобы имена доменов второго уровня имели в длину не более 12 символов, несмотря на то что DNS допускает использовать в каждой составляющей дох символов и 255 символов в полном имени. Двенадиатиспмвольное ограничение часто игнорируется, поэтому нет смысла его придерживаться (не стоит, однако, забывать о том, что длинные имена очень неудобно вводить.
Взрывоподобный рост числа доменов Протокол DNS предназначался для того, чтобы можно было связать доменное имя организации с сервером имен, закрепленным да этой организацией. Данная схема должна была применяться во всех организациях, подключенных к Internet. Но сегодня сеть Internet стала элементом массовой культуры, и доменные имена есть у многих коммерческих продуктов, кинофильмов, спортивных событий и т.д. Имена наподобие twinkies.com или playstation.com ие связаны (напрямую) с компаниями, создавшими продукт они используются скорее в рекламных целях. Неясно, сможет лн DNS справиться с подобным разрастанием глобальной сети Проблема заключается в том. что дерево имен DNS является эффективной информационной структурой лишь в том случае, когда в нем прослеживается четкая иерархия.
" Следует отметить, что многие версии BIND не работают с такими именами.
" Не все имена с повторяющимися компонентами считались нелегальными. Например. xinet.xinet.com всегда было допустимым именем, поскольку имя домена -- xinet.com, а в нем есть компьютер xinet.
Глово 16. Системо доменных имен
423
Но когда каждая организация дает сотням или тысячам своих продуктов доменные имена, расположенные у самой вершины дерева, о какой бы тони было иерархии говорить не приходится. На самом деле нам нужна служба каталогов, которая связывала бы названия различных торговых марок с соответствующими компаниями, предоставив DNS возможность заниматься только адресами. В своем начальном виде эта идея реализуется в современных Web-броузерах посредством сервиса, предоставляемого компанией RealNames Corporation. Но эта услуга не бесплатна только организации, подписавшиеся на нее и заплатившие определенную сумму денег, смогут иметь свои ключевые слова в базе данных. Другое возможное решение заключается в установлении принудительной иерархии имен, однако подобное никогда не случится все зашло слишком далеко и компании, имеющие серверы .com. заняли прочное место на рынке. Регистрация домена второго уровня Для того чтобы получить домен второго уровня, необходимо подать заявку в орган управления соответствующего домена верхнего уровня. В настоящее время организация ICANN занимается аккредитацией многочисленных агентств, управляющих регистрацией имен в географических доменах. На момент написания книги существовало около 25-ти регистрационных бюро и еще почти 80 проходили процедуру аккредитации. Полный их список имеется на узле www.icann.org. В Европе заявления о предоставлении доменных имен принимает организация CENTR (Council of European National Top-level domain Regis- tries — Совет европейских национальных доменных канцелярий верхнего уровня. Ее адрес — www.centr.org. Там же можно узнать адреса региональных регистрационных бюро. В азиатско-тихоокеанском регионе ответственным органом является организация APNIC (Asia-Pacific Network
Information Center — Азиатско-тихоокеанский центр сетевой информации www.apnic.net. Для того чтобы заполнить бланки регистрации, нужно назначить ответственного технического специалиста, ответственное административное лицо и хотя бы два компьютера, которые будут серверами домена. Кроме того, нужно выбрать доменное имя, еще никем незанятое.
Создоние собственных поддоменов Процедура формирования поддомена аналогична процедуре создания домена второго уровня, за исключением того, чгго ответственный орган теперь находится в пределах самой организации. Этот процесс предусматривает следующие этапы выбор имени, уникального для данного поддомена; назначение двух илн более компьютеров серверами нового домена согласование всего сделанного с администратором родительского дом сил Прежде чем осуществлять передачу полномочий, серверы родительского домена должны убедиться в том. что серверы имен дочернего домена сконфигурированы и работают правильно Если данное условие не выполняется. произойдет то. что называется напрасным делегированием. Подробнее об этом говорится в параграфе 16.14.
424
Чость It Роботов сетях

16.6. Пакет BIND
BIND (Berkeley Internet Name Domain — система доменных 1тегпе1-имен реализации университета Беркли) — это открытый программный пакет, предлагаемый организацией ISC. Он реализует протокол DNS и функционирует в качестве сервера имен на платформах UNIX (с недавнего времени также в Windows NT). Версии пакета B I N D Имеются три основные разновидности пакета. BIND 4. BIND 8 и
BIND 9- Первая из ннх существовала с концах гг. (ее выпуск примерно соответствует появлению документов RFC 1034 и RFC 1035). Вторая была выпущена в 1997 га третья — в середине 2000 года. Версий 5. 6 и 7 никогда не было. Существовала красивая легенда, будто версия 8 содержала в себе столь значительные изменения, что авторы решили увеличить ее номер в два раза по сравнению с предшественницей. Это, конечно жене так. Просто пакет BIND 8 предназначался для 4.4BSD, где номера версий многих программных продуктов были доведены до восьми (тоже самое произошло с системой sendmail, которая также "перескочила" через несколько номеров) Пакет BIND 8 содержит множество технических новинок, способствующих повышению эффективности, надежности и безопасности. В BIND 9 планка поднялась еще выше поддерживаются многопроцессорные системы, потоковые операции, реальные технологии безопасности (шифрование с открытым ключом, стандарт IPv6, инкрементные зонные пересылки и многое другое. Пакет BIND 9 оказался полностью переписанными. по сути, реализованным заново. В нем изолированы фрагменты кода, зависящие от платформы, благодаря чему стало легче переносить пакет в другие операционные системы. Внутренняя структура пакета BIND 9 существенно изменилась, но процедура конфигурации осталась той же. Поддержка пакета BIND 4 осуществляется только в виде выпусков "заплат, закрывающих бреши в механизме защиты. Вскоре даже такая поддержка прекратится. Ожидается, что через год или два, когда работа пакета
BIND 9 стабилизируется ион получит широкое распространение, уйдет в небытие и BIND 8. В этой главе мы будем описывать язык конфигурирования обоих пакетов BIND 8 и 9. Многие организации затягивают с обновлением версий, поскольку им не хочется менять работу полностью функционирующей системы. Те, кто до сих пор работает смогут воспользоввться сценарием named-boot - conf.pl, входящим в дистрибутивы версий 8 и 9. Он преобразует конфигурационный файл из формата версии 4 в эквивалентный формат версии 8 или 9. Записи самой базы данных DNS менять не требуется. Конечно, преобразованный конфигурационный файл не будет поддерживать новые свойства версий 8 и 9, но зато он послужит отправным пунктом для начала расширения системы. Определение текущей версии Поставщики операционных систем часто не указывают, какие версии внешних программных пакетов они включают в свои дистрибутивы. Поэтом) нам, администраторам, приходится выступать в роли ищеек, чтобы узнать, с какой версией мы имеем дело. В случае пакета BIND получить интересующую
I ново 16 Системо доменных имен
425
нас информацию можно посредством программы dig, входящей в состав пакета. Команда d i g б сервер возвращает номер версии при условии, что эта информация не была удалена из конфигурационного файла. К примеру, данная команда выдает нужный результат для сервера vix.com:
% d i g e b b . r c . v i x . c o m v e r s i o n . b i n d t x t c h a o s
VERSION.BIND. OS CHAOS TXT "fi.2.3-T4B" нов случае сервера cs.colorado.edu она бессильна
% d i g e m x o f l . c s . c o l o r a d o . e d u v e r s i o n . b i n d t x t chaos
VERSION.BIND. OS CHAOS TXT "wouldn't: you l i k e to k n o w . . . " Некоторые администраторы конфигурируют пакет B I N D так. чтобы номер его версии нельзя было узнать посредством такого рода запросов. Считается, что это повышает безопасность системы. Мы ие одобряем подобную практику, хотя она действительно способна поумерить пыл некоторых юных хакеров Подробнее о задании версии речь пойдет в параграфе 16.9. Обычно можно узнать версию BIND, просматривая журнальные файлы в каталоге /var/log или его эквивалентах. Например, демон named при запуске регистрирует свой номер версии через систему Syslog (средство "daemon"). Поиск посредством команды grep дает такие результаты
Dec 13 1 6 : 3 2 : 2 7 d i s a s t e r nameri[2399j: s t a r t i n g , named 4 . 9 . 7 Wed Sep 2 0 9 : 3 9 : 1 2 GMT 1996 FHNE_14 618
Dec 13 1 6 : 3 5 : 1 3 suod named[93251: s t a r t i n g , nanied 8 . 2 . 2 - P 3 Wed Nov 10 1 7 : 2 7 : 5 9 MST 1599 nu.llert@haxi.-us / ' n f s / d e p o t / s r c / c s / B i n a / b i n d -
8 . 2 . 2 - Р З / o o ^ j /sun4-*-SunOS4/bin/named
О системе Syslog рассказывалось в s iaec 11.
Первая строка получена в HP-UX 11.00 (дистрибутивный вариант системы, вторая — в SunOS (система некоторое время была в эксплуатации) Во втором случае данные немного неверны, поскольку "заплата' 4 для
BIND 8.2.2 по какой-то причине не повысила отображаемый уровень "заплаты. В действительности полная версия пакета — Р. Если демон named инсталлирован, но система не запускает его иа этапе начальной загрузки, вызовите этот демон самостоятельно (без аргументов) от имени пользователя root Демон зарегистрирует свои номер версии, обнаружит отсутствие конфигурационного файла и завершится. В табл 16.4 указано, какие версии BIND входят в состав наших тестовых систем. В версиях ниже 8.2.2-РЗ имеются проблемы с безопасностью.
Тоблицо 16.4. Версии BIND в розничных опероционных сисгемох
Системо Версия ОС Версия BIND
Solans
7 клн 8 8.1.2
HP-UX
11.00 4.9 7
Red Hat
6.1 8.2 6.2 8.2.2- PS
FreeBSD Я. 4 шш 4.0 8.2.2- PS
426
Чость II. Роботов сетях
Известно, что в Red Hat номера версий фиксируются и не меняются при последующей установке "заплат. Поэтому при поиске номера может отображаться недостоверная информация, как в показанном выше примере. В Red Hat внутренние номера версий добавляются к именам файлов, содержащих исходные тексты пакета, и иногда к ним присоединяется внутренний номер исправления или "заплаты. Например, bind-8.2-7.arch.rpm — это седьмое исправление исходной версии 8.2. Компоненты покета B I N D В пакет BIND входят три компонента демон named, отвечающий на запросы библиотечные подпрограммы, контактирующие с серверами распределенной базы данных DNS; программы nslookup, dig, host, позволяющие выполнять запросы из командной строки. Согласно терминологии, принятой в DNS, демон вроде named (или компьютер, на котором он работает) называется сервером имен. а программа- клиент, которая обращается к нему, — распознавателем. Ниже мы вкратце рассмотрим функции всех этих компонентов, ареальная конфигурация пакета
BIND описывается начиная с параграфа 16.8. Демон nomed: сервер имен покето B I N D Демон named отвечает на запросы об именах компьютеров и их [Р-адресах. Если демону неизвестен ответ на какой-нибудь запрос, он опрашивает другие серверы и помещает результаты их ответов в кэш. Кроме того, этот демон осуществляет зонные пересылки, копируя данные между серверами домена.
(Зона — это домен без своих поддоменов. Серверы имен работают именно с зонами, но часто говорится "домен, хотя на самом деле подразумевается "зона) Серверы имен работают в нескольких режимах, различающихся по нескольким аспектам, поэтому дать их точное определение нелегко. Ситуация усложняется еше и тем, что один и тот же сервер может играть неодинаковые роли в разных зонах. В табл. 16.5 перечислены прилагательные, употребляемые при описании серверов имен. Определения, данные с отступом, считаются относящимися к более крупной категории. Серверы нмен систематизируются на основании источника данных авторитетный, кзширующий. главный, подчиненный, типа хранимых данных (усеченный, пути расиространения запроса (переадресующий), типа выдаваемого ответа (рекурсивный, нерекурсивный) и, наконец, доступности сервера (невидимый. В следующих нескольких разделах конкретизируются наиболее важные из этих различий об остальных речь пойдет в других разделах главы.
©
Глово 16. Системо доменных имен 4 2 7
Таблица 16.5. Таксономия серверов имен Туп се . ера Авторитетный главный подчиненный усеченный внутренний
Неавторитетный
2 кэцщрующий переадресуюший Рекурсивный
Нерекурсивный Описание _ Официальный представитель зоны Основное хранилище зонных данных получает информацию из дискового файла Копирует свои данные с главного сервера Напоминает подчиненный сервер, ио копирует данные только о серверах имен (записи NS) Сервер, доступный только в пределах домена (также называется невидимым серверам) Отвечает на запросы, пользуясь данными из кэша; ис знает о том, являются ли эти данные корректными
Кэширует данные, полученные от предыдущих запросов обычно не имеет локальных зон Выполняет запросы от имени многих клиентов формирует большой кэш Осуществляет запросы от имени клиента до тех пор, пока не будет найден ответили получена ошибка Отсылает клиента к другому серверу, если не может получить ответ на запрос Внутренний сервер доступен любому, кто знает его IP-aapec. Строго говоря, атрибут "неанторитстный" относится к ответу на запроса не к серверу. Авторитетные и к э ш и р у ю щи е серверы Главный, подчиненный и кэшируюший серверы различаются только двумя характеристиками откуда поступают данные и авторитетен ли сервер для данного домена. В каждой зоне есть один основной сервер имен. На нем хранится официальная копия зонных данных (в файле на диске. Системный администратор модифицирует информацию, касающуюся зоны, редактируя файлы главного сервера. Подчиненный сервер копирует свои данные с главного сервера посредством операции, называемой зонной пересылкой. В зоне может быть несколько подчиненных серверов обязательный минимум — один. Усеченный сервер — это особая разновидность подчиненного сервера, загружающего с главного сервера только записи NS (описания серверов имен. О том, зачем нужно создавать такой сервер, речь пойдет в параграфе 16.11. Один и тот же компьютер может быть главным сервером для одних зон и подчиненным — для других.
О зонных пересылках рассказывается в параграфе 16.12.
Кэшируюший сервер имен загружает адреса серверов корневого домена из конфигурационного файла и получает все остальные данные, кэшируя ответы на выдаваемые им запросы. Своих собственных данных у кэширую- шего сервера нет, и ои не является авторитетным ни для одной зоны. Пример создания такого сервера приведен в параграфе 16.10, в разделе "Кафедральный сервер. Гарантируется, что авторитетный ответ сервера имен является точным неавторитетный ответ может быть устаревшим. Тем не менее большое число неавторитетных ответов оказывается совершенно корректным Главные и подчиненные серверы авторитетны для своих зон, ноне для кэшироп.шной
428
Чость II. Работа в .етях
информации о других доменах. По правде говоря, даже авторитетные ответы могут быть неточными, если системный администратор изменил данные главного сервера и забыл обновить их порядковый номер либо запустить команду ndc reload (или если изменения еше не успели дойти до подчиненных серверов) Главный сервер имен должен располагаться на машине, которая стабильна, имеет небольшое количество пользователей, относительно безопасна п подключена через источник бесперебойного питания. Необходимо, чтобы подчиненных серверов имен было минимум два. причем один из них — вне организации. Подчиненные серверы на местах должны быть включены в разные сети ив разные цепи питания. В зонных данных домена обычно присутствуют идентификаторы серверов имен всех его подлом е нов. Наличие подобной цепочки позволяет клиентам опускаться вниз по дереву доменов в поисках любого узла, подключенного к Internet. Если в родительском домене не упоминаются определенные серверы имен полдомена, они становятся "внутренними" и недоступными для внешнего мира.
Кэшируюшие серверы не авторитетны, но они. тем не менее, позволяют сократить объем трафика во внутренней сети и уменьшить время затрачиваемое на выполнение запросов. Желательно размешать один такой сервер в каждой подсети. В большинстве организаций запросы от настольных компьютеров обычно проходят через кэширующий сернер. Вине рекомендовалось делать один и тот же сервер имен авторитетным для одних тони кэшируюшим — для других. Каждый демон named эксплуатировал свою резидентную базу данных, и смешение могло произойти лишь в том случае, когда из-за нехватки памяти данные выгружались на диск. В BIND 9 эта проблема устранена. Рекурсивные и нерекурсивные серверы Серверы имен бывают либо рекурсивными, либо нерекурсивными. Если у нерекурсивного сервера есть адрес, оставшийся в кэше от предыдущего запроса, или если этот сервер авторитетен для домена, к которому относится запрашиваемое имя, то он даст соответствующий ответ. В противном случае он вернет отсылку на авторитетные серверы другого домена, которые должны знать ответ. Клиент нерекурсивного сервера должен быть готов принимать отсылки и обрабатывать их. У нерекурсивных серверов обычно есть веские причины не выполнять дополнительную работу. Например, все корневые серверы и серверы доменов верхнего уровня являются нерекурсивными, поскольку им приходится выполнять до 10000 запросов в секунду. Рекурсивный сервер возвращает только реальные ответьг илн сообшения об ошибках. Он сам отслеживает отсылки, освобождая от этой обязанности клиента. Базовая процедура анализа запроса, по сути, остается той же единственное отличие заключается в том, что рекурсивный сервер заботится об обработке отсылок, не возвращая их клиенту. Библиотеки функций распознавания, имеющиеся в большинстве версий
UNIX, не понимают отсылок. Они ожидают, что локальный сервер имен является рекурсивным. Есть один побочный эффект при отслеживании отсылок: в кэше сервера имен накапливается информация о промежуточных доменах. При работе в локальной сети от этого обычно только польза, поскольку в последующих
Глово 16. Системо доменных имен
429
операциях поиска, инициируемых любым компьютером этой сети, можно будет пользоваться результатами предыдущих запросов. С другой стороны, сервер домена верхнего уровня (такого как "com" или "edg") не должен хранить информацию, запрашиваемую компьютером, который находится на несколько уровней ниже. В ранних версиях BIND требовалось модифицировать исходный код и перекомпилировать пакет, чтобы изменить рекурсивность сервера. Затем появилась опция командной строки -г. которая теперь является параметром конфигурационного файла. Можно даже сконфигурировать сервер таким образом, что он будет рекурсивным для внутренних клиентов и нерекурсив- ным — для внешних. Отсылки генерируются иа иерархической основе. Если сервер, к примеру, не сможет узнать адрес узла lair.cs.colorado.edu, он выдаст отсылки к серверам доменов cs.colorado.edu, colorado.edu, "edu" или корневого домена. Отсылка должна содержать адреса серверов того домена, на который она указывает, поэтому выбор домена ие случаен сервер должен ссылаться на тот домен, серверы которого ему уже известны. Как правило, возвращается наиболее полный из известных доменов. В нашем примере в первую очередь были бы выданы адреса серверов домена cs.colorado.edu, при условии, что они известны. Если этот домен неизвестен, но известен домен colorado.edu. были бы выданы адреса его серверов имени т.д. Сервер имен предварительно наполняет свой кэш содержимым файла "подсказок, в котором указаны серверы корневого домена. Благодаря этому всегда можно сделать какую-нибудь отсылку, даже если она гласит "спроси у корневого сервера. Модуль распознавания Клиенты ищут соответствия между именами компьютеров и их адресами, вызывая библиотечную функцию gethostbvnamcO- В исходной версии этой функции имена искались в файле /etc/hosts. Для того чтобы такую информацию выдавала система DNS, функция должна делать запросы к модулю распознавания, который знает, как находить серверы имени взаимодействовать сними. В большинстве операционных систем функция get host byriame() может черпать информацию из нескольких источников обычных файлов (например,
/etc/hosts), DNS и даже локальных административных СУБД, таких как NIS и NIS+. Иногда возможен четкий административный контроль над тем, какие источники опрашиваются ив каком порядке Подробнее об этом рассказывается в параграфе 18.3, а также в параграфе 16.16 применительно к нашим тестовым системам. Выполнение запросов из командной строки В пакет BIND входят программы dig и nslookup. позволяющие выполнять запросы в режиме командной строки. Они полезны при отладке и как инструменты извлечения информации из базы данных DNS Обе программы имеют сходные футпшнональные возможности, но реализованы немного по-разному. Подробнее о них рассказывается в параграфе 16.14.
430
Чость II. Роботов сетях

16.7. Как работает D N S Каждый компьютер, пользующийся услугами DNS. является либо клиентом данной системы, либо одновременно и клиентом, и сервером. Те читатели, которые не планируют запускать серверы DNS. могут, пропустив следующие несколько разделов, сразу переходить к параграфу 16.8. Отметим, однако, что эти разделы полезны для более глубокого понимания архитектуры
DNS. Делегирование Все серверы имен знают о существовании корневых серверов. Последние, в свою очередь, знают о доменах "com", "org", "edu", "fi". "de" и других доменах верхнего уровня. Сервер домена "edu" знает о домене coIorado.edu, сервер домена "com" знает о домене adrnin.com и т.д. Каждая зона может делегировать полномочия по управлению своими поддоменами другим серверам. Рассмотрим реальный пример. Предположим, требуется узнать адрес узла vangogh.cs.berkeley.edu с машины lair cs.colorado.edu. Компьютер lair просит свой локальный сервер имен, ns.cs.colorado.edu, найти ответ на этот вопрос. Последующие события изображены на рис. А. Мы использовали относительные имена, чтобы уменьшить неразбериху и улучшить читабельность надписей. Цифры возле стрелок определяют порядок событий, а буквы — тип транзакции (запрос, ответили отсылка. Мы предполагаем, что перед запросом никакие из требуемых данных не кэшировались, за исключением имени адресов серверов корневого домена. Рекурсивные Нерекурсивные Рис. А. Процесс оброботки зопросо в DN5 Локальный сервер имен не знает нужный адрес. Более того, ему ничего неизвестно ни о домене cs.berkeley.edu. ни о домене berkeley.edu. Он знает лишь некоторые серверы корневого домена и. будучи рекурсивным, спрашивает корневой домен об узле vangogh.cs.berkeIey.edu. Раньше корневые серверы хранили данные как о корневых зонах, таки об общих доменах, но сегодня у последних есть свои собственные серверы имен. В ответ на запрос к корневому серверу об узле vangogh.cs.berkeley.edu мы получим ссылку на сервер домена "edu". Локальный сервер имен посылает свой запрос к серверу домена "edu"' и получает обратно ссылку на серверы домена berkeley.edu. Тогда он повторяет запрос, направляя его в домен berkeley.edu. Если сервер университета Беркли
Глово 16. Системо доменных имение рекурсивен и не содержит ответ в кэше, он вернет ссылку на домен cs.berkeley.edu. Сервер этого домена авторитетен в отношении запрашиваемой информации и возвращает адрес компьютера vangogh. Когда все закончится, в кэше сервера ns.cs.colorado.edu окажется адрес компьютера vangogh. В кэше также будут списки серверов доменов "edu". berkeley.edu и cs.berkeley.edu. Демон named посылает запросы по протоколу UDP через порт 53. Ответные пакеты также имеют формат UDP, если только их объем не превышает 512 байтов в этом случае используется протокол TCP. В зонных пересылках всегда применяется протокол TCP.
Кэширование и эффективность Благодаря кэшированию повышается эффективность поиска кэширован- ный ответ почти бесплатен и, как правило, точен, так как адресно-именные соответствия меняются редко. Большинство запросов касается локальных машин и разрешается быстро. Пользователи невольно содействуют повышению эффективности работы серверов имен, так как многие запросы повторяются. В течение долгого времени кэширование применялось только к положительным ответам. Если имя или адрес компьютера было невозможно найти, этот факт не фиксировался. Схема кэширования отрицательных ответов была описанв в документе RFC 1034, но она оказалась неполной и осталась нереализованной в большинстве версий BIND. В 1998 г. был опубликован документ RFC2308, в котором описывалась обновленная схема отрицательного
кэширования. Она была реализована в BIND 8.2 в виде опционального компонента, нов это уже обязательный компонент. Измерения, проведенные на сервере RIPE в Европе, показали, что 60% запросов относилось к несуществующим данным (многие запросы были адресованы домену I27.in-addr.arpa или содержали в качестве сетевых имеи названия сервисов Microsoft). Кэшируя эту информацию как можно глубже в дереве, можно добиться резкого снижения нагрузки на корневые сервгры. При отрицательном кэшировании сохраняются ответы следующих типов отсутствие узла или домена, соответствующих запрашиваемому имени данные запрашиваемого типа не существуют для указанного узла запрашиваемый сервер не отвечает сервер недоступен из-за проблем в сети Ответы первых двух типов сохраняются в кэше в течение 1—3 часов, остальные — 5 минут. Неавторитетные ответы могут кэшироваться, а авторитетные негативные ответы — обязаны.
Демон named часто получает несколько записей в ответ на запрос. Например, при попытке узнать адрес сервера имен корневого домена будет получен список из всех 13-ти корневых серверов. К какому из них следует обращаться Когда демону named приходится выбирать среди удаленных серверов, все из которых авторитетны для данного домена, он в первую очередь определяет период кругового обращения (round-trip time, RTT) каждого сервера. Затем серверы сортируются по "корзинам" в соответствии со значением RTT. после чего выбирается сервер из самой быстрой корзины. Серверы в пределах одной корзины считаются равнозначными и выбираются по циклической схеме.
432 Часть II. Робота в сетях
Простейший, ио весьма эффективный способ распределения нагрузки — закреплять одно имя за несколькими адресами (соответствующими разным компьютерам www IN А 1 9 2 . 1 6 8 . 0 . 1
IN А 1 9 2 - 1 6 8 - 0 . 2
IN А 1 9 2 . 1 6 8 . 0 . 3 Загруженные серверы, такие как Yahoo ив действительности не являются одной машиной. Они просто известны под одним доменным именем в DNS. Сервер имен, обнаруживший несколько записей с одинаковым именем и типом, возвращает все их клиенту, нов циклическом порядке. Например, порядок записей А в показанном выше примере будет
I, 2, 3 для первого запроса, 2, 3, 1 — для второго и 3, 1 , 2 — для третьего. Расширенный протокол D N S Исходное определение протокола DNS датируется концом х гт. и предполагает использование протоколов UDP и TCP. Первый нужен для запросов и ответов, а второй — для зонных пересылок между главными и подчиненными серверами. К сожалению, максимальный размер пакета, который гарантированно принимается всеми реализациями UDP, составляет
512 байтов. Это слишком мало для новых схем обеспечения безопасности
DNS, подразумевающих включение в каждый пакет цифровой подписи. Данное ограничение влияет на число и названия корневых серверов. Чтобы все данные этих серверов умещались в байтовом пакете, количество серверов ограничено числом 13. а имя каждого сервера состоит из одной буквы. Многие распознаватели выдают сначала запроси если приходит усеченный ответ, то запрос повторяется в формате TCP. Эта процедура позволяет выйти за рамки байтового лимита, но она неэффективна.
Кое-кто может посчитать, что следует вообще отказаться от UDP и перейти исключительно на TCP, но соединения являются гораздо более дорогостоящими. Обмен данными между серверами имен в рамках протокола UDP может свестись всего к двум пакетам один запроси один ответ. В случае протокола TCP требуется минимум семь пакетов трехфазовое квитирование для инициализации диалога, запрос, ответ и завершающее квитирование для разрыва соединения. В середине х гг. протокол DNS был усовершенствован механизмами инкрементных зонных пересылок (напоминает применение команды diff для сравнения старого и нового зонных файлов прототипом послужила программа, написанная Ларри Уоллом), асинхронных уведомлений (для информирования подчиненных серверов об изменениях файлов главного сервера) и динамических обновлений (для узлов. Все эти нововведения привели к расширению функциональных возможностей DNS, но они не решили фундаментальную транспортную проблему. В конце х гг. появилась спецификация EDNS0 (расширенный протокол DNS, версия 0), которая устраняла некоторые недостатки DNS. В этой спецификации запрашивающая сторона сообщает размер буфера сборки пакетов, поддерживаемые опции и версию протокола. Если сервер имен отвечает сообщением об ошибке, запрашивающая сторона возвращается к исходному протоколу DNS. Пакет BIND 9 реализует спецификацию EDNS0 как на стороне сервера, таки на стороне распознавателя.
Глово 16. Системо доменных имен


Поделитесь с Вашими друзьями:
1   ...   32   33   34   35   36   37   38   39   ...   82


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал