Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2008-07-03 19:03:24
Size: 14831
Editor: eSyr
Comment:
Revision 18 as of 2008-07-13 14:13:24
Size: 23388
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
В этом стеке протоклов (TCP/IP), который выглядит весьма естественным, существует такая определённсть на всех уровнях, кроме пследнего. То есть, на физ. уровне --- провод, на канальном --- езернетная дырка, на сетевм уровне --- идентификация и маршрутизация, на транспортном уровне --- транспортные протоколы. Поэтму на каждм уровне существует постижимое количество пртоколов, которые описывают, как решаются эти задачи. Когда же речь заходит об уровне прикладнм, то получается, что сколько у нас плоьзовательнских задач, то столько протоколов мы должны просмотреть. В /etc/services описаны зарегистирирванные нмера портв в формате имя порт/протокол #комментарий. Это ни каким образом нас не связывает на предмет того, чтбы расположить службу на нестандартном порту. Другой вопрос, что подключиться к немсу можно только зная порт. Ещё хуже, если сервис на каком-нибудь не своём стандартнм порту. Ещё что надо вспмнить с первого раза --- порт это понятие транспортного уровня, которое в случае прикладного уровня используется как вспомогательная информация. ''Примечание: про DNS нужна пара картинок. VsevolodKrishchenko''
Line 5: Line 5:
Из всех служб, из всех программ, которые работают на прикладном уровне, существует как минимум одна сетевая служба, без которой работать очень тяжело. Эта служба называется DNS (Domain Name Service). В чём её смысл? В прошлый раз мы поговорили о том, как раздаются ip-адреса (есть иканн, рег. провайдеры, локальные, ...). Если посмотреть на технологию маршрутизации, то можноо увидеть, что структура сети с т. з. IP-адресов подчиняется топологии. Вот объединены несколько компьютеров в локальную сеть --- значит у них адреса из одной сети, если из разных сетей --- разные. Если какая-то организация получила 10 адресов из диапазона, а птом получила ещё 100, то, тем не менее, эти два диапазона могут быть совершенно разные, поскольку они отражают не тот факт, какая организция ими владеет, а то, какая часть интернета ими занята. Это очень неудобно с точки зрения социальной, мы не можем нормально сказать, чья же это сеть, что это за компьютеры, и так далее. Другая проблема в том, что человек довольно тяжело запоминает числа. Представьте себе, что мы ходили бы по интернету, используя IP-адреса. Мы бы озверели. Поэтому хочется решить две задачи: присвоить всем компьютерам имена и чтобы эти имена отражали административную структуру интернета, чтобы по имени было понятно, чей он. Более того, в качестве бонуса, сама процедура выдачи этих имён должна подчиняться этой административной структуре интернета. Какую задачу мы тем самым хотим решить? Как трудно решщить задачу нумерации, так трудно решить задачу именования, даже сложнее. Административная структура никак не подчиняется количеству лежащих проводов и таким вот вещам. Соответственн, пытаться создавать центарлизованную базу всех имён в интернете --- смерть на взлёте, такая база никогда не будет актуальна, к тому же нагрузка на эту базу будет феерическая. Поэтому возникла идея устроить не только процесс именования, но и процесс раздачи имён не с помощью одного хранилища, а пирамидально. === Назначение службы доменных имен DNS ===
Line 7: Line 7:
Как это устроено. Существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети, и, более того, не обязаны этого знать. что они обязаны знать: какие есть зоны, состоящие из одного имени. Наприме, зона ru, com, info, de... Во-первых, они знают, какие имена первого уровня сущ. в принципе. Корневые сервера знают имена зон. Какие бывают окончания у доменных имён. Помимо этого, они знают ещё одну информацию: они ещё знают про каждую зону адрес того сервера, который знает про все поддомены зоны (nameserver). Из всех многочисленных сетевых служб, работающих на прикладном уровне и обрабатывающие сетевые запросы клиентов, существует одна без которой и всем остальным работать очень тяжело, если вообще возможно. Эта служба называется DNS (''Domain Name Service'' --- служба доменных имен).
Line 9: Line 9:
Врезка: соответствие имени и ip-адреса. Вот у неас есть все ip-адреса в интернете. Когда их было 15, был такой файл под названием /etc/hosts, который содержал базу по всем именам компьютеров в интернете. Он содержал имена и ip-шники адресов. Один ip мог иметь несколько имён. К существующей схеме пришли не от хорошей жизни. Поскольку когда компьютеров стало много, оказалось, что администраторы хотят сами именовать свои компьютеры, и они не хотят скачивать постоянно /etc/hosts из одног места. Следовательно, нужно что-то, что пребравывает имя в ip. Так как такого файла нет, то нужна такая программа, а админстраторы имена будут каждый сам у себя назначать. Все подключения используют ip, а dns это приятная настройка, но без котрой нельзя. Соответственно задача: втобы было преобрахз и он контролировалось теми людьми, которые отвечают за этот компьютер. Рассмотрим, чём назначение службы имен. В прошлый раз мы говорили о том, на каких условиях, как и кем раздаются ip-адреса (ICAAN, региональные провайдеры, локальные, и т.д.). Если посмотреть на технологию маршрутизации, то можно увидеть, что структура сети с точки зрения IP-адресов строго подчиняется топологии: если несколько компьютеров объединены в единую локальную сеть, то у них будет одинаковый адрес сети, а если компьютеры находятся в разных локальных сетях,то у них будут различающиеся IP-адреса в части адреса сети. Если какая-нибудь организация сначала получила десять адресов из диапазона, а затем ей оказалось этого мало и она получила ещё сто, то, тем не менее, эти два диапазона IP-адресов вполне могут быть совершенно разными, поскольку они отражают не тот факт, какая конкретная организация ими владеет, а тот факт, какая "часть" интернета ими занята, т.е. топологию.
Line 11: Line 11:
Соответственно, у кажлого сервера условно говоря есть этот файл, но там не всё, а только корневые. ... Дальше происходит ровно так, как ... Если посмотреть в словаре слово домен, т оно появилось очень давно, и означает оно область владений вассала. Аналогично устроена доменная система --- "вассал моего вассала не мой вассал". Таким бразом, этот сервер, который отвечает за зну ru, отвечает только за те компюьтеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru, msu.ru. А если в имени больше составляющих, то уже дальше спршивается у msu.ru, а н уже обязан тветить, кто такой imap.cmc.msu.ru. Это очень неудобно с социальной точки зрения, так как мы не можем без дополнительной информации ответить на вопрос о том, чья же сеть перед нами, что это за компьютеры, и так далее. Другая проблема состоит в том, что человек довольно тяжело запоминает числа. Представьте себе, если бы мы набирали в браузере вместо имен сайтов четырехбайтные IP-адреса. Это крайне неудобно. Поэтому хочется решить сразу две задачи: присвоить всем компьютерам имена, чтобы идентифицировать их ими, и так составить эти имена, чтобы отражали не топологическую структуру интернета, а административную, то есть чтобы по имени компьютера было понятно, какой организации он принадлежит. Более того, было бы естественно, если бы сама процедура выдачи этих имён должна подчиняться административной структуре интернета.
Line 13: Line 13:
По сути, мы описали иерархисескую распределённую базу данных. Если мы пчитаем документацию к bind, то увидим, что это не просто база данных, то увидим, что там можно хранить что угодно, там есть различные текстовые поля. Задача именования всех компьютеров в интернете сложнее, чем задача их перенумерации. Сложнее потому, что в отличии от перенумерации административная структура никак не подчиняется физическим аспектам сети. Соответственно, пытаться создавать централизованную базу всех имён всех компьютеров в интернете, как было на заре возникновения интернета, --- это шаг в заведомо неверном направлении, так как это очень сложно, и учитывая, что интернет испытывает сбои, такая база никогда не будет актуальна --- там будут устаревшие части и не будет вновь появившихся, к тому же нагрузка на эту базу будет слишком высокой. Поэтому возникла идея устроить не только процесс именования, но и процесс раздачи имён не с помощью единого хранилища, а в виде древовидно организованного распределенного хранилища.
Line 15: Line 15:
Есть некая проблема, связанная с тем, чтбы добраться до ip, соотв. imap.cmc.msu.su. Неужели, каждый раз, когда нам пнадобиться, находясь в домене непнятно каком, как тлько нам потребуется зайти на факультетский почтовой сайт, нам птребуется напрягать корн. сервер? Оказывается, нам всё равно надо ходить на корневй сервер. Так вообще быть не должно. Для того, тчобы эту процедуру зделать более эффективной, есть три задумки, которые сильно облегчают нагрузку. Необходимо подчеркнуть, что все подключения по-прежнему осуществляются по IP-адресу , а служба доменных имен --- это всего лишь надстройка для удобства, хотя и очень полезная, но в теории не необходимая. Поэтому прежде чем произойдет обмен данными между машинами, если в качестве адреса машины указанно доменное имя, то необходимо преобразовать это имя в IP-адрес и затем соединиться. Преобразование происходит сначала по файлу {{{/etc/hosts}}}, а затем запросом службы DNS, как будет рассказано далее.
Line 17: Line 17:
Улучшение номер раз состоит в том, что каждая запись соответствия ip-адреса доменнму имени содержит в себе инф. о том, в течение какого времени она действительна и может не меняться. То есть, если мы один раз выяснили, что адресу imap.cs.msu.ru соответствует адрес такой-т, т в течение этого самоого времени, в течение которог эта запись не может гарантированно меняться, мы можем эту запись закешировать. Каждая запись имеет время жизни (около недели), и время, в течение которого сдержимое считается актуальными. Это сильно снижает нагрузку, поскольку в первый раз происх. взаимод. по все цепочке, а в следующие разы время уже не истекло. И даже когда время актуальности истечёт, то можно всё равно пользоваться === История возникновения DNS ===
Line 19: Line 19:
Второе. Чем больше в расп. системе узлов, тем ниже надёжность. Для борьбы с этим. исп. кэши. Ещё одно --- NS-сервреров длжно быть более одного. И желательно, чтобы у них ip очень разные. При этом для удобства адм. устр. такая штука, пользователю абсолютно всё равно, какой ему ответил. Вопрос: а как админ будет редактировать два файла на разных машинах? На самом деле среди этих машин естьглавная, но об этом знает только администратор. Но со стороны же они равноправны. Важное добавление: соответствие имени и ip-адреса. Во времена, когда адресов в интернете было где-то около 15, существовал файл под названием {{{/etc/hosts}}}, который содержал базу данных по всем именам этих адресов. Его формат очень простой --- IP-адрес и имена, ему соответствующие (файл это используется и сейчас, но обычно хранит только имена самого компьютера).
Line 21: Line 21:
Третий способ --- ограничение свободы обычного пользователя. Дело вот в чём: если вы обращаетесь к какому-то неймсерверу с запросом относительно преобр. ip-адреса, никакого отн. к этому серверу не имеющего, то он может ответить "не знаю". Такой запрос (на который можно получить ответ "не знаю") называется нерекурсивным. Друговй вриант: кгда вы обращаетесь к серверу с рекурсивным запросом, то неймсервер обращается к корневму и так далее. В итоге либо преобр. будет произв., либо нет такого имени, и ... . И в отличие от нерек. запроса, рек. запросы обычно разрешены только для своих машин. Идея состоит в том, что даже когда компьютеров всего несколько десятков, может так случиться, что один компьютер будет иметь несколько имен. Почему? Потому что он может выступать в нескольких ипостасях --- с одной стороны это компьютер, принадлежащий какой-либо организации, а с другой стороны, к примеру --- компьютер, участвующий в таком-то проекте. И соответственно, если мы хотим подключиться к этой организации, мы вспомним, что его имя связано с именем организации, а если мы хотим подключиться к проекту --- что его имя связанно с именем проекта. В данном случае мы видим, что имена устроены весьма примитивно. К существующей схеме пришли не от хорошей жизни. Когда компьютеров стало очень много, то:
Line 23: Line 23:
В результате получается вот какая штука: далеко не все компьютеры могут посылать далеко не всем неймсерверам рек. запросы. Существует два уровня: какие-то неймсервера дверяют каким-то машинам, а остальным не доверяют.  * во-первых, оказалось, что администраторы сетей почему-то хотят сами именовать свои компьютеры;
 * во-вторых --- администраторы всех компьютеров на свете почему-то не хотят скачивать постоянно /etc/hosts из центрального хранилища, предпочитая писать /etc/hosts собственноручно, и он, естественно, не совпадает у всех компьютеров в интернете.

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

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

=== Организация системы доменных имен ===

Мировая система доменных имен организована следующим образом: существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети (и, более того, не обязаны этого знать). Вместо этого они содержат информацию о так называемых зонах DNS, состоящих из одного имени. Например, существуют зоны ru, com, info, de и так далее. Во-первых, они знают о том, какие имена первого уровня существуют в принципе, поскольку их относительно немного. Недавно их было совсем мало --- в старых справочниках по интернету указывались только com, net, org, edu, gov и еще несколько зон, связанных с государствами, по двух-буквенным кодам. В какой-то момент было принято решение сильно расширить диапазон, а недавно приняли решение, что для записи имен зон будет использоваться кодировка юникод, что позволит создать имена зон на национальных алфавитах.

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

Если посмотреть в словаре слово домен, мы узнаем, что оно появилось очень давно, и означает оно область владений феодального вассала. Феодальная структура была устроена пирамидально и самое главное - по принципу (соблюденному и в DNS) "вассал моего вассала --- не мой вассал". Т.е. сервер отвечает за своих непосредственных подчиненных, и не отвечает за прямых подчиненных, которые не являются непосредственными. Рассмотрим имя imap.cs.msu.ru. Сервер, который отвечает за зону ru, отвечает только за те компьютеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru, msu.ru. А если в имени больше составляющих, то nameserver зоны ru не обязан знать ip адрес этого хоста (хотя он может и хранить его в силу разных причин). Но он обязан знать адрес nameserver'а msu.ru. Дальше запрашивается msu.ru, а он уже обязан ответить, кто такой cmc.msu.ru, и так далее. В итоге мы получим в ответ либо ip-адрес, либо сообщение о том, что такого домена нету.

По сути, мы описали иерархическую распределённую базу данных. Если мы почитаем документацию к bind (сервер имен, часто использующийся в Linux),то увидим, что это не просто база данных, ведь там можно хранить что угодно --- любые текстовые поля, любые поля, соответствующие IP-адресам. Существует также RFC, описывающий, как хранить внутри текстовых полей данные разного типа.

=== Производительность и надежность системы доменных имен ===

Есть некая проблема, связанная с тем, чтобы добраться до IP-адреса, соответствующего imap.cmc.msu.su. Неужели, каждый раз, когда нам понадобится, находясь в каком-то другом домене, зайти на факультетский почтовой сервер, потребуется запрашивать корневой сервер? Тогда зачем все это было придумано, ведь число запросов на корневые сервера будет по прежнему огромно? Поэтому для того, чтобы эту процедуру сделать более эффективной, есть три идеи, которые сильно облегчают нагрузку.

 1. Каждая таблица с записью соответствия IP-адреса доменному имени содержит в себе информацию. о том, в течение какого времени эта таблица, во-первых, действительна, а в-вторых, может не меняться, то есть ее время жизни и задержка на изменение. Таким образом, если мы один раз выяснили, что имени imap.cs.msu.ru соответствует некий адрес, то в течение времени задержки на изменение --- т.е. времени, в течении которого эта запись гарантированно не будет меняться --- мы можем эту запись поместить в кеш доменных имен и не обращаться за ним к серверам имен в дальнейшем. Каждая такая таблица имеет свое время жизни (около недели), и время, в течение которого содержимое считается актуальным. Это сильно снижает нагрузку, поскольку в первый раз происходит взаимодействие по всей иерархии DNS, а в следующие разы взаимодействия не происходит, пока время задержки на изменение еще не истекло. И даже когда время актуальности истечёт, то возможно, что не будет происходить все преобразование имени, а произойдет всего лишь запрос вышестоящему серверу имен, не обновились ли данные у него. И если он отвечает "нет", то записью можно пользоваться дальше.

 2. Чем больше в распределенной системе узлов, тем ниже совокупная надёжность самой системы. Для борьбы с этим тоже годится использование кеширования. Сильно повышает надежность требование, чтобы NS-серверов было более одного. И желательно, чтобы у них были существенно разные IP-адреса, например в разных сетях класса B. При этом для удобства администратора система устраивается так, что пользователю было абсолютно всё равно, какой из NS-серверов ему ответил. Все NS-сервера равноправны. Вопрос: а как несчастный администратор будет редактировать файлы сразу на двух машинах, которые лежат в абсолютно разных местах интернета? Ответ: На самом деле среди этих машин есть главная, но об этом знает только администратор, и обычно он редактирует файл только на ней, а остальные просто скачивают с нее.

 3. Некоторое ограничение свободы обычного пользователя. Дело вот в чём: если вы обращаетесь к какому-либо NS-серверу с запросом относительно преобразования IP-адреса, никакого отношения к домену, за который отвечает этот сервер, не имеющего, то он имеет право ответить "не знаю". Такой запрос (на который можно получить ответ "не знаю") называется нерекурсивным. Все DNS-сервера в сети отвечают на нерекурсивные запросы. Другой вариант: когда вы обращаетесь к серверу с т.н. рекурсивным запросом, тогда NS-сервер самостоятельно обращается к корневому и так далее. В итоге либо преобразование будет произведено, либо вам ответят, что нет такого имени, либо вам ответят, что время запроса превысило лимит. И в отличие от нерекурсивного запроса, рекурсивные запросы обычно разрешены только для "своих" машин, т.е. решение, удовлетворяет ли сервер рекурсивные запросы или нет, принимает системный администратор этого сервера. В результате получается так, что далеко не все компьютеры могут посылать далеко не всем NS-серверам рекурсивные запросы. Как правило существует два уровня: существует некая группа адресов, которым доверяют и они могут посылать рекурсивные запросы, а остальным нельзя.

Таким образом, конечные пользователи обычно работают с кеширующим сервером имен, расположенном в локальном сети, который, в свою очередь, передает рекурсивные запросы к кеширующему серверу имен провайдера.
Line 31: Line 58:
|| 0  || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || || || 70 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov + ОльгаТочилкина, VsevolodKrishchenko|| || ||

Преобразование имён и IP-адресов: теория

Примечание: про DNS нужна пара картинок. VsevolodKrishchenko

Назначение службы доменных имен DNS

Из всех многочисленных сетевых служб, работающих на прикладном уровне и обрабатывающие сетевые запросы клиентов, существует одна без которой и всем остальным работать очень тяжело, если вообще возможно. Эта служба называется DNS (Domain Name Service --- служба доменных имен).

Рассмотрим, чём назначение службы имен. В прошлый раз мы говорили о том, на каких условиях, как и кем раздаются ip-адреса (ICAAN, региональные провайдеры, локальные, и т.д.). Если посмотреть на технологию маршрутизации, то можно увидеть, что структура сети с точки зрения IP-адресов строго подчиняется топологии: если несколько компьютеров объединены в единую локальную сеть, то у них будет одинаковый адрес сети, а если компьютеры находятся в разных локальных сетях,то у них будут различающиеся IP-адреса в части адреса сети. Если какая-нибудь организация сначала получила десять адресов из диапазона, а затем ей оказалось этого мало и она получила ещё сто, то, тем не менее, эти два диапазона IP-адресов вполне могут быть совершенно разными, поскольку они отражают не тот факт, какая конкретная организация ими владеет, а тот факт, какая "часть" интернета ими занята, т.е. топологию.

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

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

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

История возникновения DNS

Важное добавление: соответствие имени и ip-адреса. Во времена, когда адресов в интернете было где-то около 15, существовал файл под названием /etc/hosts, который содержал базу данных по всем именам этих адресов. Его формат очень простой --- IP-адрес и имена, ему соответствующие (файл это используется и сейчас, но обычно хранит только имена самого компьютера).

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

  • во-первых, оказалось, что администраторы сетей почему-то хотят сами именовать свои компьютеры;
  • во-вторых --- администраторы всех компьютеров на свете почему-то не хотят скачивать постоянно /etc/hosts из центрального хранилища, предпочитая писать /etc/hosts собственноручно, и он, естественно, не совпадает у всех компьютеров в интернете.

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

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

Организация системы доменных имен

Мировая система доменных имен организована следующим образом: существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети (и, более того, не обязаны этого знать). Вместо этого они содержат информацию о так называемых зонах DNS, состоящих из одного имени. Например, существуют зоны ru, com, info, de и так далее. Во-первых, они знают о том, какие имена первого уровня существуют в принципе, поскольку их относительно немного. Недавно их было совсем мало --- в старых справочниках по интернету указывались только com, net, org, edu, gov и еще несколько зон, связанных с государствами, по двух-буквенным кодам. В какой-то момент было принято решение сильно расширить диапазон, а недавно приняли решение, что для записи имен зон будет использоваться кодировка юникод, что позволит создать имена зон на национальных алфавитах.

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

Если посмотреть в словаре слово домен, мы узнаем, что оно появилось очень давно, и означает оно область владений феодального вассала. Феодальная структура была устроена пирамидально и самое главное - по принципу (соблюденному и в DNS) "вассал моего вассала --- не мой вассал". Т.е. сервер отвечает за своих непосредственных подчиненных, и не отвечает за прямых подчиненных, которые не являются непосредственными. Рассмотрим имя imap.cs.msu.ru. Сервер, который отвечает за зону ru, отвечает только за те компьютеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru, msu.ru. А если в имени больше составляющих, то nameserver зоны ru не обязан знать ip адрес этого хоста (хотя он может и хранить его в силу разных причин). Но он обязан знать адрес nameserver'а msu.ru. Дальше запрашивается msu.ru, а он уже обязан ответить, кто такой cmc.msu.ru, и так далее. В итоге мы получим в ответ либо ip-адрес, либо сообщение о том, что такого домена нету.

По сути, мы описали иерархическую распределённую базу данных. Если мы почитаем документацию к bind (сервер имен, часто использующийся в Linux),то увидим, что это не просто база данных, ведь там можно хранить что угодно --- любые текстовые поля, любые поля, соответствующие IP-адресам. Существует также RFC, описывающий, как хранить внутри текстовых полей данные разного типа.

Производительность и надежность системы доменных имен

Есть некая проблема, связанная с тем, чтобы добраться до IP-адреса, соответствующего imap.cmc.msu.su. Неужели, каждый раз, когда нам понадобится, находясь в каком-то другом домене, зайти на факультетский почтовой сервер, потребуется запрашивать корневой сервер? Тогда зачем все это было придумано, ведь число запросов на корневые сервера будет по прежнему огромно? Поэтому для того, чтобы эту процедуру сделать более эффективной, есть три идеи, которые сильно облегчают нагрузку.

  1. Каждая таблица с записью соответствия IP-адреса доменному имени содержит в себе информацию. о том, в течение какого времени эта таблица, во-первых, действительна, а в-вторых, может не меняться, то есть ее время жизни и задержка на изменение. Таким образом, если мы один раз выяснили, что имени imap.cs.msu.ru соответствует некий адрес, то в течение времени задержки на изменение --- т.е. времени, в течении которого эта запись гарантированно не будет меняться --- мы можем эту запись поместить в кеш доменных имен и не обращаться за ним к серверам имен в дальнейшем. Каждая такая таблица имеет свое время жизни (около недели), и время, в течение которого содержимое считается актуальным. Это сильно снижает нагрузку, поскольку в первый раз происходит взаимодействие по всей иерархии DNS, а в следующие разы взаимодействия не происходит, пока время задержки на изменение еще не истекло. И даже когда время актуальности истечёт, то возможно, что не будет происходить все преобразование имени, а произойдет всего лишь запрос вышестоящему серверу имен, не обновились ли данные у него. И если он отвечает "нет", то записью можно пользоваться дальше.
  2. Чем больше в распределенной системе узлов, тем ниже совокупная надёжность самой системы. Для борьбы с этим тоже годится использование кеширования. Сильно повышает надежность требование, чтобы NS-серверов было более одного. И желательно, чтобы у них были существенно разные IP-адреса, например в разных сетях класса B. При этом для удобства администратора система устраивается так, что пользователю было абсолютно всё равно, какой из NS-серверов ему ответил. Все NS-сервера равноправны. Вопрос: а как несчастный администратор будет редактировать файлы сразу на двух машинах, которые лежат в абсолютно разных местах интернета? Ответ: На самом деле среди этих машин есть главная, но об этом знает только администратор, и обычно он редактирует файл только на ней, а остальные просто скачивают с нее.
  3. Некоторое ограничение свободы обычного пользователя. Дело вот в чём: если вы обращаетесь к какому-либо NS-серверу с запросом относительно преобразования IP-адреса, никакого отношения к домену, за который отвечает этот сервер, не имеющего, то он имеет право ответить "не знаю". Такой запрос (на который можно получить ответ "не знаю") называется нерекурсивным. Все DNS-сервера в сети отвечают на нерекурсивные запросы. Другой вариант: когда вы обращаетесь к серверу с т.н. рекурсивным запросом, тогда NS-сервер самостоятельно обращается к корневому и так далее. В итоге либо преобразование будет произведено, либо вам ответят, что нет такого имени, либо вам ответят, что время запроса превысило лимит. И в отличие от нерекурсивного запроса, рекурсивные запросы обычно разрешены только для "своих" машин, т.е. решение, удовлетворяет ли сервер рекурсивные запросы или нет, принимает системный администратор этого сервера. В результате получается так, что далеко не все компьютеры могут посылать далеко не всем NS-серверам рекурсивные запросы. Как правило существует два уровня: существует некая группа адресов, которым доверяют и они могут посылать рекурсивные запросы, а остальным нельзя.

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

70

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov + ОльгаТочилкина, VsevolodKrishchenko


PspoClasses/080703/01DNSTheory (last edited 2008-10-09 21:15:58 by eSyr)