PspoClasses/080703/01DNSTheory

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

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

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

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

Врезка: соответствие имени и ip-адреса. Вот у неас есть все ip-адреса в интернете. Когда их было 15, был такой файл под названием /etc/hosts, который содержал базу по всем именам компьютеров в интернете. Он содержал имена и ip-шники адресов. Один ip мог иметь несколько имён. К существующей схеме пришли не от хорошей жизни. Поскольку когда компьютеров стало много, оказалось, что администраторы хотят сами именовать свои компьютеры, и они не хотят скачивать постоянно /etc/hosts из одног места. Следовательно, нужно что-то, что пребравывает имя в ip. Так как такого файла нет, то нужна такая программа, а админстраторы имена будут каждый сам у себя назначать. Все подключения используют ip, а dns это приятная настройка, но без котрой нельзя. Соответственно задача: втобы было преобрахз и он контролировалось теми людьми, которые отвечают за этот компьютер.

Соответственно, у кажлого сервера условно говоря есть этот файл, но там не всё, а только корневые. ... Дальше происходит ровно так, как ... Если посмотреть в словаре слово домен, т оно появилось очень давно, и означает оно область владений вассала. Аналогично устроена доменная система --- "вассал моего вассала не мой вассал". Таким бразом, этот сервер, который отвечает за зну ru, отвечает только за те компюьтеры, которые имеют двусложные имена, оканчивающиеся на ru, например, www.ru, msu.ru. А если в имени больше составляющих, то уже дальше спршивается у msu.ru, а н уже обязан тветить, кто такой imap.cmc.msu.ru.

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

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

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

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

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

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

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