4.4 Анализ доменной структуры сети

ANDNA (Abnormal Netsukuku Domain Name Anarchy) - распределенная, не иерархическоя, и децентрализированая система управления именеми хостов Netsukuku. Она заменяет систему DNS.

База данных ANDNA рассеяна по всей сети Netsukuku. В самом плохом случае каждый узел должен будет использовать несколько сотен килобайтов памяти.

4.4.1 ANDNA

ANDNA основан на принципе, что каждое имя хоста h является строкой не больше 512 байтов. Беря хеш H (h) имени хоста, мы получаем число. Мы считаем это число IP, и мы называем узел хеш узлом, которому принадлежит тот же самый IP. Каждый хеш узел хранит маленькую часть распределенной базы данных ANDNA.

Узел n

ip: 123.123.123.123

хеш (имя хоста: "netsukuku")=11. 22. 33. 44

||

Узел i

ip: 11.22.33.44

{[База данных Andna узла i]}

{хеш ("netsukuku")---> 123.123.123.123}

Регистрация имени хоста h, узлом n следует ниже:

• n вычисляет i = H (h);

• n посылает регистрационный запрос i;

• i ассоциируется в базе данных H (h) с IP n, который является IP (n).

Разрешающая способность имени хоста h узлом m:

• m вычисляет i = H (h)

• m посылает запрос разрешающей способности i

• i отсылает назад к m IP, связанного с H (h), который в этом примере является IP (n).

Хеш gnode. Есть вероятность, что хеш H (h) не ответит никакому активному узлу: если есть в общей сложности 230 активных узлов, и мы используем IP 32 битов, то, беря 32 битный хеш h вероятность равна 25 %. Кроме того, даже активные узлы могут выходить из сети.

Поэтому, регистрация имени хоста будет сохранена всеми узлами единственного gnode. Это гарантирует распределённость и избыточность базы данных. gnode связанный с H (h) является хеш gnode, и это - просто gnode уровня 1 из хеш узла H (h). Мы обозначим gH (h) как предыдущий и nH (h) как последующий. Мы можем написать что:

nH (h) gH (h).

Аппроксимизированный хеш gnode. Даже если хеш gnodes не может существовать, стратегия аппроксимизации будет использоваться: самый близкий активный gnode к хеш gnode станет округленным хеш gnode, который полностью займет место оригинала (не существующего) хеш gnode. Округленный хеш gnode (rounded hash gnode) обозначим как rgH (h).

Вообще, когда мы обращаемся к gnode, который принял регистрацию,­ нет никакого различия между двумя видами gnodes, их всегда называют хеш gnodes.

Присоединение. Когда узел присоединяется к Netsukuku, то он автоматически становится частью хещ gnode, таким образом он также выполнит andna присоединение. Присоединяясь он получит всь кэш и базы данных, которые уже распространены в его хеш gnode.

Криптография ANDNA. Прежде, чем сделать запрос к ANDNA, узел генерирует несколько RSA ключей, то есть открытый и закрытый ключи. Размер открытого ключа будет ограничен для экономии пространства. Запрос имени хоста, сделанного к ANDNA, будет подписан при помощи секретного ключа, и в том же самом запросе будет прикреплен открытый ключ. Таким образом, узел будет в состоянии идентифицировать себя при своих будущих запросах.

Предел имен хоста. Максимальное число имен хоста, которые могут быть зарегистрированы, 256. Этот предел необходим, чтобы предотвратить массивную регистрацию имен хоста, которые могут привести к перегрузке системы ANDNA. Один ее побочный эффект должен замедлить действие спаммеров, которые регистрируют тысячи общих слов, чтобы перепродать их.

Реализация предела. Встречный узел - узел с ip равным хешу открытого ключа узла, который регистрировал имя хоста h. Мы обозначим встречный узел связанный с узлом n как cr (n). Таким образом, для каждого узла n, который регистрировал ­имя хоста h, существует его соответствующий встречный узел cr (n).

Встречный узел cr (n) сохранит число имен хоста регистрированным n.

Когда хеш gnode получает регистрационный запрос, посланный n, он входит в контакт с cr (n), который отвечает, говоря сколько имен хоста было уже зарегистрировано n. Если n не превысил свой предел, то cr (n) увеличит свой счетчик и позволит хеш gnode регистрировать имя хоста.

cr (n) активируется запросом проверки, который посылает хеш gnode. n должен сохранить cr (n) активным следуя за теми же самыми правилами бездействия (hibernation rules). Фактически, если cr (n) не получает больше запросы проверки, он деактивирует себя, и все зарегистрированные имена хостов станут недопустимыми.

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

Регистрация шаг за шагом:

1. Узел n хочет регистрировать своё имя хоста h,

2. Он находит округленный хеш gnode rgH (h) и связывается с одним из ее узлов случайным образом. Позволим этому узлу быть y.

3. n посылает регистрационный запрос в y. Запрос включает открытый ключ узла n. pkt также подписан секретным ключом n.

4. Узел y проверяет, чтобы быть эффективно самым близким gnode к хеш gnode, при обратном он отклоняет запрос. Правильность сигнатуры также проверяется.

5. Узел y входит в контакт со счетчиком gnode cr (n) и посылает к нему IP, хеш имени хоста, который будет зарегистрирован и копию регистрационного запроса.

6. cr (n) проверяет данные и дает добро.

7. Узел y, после утвердительного ответа, принимает регистрационный запрос и добавляет запись в его базе данных, сохраняя дату регистрации.

8. y передает gnode свой регистрационный запрос.

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

Бездействие имени хоста. Хеш gnode сохраняет имя хоста в состоянии бездействия в течение приблизительно 30 дней с момента его регистрации или последнего обновления. Время истечения очень долгое, для стабилизации домена. Таким образом, даже если кто-то нападает на узел, чтобы захватить его домен, он должен будет ждать 30 дней, чтобы полностью получить его.

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

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

У пакета запроса обновления есть id, которое равно числу уже посланных обновлений. pkt также подписан секретным ключом узла, чтобы гарантировать истинность запроса. pkt посылают в любой узел хеш gnode, который пошлет копию запроса на счетчик gnode, чтобы проверить его активность и что запись, связанная с обновляемым именем хоста, существует. Напротив, запрос обновления отклоняется.

Мутация хеш gnodes. Если общий округленный gnode переходит в новый gnode, который ближе к хеш gnode, он обменяет свою роль с ним, то есть новый gnode станет округленным хеш gnode.

Этот переход является пассивным. Когда узел регистра обновит свое имя хоста, он непосредственно свяжется с новым округленным gnode. Так как имя хоста, сохраненное в старом округленном gnode не будет обновлено, оно будет упущено.

В то время как имя хоста еще не было обновлено, все узлы, пытающиеся решить это, найдут новый округленный gnode самый близкий к хеш gnode и таким образом они пошлют свои запросы разрешающей способности в новый gnode.

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

Таким образом, регистрация имени хоста автоматически передана от старого gnode в новый.

Если атакующий в состоянии послать регистрационный запрос в новый хеш gnode перед тем как законный владелец имени хоста обновит его или перед тем когда происходит пассивная передача он будет в состоянии захватить его.

Чтобы предотвратить это, новый хеш gnode будет всегда проверять регистрационный запрос дважды, входя в контакт со старым хеш gnode.

Еще одна очередь. Каждый узел может выбрать любое имя хоста, даже если имя хоста было уже выбрано другим узлом.

Кэш andna сохранит очередь в записиях MAX_AN DNA_QUEUE (5). Когда функционирование имени хоста на вершине очереди завершиться, оно автоматически заменится следующим именем хоста.

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

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

Разрешенный hnames кэш читается любым узлом. Узел x, эксплуатируя эту особенность, может спросить у любого узла y, выбранного случайным образом, в своем том же самом gnode, разрешить для себя данное имя хоста. Узел y, будет искать в своем разрешенном кэше имя хоста, и на отрицательном результате узел решит это стандартным способом, посылая результат в узел x. Эта методика избегает перегрузки хеш gnodes хранения очень известных имен хоста.

Если узел будет хотеть знать все имена хоста, связанные с ip, то он непосредственно войдет в контакт с узлом, которому принадлежит этот ip.

Оболочка DNS. Оболочка сервера имен доменов слушает запросы разрешающей способности, посланные localhost, и инкапсулирует их: она посылает ANDN демону имя хоста, чтобы решить и получает его разрешение.

Благодаря оболочке возможно использование ANDNA, не изменяя другие предустановленные программ.

4.4.2 Scattered Name Service Disgregation

Scattered Name Service Disgregation в ANDNA является эквивалентом записи SRV из интернетовского DNS.

SNSD не то же самое что и "запись SRV", фактически, у него есть свои собственные уникальные особенности.

С SNSD возможно связать IP и имя хоста к другому имени хоста.

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

Пример:

Узел X регистрировал имя хоста " angelica ". Заданный по умолчанию IP " angelica " "1.2.3.4".

X ассоциирует имя хоста "katrin" к сервисному номеру 'http' (80) из " angelica ".

X ассоциирует IP "11.22.33.44" к сервисному номеру 'ftp' (21) из "'angelica ".

Когда узел Y получает "angelica", он получает 1.2.3.4, но когда его web-браузер пытается получить его, он просит запись связанную с сервисом 'http', поэтому разрешающая способность возвратит "katrin". Браузер получит ­"katrin" и наконец соединится с сервером. Когда ftp клиент Y попытается получить " angelica ", он получит IP "11.22.33.44" .

Узел, связанный с записью SNSD, называют "узлом SNSD". В этом примере "katrin" и 11.22.33.44 узлы SNSD.

Узел, который регистрирует записи и сохраняет регистрацию основного имени хоста, всегда называют "узлом регистра", но его можно также назвать "Нулевым узлом SNSD", фактически, это соответствует самой общей записи SNSD: сервисный номер которой ­0.

Сервисный номер определяет область видимости записи SNSD. IP, связанный с сервисным номером 'x', будет возвращен только запросу разрешающей способности, у которого есть тот же самый сервисный номер.

Сервисный номер - число порта определенного сервиса. Порт сервиса может быть получен из /etc/services.

Сервисный номер 0 соответствует нормальной записи ANDNA. Относительный IP будет возвращен к общему запросу разрешающей способности.

У записи SNSD есть также приоритетное число. Это число определяет приоритет записи внутри массива.

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

Вес числа, связанный с каждой записью SNSD, используется, когда есть больше чем одна запись, у которых есть одинаковое приоритетное число. В этом случае это – то, как клиент выбирает, которую запись использовать, чтобы соедениться с серверами:

Клиент спрашивает ANDN запрос разрешающей способности, и получает его, например: 8 различных записей.

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

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

Возможно также использование веса равного 0 для отключения записи.

Число веса должно быть меньше чем 128.

Регистрация SNSD. Есть возможность ассоциировать до 16 записей на единственное имя хоста. Максимальное ­число записей которые могут быть зарегистрированы - 256.

Регистрация записей SNSD выполнена тем же самым узлом регистра.

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

Узел регистра может также захотеть использовать дополнительную особенность SNSD, чтобы убедиться, что имя хоста SNSD всегда связано со своей машиной, которой доверяют. В этом случае, узел регистра нуждается в ANDN открытом ключе узла SNSD, чтобы послать периодический вызов узлу. Если узел будет не в состоянии отвечать, то узел регистра пошлет в ANDN удаляющий запрос об относительном записи SNSD.

Регистрация записей SNSD имен хоста, которые только поставлены в очередь в andna, очереди отменяются.

Фактически, шаги необходимые для регистрации записи SNSD:

1. Modify the /etc/netsukuku/snsd_nodes file.

register_node# cd /etc/netsukuku/

register_node# cat snsd_nodes

#

# SNSD nodes file

#

# The format is:

# hostname:snsd_hostname:service:priority:weight[:pub_key_file]

# or

# hostname:snsd_ip:service:priority:weight[:pub_key_file]

#

# The ‘pub_key_file’ parameter is optional. If you specify it, NetsukukuD will

# check periodically ‘snsd_hostname’ and it will verify if it is always the

# same machine. If it isn’t, the relative snsd will be deleted.

#

katrin:pippo:http:1

katrin:1.2.3.4:21:0

angelica:frenzu:ssh:1:/etc/netsukuku/snsd/frenzu.pubk

register_node #

register_node # scp frenzu:/usr/share/andna_lcl_keyring snsd/frenzu.pubk

2. Send a SIGHUP to the NetsukukuD of the register node:

register_node# killall -HUP ntkd

# or, alternatively

register_node# rc.ntk reload

Нулевой SNSD IP.

У основного IP, связанного с нормальным именем хоста, есть такие значения по умолчанию:

IP = register_node IP # Это значение не может быть изменено

service = 0

priority = 16

weight = 1

Есть возможность ассоциировать другие записи SNSD в 0 сервисе, но это не позволит изменить основной IP. Основной IP может быть только IP адресом register-node

Хотя это не возможно, установить различную ассоциацию для основного IP, оно может быть отключено устанавливая его вес номера в 0.

Строка используемая для изменения приоритета, и значения веса основного IP:

hostname:hostname:O:priority:weight

# Например:

register_node # повторяют katrin:katrin:O:23:12 »/etc/netsukuku/snsd_nodes

Цепочка SNSD

Поскольку возможно назначить различные псевдонимы и резервные IP к нулевой записи, есть возможность создать цепочку SNSD.

Например:

регистры katrin: katrin:80-> pippo

регистры pippo: pippo:O-> frenzu

регистры frenzu: frenzu:O-> angelica

Однако цепочки SNSD проигнорированы, только первую разрешающую способность считают правильной. С тех пор в нулевом сервисе всегда есть основной IP, разрешающая способность всегда выполняется.

В этом случае ("katrin:80-> pippo:0") разрешающая способность возвратит основной IP "pippo:0".

Ответ на запрос разрешающей способности в виде 0, возвращает всегда IP, а не имя хоста.