From: rexxnor <rexxnor+gnunet@brief.li>
Date: Fri, 25 Jan 2019 16:24:47 +0000 (+0100)
Subject: fixed up documentation for ascension
X-Git-Tag: v0.11.0~127^2~2
X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=8b48d928864af10bd1a31e55daf23c54bf0e4100;p=oweals%2Fgnunet.git

fixed up documentation for ascension
---

diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
index 1d3e1d3fb..2da262b34 100644
--- a/doc/handbook/chapters/developer.texi
+++ b/doc/handbook/chapters/developer.texi
@@ -8130,19 +8130,15 @@ The transformation of MX records is done in a simple way.
 gnunet-namestore -z example.com -n mail -R 3600 MX n 10,mail
 @end example
 
-Finally, one of the biggest struggling points was the NS records that are found
+Finally, one of the biggest struggling points were the NS records that are found
 in top level domain zones. The intended behaviour for those is to add GNS2DNS
-records for the zone so that gnunet-gns can resolve the for those domain on it's
-own. Also a very important aspect of this is, that gnunet needs to be able to
-resolve the nameservers from it's own database. This requires migration of the
-DNS GLUE records as well.
+records for those so that gnunet-gns can resolve records for those domains on
+its own. This requires migration of the DNS GLUE records as well, provided that
+they are within the same zone.
 
-This proved to be quite a challenge to implement, as in GNS every dot is a
-strict zone cut.
-
-The issue was fixed by creating a hierarchical zone structure in GNS and linking
+A solution was found by creating a hierarchical zone structure in GNS and linking
 the zones using PKEY records to one another. This allows the resolution of the
-nameservers to work within GNS.
+nameservers to work within GNS while not taking control over unwanted zones.
 
 @node DNS Zone Size
 @subsubsection DNS Zone Size
diff --git a/doc/handbook/chapters/user.texi b/doc/handbook/chapters/user.texi
index a659be9a3..0703adafc 100644
--- a/doc/handbook/chapters/user.texi
+++ b/doc/handbook/chapters/user.texi
@@ -1895,7 +1895,8 @@ option ``DISABLE'' to ``YES'' in section ``[namecache]''.
 @node Migrating an existing DNS zone into GNS
 @subsection Migrating an existing DNS zone into GNS
 
-After installing the tool according to the README file you have the following options:
+After installing the tool according to the README file you have the following
+options:
 @example
 Ascension
 
@@ -1916,15 +1917,18 @@ Options:
     -v --version    Show version.
 @end example
 
-To migrate the Syrian top level domain - one of the few top level domains that still supports zone transfers - use the following command:
+To migrate the Syrian top level domain - one of the few top level domains that
+still supports zone transfers - use the following command:
 
 @example
 $ ascension sy. -ns ns1.tld.sy.
 @end example
 
-The program will continue to run as a daemon and update once the refresh time specified in the zones SOA record has elapsed.
+The program will continue to run as a daemon and update once the refresh time
+specified in the zones SOA record has elapsed.
 
-At this point you might want to write for example a systemd unit file to start and enable the service, so that your zone is migrated automatically.
+At this point you might want to write for example a systemd unit file to start
+and enable the service, so that your zone is migrated automatically.
 
 @node re@:claim Identity Provider
 @section re@:claim Identity Provider