commit 2699b32e91b3e54b9675a30dfa3c16d21877916d
parent bd47a611a2c52bcc9cb98fc4787416f64b031dbf
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 20 May 2022 22:54:11 +0200
add migration
Diffstat:
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2,6 +2,7 @@
<!DOCTYPE rfc [
<!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
+<!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">-->
<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
@@ -2963,6 +2964,7 @@ Purpose | Name | References | Comment
</references>
<references>
<name>Informative References</name>
+ &RFC1928;
&RFC4033;
&RFC6066;
&RFC7363;
@@ -3144,9 +3146,14 @@ Purpose | Name | References | Comment
</front>
</reference>
-
-
-
+ <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html">
+ <front>
+ <title>System Databases and Name Service Switch</title>
+ <author>
+ <organization>GNU Project</organization>
+ </author>
+ </front>
+ </reference>
</references>
<section>
@@ -3309,7 +3316,7 @@ Value Symbol Symbol
specification.
</t>
</section>
- <section>
+ <section anchor="uc_virthost">
<name>Virtual Hosting</name>
<t>
HTTP virtual hosting and TLS Server Name Indication are common
@@ -3382,7 +3389,66 @@ Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
For example, the name in the URL bar may remain as "www.example.gnu"
even if the used unique name differs.
</t>
- </section>
+ </section>
+ <section>
+ <name>Migration Paths</name>
+ <t>
+ DNS resolution is built into a variety of existing software
+ components.
+ Most significantly operating systems and HTTP clients.
+ This section illustrates possible migration paths for both in order
+ to enable "legacy" applications to resolve GNS names.
+ </t>
+ <t>
+ One way to efficiently facilitate the resolution of GNS names
+ are GNS-enabled DNS server implementations.
+ Local DNS queries are thereby either rerouted or explicitly configured
+ to be resolved by a "DNS-to-GNS" server that runs locally.
+ This DNS server tries to interpret any incoming query for a name
+ as a GNS resolution request.
+ If no start zone can be found for the name and it does not end in
+ a zTLD, the server tries to resolve the name in DNS.
+ Otherwise, the name is resolved in GNS.
+ In the latter case, the resulting record set is converted to a DNS
+ answer packet and is returned accordingly.
+ An implementation of a DNS-to-GNS server can be found in
+ <xref target="GNUnet"/>.
+ </t>
+ <t>
+ A similar approach is to use operating systems extensions such as
+ the name service switch (<xref target="nsswitch"/>).
+ It allows the system administrator to configure plugins
+ which are used for hostname resolution.
+ A GNS name service switch plugin can be used in a similar fashion as
+ the "DNS-to-GNS" server.
+ An implementation of a glibc-compatible nsswitch plugin for GNS
+ can be found in <xref target="GNUnet"/>.
+ </t>
+ <t>
+ The methods above are usually also effective for HTTP client
+ software.
+ However, HTTP clients are commonly used in combination with
+ TLS.
+ TLS certificate validation and in particular server name indication
+ (SNI) requires additional logic in HTTP clients when GNS names are
+ in play (<xref target="uc_virthost"/>).
+ In order to transparently enable this functionality for migration
+ purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"/>
+ can be configured to resolve domain names.
+ The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable
+ of resolving both GNS and DNS names.
+ In the event of a TLS connection request with a GNS name, the SOCKS5
+ proxy can act as a man-in-the-middle, terminating the TLS connection
+ and establishing a secure connection against the requested host.
+ In order to establish a secure connection, the proxy may use LEHO
+ and TLSA records stored in the record set under the GNS name.
+ The proxy must provide a locally trusted certificate for the GNS
+ name to the HTTP client which usually requires the generation and
+ configuration of a local trust anchor in the browser.
+ An implementation of this SOCKS5 proxy can be found in
+ <xref target="GNUnet"/>.
+ </t>
+ </section>
</section>
<section>
<name>Example flows</name>
