К. Закер - Компьютерные сети. Модернизация и поиск неисправностей (953092), страница 156
Текст из файла (страница 156)
Глава 20. Система деменны» имен Кэширование 0й8-серверов Описанный выше процесс может показаться излишне долгим и сложным. Однако, во многих случаях. 0ХБ-серверу клиента нет никакой необходимости посылать запросы серверам каждого домена, присутствующего в запрашиваемом ОИЗ-имени. Это связано с тем, что РЫБ-серверы обладюот сцособностыо сохранять инфзрмапию о пространстве имен, которую им удалось выяснить в процессе разрешения имен, и удерживать ее в каше на локальном жестком диске. 1ЖБ-сервер, получающий запросы от клиентов, кэширует, например, адреса запрашиваемых систем так же, как и адреса авторитетных серверов конкретных доменов.
В следующий раз, когда клиент будет посылать серверу запрос с именем, разрешение которого уже было проведено, сервер сможет отвеппь немедленно, пользуясь кэшированной информацией. Кроме того, если клиент запрашивает имя, принадлежюцее к тому же домену, что и уже разрешенное, сервер может отправить запрос прямо авторитетному серверу данного домена, а не корневому серверу имен, Таким образом, пользователи часто могут обнаружить, что разрешение имен доменов, постоянно используемых для доступа, проходит значительно быстрее, так как один из серверов, участвующих в разрешении имен, уже имеет информацию об этом домене в своем кэше. С другой стороны, разрешение имен неизвестных доменов занимает существенно больше времени, так кзк для этом требуется применение полного процесса запросов и ссылок. Отрицательнее кэширование Кроме хранения ин4юрмации„способствующей ускорению процесса разрешения имен, большинство современных реализаций ОЫЗ-серверов также обладают способностью к отрицательному кэшированию.
Отрияатлевьлов кэширование ~аврале сает) осуществляется, когда ВИЗ-сервер фиксирует ин4юрмацию об именах, которые не существуют в определенных доменах. Например, если клиент посылает ОХЗ-серверу запрос, содержащий имя, ще домен второго уровня не существует, сервер домена верхнего уровня ответит на соответствующий запрос ОИЗ-сервера сообщением об ошибке. После этого МЧБ-сервер будет хранить ин4юрмацию этого сообщения об ошибке в своем кэше.
В следующий раз, когда клиент станет запраптиыгь имя из этого же домена, ОХБ-сервер сможет сразу ответить собственным сообщением об ошибке, без необхсщимости консультирования с сервером ломена верхнего уровня. Продолжительность кэширования данных Кэширование является цлним из жизненно важных элементов архитектуры РИБ, так как позволяет значительно уменьшить число запросов,.
направляемых корневым серверам: имен и серверам доменов верхнего уровня, кп торые, находясь на вершине дерева ьу1чБ, с большой вероятностью могуг стать узким местом" всей системы. Одншш кэшврованидл информация серверов должна периодически очищаться, и гранйца между эффективным и неэффективным юшированием проходит по очень тонкой линии. Так как ЕЙЧЗ-серверы иэшируют записи о ресурсах, в любом авторитетном сервере для изменений потребуются часы или даже дни, чтобы распространиться по всей сети Интернет. В течение же этою периода'пользователи могут получать некорректную информацию в ответ на сваи забросы.
Если информация остается в каше ИЧЗ-серверов слишком долгое время, то изменения, производимые админжтратарами в базах данных ВЯЗ-серверов, булуг распространяться по глобальной сети очень медленно. Если кэш ОИЗ-серверов очищается слишком быстро, стремительно возрастает количество запросов, направляемых корневым серверам имен и серверам даменов верхнего уровня. Конкретное время, в течение которого ХЙЧЗ-данные будут сохраняться в каше сервера, носит название времени эгиии 19Ме то 11г4. В отличие от большинства остальных способов кэширования информации. администратор сервера, нэ, катаром созлается кэш, не имеет::возможности запать время жизни ланных ГНИ. Вместо этого администраторы кюкдаго автаритетиога ЕПЧЗ-сервера указывают, насколько долго информация записей а ресурсах соответствующе1о'домена или зоны должна будет храниться в там сервере, где бужт кжирэваиа.
Это позволяет администраторам задаввгь время жизни информации в зависимости от скорости изменения данных конкретного авторитетного 111чЗ-сервера. В сети, где часто происходит смена 1Р-адресов н добавление новых записей о ресурсах, маленыгае значение времени жизни будет увеличивать вероятность того, что клиенты получат даспзвернуЮ информацию, соответствующую текущему соспвпппо сети В сети, где изменения происходят редко, можно пользавщься баиылнм значением времени жизни, чтобы умеш шить число запросов, направляемых серверам родительских, по отношению к данному домену нли'зоне, даменов. Рвспрвдвлвние нагрузки в Ов1е1 В большинстве.
случаев ОИЗ-серверы содержат диформацию только об одном 1Р-щйзесе для каждого хост-нмени. Несмотря на это, иногда возникают ситуации, когда системе требуется более алного 1Р-адреса. Например, в случае силию загруженного трафикам ЖеЬ-сайтэ, одного сервера может быть недостаточно для обслуживания всех клиентов. Однако для того, чтобы иметь множестаенные идентичные серверы с собственными адресами, содержащие один и тот же сайт, необходим механизм, позволяющий убедиться, чта работа по обработке запросов клиентов распределена между отдельными машинами.
Один из спасобаа осуществления этого заключается в контроле над тем, как авторитетные серверы домена, к которому принадлежит сайт, проводят разрешение ПИЗ-имени конкретного ЖеЬ-серве~. Некоторые'реализации ВЯЗ-серверов позволяют сазлавать множественные записи о ресурсах с раз- Глава аО. Сна гегаа ременных имен личными 1Р-адресами для одного хост-имени. Когда сервер получает запросы на разрешение данного имени, он использует имеющиеся записи о ресурсах в циклическом режиме, чтобы предоставлять каждому следующему клиенту 1Р-адрес другой машины.
Следует обратить внимание, что кэширование информации ОИЗ-сервераьги приводит к снижению эффективности подобного циклического механизма„ так как сервер скорее использует данные о сайте, содержащиеся в его кэше, чем будет генерировать новый запрос и возможно получит в ответ 1Р-адрес иной системы. В результате, обычно целесообразно использовать относительно малые величины времени жизни для информации дублирующихся записей о ресурсах. Обратное разрешение иыен Система доменных имен была разработана для обеспечения разрешения ВИБ-имен в 1Р-адреса, но возникают также ситуации, котла требуется разрешать уже известные 1Р-адреса в ВИЗ-имена. Такие случаи относительно редки.
Например, в 1ой-файлах некоторые системы конвертируют 1Р-адреса в ВИЛ-имена, чтобы сведать содержимое файлов более удобным для людей, которые будут их читать. Некоторые системы используют обратное разрешение имен в ходе процедур аугентификации. Структура пространства имен ВИБ и метод„с помощью которого оно распределено между различньгми серверами, основаны на иерархии имен доменов.
Когда вся база данных находится на одном компьютере, например как при использовании файла Ьпгз, процесс поиска конкретного адреса для выяснения имени, ассоциированного с ним, ничем принципиально не опгичается от поиска имени для определения соответствующего ему адреса. С другой стороны, поиск конкретного имени в пространстве имен 11ИЯ, как представляется, потребует просмотра информации всех ВИЗ-серверов сети Интернет, что, конечно же, не может считаться практичным. Чтобы обеспечить обратное разрешение имен, не прибегая к массивному поиску по всей сети Интернет, дерево 0Из включает специазьную ветвь, которая испальзует десятичные значения 1Р-адресов с точечным разделением в качестве имен доменов.
Эта ветвь берет начало от домена под названием ш-иЫг.агре, расположенного сразу после корня дерева ЕФБ, квк показано на рис. 20.5. Непосредственно за доменом 1п-агЫг.агре располагакпся 256 поддоменов, имеющих имена от 0 до 255, которые представшют всвьидкные значения первого байта 1Р-адреса. Каждый из этих подломенов включает по 256 собственных поддоменов, представляющих возможные значения второго байта 1Р-адреса. Следуюцпгй уровень содержит еще по 256 поддоменов, каждый из которых'мгекет включать до 256 пронумерованных хостов, что позволяет представлять третий и четвертый байты 1р-адреса.
Часта К бвтеаме слумбм саединееиа Рис. 20.6. ИереРямя домена М-шЫг.ирв С уястом структуры домена ш-аМгагра, каждмй 'хоет, представленный на ВХЗ-сервере 'стандартным ВЯЗ-именем; такие имват аквавалентное: П1 1З- нмя, сконструированное с использованием ?Р-адреса Таким образом, если система с 1Р-адресом 192.16Б.214.23 входит, по ин$орыапии базы данных ОХЗ-сервера, в домен гаскег.соп~ под хосг-именем твпч, то одновременно существует и другая запись о ресурсе для данной системы, где Фигурирует ВЯЗ-имя 23.214;1бйт192.щ-агИг.жра. Такое имя подразумевает, что существует хост под номером 23 в домене под названием 214.166.192.ш-асЫг.азра (рис. 20.6). рею. Л6.6.
Дяя явжлюго хоста в базе деннмя ЕИЧБ имеется две зеписи о ресурсе Структура етого домена позволяет системе вести поиск 1Р-адреса хоста в домене (зоне) без необходимости консультирования с другими серверами дерева ОХИ. В большинстве случаев существует возможность конфигурировать 1ЖЗ-сервер для автоматического создания эквивалентной записи о ресурсе в домене Ы-асЫг.агра при включении каждого нового хоста в стандартное пространство имен 1)Х$. Значения байсов 1Р-адреса отображаются в домене ш-асЫг.агра в обратном порядке, так как в Огчб-имени слово наименьшего разряла всегла стоит первым, в то время ках в 1Р-адресе байт наименьшего разряда находится на последнем месте.
Другими словами, структура 0%-имени отображает структуру дерева 1)И$, причем его корень остается справа, а имя хоста слева. В 1Р-адресе, наоборот, идентификатор хоста находится справа, а идентификатор сети занимает крайнее левое положение. Теоретически возможно создание структуры подобного домена с использованием естественного порядка байтов 1Р-адреса, но зто значительно усложнит процесс администрирования, так как создаст дополнительные трудности при делегировании тех полномочий по техническому обслуживанию, копзрые основаны на 1Р-адресах. Если, например, в корпоративную сеть входят три дочерних офиса, каждый из которых имеет собственный 1Р-адрес класса С (192ЛбаЛ, 192.16В.2 и 192Л68.3), существует возможность, что доменамн по обратному разрешению имен будуг управлять разные люди.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
