RFC 9498 - GNU名システム

このドキュメントは、GNU名システム（GNS）の技術仕様を提供します。GNSは、ドメイン名システム（DNS）プロトコルに代わるプライバシーを強化する代替手段を提供する、分散型の検閲耐性ドメイン名解像度プロトコルです。

このドキュメントでは、リソースレコード、解像度プロセス、暗号化ルーチン、および実装者が使用するためのセキュリティとプライバシーの考慮事項の規範的なワイヤ形式を定義します。

この仕様はIETFの外側で開発され、IETFコンセンサスはありません。ここでは、GNSの機能について読者に通知し、将来のGNSの実装をガイドし、実装間の相互運用性（たとえば、既存のGNUNET実装）を確保するために公開されています。

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9498で取得できます。

著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

この仕様では、GNU名システム（GNS）、検閲抵抗性、プライバシー普及、および分散型ドメイン名解像度プロトコルである説明されています。GNSは、名前の名前の拘束力を任意のトークンに暗号化し、今日の公開キーインフラストラクチャのいくつかに代わるものとして、いくつかの点で2倍にすることができます。

ドメイン名システム（DNS）の用語[RFC1035]ごとに、GNSはローカルルートゾーンの展開のアイデア（[RFC8806]を参照）にほぼ従っています。特定のルートゾーン。GNS参照実装では、ユーザーはローカル構成を介して名前の制御をゾーンに自律的かつ自由に委任できます。GNSは、各ユーザーがセットアップを制御することを期待しています。セクション9.10のガイドラインに従うことにより、ユーザーは名前の解決方法に関する混乱を避けることができます。

名前の解像度とゾーンの普及は、ユーザーがゾーンにローカル名を割り当てることができるPetNameシステムの原則に基づいています。GNSは、単純な分散セキュリティインフラストラクチャ[SDSI]からのアイデアにルーツを持ち、セキュア識別子の分散マッピングを記憶に残る名前に可能にします。GNSの背後にある暗号化のアイデアの最初の学術的説明の1つは、[GNS]にあります。

このドキュメントでは、リソースレコード、解像度プロセス、暗号化ルーチン、および実装者が使用するためのセキュリティとプライバシーの考慮事項の規範的なワイヤ形式を定義します。

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

APEXラベル：このタイプのラベルは、特定のラベルを提供せずに解決できるゾーンでリソースレコードを公開するために使用されます。これは、DNS [RFC4033]の「ゾーンアペックス」と呼ばれるものを提供するためのGNSメソッドです。頂点ラベルは、文字u 0040（ "@" quotesなし）を使用して表されます。

アプリケーション：アプリケーションは、GNS実装を使用して名前をレコードに解決し、その内容を処理するコンポーネントです。

ブラインドゾーンキー：ブラインドゾーンキーは、ゾーンキーとラベルから派生したキーです。ゾーンキーと、導出された特定のラベルの知識なしに、ゾーンキーとそれから導出された視覚障害ゾーンキーは、リンクできません。

拡張ラベル：このタイプのラベルは、レコードがある権威あるゾーンを参照するために使用されます。拡張ラベルの主要な使用は、リダイレクトターゲットがリダイレクトレコードの権威あるゾーンと比較して定義されるリダイレクションです（セクション5.2を参照してください。）。拡張ラベルは、文字u 002b（ "" quotesなし）を使用して表されます。

ラベルセパレーター：名前のラベルは、引用符なしでラベルセパレーターu 002e（ "。"）を使用して分離されます。GNSでは、ゾーントップレベルドメイン（ZTLDS）（以下を参照）およびボックスレコード（セクション5.3.3を参照）を除く、名前のすべてのラベルセパレーターは別のゾーンへの委任を示しています。

ラベル：GNSラベルは、[RFC8499]で定義されているラベルです。ラベルは、ユニコード正規化形式C（NFC）[Unicode-Uax15]のUTF-8弦です。Apexラベルと拡張ラベルは、このドキュメントの残りの部分で定義されている解像度プロトコルに特別な目的を持っています。ゾーン管理者は、登録ポリシーを通じて他のラベルと簡単に混同される可能性のある特定のラベルを許可する場合があります（セクション9.4も参照）。

名前：GNSの名前は[RFC8499]で定義されているドメイン名です：名前はUTF-8文字列[RFC3629]です。名前は右端のラベルから解決されます。GNSは、名前やラベルに長さの制限を課しません。ただし、アプリケーションは、名前とラベルの長さがDNS、特にアプリケーション（IDNA）の国際化ドメイン名と互換性があることを保証する場合があります[RFC5890]。[RFC5895]の精神では、アプリケーションは、[Unicode-UTS46]によると、DNSとの互換性を確保したり、特定のユーザーの期待をサポートしたり、特定のユーザーの期待をサポートしたりするためにプリプロース名とラベルを付けることができます。GNS名はDNS名と区別できない場合があり、GNS名を処理する際には、アプリケーションと実装者が注意する必要があります（セクション9.10を参照）。（予約済みの）DNSドメインを使用したサンプルドメインの誤解を避けるために、このドキュメントは[RFC9476]に準拠して接尾辞「.gns.alt」を使用します。「.gns.alt」は、gana ".alt subdomains" registry [gana]にも登録されています。

リゾルバー：このドキュメントでは、リゾルバーは、セクション7で定義された再帰名解決ロジックを提供するGNS実装のコンポーネントです。

リソース記録：GNSリソースレコードは、GNSゾーンのラベルに関連付けられた情報です。GNSリソースレコードには、リソースレコードタイプで定義されている情報が含まれています。

開始ゾーン：特定のGNS名を解決するには、この名前の初期開始ゾーンを決定する必要があります。スタートゾーンは、ZTLDを使用して名前の一部として明示的に定義できます。それ以外の場合は、ローカルサフィックスからゾーンのマッピングを介して決定されます（セクション7.1を参照）。

トップレベルのドメイン（TLD）：GNS名の右端の部分はGNS TLDです。GNS TLDは、1つ以上のラベルで構成できます。DNS TLD（[RFC8499]で定義）とは異なり、GNSはすべてのユーザーが同じグローバルルートゾーンを使用することを期待していません。代わりに、ZTLDSを除き（セクション4.1を参照）、GNS TLDは通常、ローカルリゾルバーの構成の一部であり（セクション7.1を参照）、したがってグローバルに一意ではない可能性があります。

ゾーン：GNSゾーンには、権威ある情報（リソースレコード）が含まれています。ゾーンは、ゾーンキーによって一意に識別されます。DNSゾーンとは異なり、GNSゾーンはApexラベルの下にSOAレコードを持つ必要はありません。

ゾーンキー：ゾーンキーは、ゾーンを一意に識別するキーです。通常、非対称キーペアの公開鍵です。ただし、GNSではゾーンキーが不正な当事者に開示されるべきではない共有秘密である可能性があるため、確立された技術用語「公開鍵」は誤解を招くものです。

ゾーンキー派生関数：ゾーンキー派生関数（ZKDF）は、ラベルを使用してゾーンキーをブラインドします。

ゾーンパブリッシャー：ゾーンパブリッシャーは、セクション6で定義されているようにローカルゾーンの管理と出版物を提供するGNS実装のコンポーネントです。

ゾーン所有者：ゾーン所有者は、秘密の所有者（通常は秘密鍵）であり、（ラベルと署名の値とともに）それぞれの盲検ゾーンキーにg to decode the labels into a zone type and zone key.

ゾーントップレベルドメイン（ZTLD）：GNS ZTLDは、GNS名の最後にあるGNSラベルのシーケンスです。ZTLDは、ゾーンのゾーンタイプとゾーンキーをエンコードします（セクション4.1を参照）。ゾーンキーの統計的な一意性により、ZTLDもグローバルに一意です。ZTLDラベルシーケンスは、ラベルをゾーンタイプとゾーンキーにデコードしようとすることにより、通常のTLDラベルシーケンスとのみ区別できます。

ゾーンタイプ：GNSゾーンのタイプは、ゾーンキー、ブラインドゾーンキー、暗号化署名の暗号システムとバイナリエンコード形式を決定します。

GNSは、PetNameシステムを説明するために一般的に使用される3つのプロパティを示します。

ZTLDSの概念によるグローバル名：ゾーンはゾーンキーによって独自に識別できるため、統計的に一意であるため、ZTLDはゾーンのグローバルに一意のマッピングです。その結果、ZTLD接尾辞を備えたGNSドメイン名もグローバルに一意です。ZTLDの接尾辞の名前は記憶に残るものではありません。

ゾーン用の記憶に残るPetNames：ユーザーは、ゾーンへのローカルで記憶に残る参照を構成できます。このようなPetNamesは、地元のオペレーターにゾーンの便利な名前を提供するZTLDモニカーとして機能します。PetNamesは、それぞれのゾーンを参照するときに使用する良いラベルを検索する他のユーザーのための提案として公開される場合があります。

名前からレコードへの安全なマッピング：GNSにより、ゾーンオーナーはラベルをリソースレコードにマッピングしたり、ラベルによって誘発されたサブドメインの名前の権限を他のゾーンに委任できます。ゾーンオーナーは、この情報を公開して、他のユーザーが利用できるようにすることを選択できます。マッピングは、リモートストレージで公開される前に、それぞれのラベルから派生したキーを使用して暗号化および署名されます。名前が解決されると、代表団を含むリソースレコードの署名が再帰的なリゾルバーによって検証されます。

このドキュメントの残りの部分では、「実装者」とは、開発者がResolver、Zone Publisher、Start Zoneなどのサポート構成を含むGNS実装を構築することを指します（セクション7.1を参照）。

上記から、GNSはグローバルで、安全で、記憶に残る名前をサポートしていないということです。代わりに、名前はグローバルであり、記憶に残るものではないか、グローバルにユニークで記憶に残るものではありません。ゾーン内のレコード「例」を指すグローバル名の例は次のとおりです。

example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884

ここで、ユーザーが上記の名前の「例」レコードでゾーンのpetName「pet.gns.alt」をローカルに構成した場合を検討してください。「embles.pet.gns.alt」という名前は、上記のグローバルに一意の名前と同じレコードを指しますが、名前の解決は「pet.gns.alt」petnameが構成されているローカルシステムでのみ機能します。

PetNamesの委任とその後の委任の解決は、単純な分散セキュリティインフラストラクチャ[SDSI]からのアイデアに基づいて構築されています。GNSでは、システムがゾーンパブリッシャーの実装を提供する場合は、ゾーンの任意の数のゾーンを作成および管理できます（セクション4を参照）。各ゾーンについて、ゾーンタイプは、暗号化されたデータ、パブリックキー、および署名の暗号化操作のそれぞれのセットとワイヤ形式を決定します。ゾーンには、所有者がラベルからリソースレコード（セクション5を参照）までのマッピングを入力できます。ラベルは、代表団の記録にマッピングできます。これにより、対応するサブドメインが別のゾーンに委任されます。サブドメインをその直接の親ゾーンに委任するなど、円形の代表団は明示的に許可されています。（レガシー）アプリケーションをサポートし、PetNamesの使用を促進するために、GNSは既存のDNSレコードのサポートに加えて補助レコードタイプを定義します。

ゾーンの内容は、図1に示すように、リモートキー値ストレージで公開される前に暗号化および署名されています（セクション6を参照）。このプロセスでは、キーブラインドの使用を通じてネットワークから一意のゾーン識別が隠されています。キーブラインドにより、盲検化されたパブリック/プライベートキーペアを使用して、ゾーンコンテンツの署名を作成できます。この盲検化は、元のゾーンキーからの決定論的キーの派生を使用して、盲検化因子が導き出される入力としてレコードレーベル値を使用して対応する秘密キーを使用して実現されます。具体的には、ゾーンの所有者は、ラベルの下で公開された各レコードセットの盲検化されたプライベートキーを導き出すことができ、リゾルバーは対応する盲目のパブリックキーを導き出すことができます。GNSの実装は、専用のインフラストラクチャを必要とせずにネットワーク内での可用性を促進するために、分散ハッシュテーブル（DHTS）などの分散型リモートストレージエンティティを使用することが期待されています。このような分散または分散型ストレージエンティティの仕様は、このドキュメントの範囲外ですが、既存の実装には[RFC7363]、[Kademlia]、または[R5N]に基づくものが含まれます。

ユーザーがゾーンを作成および管理できるようにするために、GNS実装の一部としてゾーンパブリッシングの実装を提供する必要があります。この機能が実装されていない場合、名前解決の初期ステップのゾーンキーが構成されている場合（セクション7を参照）、または名前がZTLD接尾辞で終了する場合、名前を解決できます。

アプリケーションは、Resolverを使用してGNS名を調べます。構成可能な開始ゾーンから始まる名前は、図2に示すように、ゾーン代表団を再帰的にフォローすることで解決されます。名前の各ラベルについて、再帰GNSリゾルバーはストレージレイヤーからそれぞれのレコードセットを取得します（セクション7を参照）。ラベル値とゾーンキーに関する知識がなければ、異なる派生キーは、元のゾーンキーと互いの両方にリンクできません。これにより、ゾーンの列挙が防止されます（高価なオンラインブルートフォース攻撃を除く）：クエリまたは特定のゾーンを使用した対応する暗号化されたレコードセットの提携を確認するには、ゾーンキーとラベルの両方の知識が必要です。プロトコルによるストレージ。同時に、暗号化された各レコードセットに関連付けられたブラインドゾーンキーとデジタル署名により、リゾルバーと忘却のリモートストレージが、発信ゾーンやレコードセットについて何も開示せずに公開された情報の整合性を検証することができます。