Материал из eSyr's wiki.

• Диктофонная запись: http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_12_03.ogg

[править] Лекция

[править] Вступление

Сегодня прикладной уровень TCP/IP в Linux.

Первое — DNS.

В прошлый раз мы закончили на том, как самому написать сетевой сервер.

Тема, которую лектор не затронет — RPC.

Казалось бы, мы обсудили весь функционал в linux для работы с сетью, тем не менее, есть одна базовая система, без правильной настройки которой ей пользоваться трудно.

[править] Проблема

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

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

У этой архитектуры есть три недостатка:

• IP адрес — такая штука, которую сложно запомнить. Один можно запомнить, а вот сотню адресов сложно. Эта задача решалась, и очень простым способом: есть /etc/hosts, в котором перечислены в очень простом формате ip-адрес и его имена. Пока в интернете было компьютеров 20—30, это замечательно работало. Когда их стало больше, задумались о том, что надо по-другому организовать эту архитектуру.
• Как только выяснилось, что интернет это не три локальных сети, а много сетей, то возникла проблема определения по ip-адресу компьютера. Точнее, как определить административную принадлежность компьютера по сравнению с его жёсткой ip-адресацией, которая зависит исключительно от топологии сети. Необходима система именования, отвязанная от топологии сети.
• Понятие административной принадлежности имеет оборотное свойство: проблема не только в том, чтобы по имени компьютера выяснить, зачем он вообще нужен, проблема в том, чтобы грамотно раздать людям из различных зон административной ответственности права раздавать эти имена.

Задача при этом такова: нужно придумать имена, при том имена должны отражать административную структуру интернета, и нужно решить задачу, чтобы каждый администратор именовал свои компьютеры. Это намекает на распределённую систему, которая будет заниматься преобразованием имён в ip-адреса и обратно.

[править] DNS как решение

Каким образом это сейчас решается с помощью DNS? Существует некая организация, которая принимает решение о заведении корневых домненов --- ICANN. (недавно она продавилась под китайцами и решила начать раздавать корневые домены в национальных языках).

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

Кроме того, в этой организации надо зарегистрироваться, чтобы раздавать домены в зоне ru. Это определяет, что ответственность внутри этой зоны лежит на зарегистрированной организации (в случае с ru это руцентр), и ICANN уже практически всё равно, что там творится.

Аналогично у руцентра регистрируется некая организация, которая говорит, что она отвечает, например, за зону msu.ru. И тут уже, помимо раздачи зон, ещё раздаются имёна компьютерам в этом домене.

И тут решаются все три задачи.

Такая организация называется доменной. Произошло от слова домен, которое означает феод, владение феодала.

Под королём были домены первого уровня.

При этом соблюдался принцип: вассал моего вассала не мой вассал.

По этой причине это и называется доменная система.

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

[править] Сервисы

Как это устроено на самом нижнем уровне:

Есть /etc/services, в котором прописано соответствие сервисам портов.

Клиент подключается по указанному порту к серверу, за которым его ждут услуги.

manmachine: диапазон красных портов

К тому, что происходит при использовании данного порта данный порт отношения не имеет. При этом было бы хорошо договориться, что определённый порт соответствовал определённому протоколу.

Это соответствие существует чисто для удобства пользователя. Мы когда подключаемся по 80 порту, ожидаем встретить http-сервер, и так далее.

Но всегда нужно иметь в виду, что на прикладном уровне это штука далеко не всегда встречающаяся.

В /etc/services можно увидеть порт 53, который отвечает как раз за dns.

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

Этот сервер, но в случае dns он заявлен как отвечающицй на tcp, так и на udp. Почему так: запрос на преобразование ip-адреса в доменное имя и обратно как правило укладывается в один пакет. Соответственно, ответ тоже, как правило, укладывается в один пакет. Поскольку такой запрос и такой ответ представляют собой датаграмму, почему бы не использовать протокол датаграмм? К тому же, использование TCP утяжелило бы обмен примерно в 4 раза.

Клиентская часть, resolver, есть практически на любой машине. Если его нет, то пользователь считает, что интернета нет.

Есть /etc/resolv.conf, где указано, где находится DNS сервер.

К слову о FQDN, полном имя домена: в /etc/resolv.conf указываются две вещи: какие компьютеры являются dns-серверами, и вторая информация --- список доменов, в которых будет производиться поиск, если вы указали не полное имя, а краткое.

/etc/resolv.conf может не использоваться, если resolver запускается в chroot (например, так в alt). Поэтому, например, при ручной модификации файла, далеко не сразу службы, которые его используют, начнут его использовать.

[править] Архитектура

Теперь об архитектуре. Очевидно, с точки зрения программы реализация должна быть такая: есть понятие "сервер", это сервер. Каждая организация должна иметь такого рода сервер, который предоставляет услуги преобразования имён и адресов в соответствие с теми именами, которые есть.

Каждый доменный сервер должен знать всю информацию об именах в своём домене и информацию о серверах, которые обслуживают зоны в домене.

Получается, что эта такая иерархически распределённая база данных.

Далее. вот прописал какой-то сервер в качестве сервера доменных имён. Далее вопрос: я же хочу спрашивать не только имена в этом домене, но и всякие другие. Должен ли он иметь full view? Конечно, нет.

Хорошо, а как он будет узнавать? Никак, он скажет, спроси у корневого. Спрашиваем у корневого: он говорит, я не знаю, знаю про com. Кто знает про com, знает только про cdrom.com. А тот уже знает про ftp.cdrom.com.

Вот это — рекурсивный запрос.

При этом делается такая прогулка.

Если бы все компьютеры в интернете работали бы так, то к корневым серверам было бы слишком много запросов. Поэтому обычно так не делают, хотя можно. Поэтому обычно можно сначала послать прямой запрос своему dns-серверу, который уже может ответить да / нет / не знаю. Кроме того, клиентские машины обычно не делают рекурсивные запросы, они посылают только прямые, а уже dns-сервер занимается рекурсивным запросом и занимается кешированием. Почему это лучше: если целая сеть ломится по какому-то ip, то в кеше останутся ip dns-серверов ещё для com и cdrom.com.

Для того, чтобы не происходило злоупотребление, есть практика рекурсивные запросы выполнять только для своих хостов.

[править] Кэш запросов

Теперь, что касается способов увеличения безобразия. В каждой такой таблице соответствия ip-адресов и имён, которые хранит dns-сервер, есть ttl. Она говорит, какое время полученная запись может считаться валидной. Зачем это сделано: чтобы если понадобится изменить ip-адрес, об этом узнали через некоторое время. Обычно TTL выставляется в сутки. Если же у вас сеть меняется часто, то можно уменьшить ttl, но нужно быть готовым к увеличению нагрузки.

Есть ещё expired, который используется, если ttl просрачивается, а dns недоступен.

[править] Дополнительные возможности

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

По какому признаку принимается решение, что данный сервер авторитетен на вопросы про DNS? Помимо преобразования имён адреса, DNS оказывает услуги по преобразованию имён во что угодно.

• A — адреса.
• NS — списки авторитетных адресов для данного домена.
• MX — адрес/имя почтового сервера.
• TXT — произвольный текст.

DNS-сервера используются для того, чтобы хранить информацию о спамерах. Оно устроено именно как dns-сервер. Ему скармливается ip задом наперёд, и по ответу понятно, что это за ip.

Остались две с половиной темы:

• Завершить DNS
• RPC
• p2p

[править] Конспект Kda

Сначала анекдот. На сайте про линукс в разделе «Методические пособия» стали публиковать результаты работы группы. Первое, что видит человек, это необработанные конспекты. «Лектор жалуется на ...».

Сегодня начало разговора о прикладном уровне Линукс. Лектор планировал рассказать про три вещи, но расскажет, скорее всего, про одну. DNS. В прошлый раз мы закончили на том, как писать свой сетевой сервер. У нас есть концепция файлового ввода-вывода, асинхронного ввода-вывода. Сокеты, оказывается, поддерживают read и write. Тема RPC сегодня не будет затронута. Шла речь о сетевом сервере.

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

Недостаток первый, самоочевидный. IP vs. DNS. IP-адрес практически невозможно запомнить. 9-12 цифр запомнить еще можно. Но сотни адресов запомнить не реально. Поэтому одна из задач в том, чтобы придумать имена. Эта задача решалась, очень простым способом. В каталоге /etc есть файл hosts, в котором перечислены в простом формате соответствия адресов и имен компьютеров. Он есть даже в Windows. Было популярно модифицировать в 90-е гг. содержимое этого файла. Файл высокоприоритетный. Если мы впишем туда соответствие, оно будет использовано. Пока было 20-30 компьютеров, все было хорошо. При появлении нового компьютера вписывали вручную на каждой машине.

Потом компьютеров стало очень много. Как только выяснилось, что Интернет — это не три локальные сети, а большая структура, возник вопрос, как определить по IP-адресу, чей он. Административная принадлежность. Не выяснение адреса человека, а само понимание, что компьютер принадлежит проекту freebsd.org и т.п. Принадлежность компьютера организации, отвязанная от топологии.

Также нужно понять, зачем компьютер в сети нужен. Также задача раздачи прав на присваивание имен.

В файл вносим изменения при появлении новых компьютеров. При большом количестве компьютеров это не работает. Нужна операция преобразования имен компьютеров в адреса. IP выдает провайдер, а имена администратор сети.

Передача полномочий.

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

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

Существует организация, принимающая решения о легализации корневых доменов. Корневой домен используется в качестве генерального окончания имени компьютера. Старые .org, .com, .net, потом по странам .ru, .uk, su, несколько лет назад появились .info, .biz. Важно другое. Их не так много. Первых около десятка, вторых в районе количества стран, третьих тоже несколько десятков. В общем, немного.

Помимо того, что эта организация принимает решение о доменах, в ней нужно зарегестрироваться организациям, которые будут выдавать адреса в соответствующих зонах. Зона ответственности за домен .ru лежит на зарегестрированной организации, а не на ICANN. Организация в свою очередь выдает права на домен, например, msu.ru. Взаимодействие с организациями, владеющими доменами второго уровня. Отвечать за имена компьютеров в этом домене. Помимо поддоменов, есть компьютеры, имена которых заканчиваются на .ru. Например, www.ru. Им владеет «Демос». msu.ru поступает также. Организация сидит в Главном здании. Она раздает домены третьего уровня, например, cmc.msu.ru. Также отвечает за имена в зоне msu.ru. Например, www.msu.ru.

Мы решаем обе задачи, в смысле, все три. Мы присваиваем имена. До седьмого уровня имена даже запоминаются. Имена в реальности отражают структуру Интернета (кто взял ответственность за имена). Именованием компьютеров внутри домена ведает нижележащая организация. По этой причине такую иерархию назвали доменной. В русском языке есть слово д`омен (владения феодала внутри феода). Помним, что устройство феодальной собственности имело иерархическую структуру. Король владел всем, у него были феодалы первого уровня, у них феодалы второго уровня. «Вассал моего вассала не мой вассал». Принцип тот же самый.

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

Все прекрасно, осталось это реализовать. Что об этом думают компьютеры? Ситуация следующая. Есть корневые серверы, их немного.

Как это устроено на нижнем уровне? Как было сказано в начале лекции, есть файл /etc/services. Разговор о сетях. Порт — число, по которому ожидает некий сервис. На транспортном уровне это один из элементов адреса, а на прикладном — такая штука, за которой нас ждут услуги. При этом, как было сказано в прошлый раз, было бы неплохо договориться, какой порт за какие услуги отвечает. На траспортном уровне разделение потоков. К собственно приложению это число (порт) прямого отношения не имеет. Было бы удобно договориться о том, что определенный порт соответствует приложению, которое будет ждать пользователя, подключившегося к порту.

Существует организация IANA, которая занимается следующим. Взяла на себя роль стандартизатора. Есть два понятия — well-known services, secure services. После долгих обсуждений и доказательства, что это нужный сервис и неплохо его привязать к номеру портов, в список соответствий номеров портов сервисам вписывается новый файл. Во FreeBSD список больше, чем в Линукс. Даже есть сервис Gandalf. Соответствие чисто для удобства пользователя. Мы подключаемся к 80 порту и ожидаем, что нас встретит веб-сервер. На 443 порту ожидаем защищенный веб-сервер. На прикладном уровне порт — штука, не всегда встречающаяся. FTP сервер можно запустить, чтобы он читал данные из стандартного ввода. Порт не обязателен. Есть исключения. Внутри протокола FTP заложена передача адреса компьютера и порта, к которому надо подключиться. Важно, что он передает порт. В SMTP нет понятия порт, а в FTP есть.

В файле /etc/services есть порт 53, отвечающий за DNS. Технология привязывания службы к порту является частью более общего механизма, который сужает понятие прикладной протокол до клиент-серверного протокола. Когда речь идет об услугах, речь идет о клиент-серверном взаимодействию. Подключаемся по условленному порту, нам оказывают услуги. Бывает обмен симметричный. Когда речь идет о подключении непонятно откуда на 80 порт, тот, кто подключается — клиент, а тот, к кому подключились — сервер, обмен асимметричный.

53 порт. Сервер, о котором идет речь, в случае DNS заявлен как отвечающий и по TCP, и по UDP. UDP используется чаще. Почему? Запрос укладывается в один пакет. Какой адрес у такого имени? Ответ тоже укладывается в один пакет. Адреса нет. Или, наоборот, выдается адрес. Используем протокол для датаграмм. Использование протокола TCP утяжелило бы трафик в несколько раз. А с трафиком проблема сильная.

Клиент-сервер. Это значит, что машина-клиент должна иметь клиентскую часть и должна знать, где находится серверная часть. Куда подключаться, кому слать запрос. Асимметричность. Клиентская часть есть на любом компьютере, подключающемся к Интернету. Никаких yandex.ru в TCP нет. Имена — понятие прикладного уровня. Нужно преобразовать имя в адрес.

Есть файл /etc/resolv.conf, который описывает некоторые понятия. FQDN — полное доменное имя, начиная от корня. Не Вася, а Вася.msu.ru. В файле указывается, какие компьютеры являются серверами. А также список доменов, в которых будет производиться поиск, если мы указали не полное имя, а краткое. Если ищем cmc, и указано search msu.ru, будет искаться cmc.msu.ru. Часто файл лежит не в /etc, или копируется и подсовывается в «правильное место». В Альте лежит в /var/resolv. Службе нужна вся сеть. Потенциально она опасна. Ее читали все эксперты. Но ее нужно запускать в изолированном окружении. Тот кусок, который пользуется, не видит нормального окружения. Если руками модифицировать этот файл, далеко не сразу службы, которые им пользуются, начнут им пользоваться. В Альте нужно запустить специальную команду.

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

Что получается? Распределенная иерархическая база данных, представляющая собой строгое дерево. Устроена следующим образом. Есть корневые сервера. Каждый делает одно и то же. Их 12 просто потому, что их должно быть много. Сервера первого уровня. Сервер зоны .ru знает компьютеры и поддомены. Сервер .msu.ru знает компьютеры и поддомены и т.д.

Есть компьютер. Прописал сервер в качестве доменного сервера. Вопрос первый. Хочу спрашивать адреса не только в зоне cmc.msu.ru, а все. Следует ли, что сервер должен знать все адреса? Нет. Как узнавать информацию о cdrom.com? Ответ очевиден. Если мой сервер не знает, он должен посылать в правильное место, спроси у того, кто знает. Какое правильное место cmc.msu.ru может предложить? Никакое. Дальше идем по цепочке вверх до корневого сервера. Корневой сервер спрашивает у сервера зоны .com. Тот у cdrom.com.

Рекурсивный запрос. Прогулка по иерархии. Выбирается наиболее подходящий сервер для начала, затем спрашиваем про вассала, у того про его вассала. Если бы все работали вышеописанным методом, в области подключения корневых серверов были бы перегрузки. Ситуация более сложная и более разумная. Рекурсивный запрос позволен не всем. Рекурсивный запрос может делат кто угодно. Но так не делают. Клиент посылает не рекурсивный запрос, а прямой. Либо получаем IP, либо нет. Третий вариант — таймаут. Прямой запрос — вот IP, либо IP у имени нет, либо не знаю. При обращении к серверу с прямым запросом, сервер может отказаться отвечать. Допустим, что существует небольшое число DNS-серверов. Компьютеров миллионы, серверов тысячи. В несколько раз больше, чем доменов.

Обычный компьютер посылает прямой запрос DNS-серверу. А сервер начинает всю эту штуку с рекурсивными запросами. Когда придет ответ серверу, он посылает ответ клиенту. Каждый клиент не занимается рекурсивным запросом, не ломится на корневой сервер. А локальные серверы кэшируют ответы. Почему это лучше? Если целая сеть ломится на сервер и хочет распознать адрес, в кэше останутся адреса других серверов. Будем знать адрес сервера .com, сервера cdrom.com, можем не лезть на корневой сервер. Чем больше запросов, тем больше используется кэш в серверах.

Мы с домена в cmc.msu.ru пошлем запрос на cdrom.com. Если спросим о sourceforge.com, нас пошлют. Своим сервер бы ответил, а чужим нет. Адреса, которые указаны в resolv.conf, специфичны, они дадут послать запрос и сделать его рекурсивным. Другие серверы не дадут делать такие запросы.

Это ограничительные способы. Достичь производительности путем ограничений тяжело, будет только хуже ее использовать. Что касается способов увеличения быстродействия. В каждой таблице (зоне ответственности) соответствия имен и адресов имеется TTL (time to live). В течение этого времени закэшированная запись будет валидна. Если наш сервер рассказал про ftp.cdrom.com, он закэширует эти данные. Если администраторы cdrom.com что-то изменят, мы потом узнаем об этом. В течение обычно суток считается, что адрес не меняется. Если же IP меняются постоянно (раз в час), ставим TTL раз в час и в 24 раза увеличится нагрузка на сеть. С одной стороны гарантируется механизм кэширования, с другой стороны есть управляемость кэшами, которые засели непонятно где.

Помимо этого есть понятие устаревания записи, когда она не просто удаляется из кэша, а если она устарела, ей даже доверять нельзя. Запись устарела, а DNS-сервер упал. Запись держится в кэше. Нам отвечают «Вот вам информация не первой свежести». Потом же (через неделю) запись просто удалится из кэша в любом случае.

Еще одна идея, которая позволяет убыстрить и увеличить надежность системы. Мы упоминали о том, что сервер может не отвечать, не обязательно потому что перестал функционировать, а могла пропасть связность с Интернетом. При регистрации регистрируем не менее двух серверов. Должны находиться в разных сетях класса B. Зачем это делается? И тот, и другой сервер являются авторитетными. К ним пойдет запрос, тот и другой сервер будут возвращаться в качестве ответа на рекурсивный запрос. Если один из них не работает, будет опрошен второй. Это в два раза увеличит надежность. На кэширование это никак не влияет. Увеличит таймаут.

Тут другая проблема. У какого сервера мы имеем право спрашивать окончательную истину? Мы спрашиваем о том, кто такой cdrom.com. Кто ответил, родной сервер или наш. Когда мы хотим узнать, кто отвечает за cdrom.com, мы не можем полагаться на кэши. Или хотим насильственно кэшировать зону. Обращаемся к авторитетному серверу. Но их минимум два. Такого не бывает. Один primary, другой secondary. Межсерверная передача зон. Можем договориться с товарищем, чтобы на его сервер скачивалась наша зона. Если у провайдера записан и сервер товарища, и наш сервер, получаем, что истина в последней инстанции — другой сервер, но наш тоже авторитетен.

По какому признаку принимается решение о авторитетности? Помимо услуг по преобразованию имен в адреса, оказываются услуги о преобразовании имен в другие штуки. Запись A — адрес. Запись NS — список адресов, которые являются авторитетными для данного домена. Запись MX — адрес сервера, отвечающего за пересылку почты для данного домена. Тип TXT — посылаем имя, возвращается текст. DNS можно пользоваться, как базой данных.

DNS-сервера используются для хранения информации о спамерах. У нас зависло две темы. В следующий раз завершение DNS, RPC, peer-to-peer.