commit 4ba72c1d3f22b8dc41a6c4417c61f5f76e197b3a
parent 9a0fd54ae7d79d8d87491c06a3ae555d738b052a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 31 Jul 2022 13:51:43 +0200
minor error
Diffstat:
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/keyconcepts.md b/keyconcepts.md
@@ -74,14 +74,15 @@ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0
You can find your peer identity by running `gnunet-peerinfo -s`.
+
+## Zones in the GNU Name System (GNS Zones)
+
GNS zones are similar to those of DNS zones, but instead of a hierarchy of authorities to governing their use, GNS zones are controlled by a private key. When you create a record in a DNS zone, that information is stored in your nameserver. Anyone trying to resolve your domain then gets pointed (hopefully) by the centralised authority to your nameserver. Whereas GNS, being fully decentralized by design, stores that information in DHT. The validity of the records is assured cryptographically, by signing them with the private key of the respective zone.
Anyone trying to resolve records in a zone of your domain can then verify the signature of the records they get from the DHT and be assured that they are indeed from the respective zone. To make this work, there is a 1:1 correspondence between zones and their public-private key pairs. So when we talk about the owner of a GNS zone, that’s really the owner of the private key. And a user accessing a zone needs to somehow specify the corresponding public key first.
For more information, refer to the following paper:
-## Zones in the GNU Name System (GNS Zones)
-
Matthias Wachs, Martin Schanzenbach, and Christian Grothoff. A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System. In proceedings of 13th International Conference on Cryptology and Network Security (CANS 2014). 2014. https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf
