Обзор
Это предложение о добавлении поддержки обратных DNS-запросов к I2P.
Текущий механизм перевода имени
GarliCat (GC) выполняет перевод имени для установки соединений с другими GC узлами. Этот перевод имени представляет собой перекодировку двоичного представления адреса в форму кодирования Base32. Таким образом, перевод работает в обе стороны.
Эти адреса выбраны длиной 80 бит. Это связано с тем, что Tor использует 80-битные значения для адресации своих скрытых услуг. Таким образом, OnionCat (который является GC для Tor) работает с Tor без дополнительного вмешательства.
К сожалению (в отношении этой схемы адресации), I2P использует 256-битные значения для адресации своих услуг. Как уже упоминалось, GC перекодирует между двоичной и кодированной в Base32 формой. По природе GC, являющегося VPN третьего уровня, в своем двоичном представлении адреса определяются как адреса IPv6, которые имеют общую длину 128 бит. Очевидно, 256-битные адреса I2P не подходят.
Таким образом, становится необходимым второй этап перевода имени: IPv6 адрес (бинарный) -1а-> Base32 адрес (80 бит) -2а-> I2P адрес (256 бит) -1а- … перевод GC -2а- … поиск в I2P hosts.txt
Текущее решение заключается в том, чтобы позволить маршрутизатору I2P выполнять работу. Это достигается за счет вставки 80-битного Base32 адреса и его назначения (адрес I2P) как пары имя/значение в файл hosts.txt или privatehosts.txt маршрутизатора I2P.
Это в основном работает, но зависит от службы имен, которая (по моему мнению) находится в стадии развития и не является достаточно зрелой (особенно в отношении распространения имен).
Масштабируемое решение
Я предлагаю изменить этапы адресации в отношении I2P (а возможно и для Tor) таким образом, чтобы GC выполнял обратные запросы адресов IPv6, используя стандартный DNS-протокол. Обратная зона должна прямо содержать 256-битный адрес I2P в его кодированной форме Base32. Это изменяет механизм поиска на одноэтапный процесс, добавляя дополнительные преимущества. IPv6 адрес (бинарный) -1b-> I2P адрес (256 бит) -1b- … обратный DNS-запрос
DNS-запросы в Интернете считаются утечками информации, что касается анонимности. Таким образом, эти запросы должны выполняться в пределах I2P. Это подразумевает, что в пределах I2P должно быть несколько DNS-сервисов. Поскольку DNS-запросы обычно выполняются с использованием протокола UDP, GC сам необходим для передачи данных, потому что он переносит UDP-пакеты, которые I2P изначально не поддерживает.
Дополнительные преимущества связаны с DNS:
- Это хорошо известный стандартный протокол, поэтому он постоянно улучшается, и существует много инструментов (клиентов, серверов, библиотек,…).
- Это распределенная система. Она поддерживает хостинг пространства имен на нескольких серверах параллельно по умолчанию.
- Она поддерживает криптографию (DNSSEC), которая позволяет аутентифицировать ресурсные записи. Эта функция может быть напрямую связана с ключами назначения.
Будущие возможности
Возможно, что этот сервис именования также может использоваться для прямых запросов. Это перевод имен хостов в адреса I2P и/или адреса IPv6. Но этот вид запроса требует дополнительного изучения, поскольку такие запросы обычно выполняются с помощью локально установленной библиотеки резолверов, которая использует обычные Интернет-серверы имен (например, как указано в /etc/resolv.conf на Unix-подобных системах). Это отличается от обратных запросов GC, который я объяснил выше. Дальнейшей возможностью может быть автоматическая регистрация адреса I2P (назначения) при создании входящего туннеля GC. Это значительно улучшило бы удобство использования.