Всем привет! Это вторая из статей о Netsukuku — проекте создания P2P альтернативы современному Интернету.
В этот раз я расскажу об ANDNA (A Netsukuku Domain Name Architecture) — службе разрешения имен в IP адреса, являющейся местным аналогом службы DNS и протокольно совместимой с ней.
Тем кто не знает о чем вообще речь, рекомендую прочитать первую часть.
Предисловие
В прошлой статье, вследствие
В общем, вторая часть получилась такой, какой получилась :)
Основные принципы
В современном Интернете, достучаться до некоторого узла сети можно двумя способами. Первый — это напрямую указать IP адрес узла. Второй способ — адресовать узел по его имени. Хороших имен мало и все хотят их заполучить. Поэтому выделение и использование имен приходится регулировать законодательно. Для этого существуют организация ICANN, руководящая процессом создания зон и делегирующая права регистраторам отдельных стран.
В случае с Netsukuku дела обстоят иначе. Поскольку адрес узла — величина переменная, то привязывать имя напрямую к IP нельзя. Сеть является децентрализованной, и в общем случае неуправляемой. Соответственно, подход к процессу регистрации имен тоже должен отвечать этим требованиям.
Все узлы имеют равные права на получение имени. Единственное ограничение связано с количеством имен, ассоциированных с отдельным узлом (для предотвращения киберсквоттинга). В остальном — пользователь волен выбирать любое имя длиной до 500 символов. Так что при наличии фантазии, дефицита имен не будет :)
Как и вся сеть Netsukuku, служба ANDNA построена по распределенному принципу. Таким образом, не существует единого хранилища данных. Информация «размазана» по всем узлам сети; многократное дублирование обеспечивает надежность и отказоустойчивость ее работы. По расчетам, объем базы на каждом узле даже в худшем случае не должен превышать 300 Кб, так что требования по минимизации используемых ресурсов соблюдаются и здесь.
Регистрация имени узла
Предположим, что некоторый узел X хочет зарегистрировать имя «habr.ru»:
Для этого, он вычисляет хеш от имени: h(«habr.ru») = 0x11223344. Числовое представление хеша трактуется как адрес узла, который будет считаться хранилищем. Это так называемая хеш нода (узел H). Далее, хеш нода производит некоторые проверки (о них написано чуть ниже), а затем заносит ассоциацию имени и адреса в свою базу данных. После этого, узел X считается владельцем имени и просто так его не потеряет.
Любой узел, желающий узнать адрес узла с именем «habr.ru», точно так же вычисляет хеш и дает запрос к узлу H (а точнее, к случайно выбранному соседу из той же группы).
Конечно, при низкой заселенности адресов, прямое попадание хеша будет довольно редким, поэтому делаются некоторые допущения:
• Если узел с адресом H существует, используется он;
• Если нет, используется gnode адреса H (11.22.33.x);
• Если и группы такой нет, то берется группа с номером, ближайшим к желаемому (например, 11.22.34.x). Такая группа называется округленной (rounded gnode).
Важно отметить, что это ни в коей мере не мешает нормальной работе службы. При появлении новых узлов в любом месте сети, служба автоматически адаптируется к изменившимся условиям.
Контроль доступа
Зарегистрировав некоторое удачное имя, мы естественно не хотим, чтобы произвольный узел отнял его у нас. Это обеспечивается цифровыми сертификатами. Контроль прав осуществляется на всех этапах взаимодействия и является вполне надежным.
При регистрации нового имени, узел-инициатор генерирует пару криптографических ключей, а затем открытый ключ передает на домен среди прочей регистрационной информации. Этот ключ будет сохраняться хеш нодой все время существования данного имени; любые действия владельца должны быть подтверждены соответствующей цифровой подписью. Таким образом, при изменении IP адреса узла, либо продлении регистрации имени, узел владельца должен предварительно подтвердить свои права.
По умолчанию, хеш нода будет хранить информацию об имени в течение 30 дней после регистрации. После этого, необходимы действия владельца имени по его продлению. Имя останется вашим, если хотя бы раз в месяц ваш узел будет появляться в сети.
Если по истечении этого срока регистрация продлена не была, то имя отдается следующему желающему. Причем механизм «живой очереди» предусмотрен и здесь.
Очередь регистрации
В каждый момент времени с некоторым именем может быть ассоциирован только один узел. Однако, любой желающий может подать заявку на имя, попытавшись зарегистрировать его на себя. Хеш нода хранит список из пяти кандидатов на регистрацию, который заполняется в порядке поступления запросов.
Как только имя будет освобождено, хеш нода удаляет верхнюю запись и производит перерегистрацию имени на нового владельца. Короче говоря, обычный подход — кто раньше встал, того и тапки.
Ограничение количества имен
Формально, узел может иметь сколько угодно имен. Однако, из практических соображений, вводится ограничение на количество имен, равное 256. Мне кажется, что и 16 было бы выше крыши, но видимо у авторов иное мнение :)
Помимо хеш ноды, в регистрации так же участвует и т. н. counter node — узел счетчик. Этот узел хранит количество имен, ассоциированных с исходным узлом. Работает это так:
При получении запроса на регистрацию, хеш нода H вычисляет хеш от открытого ключа «ABC» узла X, который в свою очередь уже трактуется как адрес узла счетчика C. Хеш нода дает запрос к счетчику, с тем чтобы выяснить, сколько имен в настоящий момент ассоциировано с регистрирующимся узлом.
Если это количество не превышает лимита, то величина счетчика увеличивается на 1 и регистрация продолжается. Если нет — в регистрации домена узлу будет отказано.
Поскольку единого хранилища информации нет и заранее неизвестно, кто будет использоваться в качестве узла счетчика, то скомпрометировать данный механизм практически невозможно.
Фактически, задача взломщика сводится к задаче генерации пары ключей по заранее известному хешу (адресу). А это ведет сразу к двум сложнейшим задачам: а) найти коллизию хеш функции (восстановить исходный блок) и б) по этому блоку (открытому ключу) построить закрытый ключ, что нереально вдвойне.
Распределенное кеширование запросов
Каждый узел, произведший разрешение некоего имени в адрес, сохраняет результат у себя в кеше. Этот кеш доступен для чтения всем окружающим. Узел X выполняющий поиск узла, на самом деле спрашивает своего соседа Y из той же группы, который выбирается случайным образом. Далее возможны два варианта.
Вариант первый: сосед проверяет наличие записи у себя в кеше и возвращает ее узлу X.
Вариант второй: записи в кеше не оказалось; узел Y производит разрешение обычным образом.
Следствием работы данного алгоритма является повышение скорости работы службы и снижение нагрузки на хеш ноды, соответствующие популярным именам.
Обратное разрешение имени
Если узел X желает узнать все имена, ассоциированные с узлом Y, он просто-напросто спрашивает об этом сам узел Y :)
Обеспечение избыточности
Поскольку любой узел в нашей сети в любой момент может быть отключен, то необходимо предусмотреть механизм избыточности в хранении информации. Это реализуется на уровне группы, содержащей хеш ноду.
При регистрации нового имени информация заносится во все узлы группы, то есть вся группа узлов близких к хеш ноде, будет содержать копии информации. Соответственно, при отключении основной хеш ноды, любой узел группы сможет ответить на вопрос.
Когда производится разрешение имени, то узел вычисливший хеш, обращается к произвольному узлу хеш группы, то есть a.b.c.x. Таким образом получается, что все узлы группы обрабатывают запросы равномерно.
Похожий механизм применяется и для групп счетчиков.
Совместимость с DNS
Служба ANDNA может работать в режиме совместимости с традиционным DNS. Для этого, на узле пользователя запускается «обертка», прослушивающая 53й порт и перенаправляющая запросы в сеть. Благодаря этому, существующий софт сможет без каких-либо изменений работать в сети Netsukuku.
Резюме
Итак, в этой статье мы с вами рассмотрели службу ANDNA, которая используется для хранения и разрешения имен узлов. Мы выяснили, что служба соответствует идеологии всей сети Netsukuku, является распределенной и отказоустойчивой. Хранение информации не сильно напрягает каждый узел, а потому так же не представляет из себя проблемы. Любой бюджетный маршрутизатор справится с этой работой.
Заключение
В заключение хотелось бы отметить, что эта статья фактически представляет собой вольный пересказ документации. Авторы отмечают, что в целом архитектура службы проработана, но еще далека от завершения. Меня в частности, несколько смущает механизм внесения избыточности.
Как было сказано выше, избыточность достигается распределением информации внутри группы хеш узла. С одной стороны, это позволяет легко распределять нагрузку между узлами, выбирая их случайным образом.
С другой — не совсем ясно что делать, если вся группа вдруг окажется отрезанной от сети. Получается, что в остальной части сети не окажется ни одного узла, могущего разрешить имя, хеш которого приходится на отключенную группу. Вероятно, решение надо искать в механизме периодического опроса владельцем имени своей хеш группы. Если вдруг она целиком недоступна — перерегистрировать имя заново. Затем, когда связь восстановится, хеш группы всегда смогут договориться (сравнив ключи и узнав, что владелец обеих копий имен — один и тот же).
За сим, попрошу откланяться. Надеюсь, эта статья вам понравилась так же, как и предыдущая :)
P.S: В следующий раз я более детально затрону вопросы маршрутизации, алгоритма QSPN и вопросов, связанных с ним.
P.P.S: Еще вопрос: подходит ли такой уровень детализации для статей? Может быть, стоит копать глубже? Или наоборот, концентрироваться больше на идеях, а не на реализации? Хотя последней здесь и так почти не было.
Диаграммы созданы с использованием редактора smartdraw.
Отдельные графические элементы взяты с iconfinder.net
