Различия между версиями 1 и 5 (по 4 версиям)
Версия 1 от 2008-07-03 22:03:24
Размер: 14831
Редактор: eSyr
Комментарий:
Версия 5 от 2008-07-04 13:23:24
Размер: 25395
Редактор: ArtemSerebriyskiy
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
В этом стеке протоклов (TCP/IP), который выглядит весьма естественным, существует такая определённсть на всех уровнях, кроме пследнего. То есть, на физ. уровне --- провод, на канальном --- езернетная дырка, на сетевм уровне --- идентификация и маршрутизация, на транспортном уровне --- транспортные протоколы. Поэтму на каждм уровне существует постижимое количество пртоколов, которые описывают, как решаются эти задачи. Когда же речь заходит об уровне прикладнм, то получается, что сколько у нас плоьзовательнских задач, то столько протоколов мы должны просмотреть. В /etc/services описаны зарегистирирванные нмера портв в формате имя порт/протокол #комментарий. Это ни каким образом нас не связывает на предмет того, чтбы расположить службу на нестандартном порту. Другой вопрос, что подключиться к немсу можно только зная порт. Ещё хуже, если сервис на каком-нибудь не своём стандартнм порту. Ещё что надо вспмнить с первого раза --- порт это понятие транспортного уровня, которое в случае прикладного уровня используется как вспомогательная информация. В этом стеке протоколов (TCP/IP), который выглядит весьма естественным образом , существует некая определённость на всех
уровнях, кроме последнего. А именно когда речь идет о решении задач физического уровня пользователь представляет себе некий
провод, когда речь идет о канальном- он же интерфейсный уровень мы себе представляем некое устройство при помощи которого
провод которое втыкается в компьютер и организуется некая логика передачи данных по этому проводу. Когда речь идет о о
сетевом уровне мы понимаем что вот есть две задачи - это идентификация всех абонентов сети и маршрутизация, когда речь идет
о транспортном уровне мы понимаем что решаем транспортные проблемы. Поэтому на каждом из этих уровней существует по
крайней мере умопостижимое количество разных протоколов- т.е. договоренностей о том как решаются задачи. Иногда этих
протоколов много,иногда их мало. На транспортном уровне их вроде бы всего 2-TCP и UDP. Когда же речь заходит об уровне
прикладном, то получается, что сколько у нас пользовательских задач, столько протоколов мы и должны просмотреть. В
/etc/services описаны примерно 600 зарегистрированных номеров портов в формате имя порт/протокол #комментарий. Когда мы
подключаемся к определенному порту мы ожидаем что с той стороны нас будет ожидать приложение, которое общается с нами по
тому протоколу, который указан в этом файле. Это ни каким образом нас не связывает на предмет того, чтобы расположить
службу на нестандартном порту,что делается довольно часто. Другой дело, что если например веб-сервер функционирует не на
стандартном порту- порту :80, то подключиться к нему можно только узнав номер этого порта. Ещё хуже, если сервис на
чьем-то чужом стандартном порте. Ещё что надо вспомнить с прошлого раза --- это что порт это понятие транспортного
уровня, которое в случае прикладного уровня используется как вспомогательная информация.
Строка 5: Строка 20:
Из всех служб, из всех программ, которые работают на прикладном уровне, существует как минимум одна сетевая служба, без которой работать очень тяжело. Эта служба называется DNS (Domain Name Service). В чём её смысл? В прошлый раз мы поговорили о том, как раздаются ip-адреса (есть иканн, рег. провайдеры, локальные, ...). Если посмотреть на технологию маршрутизации, то можноо увидеть, что структура сети с т. з. IP-адресов подчиняется топологии. Вот объединены несколько компьютеров в локальную сеть --- значит у них адреса из одной сети, если из разных сетей --- разные. Если какая-то организация получила 10 адресов из диапазона, а птом получила ещё 100, то, тем не менее, эти два диапазона могут быть совершенно разные, поскольку они отражают не тот факт, какая организция ими владеет, а то, какая часть интернета ими занята. Это очень неудобно с точки зрения социальной, мы не можем нормально сказать, чья же это сеть, что это за компьютеры, и так далее. Другая проблема в том, что человек довольно тяжело запоминает числа. Представьте себе, что мы ходили бы по интернету, используя IP-адреса. Мы бы озверели. Поэтому хочется решить две задачи: присвоить всем компьютерам имена и чтобы эти имена отражали административную структуру интернета, чтобы по имени было понятно, чей он. Более того, в качестве бонуса, сама процедура выдачи этих имён должна подчиняться этой административной структуре интернета. Какую задачу мы тем самым хотим решить? Как трудно решщить задачу нумерации, так трудно решить задачу именования, даже сложнее. Административная структура никак не подчиняется количеству лежащих проводов и таким вот вещам. Соответственн, пытаться создавать центарлизованную базу всех имён в интернете --- смерть на взлёте, такая база никогда не будет актуальна, к тому же нагрузка на эту базу будет феерическая. Поэтому возникла идея устроить не только процесс именования, но и процесс раздачи имён не с помощью одного хранилища, а пирамидально.
Строка 7: Строка 21:
Как это устроено. Существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети, и, более того, не обязаны этого знать. что они обязаны знать: какие есть зоны, состоящие из одного имени. Наприме, зона ru, com, info, de... Во-первых, они знают, какие имена первого уровня сущ. в принципе. Корневые сервера знают имена зон. Какие бывают окончания у доменных имён. Помимо этого, они знают ещё одну информацию: они ещё знают про каждую зону адрес того сервера, который знает про все поддомены зоны (nameserver). Из всех служб, из всех программ, которые работают на прикладном уровне- т.е. именно как программы-обработчики сетевых
запросов, существует как минимум одна сетевая служба, без которой работать очень тяжело, если вообще возможно. Эта служба
называется DNS (Domain Name Service). В чём её смысл? В прошлый раз мы поговорили о том, на каких условиях, как и кем
раздаются ip-адреса (есть ICAAN, региональные провайдеры, локальные, ...). Если посмотреть на технологию маршрутизации,
то можно увидеть, что структура сети с точки зрения IP-адресов строго подчиняется топологии. Вот объединены несколько
компьютеров в единую локальную сеть --- значит у них будут адреса из одной локальной сети, если два компьютера находятся в
разных локальных сетях --- значит у них будут существенно разные IP-адреса. Если какая-то организация сначала получила 10
адресов из диапазона, а затем ей оказалось мало и она получила ещё 100, то, тем не менее, эти два диапазона IP-адресов
вполне могут быть совершенно разные, поскольку они отражают не тот факт, какая конкретная организация ими владеет, а тот
факт, какая "часть" интернета ими занята, т.е. отражает топологию. Это очень неудобно с точки зрения социальной, мы не
можем нормально сказать,без дополнительной информации, а чья же это сеть, а что это за компьютеры, и так далее. Другая
проблема состоит в том, что человек довольно тяжело запоминает числа. Представьте себе, если бы мы ходили бы по браузеру
используя вместо имен сайтов четырехбайтные IP-адреса. Мы бы озверели. Поэтому хочется решить сразу две задачи: присвоить
всем компьютерам имена -чтобы ходить по именами , и вторая задача - чтобы эти имена отражали не топологическую структуру
интернета, а административную, чтобы по имени было понятно, какой организации он принадлежит. Более того, в качестве
бонуса,или даже в качестве решения этой проблемы сама процедура выдачи этих имён должна подчиняться этой административной
структуре интернета. Какую задачу мы тем самым хотим решить? Также как трудно решить задачу перенумерации, еще сложнее
решить задачу именования всех компьютеров в интернете. Сложнее потому что в отличии от перенумерации административная
структура никак не подчиняется количеству лежащих проводов и таким вот вещам. Соответственно, пытаться создавать
централизованную базу всех имён всех компьютеров в интернете --- смерть на взлёте, это очень сложно, и учитывая что
интернет испытывает сбои такая база никогда не будет актуальна - там будут устаревшие части и не будет вновь появившихся, к
тому же нагрузка на эту базу будет феерическая. Поэтому возникла идея устроить не только процесс именования, но и процесс
раздачи имён не с помощью одного хранилища, а пирамидально.
Строка 9: Строка 45:
Врезка: соответствие имени и ip-адреса. Вот у неас есть все ip-адреса в интернете. Когда их было 15, был такой файл под названием /etc/hosts, который содержал базу по всем именам компьютеров в интернете. Он содержал имена и ip-шники адресов. Один ip мог иметь несколько имён. К существующей схеме пришли не от хорошей жизни. Поскольку когда компьютеров стало много, оказалось, что администраторы хотят сами именовать свои компьютеры, и они не хотят скачивать постоянно /etc/hosts из одног места. Следовательно, нужно что-то, что пребравывает имя в ip. Так как такого файла нет, то нужна такая программа, а админстраторы имена будут каждый сам у себя назначать. Все подключения используют ip, а dns это приятная настройка, но без котрой нельзя. Соответственно задача: втобы было преобрахз и он контролировалось теми людьми, которые отвечают за этот компьютер. Как это устроено? Существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в
сети, и, более того, не обязаны этого знать. Что они обязаны знать? Они обязаны знать информацию о том какие есть зоны
состоящих из одного имени. Например, зона ru, com, info, de... Во-первых, они знают, о том какие имена первого уровня
существуют в принципе, поскольку их немного. Недавно их было совсем мало- в старых справочниках по интернету указывались
com, net,org,edu,gov и несколько зон связанных с государствами, по двух-буквенным кодам. В какой-то момент было принято
решение сильно расширить диапазон, а недавно приняли решение что там будет использоваться Юникод.
Строка 11: Строка 52:
Соответственно, у кажлого сервера условно говоря есть этот файл, но там не всё, а только корневые. ... Дальше происходит ровно так, как ... Если посмотреть в словаре слово домен, т оно появилось очень давно, и означает оно область владений вассала. Аналогично устроена доменная система --- "вассал моего вассала не мой вассал". Таким бразом, этот сервер, который отвечает за зну ru, отвечает только за те компюьтеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru, msu.ru. А если в имени больше составляющих, то уже дальше спршивается у msu.ru, а н уже обязан тветить, кто такой imap.cmc.msu.ru. Корневые сервера знают о наличии так называемых зон- а именно о том какие вообще бывают окончания у доменных имен. Но
помимо этого, они знают также ещё одну информацию: они ещё знают про каждую зону адреса тех серверов, который содержит
информацию про содержимое этих зон- т.е. про те компьютеры имена которых кончаются на окончание зоны. (nameserver).
Строка 13: Строка 56:
По сути, мы описали иерархисескую распределённую базу данных. Если мы пчитаем документацию к bind, то увидим, что это не просто база данных, то увидим, что там можно хранить что угодно, там есть различные текстовые поля. Врезка: соответствие имени и ip-адреса. Вот у нас есть все ip-адреса в интернете. Когда этих всех было штук 15, был такой
файл под названием /etc/hosts, который содержал базу по всем именам всех компьютеров во всем интернете. Его формат очень
простой- ip-адрес и имена ему соответствующие. Идея состоит в том что даже когда их всего 15 может так случиться что один
компьютер будет иметь несколько имен. Почему? Потому что он выступает в нескольких ипостасях- с одной стороны он компьютер
принадлежащий организации такой-то, а с другой стороны- компьютер участвующий в таком-то проекте. И соответственно если мы
хотим подключиться у этой организации мы вспомним что его имя связанно с именем организации, а если мы хотим подключиться
к проекту мы вспомним что его имя связанно с именем проекта. В данном случае мы видим что имена устроены весьма примитивно.
К существующей схеме пришли не от хорошей жизни. Поскольку когда компьютеров стало очень много, оказалось, что
администраторы каких-то сетей почему-то хотят сами именовать свои компьютеры, и вторая проблема- администраторы всех
компьютеров на свете почему то не хотят скачивать постоянно /etc/hosts из центрального места. Вот они сами пишут этот
/etc/hosts и он не совпадает у всех компьютеров в интернете. В какой-то момент до народа стало доходить что вообще файлом
/etc/hosts дело ограничиться не может и надо создать некую систему которая дела бы тоже самое: преобразовывала строковое
имя в числовой адрес и обратно. Но раз у нас нету этого файла то мы должны пойти к некой программе и сказать: преобразуй.
А тогда уже пришла в голову идея, что, поскольку администраторы сами раздают имена, то пуская они и дальше сами раздают,
но в своей области владения. Вот ты администрируешь какие-то компьютеры- вот ты им имена и выдаешь. Т.е. решается задача
1)преобразования доменных имен в адреса и обратно(поскольку все подключения по-прежнему осуществляются по IP-адресу , а
служба доменных имен- это всего лишь надстройка для удобства, а вовсе не необходимая сущность). Поэтому прежде чем
произойдет обмен данными между машинами, если в качестве ip-адреса указанно доменное имя, то необходимо сходить к DNS,
преобразовать это имя в ip и затем соединиться.
Строка 15: Строка 76:
Есть некая проблема, связанная с тем, чтбы добраться до ip, соотв. imap.cmc.msu.su. Неужели, каждый раз, когда нам пнадобиться, находясь в домене непнятно каком, как тлько нам потребуется зайти на факультетский почтовой сайт, нам птребуется напрягать корн. сервер? Оказывается, нам всё равно надо ходить на корневй сервер. Так вообще быть не должно. Для того, тчобы эту процедуру зделать более эффективной, есть три задумки, которые сильно облегчают нагрузку. Решение задачи состоит в том что у каждого системного администратора свой файл преобразования хостов и IP-адресов. Точнее
не файл, а специальная таблица. но эта таблица не от фонаря берется, а распределяется по вышеизложенной схеме.
Строка 17: Строка 79:
Улучшение номер раз состоит в том, что каждая запись соответствия ip-адреса доменнму имени содержит в себе инф. о том, в течение какого времени она действительна и может не меняться. То есть, если мы один раз выяснили, что адресу imap.cs.msu.ru соответствует адрес такой-т, т в течение этого самоого времени, в течение которог эта запись не может гарантированно меняться, мы можем эту запись закешировать. Каждая запись имеет время жизни (около недели), и время, в течение которого сдержимое считается актуальными. Это сильно снижает нагрузку, поскольку в первый раз происх. взаимод. по все цепочке, а в следующие разы время уже не истекло. И даже когда время актуальности истечёт, то можно всё равно пользоваться Возвращаемся к схеме. Итак у нас есть корневые серверы которые выдают ответ на вопрос довольно простого свойства-
во-первых существует ли в принципе такое имя(проверяя окончание) и если оно существует то где находиться сервер который
знает про имена с этими окончаниями. Он называется сервер доменных имен(nameserver)
Строка 19: Строка 83:
Второе. Чем больше в расп. системе узлов, тем ниже надёжность. Для борьбы с этим. исп. кэши. Ещё одно --- NS-сервреров длжно быть более одного. И желательно, чтобы у них ip очень разные. При этом для удобства адм. устр. такая штука, пользователю абсолютно всё равно, какой ему ответил. Вопрос: а как админ будет редактировать два файла на разных машинах? На самом деле среди этих машин естьглавная, но об этом знает только администратор. Но со стороны же они равноправны. Если посмотреть в словаре слово домен, то видно что оно появилось очень давно, и означает оно область владений феодального
вассала. Феодальная структура была устроена пирамидально и самое главное - принцип, который соблюдается и в DNS -принцип
"вассал моего вассала не мой вассал". Т.е. сервер отвечает за своих непосредственных подчиненных, и не отвечает за прямых
подчиненных, которые не являются непосредственными.Рассмотрим imap.cs.msu.ru. Таким образом, этот сервер, который отвечает
за зону ru, отвечает только за те компьютеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru,
msu.ru. А если в имени больше составляющих, то nameserver зоны ru не обязан знать ip адрес этого хоста. он может знать
его- случайно- но не обязан. А обязан он знать адрес nameserver'а msu.ru. Дальше спрашивается у msu.ru, а он уже обязан
ответить, кто такой cmc.msu.ru. И так далее. В итоге мы получим в ответ либо ip-адрес либо сообщение что такого домена
нету.
Строка 21: Строка 93:
Третий способ --- ограничение свободы обычного пользователя. Дело вот в чём: если вы обращаетесь к какому-то неймсерверу с запросом относительно преобр. ip-адреса, никакого отн. к этому серверу не имеющего, то он может ответить "не знаю". Такой запрос (на который можно получить ответ "не знаю") называется нерекурсивным. Друговй вриант: кгда вы обращаетесь к серверу с рекурсивным запросом, то неймсервер обращается к корневму и так далее. В итоге либо преобр. будет произв., либо нет такого имени, и ... . И в отличие от нерек. запроса, рек. запросы обычно разрешены только для своих машин. По сути, мы описали иерархическую распределённую базу данных. Если мы почитаем документацию к bind --- nameserver чаще
всего использующийся в Linux --- то увидим, что это не просто база данных, там можно хранить что угодно- любые текстовые
поля, любые поля соответствующие IP-адресам. Существует также некий RFC описывающий как хранить внутри текстовых полей
данные разного типа.
Строка 23: Строка 98:
В результате получается вот какая штука: далеко не все компьютеры могут посылать далеко не всем неймсерверам рек. запросы. Существует два уровня: какие-то неймсервера дверяют каким-то машинам, а остальным не доверяют. Есть некая проблема, связанная с тем, чтобы добраться до ip-адреса, соответствующего imap.cmc.msu.su. Неужели, каждый раз,
когда нам понадобиться, находясь в домене непонятно каком, зайти на факультетский почтовой сервер, нам потребуется
напрягать корневой сервер? Тогда зачем все это было придумано? Оказывается, для того чтобы узнать ip-адрес машины нам всё
равно надо ходить на корневой сервер. Как была база данных с единым узким местом, так и осталась. Так вообще быть не
должно. Для того, чтобы эту процедуру сделать более эффективной, есть три задумки, которые сильно облегчают нагрузку.

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

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

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

В результате получается вот какая штука: далеко не все компьютеры могут посылать далеко не всем NS-сервера рекурсивные
запросы. Как правило существует два уровня: существует некая группа адресов, которым доверяют и они могут посылать
рекурсивные запросы, а остальным нельзя.
Строка 31: Строка 142:
|| 0 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || || || 20 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || ||

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

В этом стеке протоколов (TCP/IP), который выглядит весьма естественным образом , существует некая определённость на всех уровнях, кроме последнего. А именно когда речь идет о решении задач физического уровня пользователь представляет себе некий провод, когда речь идет о канальном- он же интерфейсный уровень мы себе представляем некое устройство при помощи которого провод которое втыкается в компьютер и организуется некая логика передачи данных по этому проводу. Когда речь идет о о сетевом уровне мы понимаем что вот есть две задачи - это идентификация всех абонентов сети и маршрутизация, когда речь идет о транспортном уровне мы понимаем что решаем транспортные проблемы. Поэтому на каждом из этих уровней существует по крайней мере умопостижимое количество разных протоколов- т.е. договоренностей о том как решаются задачи. Иногда этих протоколов много,иногда их мало. На транспортном уровне их вроде бы всего 2-TCP и UDP. Когда же речь заходит об уровне прикладном, то получается, что сколько у нас пользовательских задач, столько протоколов мы и должны просмотреть. В /etc/services описаны примерно 600 зарегистрированных номеров портов в формате имя порт/протокол #комментарий. Когда мы подключаемся к определенному порту мы ожидаем что с той стороны нас будет ожидать приложение, которое общается с нами по тому протоколу, который указан в этом файле. Это ни каким образом нас не связывает на предмет того, чтобы расположить службу на нестандартном порту,что делается довольно часто. Другой дело, что если например веб-сервер функционирует не на стандартном порту- порту :80, то подключиться к нему можно только узнав номер этого порта. Ещё хуже, если сервис на чьем-то чужом стандартном порте. Ещё что надо вспомнить с прошлого раза --- это что порт это понятие транспортного уровня, которое в случае прикладного уровня используется как вспомогательная информация.

Из всех служб, из всех программ, которые работают на прикладном уровне- т.е. именно как программы-обработчики сетевых запросов, существует как минимум одна сетевая служба, без которой работать очень тяжело, если вообще возможно. Эта служба называется DNS (Domain Name Service). В чём её смысл? В прошлый раз мы поговорили о том, на каких условиях, как и кем раздаются ip-адреса (есть ICAAN, региональные провайдеры, локальные, ...). Если посмотреть на технологию маршрутизации, то можно увидеть, что структура сети с точки зрения IP-адресов строго подчиняется топологии. Вот объединены несколько компьютеров в единую локальную сеть --- значит у них будут адреса из одной локальной сети, если два компьютера находятся в разных локальных сетях --- значит у них будут существенно разные IP-адреса. Если какая-то организация сначала получила 10 адресов из диапазона, а затем ей оказалось мало и она получила ещё 100, то, тем не менее, эти два диапазона IP-адресов вполне могут быть совершенно разные, поскольку они отражают не тот факт, какая конкретная организация ими владеет, а тот факт, какая "часть" интернета ими занята, т.е. отражает топологию. Это очень неудобно с точки зрения социальной, мы не можем нормально сказать,без дополнительной информации, а чья же это сеть, а что это за компьютеры, и так далее. Другая проблема состоит в том, что человек довольно тяжело запоминает числа. Представьте себе, если бы мы ходили бы по браузеру используя вместо имен сайтов четырехбайтные IP-адреса. Мы бы озверели. Поэтому хочется решить сразу две задачи: присвоить всем компьютерам имена -чтобы ходить по именами , и вторая задача - чтобы эти имена отражали не топологическую структуру интернета, а административную, чтобы по имени было понятно, какой организации он принадлежит. Более того, в качестве бонуса,или даже в качестве решения этой проблемы сама процедура выдачи этих имён должна подчиняться этой административной структуре интернета. Какую задачу мы тем самым хотим решить? Также как трудно решить задачу перенумерации, еще сложнее решить задачу именования всех компьютеров в интернете. Сложнее потому что в отличии от перенумерации административная структура никак не подчиняется количеству лежащих проводов и таким вот вещам. Соответственно, пытаться создавать централизованную базу всех имён всех компьютеров в интернете --- смерть на взлёте, это очень сложно, и учитывая что интернет испытывает сбои такая база никогда не будет актуальна - там будут устаревшие части и не будет вновь появившихся, к тому же нагрузка на эту базу будет феерическая. Поэтому возникла идея устроить не только процесс именования, но и процесс раздачи имён не с помощью одного хранилища, а пирамидально.

Как это устроено? Существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети, и, более того, не обязаны этого знать. Что они обязаны знать? Они обязаны знать информацию о том какие есть зоны состоящих из одного имени. Например, зона ru, com, info, de... Во-первых, они знают, о том какие имена первого уровня существуют в принципе, поскольку их немного. Недавно их было совсем мало- в старых справочниках по интернету указывались com, net,org,edu,gov и несколько зон связанных с государствами, по двух-буквенным кодам. В какой-то момент было принято решение сильно расширить диапазон, а недавно приняли решение что там будет использоваться Юникод.

Корневые сервера знают о наличии так называемых зон- а именно о том какие вообще бывают окончания у доменных имен. Но помимо этого, они знают также ещё одну информацию: они ещё знают про каждую зону адреса тех серверов, который содержит информацию про содержимое этих зон- т.е. про те компьютеры имена которых кончаются на окончание зоны. (nameserver).

Врезка: соответствие имени и ip-адреса. Вот у нас есть все ip-адреса в интернете. Когда этих всех было штук 15, был такой файл под названием /etc/hosts, который содержал базу по всем именам всех компьютеров во всем интернете. Его формат очень простой- ip-адрес и имена ему соответствующие. Идея состоит в том что даже когда их всего 15 может так случиться что один компьютер будет иметь несколько имен. Почему? Потому что он выступает в нескольких ипостасях- с одной стороны он компьютер принадлежащий организации такой-то, а с другой стороны- компьютер участвующий в таком-то проекте. И соответственно если мы хотим подключиться у этой организации мы вспомним что его имя связанно с именем организации, а если мы хотим подключиться к проекту мы вспомним что его имя связанно с именем проекта. В данном случае мы видим что имена устроены весьма примитивно. К существующей схеме пришли не от хорошей жизни. Поскольку когда компьютеров стало очень много, оказалось, что администраторы каких-то сетей почему-то хотят сами именовать свои компьютеры, и вторая проблема- администраторы всех компьютеров на свете почему то не хотят скачивать постоянно /etc/hosts из центрального места. Вот они сами пишут этот /etc/hosts и он не совпадает у всех компьютеров в интернете. В какой-то момент до народа стало доходить что вообще файлом /etc/hosts дело ограничиться не может и надо создать некую систему которая дела бы тоже самое: преобразовывала строковое имя в числовой адрес и обратно. Но раз у нас нету этого файла то мы должны пойти к некой программе и сказать: преобразуй. А тогда уже пришла в голову идея, что, поскольку администраторы сами раздают имена, то пуская они и дальше сами раздают, но в своей области владения. Вот ты администрируешь какие-то компьютеры- вот ты им имена и выдаешь. Т.е. решается задача 1)преобразования доменных имен в адреса и обратно(поскольку все подключения по-прежнему осуществляются по IP-адресу , а служба доменных имен- это всего лишь надстройка для удобства, а вовсе не необходимая сущность). Поэтому прежде чем произойдет обмен данными между машинами, если в качестве ip-адреса указанно доменное имя, то необходимо сходить к DNS, преобразовать это имя в ip и затем соединиться.

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

Возвращаемся к схеме. Итак у нас есть корневые серверы которые выдают ответ на вопрос довольно простого свойства- во-первых существует ли в принципе такое имя(проверяя окончание) и если оно существует то где находиться сервер который знает про имена с этими окончаниями. Он называется сервер доменных имен(nameserver)

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

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

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

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

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

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

В результате получается вот какая штука: далеко не все компьютеры могут посылать далеко не всем NS-сервера рекурсивные запросы. Как правило существует два уровня: существует некая группа адресов, которым доверяют и они могут посылать рекурсивные запросы, а остальным нельзя.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov


PspoClasses/080703/01DNSTheory (последним исправлял пользователь eSyr 2008-10-10 00:15:58)