[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: add migration
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: add migration |
Date: |
Fri, 20 May 2022 22:54:17 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 2699b32 add migration
2699b32 is described below
commit 2699b32e91b3e54b9675a30dfa3c16d21877916d
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri May 20 22:54:11 2022 +0200
add migration
---
draft-schanzen-gns.xml | 76 ++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9901932..df8976a 100644
--- 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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: add migration,
gnunet <=