如果我的問題沒有在這裡被回答我該怎麼做？

答：還有許多其他信息來源可供您參考。您可以閱讀額外的文件、透過 help-gnunet@gnu.org 郵件清單來詢問問題。

你們打算什麼時候發布下一個版本？

A：一般的答案為，當它準備好時。一個更佳的答案可能為：更早，若您做出貢獻（測試、除錯、編碼、紀錄）。所有的發表都會在 info-gnunet@gnu.org 的郵件清單以及 planet GNU 上公布。您可以訂閱此網站的寄件清單或是 RSS feed 以自動獲取通知。

程式碼是免費的嗎？

答：GNUnet是自由軟體，您可以根據GNU Affero 公共許可證 (AGPL) 來取得。

是否有任何已知的錯誤？

A：我們從 Mantis 系統追蹤已知的錯誤。有些錯誤偶爾會直接報告給開發人員或開發人員郵件列表。然而，由於開發人員通常沒有時間將這些錯誤放入 Mantis 資料庫，我們不鼓勵這種做法。請直接向錯誤跟踪系統報告錯誤。如果您認為某個錯誤是敏感的，您可以將其視圖狀態設置為私有（這應是例外）。

有圖形用戶界面嗎？

A：gnunet-gtk 是單獨下載的。這個組件包含各式以 GTK+ 為基礎的圖像介面，其中包含一個用於配置的圖像工具。

為什麼 gnunet-service-nse 會造成較高的 CPU 負載？

答：gnunet-service-nse 流程最初會計算出一個所謂的 "proof-of-work （工作量證明）" 用於說服網路您的對等實體是真實的（亦或者，使對手對網路規模估計器發起 Sybil 攻擊的成本很高）。取決於你的 CPU 有多快，此計算預計需要幾天的時間。如果 CPU 負載給您帶來問題，您可以在配置文件的 "nse" 部分中將設置值 "WORKDELAY" 設置為更高的值。

GNUnet 與 Tor 相比如何？

A: Tor 著重於（尤其是 Web 的）TCP 連接的匿名通信和抗審查，以及 Tor 瀏覽器捆綁包。GNUnet 則沒有一個特定的焦點；我們的主題是安全的去中心化網路，但這太廣泛了，不能稱之為一個焦點。

GNUnet 與 I2P 相比如何？

A：GNUnet 和 I2P 都希望建立一個更好、更安全、更分散的網際網路。然而，在技術層面上，兩者幾乎沒有重疊。

I2P 以 Java 撰寫，並具有使用洋蔥（或大蒜）路由的（非對稱）隧道作為各種（匿名）應用程式的基礎。I2P 則主要通過 Web 前端使用。

GNUnet 準備好在生產系統上使用了嗎？

A：GNUnet 仍然在經歷重大的發展。它在很大程度上還沒有準備好供開發人員使用。您的使用過程將根據您使用的功能而有所不同，但您可能會遇到我們當前的低階運輸系統的問題。我們目前正在重寫這些部分。（項目 "Transport Next Generation [TNG]"）

GNUnet 是否使用分佈式分類帳技術建構？

A：答案是否定的。GNUnet 是一個新的網絡協議棧，用於構建安全、分佈式和隱私保護的應用程式。雖然可以使用 GNUnet 構建分類帳，但我們目前沒有這樣的計劃。

我可以用 GNUnet 做什麼？

A：GNUnet 是一個點對點框架，我們主要是指它可以做的不僅僅是一件事。理所當然地，一些現有功能的實現與文檔比其他功能更先進。

GNUnet 提供用戶匿名和非匿名文件共享、完全去中心化和抗審查的 DNS 替代品以及 IPv4-IPv6 協議轉換和隧道機制（帶有 DNS-ALG 的 NAT-PT）。 See also: Applications.

是否可以使用 GNUnet 匿名瀏覽 WWW？

答：目前無法使用 GNUnet 進行匿名瀏覽。我們建議您使用 Tor 來匿名上網。

是否可以通過瀏覽器作為匿名 WWW 訪問 GNUnet？

A：目前沒有可以通過瀏覽器訪問 GNUnet 的代理（如 Freenet 中的 fproxy）。但僅需知道瀏覽器和代理之間使用的協議以及用於文件共享的 GNUnet 代碼，是可能構建這樣的代理的。

有圖形用戶界面嗎？

A：實際上有幾個圖形用戶介面可用於不同的功能。gnunet-setup 可用來配置 GNUnet，而 gnunet-fs-gtk 則可用來分享檔案。還有其他次為重要的 gnunet-XXX-gtk GUIs。請注意，為了獲得 GUI，您需要安裝一個單獨的下載的 gnunet-gtk 包。 gnunet-gtk 是一個元 GUI (meta GUI)，它在一個窗口中合併了大多數其他 GUI。其中一個例外是 gnunet-setup，此時它仍必須分開運行（因為設定原因，需要對等方停止）。

GNUnet 在哪些操作系統上運行？

A：GNUnet 主要在 Debian GNU/Linux 下開發和測試。此外，我們經常在 Fedora、Ubuntu、Arch、FreeBSD 和 macOS 上構建和測試 GNUnet。我們有許多其他 GNU/Linux 發行版的工作版本報告；在過去，我們曾有關於 NetBSD、OpenBSD 和 Solaris 上的工作版本的報告。然而，並不是所有這些報告都是近期的，所以如果您無法讓 GNUnet 在這些系統上工作，請您通知我們。

誰負責運行 GNS 根區域 (root zone)？

A：一個簡短的答案為：你。一個較長的回答則是：GNUnet 將運送頂級域的默認配置。此默認配置的管理體系尚未建立。在任何情況下，用戶都可以隨意修改此配置。我們希望，除非用戶自行託管此服務，普通用戶無需編輯自己的 GNS 區域。

每個用戶的 GNS 資料庫保存在哪裡？

A：簡短的回答是-- 資料庫被保存於用戶的 GNUnet peer。目前，一個用戶可以運行多個 GNUnet peer，在這種情況下，資料庫可以被保存在每個 peer 上（但是我們沒有方便複製的程式碼）。同樣地，多個 GNUnet peer 可以共享一個資料庫實例--- "gnunet-service-namestore" 可以（透過 TCP）進行遠程訪問。實際資料可以存儲在 Postgres 資料庫中，且各種複制選項同樣適用於該資料庫。結論上，用戶有很多選擇來存儲（和保護）他們的 GNS 資料庫。

GNS 域名存儲資料庫(namestore database)的預期平均大小為多少？

A：很小。根據我們查看瀏覽器歷史記錄和訪問域數的用戶研究，我們預計 GNS 資料庫只會增長到幾萬個條目，小到甚至可以安裝在行動裝置上。

GNS 是否可以抵抗美國使用的 DNS 攻擊?

A：我們相信是如此，因為除了每個個人用戶之外，沒有任何實體可以強制任何政府更改名稱的映射（然後此更改將僅適用於該用戶有權使用的名稱）。因此，如果每個人都使用 GNS，那麼政府唯一的實際攻擊即為強迫服務器的操作員更改其服務器的 GNS 記錄以指向其他地方。但是，如果某個區域的私鑰所有者不可用於強制執行，則無法更改相應的區域，且委派給該區域的任何其他區域都將獲得正確的解決方案。

GNS 與其他名稱系統 (name systems) 相比如何？

答：有關該主題的科學論文已被發表，以下是該出版物的表格。請參閱該論文以閱讀更多細節及描述。

GNS 和 CoDoNS 有什麼區別？

A：CoDoNS 分散了 DNS 資料庫（使用 DHT）但保留了 DNS 的權限結構。有了CoDoNS，IANA/ICANN 仍然擁有主導權，並依然有註冊商決定誰擁有名稱。

有了GNS，我們分散了資料庫，也分散了命名的責任：每個用戶都運行自己的個人根區域，因此用戶可以完全控制他們使用的名稱。GNS 還具有許多附加功能（以保持簡短的名稱並啟用遷移），這些功能在 CoDoNS 的環境中甚至沒有意義。

GNS 和 SocialDNS 有什麼區別？

A：如同 GNS，SocialDNS 允許每個用戶創建 DNS 映射。然而，使用 SocialDNS 的映射通過社交網路共享並進行排名。隨著社會關係的發展，名稱可能會以令人驚訝的方式發生變化。

使用 GNS 時，名稱主要通過委託來共享，因此只有當負責名稱的用戶（權限）手動更改記錄時，映射才會有所改變。

GNS 和 ODDNS 有什麼區別？

A：ODDNS 主要旨為繞過 DNS 根區和 TLD 註冊機構（例如".com"和".org"的註冊機構）。用戶們不應使用這些，每個用戶都應該維護一個（二級）域如"gnu.org"）的資料庫和各自名稱伺服器的 IP 地址。如果目標名稱伺服器更改 IP，那麼分解將會失敗。

GNS 和 Handshake 有什麼區別？

A：握手 (Handshake) 是一種基於區塊鏈的根區治理方法。因此，它不解決名稱分解 (name resolution) 過程本身，而是在初始 TLD 分解 (TLD resolution) 後將解析委託給 DNS。若不將可持續性列入考量，Handshake 可以用作額外的支持 GNS 根區治理的模型，但我們目前沒有這樣的計劃。

GNS 和 SocialDNS 有什麼區別？

A：TrickleDNS 在參與域的 DNS 解析器之間推送（"關鍵的"）DNS 記錄，以提供 "更好的可用性、更短的查詢解析時間和更快的更新傳播"。因此，TrickleDNS 專注於擊敗對 DNS 中記錄傳播的可用性（和性能）的攻擊，例如透過對 DNS 根服務器的 DDoS 攻擊。因此，TrickleDNS 關注如何確保權威記錄的分發，而權威仍然來自 DNS 層次結構。

GNS 是否需要以 PGP 信任網路 (PGP web of trust) 的方式進行真實世界的介紹（安全的 PKEY 交換）？

A：為了安全起見，眾所周知，兩方之間必須存在初始信任路徑。然而，對於不需要這樣做的應用程式，可以使用較弱的機制。例如，我們實施了先到先得 (first-come-first-served; FCFS) 權限，允許任意用戶註冊任意名稱。此權限的密鑰包含在每個 GNUnet 的安裝中。因此，任何在 FCFS 註冊的名稱實際上都是全球性的，不須被進一步介紹。但是，這些名稱的安全性完全取決於 FCFS 機構的可信度。而這些機構可以在 ".pin" TLD 被查詢到。

合法的域名所有者如何告知他人不要在 GNS 中使用其名字？

A：名稱在 GNS 中沒有所有者，因此不能存在"合法的"域所有者。任何用戶都可以在他的 NICK 記錄中要求擁有任何名稱（作為他的首選名稱或"假名"）。同樣地，所有其他用戶都可以選擇忽略此偏好並使用他們自選的名稱（甚至不指定名稱）。

您是否考慮過使您的個人 GNS 區域可見對隱私的影響？

A：GNS中的每條記錄都有一個"私有"標誌。僅當未設置此標誌時，記錄才會（通過 DHT 或區域傳輸）與其他用戶共享。因此，用戶可以完全控制公開其區域的哪些信息。

"傳統主機" (LEHO) 記錄不會因 IPv6 而過時嗎？

A：這個問題假設 (a) 虛擬主機只是因為 IPv4 位址稀缺而為必要，以及 (b) LEHO 僅在虛擬主機的環境中有用。然而，LEHO 也有助於 X.509 證書驗證（因為它們指定證書應該對哪個舊主機名有效）。此外，即使完全部署了 IPv6 且有 "無限的"IP 位址可以使用，我們不確定虛擬主機是否會消失。最後，我們不想等 IPv6 變得普遍，GNS 應該與今日的網路配合使用。

為什麼 GNS 不使用信任度量 (trust metric) 或共識來確定全球唯一名稱？

A：「閾值」為信任度量的一個根本問題。隨著信任關係的發展，映射的含義會在跨越彼此閾值時改變。我們認為由此導致解決過程的不可預測性是無法接受的。此外，信任和共識可能很容易被對手操縱。

您如何處理 GNS 中受損的區域密鑰 (zone keys)？

A：私鑰的所有者可以創建一個撤銷消息 (revocation message)。其可以充滿整個覆蓋網絡，在所有對等點創建一個副本。在使用公鑰之前，對等方檢查該密鑰是否已被撤銷。所有通過撤銷區域委託的名稱都將無法解析。在解析名稱時，對等方皆會自動檢查撤銷消息的存在。

將來可以升級 GNS 的簽名演算法 (signing algorithm) 嗎？

A：是的。我們已經修改了協議以支持替代委託記錄並努力地標準化 GNS。

理所當然地，為了支持新的簽名方案，部署的 GNS 實現必須更新。通過使用新的記錄類型來指示不同密碼系統的使用，新方案可以與現有系統并行運行。

GNS 區域如何維護多個名稱伺服器 (name servers)，如: 負載平衡 (load balancing)？

A：我們不認為這是必要的，因為 GNS 記錄被存儲（和複製）在 R5N DHT 中。因此，每當客戶端執行查找時，通常不會聯繫權限 (authority)。即使權限（暫時）離線，DHT 也會緩存記錄一段時間。然而，如果一個區域有多個伺服器被認為是必要的，區域的所有者可以簡單地運行多個對等點（並在它們之間共享區域的密鑰和資料庫）。

你們為什麼認為值得為了抵抗審查 (censorship resistance) 放棄獨特名稱 (unique names)？

A：GNU 名稱系統提供了一種抗審查的 DNS 替代方案。與任何安全機制一樣，這是需要付出代價的（名稱不是全球唯一的）。與 HTTP 連接相比，HTTPS 連接使用更多頻寬且有更高的網路延遲。根據您的應用程式，HTTPS 可能不值得其所需要付出的代價。然而，對於正在經歷審查（或擔心審查）的用戶來說，放棄全球唯一名稱可能十分值得。畢竟， 如果這個問題不被解決的話，"全球"唯一的名字又值得多少？

為什麼說 DNS 為"集中式"與"分佈式"的？

A：我們說 DNS 是"集中式"的，因為它有一個中心元件/中心故障點 --- 根區及其管理（由IANA/ICANN 所管理）。這種集中化會造成漏洞。例如，在 21 世紀初的戰爭期間，美國政府能夠重新分配對阿富汗和伊拉克國家頂級域名 (country-TLDs) 的管理。

GNS 如何防止第 3 層審查 (layer-3 censorship)？

A：GNS不能直接幫助進行第3層審查，但它可以通過兩種方式間接幫助：

1. 如今，許多網站都使用虛擬主機，因此，阻擋特定的 IP 位址比阻擋 DNS 名稱造成的附帶損害要大得多。這因此它增加了審查的成本。
2. 現有的第 3 層規避解決方案（例如 Tor）將受益於抗審查命名系統。訪問 Tor 的".onion" 命名空間目前要求用戶使用不易記住的加密標識符。有了更好的名稱，Tor 和類似 tor2web 的服務將更容易使用。

GNS 是否可以與搜索引擎一起使用？

A：GNS 不會對搜尋引擎造成重大問題，因為它們可以像任何普通用戶一樣使用 GNS 執行名稱解析。自然地，雖然我們通常希望普通用戶安裝自定義軟體進行名稱解析，但這不太可能適用於今日的搜尋引擎。然而，DNS2GNS 閘道器允許搜尋引擎使用 DNS 來解析 GNS 名稱，因此它們仍然可以將 GNS 資源編入索引。然而，由於使用 DNS2GNS 閘道器打破了加密信任鏈，傳統搜尋引擎顯然無法獲得抗審查的名稱。

GNS 如何與非託管網路體系架構 (Unmanaged Internet Architecture; UIA) 相比？

A：UIA 和 GNS 共享相同（實際上起源於 Rivest 的SDSI）的基本命名模型。然而，UIA 並不關心與舊有應用程式的整合，而是專注於該用戶多台機器之間的通用連接。相較之下，GNS 旨在盡可能多地與 DNS 相互操作，並儘可能多地與現有的 Web 基礎設施協同工作。UIA 則旨不在舊有系統 (clean slate)。

與 DNS (SEC) 相比，GNS 不會增加其可信計算基 (trusted-computing base) 嗎？

A：首先，在 GNS 中您可以明確地看到信任鏈，所以您知道您正在解析的名字屬於您的朋友、或是朋友的朋友，您可以從而決定此結果的可信任程度。自然地，可信賴計算基地 (trusted-computing base; TCB) 可以通過這種方式變得無限大——但是，考慮到名稱長度限制，單個名稱總是少於大約 128 個實體 (entities)。

GNS 如何處理服務和協議是域名的一部份的 SRV/TLSA 記錄？

A：GNS在將域名拆分為標籤進行解析時，會檢測到 "_Service._Proto"語法，將 "Service" 轉換為對應的埠號，並將 "Proto" 轉換為對應的埠號。其餘的名稱可以照常解析。然後，當結果出現時，GNS 會尋找 GNS 特定的 "BOX （盒子）" 記錄類型。BOX 記錄是包含另一條記錄（例如 SRV 或 TLSA 記錄）並向其添加服務和協議編號（以及原始盒裝記錄類型）的記錄。

我收到許多 "警告：對於Z的Y處X計算流量延遲"。請問我需要擔心嗎？

A：在此時，這是意料之中的，也是 GNUnet 高度延遲的一個已知原因。我們已開始進行重大改寫以解決此問題和其他問題，但在下一代傳輸 (Transport Next Generation; TNG) 準備就緒之前，這些警告仍在預期之中。

開啟 '/dev/net/tun' 時出現錯誤：沒有此文件或目錄？

A：若您收到此錯誤訊息，解決方法很簡單。發出以下命令（以root用戶身份）創建所需的設備文件 # mkdir /dev/net
# mknod /dev/net/tun c 10 200


'iptables: 沒有該名稱的鍊 (chain)/目標/匹配項目。'（運行gnunet-service-dns時）？

A：對於GNUnet DNS，您的 iptables 需具有 "所有者" 匹配支持。這可以通過使用正確的內核 (kernel) 選項來達成。請檢察您的內核的CONFIG_NETFILTER_XT_MATCH_OWNER 是否已設定為 'y' 或是 'm'（並且已載入模板）。

在 Fedora（或其他）上運行 PT 時"已超時"？

A：如果收到指出已達到 VPN 超時的錯誤訊息，請檢查您的防火牆是否為啟用狀態且阻擋連線。

我在載入共享庫 (shared libraries) 時遇到 '錯誤：libgnunetXXX.so.X'

A：這種錯誤通常發生在鏈接器無法找到 GNUnet 程式庫時。有兩種原因可能會造成此現象。其中一種原因為，理論上，您的系統上可能沒有安裝該程式庫；但是，如果您以正常方式編譯 GNUnet 和/或使用二進制包 (binary package)，此現象則不太可能是這種原因造成的。更常見的原因為，您將 GNUnet 安裝到鏈接器未搜索的目錄中。以下提供幾種方法解決此問題。如果您是 "root" 並且將 GNUnet 安裝至系統文件夾（例如 /usr/local），您需要將程式庫添加到系統範圍的搜索路徑中。您可以通過在 /etc/ld.so.conf 中添加一行 "/usr/local/lib/" 並運行 "ldconfig" 來完成此步驟。如果您將 GNUnet 安裝到 /opt 或任何其他類似路徑，顯然地，您必須更改相對應的 "/usr/local"。如果您沒有 "root" 權限，或者您安裝 GNUnet 時表示 "/home/$USER/"，那麼您可以明確地告訴您的鏈接器使用 "LD_LIBRARY_PATH" 環境變量以在特定目錄中搜索程式庫。舉例來說，如果您使用前綴 "$HOME/gnunet/" 來配置 GNUnet，您則要運行：

我可以忽略哪些錯誤訊息？

A：在為最終用戶構建的二進製文件中應禁用標記為"DEBUG"的錯誤訊息，並且始終可以被忽略。標記為"INFO"的錯誤訊息則為不需要進行操作的無害事件。舉例來說，GNUnet 可能使用 INFO 訊息來表示它目前正在執行需要一些時間的昂貴操作。GNUnet 也使用 INFO 訊息來顯示有關重要配置值的資訊。

GNUnet 與其他文件共享應用程式相比如何？

A：與 Napster、Gnutella、Kazaa、FastTrack、eDonkey 和大多數其他對等式網路（P2P 網路）不同，GNUnet 的設計將安全性作為最主要優先項目。我們打算製造一個具有全面安全功能的網路。許多其他 P2P 網路容易受到各式各樣的攻擊、用戶幾乎沒有隱私。GNUnet 也同時是個自由軟體，因此程式碼可以被使用，您不必擔心被軟體監視。下表總結了 GNUnet 和其他系統之間的主要區別。該表格內的訊息為據我們所知最準確的資訊。其中，要比較不同系統之間的差異不是很容易，因為有時候（幾乎）相同協議的各種實現之間存在差異。因為自由程式碼 (free code)可以被檢查，我們通常選擇自由實現 (free implementation)作為我們的參考實現 (reference implementation)。此外，由於這些系統都會隨著時間變化，以下的資料可能不是最新的。若您發現任何錯誤，請您告訴我們。最後，由於表格並沒有解釋太多（很難簡單地比較這些系統），如果您想要了解這些系統之間真正的差異，請您參考研究論文（或許加上程式碼）。

另一個重要的參考點是各種匿名的對等網路 (peer-to-peer networks)。於此，在應用領域和具體匿名實現方式方面存在差異。匿名路由 (Anonymous routing) 是一項艱鉅的研究課題，因此對於像這樣的表面對比，我們會著重於網路延遲 (latency) 的比較。另一個重要因素為程式語言。類別型安全語言 (Type-safe languages) 可能可以提供某些安全性優勢；然而，資源消耗的顯著增加可能為其所需付出的代價，而這反過來可能會降低匿名性。

是否存在任何（在GNUnet的文件共享應用程序上）已知的攻擊？

A：一般來說，出現針對關鍵字的已知明文攻擊 (known plaintext attack) 是有可能的，但是由於用戶可以控制與其所插入內容相關的關鍵字，用戶可以利用用於生成合理密碼的相同技術來進行保護，以抵制這種攻擊。無論如何，我們不會試圖隱藏內容；因此，除非用戶試圖將只能與一小群人共享的訊息插入網路，用戶並沒有真正的理由去選擇一個困難的關鍵字來混淆內容。

匿名是什麼意思？

A：匿名是指個人與（大）群體之間缺乏區別性。GNUnet 中匿名文件共享的一個中心目標是讓所有用戶（對等點）組成一個群組，並使該群組中的通信匿名，也就是說，沒有人（除了發起者）該有能力知道該群組中的哪些對等點發起了消息。換句話說，對手應該很難、甚至不可能區分原始對等點和所有其他對等點。

我的系統在參與 GNUnet 文件共享時會做什麼？

A：您在GNUnet中設置一個節點（一個對等點）。其由一個 ID（其公鑰的雜湊）標識，並且有許多可訪問的位址（可能沒有位址，例如當它位於 NAT 後面時）。您指定頻寬限制（允許 GNUnet 消耗多少流量）和資料存儲報價（您的磁碟區存儲量有多大）。然後您的節點將繼續連接到其他節點，然後成為網路的一部分。

我如何幫助將此網頁翻譯成其他語言？

A：首先，您需要在我們的 weblate 系統註冊一個賬號。請將含有您目標語言的電子郵件發送至 translations@gnunet.org 或在 irc.freenode.net 上的#gnunet chat 中尋求幫助。通常，具有足夠權限的人會授予您訪問權限。但當然地，任何的濫用行為都會導致您喪失權限。

我有一些關於新功能的好主意，我該怎麼做？

A：很可惜地，我們收到的功能請求比我們可能實現的功能來得多。能夠實際地實現新功能的最佳方法為自己做——並向我們發送程式補丁(patch)。