개요
이 제안은 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 파일에 삽입하여 이루어집니다.
이 기본적으로 작동하지만 자신의 상태에서 발전하는 중이며 완전히 성숙하지 않은 것 같은 이름 서비스에 의존합니다 (특히 이름 배포와 관련하여).
확장 가능한 솔루션
IPv6 주소에 대한 GC의 DNS 역방향 조회를 사용하여 그 프로토콜을 변경하는 방법을 제안합니다. 역방향 영역은 직접 Base32로 인코딩된 256비트 I2P 주소를 포함해야 합니다. 이는 조회 메커니즘을 단일 단계로 바꾸어 추가적인 이점을 제공합니다. IPv6 주소 (이진) -1b-> I2P 주소 (256비트) -1b- … DNS 역방향 조회
인터넷 내에서의 DNS 조회는 익명성과 관련하여 정보 유출로 알려져 있습니다. 따라서 해당 조회는 I2P 내에서 수행해야 합니다. 이는 여러 DNS 서비스가 I2P 내에 있어야 함을 의미합니다. DNS 쿼리는 대개 UDP 프로토콜을 사용하여 수행되므로, GC 자체가 UDP 패킷을 전송할 수 있어야 합니다.
DNS와 관련된 추가적인 이점은 다음과 같습니다:
- 잘 알려진 표준 프로토콜이며 지속적으로 개선되고 있고 많은 도구(클라이언트, 서버, 라이브러리 등)이 존재합니다.
- 분산 시스템입니다. 기본적으로 여러 서버에서 병렬로 호스팅되는 네임스페이스를 지원합니다.
- 암호화를 지원합니다 (DNSSEC). 이는 리소스 레코드의 인증을 가능하게 하며, 목적지의 키와 직접 연결될 수 있습니다.
미래 기회
이 이름 서비스가 순방향 조회를 수행하는 데도 사용할 수 있을 가능성이 있습니다. 이는 호스트 이름을 I2P 주소 및/또는 IPv6 주소로 변환하는 것입니다. 그러나 이러한 종류의 조회는 일반적으로 로컬에 설치된 해결사 라이브러리에 의해 수행되며, 이는 정규 인터넷 이름 서버(예를 들어 Unix와 유사한 시스템의 /etc/resolv.conf에 지정된 것)들을 사용하기 때문에 추가적인 조사가 필요합니다. 또 다른 기회는 I2P 주소(목적지)가 GC 인바운드 터널을 생성할 때 자동으로 등록되는 것입니다. 이는 사용성을 크게 개선할 것입니다.