diff options
Diffstat (limited to 'draft-schanzen-gns.xml')
| -rw-r--r-- | draft-schanzen-gns.xml | 62 |
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. |