summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2022-08-07 20:00:12 +0200
committerChristian Grothoff <christian@grothoff.org>2022-08-07 20:00:12 +0200
commit07f6bc8646568573cb8aa732701ced2e3692e831 (patch)
treebe7364eabba12420a0f3cfa7a9a527beb798bacc
parent9c73fb68ecdc3122f58b1ca1a750eeb4b6411392 (diff)
restructure intro
-rw-r--r--draft-schanzen-gns.xml62
1 files changed, 30 insertions, 32 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 7f99a2b..a90c318 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -111,45 +111,43 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- The Domain Name System (DNS) <xref target="RFC1035" /> is a unique
- distributed database and a vital service for most Internet applications.
- However, it was not designed with security in mind. This makes it very
- vulnerable, especially to attackers that have the technical capabilities
- of an entire nation state at their disposal.
+ This specification describes the GNU Name System (GNS), a
+ censorship-resistant, privacy-preserving and decentralized
+ domain name resolution protocol. GNS can bind names to any
+ kind of cryptographically secured token, enabling it to double
+ in some respects as an alternative to some of today’s public
+ key infrastructures.
</t>
<t>
- This specification describes a censorship-resistant, privacy-preserving
- and decentralized domain name resolution protocol:
- The GNU Name System (GNS), a development continuation of
- previous academic work on secure name systems <xref target="GNS" />.
- GNS can bind names to any kind of
- cryptographically secured token, enabling it to double in some respects as
- an alternative to some of today’s Public Key Infrastructures, in
- particular X.509 for the Web.
+ In the terminology of the Domain Name System (DNS) <xref
+ target="RFC1035" />, GNS roughly follows the idea of a local
+ root zone deployment (see <xref target="RFC8806"/>), with the
+ difference that the design encourages alternative roots and
+ does not expect all deployments use the same or any specific
+ root zone. In the GNS reference implementation, users can
+ autonomously and freely delegate control of names to zones
+ through their local configurations.
</t>
<t>
- In DNS terminology, GNS roughly follows the idea of a local
- root zone deployment (see <xref target="RFC8806"/>), with the difference
- that the protocol does not mandate that all deployments use the same
- or any specific root zone.
- Users can autonomously and freely delegate control of names to
- zones through their local configurations.
+ Name resolution and zone dissemination is based on the
+ principle of a petname system where users can assign local
+ names to zones. The GNS has its roots in ideas from the Simple
+ Distributed Security Infrastructure <xref target="SDSI" />,
+ enabling the decentralized mapping of secure identifiers to
+ memorable names. A first academic description of the
+ cryptographic ideas behind GNS can be found in <xref
+ target="GNS" />.
</t>
<t>
- Name resolution and zone dissemination is based on the principle of a
- petname system where users can assign local names to zones.
- It builds on ideas from the Simple Distributed Security
- Infrastructure <xref target="SDSI" />, enabling the decentralized
- mapping of secure identifiers to memorable names.
+ This document defines the normative wire format of resource
+ records, resolution processes, cryptographic routines and
+ security considerations for use by implementers.
</t>
<t>
- This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementers.
- </t>
- <t>
- This specification was developed outside the IETF and does not have
- IETF consensus. It is published here to guide implementation of GNS
- and to ensure interoperability among implementations.
+ This specification was developed outside the IETF and does not
+ have IETF consensus. It is published here to guide
+ implementers of GNS and to ensure interoperability among
+ implementations.
</t>
<section numbered="true" toc="default">
<name>Requirements Notation</name>
@@ -2561,7 +2559,7 @@ NICK: john (Supplemental)
by a single microsecond even if the user did not request a change.
In case of deletion of all resource records under a label, the
implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time
- of the last published resource block. Implementations <bcp14>MAY</bcp14> define
+ of the last published resource block. Implementations <bcp14>MAY</bcp14> define
and use a special record type as a tombstone that preserves the last
absolute expiration time, but then <bcp14>MUST</bcp14> take care to not publish a
block with this record.