Система доменных имён разрабатывалась как замена hosts файлам, и в то время, в ограниченной среде университетских сетей никто не думал о безопасности. Всё основывалось на доверии. Ещё буквально лет 8-10 назад никто не думал о том, что трафик между сервером DNS и клиентом можно записывать для продажи, либо заменять для достижения своих целей. Но уже в то время существовали трояны, добавляющие записи в локальный файл hosts, чтобы перенаправлять пользователей на подконтрольные серверы. В последние несколько лет появилось несколько новых протоколов, которые помогают устранить перехват или подмену трафика DNS. Но это только смещение точки доверия от одной группы провайдеров, к другой.

Как работает DNS?

Важно понимать, что записи, получаемые от 8.8.8.8 или 1.1.1.1 не берутся из ниоткуда. Это обычные рекурсивные серверы, которые получают данные о гипотетическом example.com примерно по такой схеме:

• Запросить у одного из корневых серверов информацию о серверах-менеджерах зоны .com

• Запросить у одного из серверов зоны NS-серверы домена example.com

• У одного из NS-серверов запросить IP-адрес домена example.com или www.example.com

Понятное дело, что тут ещё есть кэши на разных уровнях, но нас интересует цепочка доверия. Мы доверяем условному администратору DNS-сервера, к которому мы обращаемся - это может быть сервер провайдера, или пресловутый 8.8.8.8, или даже сервер провайдера, скрытый за 8.8.8.8, так как провайдер перенаправляет все такие запросы на свои серверы. Потом идут запросы к корневым и серверам зоны, а уж потом к самим серверам домена.

Не много ли узлов, которым мы должны доверять?

В 2010-ом году была введена в эксплуатацию система защиты от подмены DNS-записей DNSSEC. В принципе, она решала некоторые проблемы текущей реализации, но её внедрение сильно затянулось из-за существенных недостатков. В итоге, не так много доменов защищено этой системой, и не все серверы DNS поддерживают работу по этому протоколу. А кроме этого, доверие сместилось в сторону администраторов зон, которые подписывают записи конкретных доменов.

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

Есть ли решения таких проблем?

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

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

Например, есть EmerDNS - довольно древний блокчейн, который вроде самым первым реализовал поддержку доменных имён в своём блокчейне. А ещё есть довольно свежий проект Unstopable Domains. Но если мы говорим о доверии, то не стоит забывать, что DNS это не только некая база, но ещё и удобный доступ к ней. В идеале, чем ближе она к клиенту, тем больше доверия при работе с ней. У Эмера надо качать несколько гигабайт блокчейна, а у второго решения нужно ставить некие расширения в браузеры.

И тут появляется ALFIS

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

ALFIS - Alternative Free Identity System.

Задачи, которые я решал, сводились примерно к такому списку:

• Автономность и минимальный размер блокчейна

• Минимальная скорость роста блокчейна

• Общее удобство использования, кроссплатформенность

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

В процессе разработки пришлось пару раз изменить концепцию интерфейса, и я очень рад, что в итоге выбрал библиотеку web-view, которая использует системный браузерный движок, и позволяет получить очень компактные программы.

Итак, что из себя представляет сам ALFIS?

• Блокчейн, хранимый в базе sqlite. Всего 1,9Мб на 3145 блоков и 372 домена.

• Сетевая подсистема - p2p, написанная с нуля с использованием библиотеки mio, с шифрованием трафика и обменом пирами.

• Сервер DNS, который резолвит домены из блокчейна, перенаправляет незнакомые запросы на настроенные апстрим-серверы, включая возможность DNS-over-HTTPS. Кроме того, может блокировать рекламу по обычным файлам hosts.

Как это всё работает?

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

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

Данная стратегия позволяет удерживать блокчейн от бесконечного роста. Но это не единственное, что помогает такой задаче. Для того, чтобы блокчейн не рос постоянно, был придуман механизм подписей - пустых блоков, без транзакции, от участников сети, выбранных специальным образом. Исходя из подписи нового полного блока, по специальному простому алгоритму, выбирается 7 ключей из всего блокчейна. В этом выборе участвуют только те ключи, блоков которых в блокчейне больше либо равно текущая высота блокчейна / 100, таким образом, только постоянные пользователи могут подписывать блоки. Своеобразный PoS, если хотите. И уже из этих семи требуется 4 подписывающих блока. Таким образом формируется одна цепочка, без форков. Никакие ноды не могут откатить свой блокчейн дальше, чем на 4 блока назад, так что блокчейн не должен постоянно расти, чтобы быть впереди какого-нибудь злоумышленника. Текущий блокчейн запущен в мае 2021 года, и функционирует без проблем.

В процессе выбора алгоритма для PoW я перелопатил несколько вайтпейперов описывающих алгоритмы, устойчивые к майнингу на ASIC и GPU. В итоге, исходя из представленных решений, я скомпоновал свой алгоритм и назвал его Blakeout. Он требует довольно много RAM для подсчёта хэшей.

Какие домены поддерживаются?

Для начала скажу, что в ALFIS поддерживается 10 собственных зон:

.anon, .btn, .conf, .index, .merch, .mirror, .mob, .screen, .srv, .ygg

А зоны .anon и .ygg обладают суперспособностью - они могут содержать только записи AAAA из диапазона 200::/7, то есть созданы только для использования в сети Yggdrasil. И любой пользователь, заходя на такой сайт, может быть уверенным, что он туда попадёт именно через Yggdrasil.

Как ими пользоваться?

Информация о том, как устанавливать ALFIS на разные системы есть на GitHub. Отдельно хотел бы отметить, что в программе есть справка: ./alfis -h или alfis.exe -h. Да, многие пользователи не догадываются об этом, и спрашивают как сделать то, или иное, что там показано.

Отдельный момент: хоть у ALFIS и сделан UI на основе веб-технологий, но это не веб-UI в обычном смысле, нет возможности зайти браузером и общаться по HTTP. Так что если вам надо запустить UI, чтобы намайнить домен, или что-то проверить, то запускаете полноценную версию. А если вам нужен только сервер DNS, который будет синхронизироваться по P2P, вы можете запустить ту же полноценную версию без UI - alfis -n, либо скачать/собрать версию совсем без UI, уменьшив и без того небольшой бинарник.

На данный момент в Rust есть сложности с разработкой программ, включающих в себя разные функции вроде сервиса Windows, Tray Icon, плюс UI. Так как каждый из крейтов реализует свой цикл обработки событий. Поэтому ALFIS сейчас не может быть сервисом, или прятаться в системный лоток в виде иконки. Надеюсь, когда-нибудь это станет возможным. Либо придётся сделать разные сборки с поддержкой разных функций.

Так что там с доверием?

Я начал статью с того, что мы перемещаем точки доверия туда-сюда, но всё время они контролируются какими-то не всегда открытыми компаниями или организациями. И часто даже не одной из них.

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

Заключение

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