Продолжение – начало здесь.

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

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

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

Как вы уже знаете из предыдущей темы - основными компонентами пространства имен DNS являются домены. Домены взаимодействуют друг с другом при помощи отношений «родитель-потомок», образуя тем самым некую иерархию (смотри рисунок 1). Эти отношения рождают, как говорится – иерархию. То есть один домен является «родителем»   – остальные являются «дочерними» доменами по отношению к родителю.

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

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

Я написал слово «зарегистрированном» - это значит что действительно в интернете такому имени как  RK.COM чиновники от интернета,  официально присвоили в строгом соответствии IP-адрес, что бы к нему могли обращается.

То есть,  COM контейнер или домен первого уровня TLD (я не пишу домен, а использую термин контейнер в контексте DNS базы данных, хранящую информацию, думаю, что так проще для восприятия из ассоциации «контейнер – хранит»)  хранит информацию о своих дочерних объектах,  доменов второго уровня такие как, к примеру, у нас домен RK.COM домен второго уровня SLD.  То есть логика, грубо говоря такая  – «родил – храни». А вот информация о поддоменах который породил домен RU первого уровня (TLD) хранит информацию о всех его дочерних объектах, доменах второго уровня (SDL), к примеру XU.RU.

В свои очередь мы можем проследить  за тем что объекты которые  породил, допустим,  домен второго уровня RK.COM к примеру KONTORA.RK.COM. Информация о его имени и соответственно  его IP адрес будет хранится в контейнере RK.COM. А то что породил KONTORA.RK.COM, например PRODUKTIA.KONTORA.RK.COM будет хранится в KONTORA.RK.COM. Ну и так далее...   

В реале, такого строгого разграничения хранения информации по контейнерам в зависимости от того "кто родитель тот и хранит" – нет. Но это связанно с техническими аспектами, которые рассмотрим ниже. Я же просто привел пример как информация о базах данных DNS хранятся распределено (раздельно), и исходя из какой логики это так сделано.

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

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

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

Получается что,  вся  база данных разделена на зонные файлы (каждый контейнер содержит свой файл с базой данных)  на основе  имен доменов.  То, что я объяснил  высшее на примерах.

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

Давайте разберемся,   что такое зона DNS.

Зоны DNS.

Деление доменного пространства имен между DNS - осуществляется посредством механизма зон (zone).

Зона представляет собой базу данных, в которой содержатся записи о соответствии (некоторого множества доменных имен IP - адресами. То есть все как обычно "имя - IP адрес". Каждая зона представляет только часть доменного пространства имен. Можно сказать еще так  - 

Зоной  - называется часть домена DNS. Почему часть? Вот например, домен RK.COM может содержать несколько зон, например зону - KONTORA.RK.COM и зону - BUHGALTERIA.RK.COM. Как правило, термин "зона" используется для обозначения части домена в отношении DNS-сервера или потомка. Термин "поддомен" используется для обозначения части домена, содержащегося в зоне. При наличии в домене только одной зоны используется любой из этих терминов.

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

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

Рисунок 1.

Зоны можно разместить на одном или нескольких серверах. На каждом из этих участвующих DNS серверов будет размещается отдельная копия зоны. Для того что бы эти копии были идентичны используется репликация между серверами DNS зоны. Репликация основана на модели с "одним основным участником" (single - master replication). Что это значит? Значит что в такой модели один из DNS серверов выступает в качестве "основного носителя зоны" (primary zone), и только он имеет возможность вносить изменения в файлах зоны (имеет право на запись). Остальные DNS сервера содержат только копию зоны и эта копия доступна только для чтения. Эти сервера называются "дополнительными носителями зоны" (secondary zone).

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

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

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

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

Но не путайте доменs DNS и домены Active Directory. Эти понятия не идентичны. В интернете   домен это  поддерево в пространстве доменных имен. Имя домена отражает положение и путь к сетевому устройству в системе DNS.  К примеру что бы дойти до хоста в каком либо домене интернета, допустим на комп komp1 в домене KONTORA.RK.COM, то есть его полное имя будет  komp1.KONTORA.RK.COM, мы должны проследовать сперва в домен COM, потом в домен RK.COM, потом в домен KONTORA.RK.COM и только тут мы можем найти интересующий нас хост. 

Мы говорим что: "хост принадлежит домену KONTORA.RK.COM и поэтому находиться там-то”. 

В отличие от доменов интернета, домены  Active Directory это некая область, объединяющая группу компьютеров(и других объектов), которые при работе в сети, при поиске доступных ресурсов,  ориентируется на единый справочник (Active Directory). Active Directory распространяет на эти компьютеры свою политику безопасности.

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

Мы говорим что: "компьютер принадлежит домену KONTORA.RK.COM и поэтому имеет доступ туда-то”

Типы запросов DNS.

Из всего изложенного материала понятно что DNS сервера взаимодействуют между собой для разрешения имени которого нам необходимо. Что представляет собой термин - "разрешение имени" мы с вами уже обсуждали в предыдущей статье. Напомню что процесс разрешения имени это когда к примеру, мы вводим в наш браузер какой либо адрес типа к примеру адрес данного сайта alterego.ucoz.org а служба DNS ставит в соответствии этому символьному адресу - IP-адрес. Дело в том что все устройства в интернете, да и локальной сети для того что бы общается между собой и обращается к друг другу используют на символьные имена, а IP -адреса типа 222.22.12.25. 

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

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

Так же как пространство доменных имен имеет свою иерархию, так же и DNS сервера образуют свою иерархию, и это понятно так как они являются хранителями доменных имен, и естественно подчиняются данной иерархии. Смотрите рисунок 2.

Рисунок 2. 

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

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

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

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

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

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

Наверно пора перейти непосредственно к типу запросов DNS. Существуют вообще дав типа запросов для разрешения доменных имен а именно:

• рекурсивные
• итерациаонные (итеративные)

Рассмотрим каждый тип или схему этих запросов в отдельности.

Рекурсивные запросы DNS.

В ответ на рекурсивный запрос (recursive query) DNS клиента - DNS сервер должен возвратить либо IP адрес данного имени либо сообщение о то что данное имя нельзя разрешить. В такой схеме запросов DNS сервер рекурсивно предпринимает попытки обнаружить так названые "ближайшие" серверы ("closest known" name servers). 

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

Рисунок 3.

Допустим нам нужно обратится к хосту WWW.RK.RU.. Мы еще раз "допустим" набираем в нашем браузере символьный адрес WWW.RK.RU. Браузер не знает адрес WWW.RK.RU и поэтому он попробует сам разрешить данное имя и просмотрит собственный кэш компа. Допустим там такого адреса нет. Тогда клиент обращается к услугам DNS сервера нашей сети для разрешении этого имени. Первое что делает  DNS сервер, это просматривает свой кэш и свою базу данных на наличие там необходимой информации.  Допустим и там необходимой информации нет. В этом случае DNS сервер обратится с запросом к корневому серверу (правильнее корневым серверам, так как серверов ответственные за корневой домен много). Сервер корневого домена не располагает информацией о запрашиваемом хосте но проанализировав адрес и найдя в нем окончание (в нашем случае RU - ответит на запрос ссылкой на DNS сервер ответственный за домен RU. Обращаясь к DNS серверам домена RU, в котором содержится информация о хостах домена RK.RU, наш DNS сервер получит информацию об IP - адресе необходимого хоста или сноску на DNS сервера ответственные домен RK.RU. Обратившись к DNS серверам RK.RU наш DNS сервер получит адрес хоста а именно  WWW.RK.RU который и передаст клиенту DNS. 

Итерационные запросы DNS

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

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

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

На рисунке 4 показан пример итерационного запроса. К примеру, допустим хост komp1.rk.ru должен соединится с  хостом pc1.yahoo.com.

Рисунок 4. 

Давайте по шагам рассмотрим что предпринимает DNS клиент для разрешения этого доменного имени.

1. Клиент DNS, в нашем случае хост komp1 просматривает собственный кэш. Допустим там он не нашел ничего так как связь с хостом pc1.yahoo.com осуществляется впервые. Далее он обращается к серверу DNS обслуживающий домен RK.RU (ближайший сервер DNS). Допустим и у того тоже нет информации в кэше и в базе данных о данном имени. В этом случае он возвращает клиенту ссылку на вышестоящий сервер DNS обслуживающий домен RU.
2. Получив эту ссылку клиент самостоятельно обращается с тем же запросом к серверу DNS обслуживающий домен RU. Допустим что и на этом сервере запрашиваемой информации нет и тогда он возвращает клиенту DNS  ссылку на корневой сервер DNS. Это на рисунке домен "." (точка).
3. Клиент получив эту ссылку обращается к коревому серверу DNS. Корневой сервер получив запрос и просмотрев его обнаруживает что запрос относится к домену COM. Он возвращает клиенту ссылку на домен COM. 
4. Снова клиент DNS  а именно в нашем случае сам хост komp1.rk.ru обращается к держателю имен домена COM. DNS сервер домена ком получив запрос и просмотрев его обнаруживает что запрос относится к домену yahoo. Он возвращает клиенту ссылку на DNS сервер домена yahoo.com. 
5. И снова сам клиент запрашивает уже сервер DNS  домена yahoo.com. И тут сервер DNS  домена  yahoo.com проанализировав запрос и свои данные, находит данное запрашиваемое имя. И возвращает клиенту IP адрес соответствующий данному имени.
6.  Дальше клиент связывается с необходимым хостом.