概述
本提案涉及增加对 I2P 的 DNS 反向查找的支持。
当前的翻译机制
GarliCat (GC) 执行名称翻译以建立与其他 GC 节点的连接。这个名称翻译只是将地址的二进制表示重新编码为 Base32 编码形式。因此，翻译可以来回工作。
这些地址被选择为 80 位长。这是因为 Tor 使用 80 位长的值来寻址其隐藏服务。因此，OnionCat（Tor 的 GC）无需进一步干预即可与 Tor 协作。
不幸的是（就这个寻址方案而言），I2P 使用 256 位长的值来为其服务寻址。如前所述，GC 在二进制和 Base32 编码形式之间进行转码。由于 GC 是一个第 3 层 VPN，在其二进制表示中，地址被定义为具有 128 位总长度的 IPv6 地址。显然，256 位长的 I2P 地址无法适应。
因此，第二个名称翻译步骤变得必要： IPv6 地址（二进制）-1a-> Base32 地址（80 位）-2a-> I2P 地址（256 位） -1a- … GC 翻译 -2a- … I2P hosts.txt 查找
当前的解决方案是让 I2P 路由器执行此任务。这是通过将 80 位 Base32 地址及其目标（即 I2P 地址）作为名称/值对插入到 I2P 路由器的 hosts.txt 或 privatehosts.txt 文件中来实现的。
这基本上是可行的，但它依赖于一个名称服务（个人认为）其本身处于开发状态并且尚不成熟（特别是在名称分发方面）。
一个可扩展的解决方案
我建议改变与 I2P（也许还有 Tor）相关的寻址阶段，使 GC 使用常规 DNS 协议在 IPv6 地址上进行反向查找。反向区应直接包含以 Base32 编码形式的 256 位 I2P 地址。这将查找机制更改为单步骤，从而增加了进一步的优势。 IPv6 地址（二进制）-1b-> I2P 地址（256 位） -1b- … DNS 反向查找
在互联网中执行 DNS 查找被认为是在匿名性方面的信息泄漏。因此，这些查找必须在 I2P 内部进行。这意味着 I2P 内必须存在多个 DNS 服务。由于 DNS 查询通常使用 UDP 协议进行，因此需要 GC 自行进行数据传输，因为其负责承载 UDP 数据包，而 I2P 本身并不具备此功能。
与 DNS 相关的进一步优势：
- 它是一个众所周知的标准协议，因此不断得到改进，并且存在许多工具（客户端、服务器、库等）。
- 它是一个分布式系统。默认情况下，它支持在几个服务器上并行托管命名空间。
- 它支持加密（DNSSEC），这使得资源记录的认证成为可能。这可以直接与目标的密钥绑定。
未来机会
这个命名服务也可能用于正向查找。这是将主机名翻译为 I2P 地址和/或 IPv6 地址。但这种查找需要额外的调查，因为这些查找通常由本地安装的解析程序库执行，该库使用常规的互联网名称服务器（例如，在类 Unix 系统上，它们在 /etc/resolv.conf 中指定）。这与我上面解释的 GC 的反向查找不同。另一个可能性是，当创建 GC 入站隧道时，I2P 地址（目标）会自动注册。这将极大地提高可用性。