commit 0df90483ec4b51f71b1f933c1cafdb1955b26c6b
parent 52aef94e8f5ff03bb340931cb3e61ab0c97c4c39
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 12:48:34 +0200
fix umlaut
Diffstat:
2 files changed, 131 insertions(+), 106 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1007,7 +1007,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<div class="author">
<div class="author-name">C. Grothhoff</div>
-<div class="org">GNUnet e.V.</div>
+<div class="org">Berner Fachhochschule</div>
</div>
<div class="author">
<div class="author-name">B. Fix</div>
@@ -1247,20 +1247,26 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dl class="dlParallel" id="section-3-8">
<dt id="section-3-8.1">SHADOW</dt>
<dd id="section-3-8.2">
- If this flag is set, this record should not be used unless all (other)
- records with an absolute expiration time have expired.<a href="#section-3-8.2" class="pilcrow">¶</a>
+ If this flag is set, this record should be ignored by resolvers unless all (other)
+ records of the same record type have expired. Used to allow zone publishers to
+ facilitate good performance when records change by allowing them to put future
+ values of records into the DHT. This way, future values can propagate and may be
+ cached before the transition becomes active.<a href="#section-3-8.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-8.3">EXPREL</dt>
<dd id="section-3-8.4">
- The expiration time value of the record is a relative time and not
- an absolute time. This flag should never be encountered by a resolver
- for records resolved from the DHT.<a href="#section-3-8.4" class="pilcrow">¶</a>
+ The expiration time value of the record is a relative time (still in microseconds)
+ and not an absolute time. This flag should never be encountered by a resolver
+ for records obtained from the DHT, but might be present when a resolver looks up
+ private records of a zone hosted locally.<a href="#section-3-8.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-8.5">PRIVATE</dt>
<dd id="section-3-8.6">
This is a private record of this peer and it should thus not be
- handed out to other peers. This flag should never be encountered by
- a resolver for records resolved from the DHT.<a href="#section-3-8.6" class="pilcrow">¶</a>
+ published in the DHT. Thus, this flag should never be encountered by
+ a resolver for records obtained from the DHT.
+ Private records should still be considered just like
+ regular records when resolving labels in local zones.<a href="#section-3-8.6" class="pilcrow">¶</a>
</dd>
</dl>
<div id="gnsrecords_pkey">
@@ -1271,7 +1277,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-3.1-1">In GNS, a delegation of a label to a zone is represented through a PKEY
record. A PKEY resource record contains the public key of the zone to
delegate to. A PKEY record MUST be the only record under a label. No other
- records are allowed. The a PKEY DATA entry has the following format:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ records are allowed. A PKEY DATA entry has the following format:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.1-2.1">
@@ -1299,9 +1305,19 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
in DNS followed by a DNS server. Both names are in the format defined in
<span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
If a resolver encounters a GNS2DNS record it is expected that it first
- resolves the IP(s) of the DNS servers using DNS. Then, the encountered DNS
- name is resolved by querying the name server(s).
- The a GNS2DNS DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+ resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
+ numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
+ The DNS server names may themselves be names in GNS or DNS. If the
+ DNS server name ends in ".+", the rest of the name is to be interpreted
+ relative to the zone of the GNS2DNS record.
+ Then, the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved, and
+ resolved by querying the name server(s).
+ Multiple
+ GNS2DNS records may be stored under the same label, in which case the
+ resolve MUST try all of them. However, if multiple GNS2DNS records
+ are present, the DNS name MUST be identical for all of them.
+ A GNS2DNS DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-4">
<div class="artwork art-text alignLeft" id="section-3.2-2.1">
@@ -1329,14 +1345,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<h3 id="name-leho">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-leho" class="section-name selfRef">LEHO</a>
</h3>
-<p id="section-3.3-1">As names in GNS are not globally unique, established practices such as
- virtual hosting do not apply directly. In order to support such use cases,
- GNS support a legacy hostname record which can be used by applications
- (e.g. HTTP clients) in order to provide the necessary information.
- The resource record contains a string which is not 0-terminated representing
- the legacy hostname to use. It is expected to be found together in a single
- resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+<p id="section-3.3-1">Legacy hostname records can be used by applications that are expected
+ to supply a DNS name on the application layer. The most common use case
+ is HTTP virtual hosting, which as-is would not work with GNS names as
+ those may not be globally unique.
+
+ A LEHO resource record contains a string (which is not 0-terminated) representing
+ the legacy hostname to use (FIXME: in UTF-8 or PUNY?).
+ It is expected to be found together in a single
+ resource record with an IPv4 or IPv6 address.
+ A LEHO DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
@@ -1360,14 +1378,20 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-box" class="section-name selfRef">BOX</a>
</h3>
<p id="section-3.4-1">
- Record type used to box up SRV and TLSA records. For example, a
- TLSA record for "_https._tcp.foo.gnu" will be stored under
- "foo.gnu" as a BOX record with service 443 (https) and protocol 6
+ In GNS, every "." in a name delegates to another zone, and
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with. For example, a
+ TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
+ "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
(tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
- must unbox it if the name contained "_SERVICE._PROTO", otherwise it is
- left untouched. This is done to ensure that TLSA (and SRV)
- records do not require a separate network request, thus making TLSA
- records inseparable from the corresponding A/AAAA/VPN/etc. records.
+ must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
+ otherwise it is to be left untouched. This way, TLSA (and SRV)
+ records do not require a separate network request, and TLSA
+ records become inseparable from the corresponding address records.
A BOX DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-6">
@@ -1377,7 +1401,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
+-----------+-----------------------------------+
- | RECORD |
+ | RECORD DATA |
/ /
/ /
| |
@@ -1400,10 +1424,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dd id="section-3.4-3.6">
Record type of the boxed record. In network byte order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.4-3.7">RECORD</dt>
+ <dt id="section-3.4-3.7">RECORD DATA</dt>
<dd id="section-3.4-3.8">
- The boxed record in a format as defined in
- <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-3.4-3.8" class="pilcrow">¶</a>
+ This is the "DATA" format of TYPE as defined for the respective TYPE
+ in DNS.<a href="#section-3.4-3.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1714,10 +1738,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</dd>
<dt id="section-4.3-12.3">PADDING</dt>
<dd id="section-4.3-12.4">
- The padding MUST contain the 0 value in all octets. Not applicable for
- PKEY records.
+ The padding MUST contain the value 0 in all octets.
The padding MUST ensure that the size of the RDATA is a power of two.
- The only excption is the PKEY record type, which is never padded.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
+
+ As a special exception, record sets with (only) a PKEY record type
+ are never padded. Note that a record set with a PKEY record MUST NOT contain
+ other records.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-4.3-13">
@@ -1786,68 +1812,68 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
label := "mail"
d :=
- 7ac77c287b9f1971
- 1dcb770ae4b5210d
- e84f283b903393f8
- a09db3f347bf7818
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
zk (public zone key) :=
- 7e5d026d4911f9df
- 993e15193dc08508
- ca9e71ea233f214f
- 2e080e41dc32fc17
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
h :=
- 540ef99c5a27f32a
- b96fe70b93f7dbf2
- a68c6f41b1807c5e
- b959b71f8ece50dc
- 9b7ec146f5dcdcfe
- 53c0552863234f4c
- 33dcf484f6e96866
- ee0f2b39276b656d
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
d_h :=
- 3376c182f461fb01
- f3e009254c1c6177
- bd105c40e4e7b081
- 182ed3f702c81700
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
zk_h (derived zone key) :=
- e0aa0e6ca514b58c
- dde43ea658517456
- 6e325e54b93c8576
- 9182810f92fad776
+ 8cb514a56c0eaae0
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291
q (query key) :=
- 81d65adced4dce6f
- 3b7e7610339ae2f4
- bae26c271bbc388b
- a320e1f19db4f19b
- 6f4168fbdfc9ec20
- df3bad78d89a7211
- d720b62626dbb4d0
- a3663c39e404068e
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
AES_KEY :=
- 0d157a081ad2efaf
- a502da4e1a745767
- 214ba46ba87cdf65
- 01af1e07c006813f
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
AES_IV :=
- 7aad9fbc29b908a8
- 7ad7be3234be6b68
+ a808b929bc9fad7a
+ 686bbe3432bed77a
TWOFISH_KEY :=
- f40b1df09d08d0c9
- 2873cc2c4bdbc8e4
- d259ae11a8e82534
- 79a4d2857274e299
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
TWOFISH_IV :=
- f936d2a989e11b07
- d481c2b84b65a3b4
+ 071be189a9d236f9
+ b4a3654bb8c281d4
RDATA :=
0000000100059412 RR COUNT | EXPIRA-
@@ -1873,30 +1899,30 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
713f0a0d
SIGNATURE :=
- dee65fe070b05c05 r
- dddeb4e5504a69ad
- 654f00aedbcbfdb9
- 54bba3c5a99bc9af___________
- 33ee8046a331e707 s
- b7d2a7edbfe70dae
- 541b8b004a856b8c
- 469fbaf5394fdf10
+ 055cb070e05fe6de r
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54___________
+ 07e731a34680ee33 s
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46
BLOCK :=
- dee65fe070b05c05 SIGNATURE
- dddeb4e5504a69ad
- 654f00aedbcbfdb9
- 54bba3c5a99bc9af
- 33ee8046a331e707
- b7d2a7edbfe70dae
- 541b8b004a856b8c
- 469fbaf5394fdf10____________
- e0aa0e6ca514b58c zk_h
- dde43ea658517456
- 6e325e54b93c8576
- 9182810f92fad776____________
- 540000000f000000 SIZE (=84) | PURPOSE (=15)
- 5be2dd0912940500 EXPIRATION
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
d99d08fa123da096 BDATA
66c2fb9bf020a85d
e80818d0a84059a8
@@ -1964,12 +1990,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</address>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Christian Grothoff</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
-<div dir="auto" class="left">
-<span class="postal-code">85748</span> <span class="locality">Garching</span>
+<div dir="auto" class="left"><span class="org">Berner Fachhochschule</span></div>
+<div dir="auto" class="left"><span class="street-address">Hoeheweg 80</span></div>
+<div dir="auto" class="left">CH-<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div dir="auto" class="left"><span class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:schanzen@gnunet.org" class="email">schanzen@gnunet.org</a>
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -33,7 +33,7 @@
<organization>Berner Fachhochschule</organization>
<address>
<postal>
- <street>Höheweg 80</street>
+ <street>Hoeheweg 80</street>
<city>Biel/Bienne</city>
<code>2501</code>
<country>CH</country>
