commit 8c9bed758a54b828682236b19b013b33b56040a0
parent 1f97560c26f81b9aba2e0492c1360061a4a95e79
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 8 Mar 2022 00:01:35 +0100
dns name
Diffstat:
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1460,7 +1460,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| DNS NAME |
+| NAME |
/ /
/ /
| |
@@ -1473,7 +1473,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
]]></artwork>
</figure>
<dl>
- <dt>DNS NAME</dt>
+ <dt>NAME</dt>
<dd>
The name to continue with in DNS. The value is UTF-8 encoded and
0-terminated.
@@ -2539,38 +2539,41 @@ NICK: john (Supplemental)
</t>
</section>
<section>
- <name>Name Leakage</name>
+ <name>Namespace Ambiguity</name>
<t>
- GNS names are indistinguishable from DNS names or other special-use
- domain names <xref target="RFC6761"/>.
+ Some GNS names are indistinguishable from DNS names in their
+ respective common display format <xref target="RFC8499"/> or
+ other special-use domain names <xref target="RFC6761"/>.
+ Given such a name it is ambiguous which name system should be used
+ by an application in order to resolve it.
This poses a risk when trying to resolve a name through DNS when
it is actually a GNS name.
In such a case, the GNS name would be leaked as part of the DNS
resolution.
- This risk is also present for special-use domain names which must be
- handled before starting a DNS resolution request by the application.
</t>
<t>
- Any application MUST take into consideration the user configuration
- of resolution precedence when trying to resolve a name.
- One example of such a configuration which at the same time allows
- applications to delegate the resolution itself is the
- Name Service Switch (NSS) of Unix-like operating systems.
- It allows system administrators to configure host name resolution
- precedence and is integrated with the system resolver implementation.
- </t>
- <t>
- The order of resolution mechanisms to try is under the discretion
- of the user or system administrator.
- In the absence of an explicit configuration it is
+ In order to prevent disclosure of queried GNS names it is
<bcp14>RECOMMENDED</bcp14> that applications try to resolve
a given name in GNS before any other method in order to honor
- potential TLD overrides in GNS by the user.
+ potential suffix-to-zone mappings in GNS by the user.
If no suffix-to-zone mapping for the name exists, resolution
- <bcp14>MAY</bcp14> continue with other methods.
+ <bcp14>MAY</bcp14> continue with other methods such as DNS.
If a suffix-to-zone mapping exists for the name and the query
succeeds, fails or returns no results, resolution <bcp14>MUST NOT</bcp14>
- continue by other means.
+ continue by any other means.
+ </t>
+ <t>
+ Mechanisms such as the Name Service Switch (NSS) of Unix-like
+ operating systems are an example of how such a resolution process
+ can be implemented and used.
+ It allows system administrators to configure host name resolution
+ precedence and is integrated with the system resolver implementation.
+ </t>
+ <t>
+ The user or system administrator <bcp14>MAY</bcp14> configure one or
+ more unique suffixes for all suffix-to-zone mappings.
+ In combination with a special-use domain name for GNS or an unreserved
+ DNS TLD, this would prevent namespace ambiguity.
</t>
</section>
</section>
