Установка Microsoft Exchange Server 2010 на раз, два, три. Руководство для начинающих. Часть 3. Формирование записей ресурсов в почтовой системе Exchange Server 2010.

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

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

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

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

  • ·         DNS-клиент обращается к корневому DNS-серверу с указанием полного доменного имени;
  • ·         DNS-сервер отвечает, указывая адрес следующего DNS-сервера, обслуживающего домен верхнего уровня, заданный в старшей части запрошенного имени;
  • ·         DNS-клиент делает запрос следующего DNS-сервера, который отсылает его к DNS-серверу нужного поддомена, и т. д., пока не будет найден DNS-сервер, в котором хранится соответствие запрошенного имени IP-адресу. Этот сервер дает окончательный ответ клиенту.

Так как эта схема загружает клиента достаточно сложной работой, то она применяется редко.

Схема взаимодействия называется рекурсивной, в том случае, когда клиент перепоручает работу своему серверу. При получении рекурсивного запроса сервер должен вернуть либо ответ на запрос, либо сообщение об ошибке; все действия по поиску данных и опросу других серверов сервер берет на себя. Рекурсивный сервер возвращает только реальные ответы и сообщения об ошибках. Он сам отслеживает отсылки, освобождая от этой обязанности клиента. Базовая процедура разрешения запроса, по сути дела, та же; единственное отличие состоит в том, что этот сервер имен заботится об обработке отсылок, не передавая их обратно клиенту. В случае реализации рекурсивного запроса:

  • ·         при необходимости произвести какое-либо из DNS-преобразований («адрес в имя», «имя в адрес») DNS-клиент запрашивает локальный DNS-сервер, то есть тот сервер, который обслуживает поддомен, к которому принадлежит имя клиента, и адрес которого указан в сетевых настройках. Обращение происходит через протокол UDP на порт 53.
  • ·         если локальный DNS-сервер знает ответ, то он сразу же возвращает его клиенту; это может соответствовать случаю, когда запрошенное имя входит в тот же поддомен, что и имя клиента, а также может соответствовать случаю, когда сервер уже узнавал данное соответствие для другого клиента и сохранил его в своем кэше;
  • ·         если же локальный DNS-сервер не может выдать ответ на поступивший запрос (т.е. необходимые данные отсутствуют в его базе и кэше предыдущих запросов), то он выполняет итеративные запросы к одному из корневых серверов (root servers)  и т. д. точно так же, как это делал клиент в первом варианте; получив ответ, он передает его клиенту, который все это время просто ждал его от своего локального DNS-сервера. Практически все DNS-клиенты используют рекурсивную процедуру.

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

По этим причинам серверы имен нижних уровней обычно являются рекурсивными, а серверы высших уровней (верхнего и частично второго) — не рекурсивными.

Отсылки генерируются на иерархической основе. Если сервер, например, не сможет дать адрес машины vtau-bsd.pstu.ac.ru, он последовательно обратится к серверам домена pstu.ac.ru, ac.ru, ru и корневого домена. Отсылка должна включать адреса серверов домена, на который она указывает, поэтому выбор — не произвольный; сервер должен ссылаться на тот домен, серверы которого ему уже известны. Как правило, выдается наиболее полный из известных доменов.

Если конфигурация машины предполагает использование DNS, для преобразования имен машин в IP-адреса программы прикладного уровня, такие как Netscape Navigator и т.п., запрашивает адрес у сервера имен, ip-адрес которого указан в настройках подключения к Internet.

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

  • ·         местный сервер знает адрес, потому что этот адрес содержится в его части всемирной базы данных;
  • ·         местный сервер знает адрес, потому что кто-то недавно уже запрашивал тот же адрес. Когда запрашивается адрес, сервер DNS придерживает его у себя в памяти некоторое время на случай, если кто-нибудь еще захочет попозже тот же адрес — это повышает эффективность системы;
  • ·         местный сервер адрес не знает, но знает, как его выяснить.

Как локальный DNS-сервер может разузнать запрошенный адрес? В его прикладном или системном программном обеспечении имеется информация о том, как связаться с корневым сервером. Это сервер, который знает адреса серверов имен высшего уровня (самых правых в имени), здесь это уровень государств (ранга домена RU). У него запрашивается адрес компьютера, ответственного за зону RU. Местный DNS-сервер связывается с этим более общим сервером и запрашивает у него адрес сервера, ответственного за домен SN.RU. Теперь уже запрашивается этот сервер и у него запрашивается адрес рабочей машины terrikon.

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

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

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

 

Предположим, пользователь, работающий на компьютере с именем ada.vvsu.ru хочет посетить сайт, находящийся на хосте crypt.iae.nsk.su. Последующие события показаны на рис. 3.

Рис. 3. Схема обработки запроса DNS-сервером.

Машина ada отправляет запрос своему локальному DNS-серверу, 212.16.195.98 (ns. vvsu.ru). Мы предполагаем, что перед запросом никакие из требуемых данных не кэшировались, за исключением серверов домена ru.

Если у сервера локальных имен ns.vvsu.ru нет в кэше требуемых данных, он ответа на запрос не знает. Более того, он не знает ничего ни о cs.psu.ru, ни о psu.ru. Он знает некоторые серверы домена ru и, будучи рекурсивным, обращается с запросом о машине ada.vvsu.ru к корневому серверу доменной системы (на самом деле таких серверов 13, все данные на них идентичны), адреса корневых серверов известны каждому DNS-серверу и содержатся в файле root.cache.

Корневой сервер, как минимум, может ответить адресом сервера, отвечающего за зону su, однако в нашем случае ему известен адрес сервера, отвечающего за nsk.su (этот адрес мог оказаться в его кэше, но на самом деле корневые серверы отвечают не только за корень доменной системы, но и за большинство доменов верхнего уровня, следовательно, они могут непосредственно делегировать полномочия серверам доменов второго уровня — например, nsk.su).

Поскольку доменом su управляют не рекурсивные сервера имен, то вместо сообщения запрошенного адреса локальному серверу говорят: «Пойди-ка спроси у домена nsk.su; вот адреса серверов». Локальный DNS сервер (ns.vvsu.ru) вынужден  повторно посылать запрос о машине crypt, адресуя его серверу домена nsk.su, в кэше и базе данных которого нет готового ответа, и nsk.su возвращает адрес сервера, ответственного за crypt.iae.nsk.su.

Сервер nsk.su не знает ответа, но, будучи рекурсивным, направляет этот запрос серверу домена iae.nsk.su. Этот сервер авторитетен по запрашиваемой информации ns.vvsu.ru получает IP-адрес хоста crypt.iae.nsk.su, поскольку эти данные хранятся непосредственно в базе данных на iaebox.nsk.su, и возвращает адрес машины crypt . Сервер домена nsk.su кэширует этот адрес и возвращает его серверу ns.vvsu.ru.

В итоге, мы увидим следующие изменения:

  • ·         ns.vvsu.ru кэшировал адрес машины crypt;
  • ·         ns.vvsu.ru кэшировал данные о серверах домена nsk.su;
  • ·         сервер домена nsk.su кэшировал адрес машины crypt.

 

DNS запросы используют протокол UDP и порт 53. Если объем ответов превышает 512 байтов, то для их доставки используется протокол TCP. В зонных пересылках между серверами также применяется протокол TCP.

Для ускорения поиска IP-адресов DNS-серверы широко применяют процедуру кэширования проходящих через них ответов. Так, сервер после передачи полученных данных клиенту кэширует их для дальнейшего возможного использования. Также кэшируются и все дополнительные данные, полученные в процессе обработки запроса — например, при запросе IP-адреса хоста alpha.iae.nsk.su сервер ns.vvsu.ru сразу обратится к iaebox.iae.nsk.su, минуя опрос вышестоящих серверов. Последние версии ПО также могут кэшировать и отрицательные результаты поиска. Чтобы служба DNS могла оперативно отрабатывать изменения, происходящие в сети, ответы кэшируются на определенное время — обычно от нескольких часов до нескольких дней.

Особенности применения доменной системы имен.

1. Части доменного имени говорят о том, кто ответственен за поддержку этого имени, то есть в чьем подчинении-ведении оно находится. Они могут вообще ничего не сообщать о владельце компьютера, соответствующего этому IP-адресу, или даже (несмотря на коды стран) где эта машина находится. Вполне можно иметь в Антарктиде машину с именем antarktida.doneLsk.ua, Это совершенно ненормально, но никаким законам не противоречит.

2. Части доменного имени даже не всегда указывают локальную сеть, в которой расположен компьютер. Часто доменные имена и сети перекрываются, и жестких связей между ними нет: две машины одного домена могут не принадлежать одной сети. Например, системы firmal.donetsk.ua и firma2-donetsk.ua могут находиться в совершенно разных сетях. И еще раз: доменные имена указывают на ответственного за домен.

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

В сущности, они будут продолжать пользоваться этой службой, запрашивая ее по тому же имени, независимо от того, какой компьютер на самом деле занимается обслуживанием. Имена, по смыслу относящиеся к службе, называются «каноническими именами» или «кименами» (cnames). В Интернете они встречаются чаще всего. Например, имя www.shop.dn.ua указывает наWeb-сервер, а не на FTP-сервер.

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

5. Запоминать лучше имена, а не числовые адреса. Адреса привязаны к конкретным точкам сети. Если компьютер, предоставляющий некие услуги, переносится из одного здания в другое, его сетевое расположение, а значит, и адрес могут измениться. Имя же менять не надо и не следует.

 

http://www.opennet.ru/docs/RUS/dns1/

http://www.xserver.ru/computer/protokol/razn/4/index.shtml

http://www.it2web.ru/index.php/dns/43-catdns/88—dns-

http://www.anwiza.com/content/view/16/4/

http://www.bibliotekar.ru/rInform/index.htm

http://kunegin.com/ref3/addr_ip/f08.htm

http://it2web.ru/index.php/dns/43-catdns/73-osnovy-domennoj-sluzhby-imen-vvedenie-v-dns

http://help.fregat.com/general/ip

http://linuxforum.ru/viewtopic.php?id=129

Пока нет комментариев.

Вы должны зайти чтобы оставить комментарийt.

Нет трэкбэков.
 

You need to log in to vote

The blog owner requires users to be logged in to be able to vote for this post.

Alternatively, if you do not have an account yet you can create one here.

Powered by Vote It Up