commit 92b46818b0f5a6375781cfb74d551d8c121b0068
parent 3767ef4116a2fc47aa64fd4da5ae159dea4be4b8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sat, 26 Mar 2022 13:34:28 +0100
obsolete reference
Diffstat:
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -19,7 +19,7 @@
<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
<!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml">
-<!ENTITY RFC7706 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7706.xml">
+<!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml">
<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
@@ -35,13 +35,13 @@
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-11" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-12" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 2.26.0 -->
<front>
<title abbrev="The GNU Name System">
The GNU Name System
</title>
- <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-11"/>
+ <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-12"/>
<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
<organization>Fraunhofer AISEC</organization>
<address>
@@ -158,7 +158,7 @@
where root zone governance is centralized at the Internet Corporation
for Assigned Names and Numbers (ICANN).
In DNS terminology, GNS roughly follows the idea of a local
- root zone deployment (see <xref target="RFC7706"/>), with the difference that it is not
+ root zone deployment (see <xref target="RFC8806"/>), with the difference that it is not
expected that all deployments use the same root zone,
and that users can easily delegate control of arbitrary domain names to
arbitrary zones.
@@ -227,7 +227,8 @@
special purposes in the resolution protocol which are defined
in the rest of the document.
Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
- might be easily confused with other labels through registration policies.
+ might be easily confused with other labels through registration policies
+ (see also <xref target="security_abuse"/>).
</dd>
<dt>Apex Label</dt>
<dd>
@@ -443,7 +444,8 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- An implementation <bcp14>SHOULD</bcp14> enable the user to create and manage zones.
+ A zone master implementation <bcp14>SHOULD</bcp14> enable the user to
+ create and manage zones.
If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution are available
(see <xref target="resolution"/>).
@@ -2195,7 +2197,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
<t>
Otherwise, it is expected that the resolver first resolves the
IP addresses of the specified DNS name servers.
- The DNS name may have to be converted to an IDNA compliant
+ The DNS name <bcp14>MUST</bcp14> be converted to an IDNA compliant
representation <xref target="RFC5890" /> for resolution in DNS.
GNS2DNS records <bcp14>MAY</bcp14>
contain numeric IPv4 or IPv6 addresses, allowing the resolver to
@@ -2213,7 +2215,9 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
in which case the resolver <bcp14>MUST</bcp14> try all of them.
The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel.
If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be
- identical for all of them, if not the resolution fails and an
+ identical for all of them. Otherwise, it is not clear which name
+ the resolver is supposed to follow. If multiple DNS names are
+ present the resolution fails and an
appropriate error is <bcp14>SHOULD</bcp14> be returned to the application.
</t>
<t>
@@ -2252,7 +2256,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14>
delegate back into GNS and should only follow the DNS specifications.
For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be
- interpreted as GNS names.
+ interpreted by resolvers that support both DNS and GNS as GNS names.
</t>
<t>
GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
@@ -2343,7 +2347,7 @@ NICK: eve (non-Supplemental)
In this example, the returned NICK record is non-supplemental.
For the application, this means that the NICK belongs to the zone
"alice.example" and is published under the apex label along with an A
- record. The NICK record should be interpreted as: The zone defined by
+ record. The NICK record is interpreted as: The zone defined by
"alice.example" wants to be referred to as "eve".
In contrast, consider the following:
</t>
@@ -2925,7 +2929,7 @@ Purpose | Name | References | Comment
<!-- &RFC6781; -->
&RFC7363;
&RFC8324;
- &RFC7706;
+ &RFC8806;
&RFC6761;
<!-- &RFC3912;-->
