[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: start flags update incl CRITICAL; remov
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: start flags update incl CRITICAL; remove GTS; Add redirect record(s) |
|
Date: |
Wed, 02 Feb 2022 22:09:32 +0100 |
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 6d54577 start flags update incl CRITICAL; remove GTS; Add redirect
record(s)
6d54577 is described below
commit 6d545771fb258fcea63fb5afa5e6ab02800b2553
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Feb 2 22:09:25 2022 +0100
start flags update incl CRITICAL; remove GTS; Add redirect record(s)
---
draft-schanzen-gns.xml | 308 +++++++++++++++++++++----------------------------
1 file changed, 129 insertions(+), 179 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index ff79b42..16de1e3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -838,17 +838,19 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5...
+--------+--------+--------+--------+--------+----
-|RESERVED|PRIVATE |SUPPL |EXPREL | SHADOW | ...
+|CRITICAL|SHADOW |SUPPL |RESERVED
+--------+--------+--------+--------+--------+----
-<!-- FIXME: add DELEGATION bit to FLAGS for
- PKEY and EDKEY (and maybe CNAME/GNS2DNS?)?
- Otherwise, how can 7.3.1 work if a resolver
- does not know if a given future record type is
- a delegation type? -->
]]></artwork>
</figure>
<t>The Resource Record Flag Wire Format.</t>
<dl>
+ <dt>CRITICAL</dt>
+ <dd>
+ If this flag is set, it indicates that processing is critical.
+ Implementations that do not support the record type or are otherwise
+ unable to process the record must abort resolution upon encountering
+ the record in the resolution process.
+ </dd>
<dt>SHADOW</dt>
<dd>
If this flag is set, this record should be ignored by resolvers
unless all (other)
@@ -858,16 +860,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
This way, future values can propagate and may be
cached before the transition becomes active.
</dd>
- <dt>EXPREL</dt>
- <dd>
- 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 storage, but might be present when a
resolver looks up
- private records of a zone hosted locally.
- </dd>
- <dt>
- SUPPL
- </dt>
+ <dt>SUPPL</dt>
<dd>
This is a supplemental record. It is provided in addition to the
other records. This flag indicates that this record is not explicitly
@@ -875,14 +868,6 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
may be useful for the application. This flag should only be
encountered
by a resolver for records obtained from the storage.
</dd>
- <dt>PRIVATE</dt>
- <dd>
- This is a private record of this peer and it should thus not be
- published. Thus, this flag should never be encountered by
- a resolver for records obtained from the storage.
- Private records should still be considered just like
- regular records when resolving labels in local zones.
- </dd>
</dl>
<section anchor="gnsrecords_delegation" numbered="true" toc="default">
<name>Zone Delegation Records</name>
@@ -1289,9 +1274,49 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
]]></artwork>
</figure>
<t>The Counter Block Initialization Vector</t>
+ </section>
+ </section>
+ <section anchor="gnsrecords_redirect" numbered="true" toc="default">
+ <name>Redirection Records</name>
+ <t>
+ </t>
+ <section anchor="gnsrecords_rdr" numbered="true" toc="default">
+ <name>REDIRECT</name>
+ <t>
+ FIXME description
+ A GNS2DNS DATA entry is illustrated in <xref
target="figure_redirectrecord"/>.</t>
+ <figure anchor="figure_redirectrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS SERVER NAME |
+/ /
+/ /
+| |
++-----------------------------------------------+
+ ]]></artwork>
+ </figure>
+ <t> The REDIRECT DATA Wire Format</t>
+ <dl>
+ <dt>FIXME</dt>
+ <dd>
+ The name to continue with in DNS. The value is UTF-8 encoded and
+ 0-terminated.
+ </dd>
+ </dl>
+ <t>
+ NOTE: If an application uses DNS names obtained from GNS2DNS records
+ in a DNS request they must first be converted to a punycode
representation
+ <xref target="RFC5890" />.
+ </t>
</section>
- <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
+ <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
<name>GNS2DNS</name>
<t>It is possible to delegate a label back into DNS through a GNS2DNS
record.
The resource record contains a DNS name for the resolver to continue
with
@@ -1339,11 +1364,9 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
in a DNS request they must first be converted to a punycode
representation
<xref target="RFC5890" />.
</t>
+ </section>
</section>
-
-
- </section>
- <section anchor="gnsrecords_other" numbered="true" toc="default">
+ <section anchor="gnsrecords_other" numbered="true" toc="default">
<name>Auxiliary Records</name>
<t>
This section defines the initial set of auxiliary GNS record types.
Any
@@ -1490,60 +1513,6 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
</dd>
</dl>
</section>
- <section anchor="gnsrecords_vpn" numbered="true" toc="default">
- <name>GTS</name>
- <t>
- The GNUnet Tunnel Service record is used by
- applications to establish a tunnel between two peers in the
- peer-to-peer network (see <xref target="GNUnet"/>).
- The GTS record serves as an example of how resolvers may automatically
- initiate tunnel establishment and provide IP address information in
the
- resolution process as specified in <xref target="resolution"/>.
- </t>
- <t>
- A GTS DATA entry wire format is illustrated in
- <xref target="figure_vpnrecord"/>.
- </t>
- <figure anchor="figure_vpnrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| HOSTING PEER PUBLIC KEY |
-| (256 bits) |
-| |
-| |
-+-----------+-----------------------------------+
-| PROTO | SERVICE NAME |
-+-----------+ +
-/ /
-/ /
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- </figure>
- <t>The GTS DATA Wire Format.</t>
- <dl>
- <dt>HOSTING PEER PUBLIC KEY</dt>
- <dd>
- is a 256-bit EdDSA public key identifying the peer hosting the
- service.
- </dd>
- <dt>PROTO</dt>
- <dd>
- the 16-bit tunnel protocol number. In network byte order.
- Note that values
- below 2^8 are reserved for allocation via IANA <xref
target="RFC6895" />,
- while values above 2^8 are allocated by the
- GNUnet Assigned Numbers Authority <xref target="GANA" />.
- </dd>
- <dt>SERVICE NAME</dt>
- <dd>
- a shared secret used to identify the service at the hosting peer,
- used to derive the port number required to connect to the service.
- The service name MUST be a 0-terminated UTF-8 string.
- </dd>
- </dl>
- </section>
</section>
</section>
<section anchor="publish" numbered="true" toc="default">
@@ -1679,15 +1648,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
addition to the length of the BDATA. While a 32-bit value is used,
implementations MAY refuse to publish blocks beyond a certain
- size significantly below 4 GB. However, a minimum block size of
- 62 kilobytes MUST be supported.
- <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
- <!-- FIXME: I (CG) think for storage we should go for the minimum
- as an embedded system may not be able to handle 62k and may
- still find utility in GNS with smaller records; for the
- client-side resolver, we MAY choose to require a higher limit;
- but it is unclear that this belongs here with this field!
- (and I think we should kill the field! see above!) -->
+ size significantly below 4 GB.
</dd>
<dt>PURPOSE</dt>
<dd>
@@ -1808,10 +1769,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
<t>
When GNS name resolution is requested, a desired record type MAY be
provided by the client.
- The GNS resolver will use the desired record type to guide
- processing, for example by providing conversion of GTS records to A
- or AAAA records.
-
However, filtering of record sets according to the required record
types MUST still be done by the client after the resource record set
is retrieved.
@@ -1932,16 +1889,23 @@ example.com = zk2
obtained are considered. To filter records by validity, the
resolver
MUST at least checking the expiration time and the FLAGS of the
respective record. In particular, FLAGS may exclude shadow and
- supplemental records from being considered. The next steps depend
+ supplemental records from being considered.
+ If the resolver encounters a record with the CRITICAL flag set and
+ does not support the record type the resolution MUST be aborted
+ and an error MUST be returned. The information that the critical
+ record could not be processed SHOULD be returned in the error
+ description. The implementation MAY choose not to return the reason
for the failure,
+ merely complicating troubleshooting for the user.
+ The next steps depend
on the context of the name we are trying to resolve:
</t>
<ul>
<li>
Case 1:
- If the filtered record set consists of a single CNAME,
- the remainder of the name is prepended to the CNAME and the
+ If the filtered record set consists of a single REDIRECT record,
+ the remainder of the name is prepended to the REDIRECT data and the
recursion is started again from the resulting name.
- Details are described in <xref target="cname_processing" />.
+ Details are described in <xref target="redirect_processing" />.
</li>
<li>
Case 2:
@@ -1973,44 +1937,35 @@ example.com = zk2
Otherwise, resolution fails and the resolver MUST return an empty
record set.
</li>
</ul>
- <t>
- Finally, after the recursion successfully terminates, the client
preferences
- for the record type MUST be considered and possible conversions such as
- defined in <xref target="vpn_processing" /> MUST be attempted.
- </t>
- <!-- FIXME: maybe reorder these subsections to match order in the
- algorithm above? -->
- <section anchor="delegation_processing" numbered="true" toc="default">
- <name>Zone Delegation Records</name>
+ <section anchor="redirect_processing" numbered="true" toc="default">
+ <name>REDIRECT</name>
<t>
- When the resolver encounters a record of a supported
- zone delegation record type (such as PKEY or EDKEY)
- and the remainder of the name is not empty, resolution continues
- recursively with the remainder of the name in the
- GNS zone specified in the delegation record.
- Implementations MUST NOT allow multiple different zone
- delegations under a single label.
- Implementations MAY support any subset of ztypes. If
- an unsupported ztype is encountered, resolution fails and an
- error MUST be returned. The information that the ztype is
- unknown SHOULD be returned in the error description. The
- implementation MAY choose not to return the reason for the
failure,
- merely complicating troubleshooting for the user.
- Implementations MUST NOT process zone delegation for the empty
- apex label "@". Upon encountering a zone delegation record under
- this label, resolution fails and an error MUST be returned. The
- implementation MAY choose not to return the reason for the
failure,
- merely impacting troubleshooting information for the user.
+ If a REDIRECT record is encountered, the redirect name is
+ appended to the remaining name, except if the remaining name
+ is empty and the desired record type is REDIRECT, in which case
+ the resolution concludes with the REDIRECT record.
+ If the canonical name ends in ".+",
+ resolution continues in GNS with the new name in the
+ current zone. Otherwise, the resulting name is resolved via the
+ default operating system name resolution process.
+ This may in turn trigger a GNS name resolution process depending
+ on the system configuration.
+ <!-- Note: this permits non-DNS resolvers to be triggered via
NSS! -->
</t>
<t>
- If the remainder of the name to resolve is empty and we have
- received a record set containing only a single delegation record,
the
- recursion is continued with the record value as authoritative zone
- and the empty apex label "@" as remaining name, except in the case
- where the desired record type as specified by the client
- is equal to the ztype, in which
- case the delegation record is returned and the resolution is
concluded without
- resolving the empty apex label.
+ In order to prevent infinite loops, the resolver MUST
+ implement loop detections or limit the number of recursive
+ resolution steps. The loop detection MUST be effective even
+ if a REDIRECT found in GNS triggers subsequent GNS lookups via
+ the default operating system name resolution process.
+ </t>
+ <t>
+ If the last REDIRECT encountered was a DNS name, the resolver
+ SHOULD return the DNS name
+ as a supplemental LEHO record (see <xref target="gnsrecords_leho"
/>)
+ with a relative expiration time of one hour.
+ <!-- Note: Martin: do we actually implement this in GNS today?
+ Seems rather tricky to detect if we go via NSS... -->
</t>
</section>
<section anchor="gns2dns_processing" numbered="true" toc="default">
@@ -2074,37 +2029,6 @@ example.com = zk2
GNS resolver configuration.
</t>
</section>
- <section anchor="cname_processing" numbered="true" toc="default">
- <name>CNAME</name>
- <t>
- If a CNAME record is encountered, the canonical name is
- appended to the remaining name, except if the remaining name
- is empty and the desired record type is CNAME, in which case
- the resolution concludes with the CNAME record.
- If the canonical name ends in ".+",
- resolution continues in GNS with the new name in the
- current zone. Otherwise, the resulting name is resolved via the
- default operating system name resolution process.
- This may in turn trigger a GNS name resolution process depending
- on the system configuration.
- <!-- Note: this permits non-DNS resolvers to be triggered via
NSS! -->
- </t>
- <t>
- In order to prevent infinite loops, the resolver MUST
- implement loop detections or limit the number of recursive
- resolution steps. The loop detection MUST be effective even
- if a CNAME found in GNS triggers subsequent GNS lookups via
- the default operating system name resolution process.
- </t>
- <t>
- If the last CNAME encountered was a DNS name, the resolver
- SHOULD return the DNS name
- as a supplemental LEHO record (see <xref target="gnsrecords_leho"
/>)
- with a relative expiration time of one hour.
- <!-- Note: Martin: do we actually implement this in GNS today?
- Seems rather tricky to detect if we go via NSS... -->
- </t>
- </section>
<section anchor="box_processing" numbered="true" toc="default">
<name>BOX</name>
<t>
@@ -2116,20 +2040,33 @@ example.com = zk2
records.
</t>
</section>
- <section anchor="vpn_processing" numbered="true" toc="default">
- <name>GTS</name>
+ <section anchor="delegation_processing" numbered="true" toc="default">
+ <name>Zone Delegation Records</name>
<t>
- At the end of the recursion,
- if the queried record type is either A or AAAA and the retrieved
- record set contains at least one GTS record, the resolver SHOULD
- open a tunnel and return the IPv4 or IPv6 tunnel address,
- respectively.
- If the implementation does not have the capacity to establish
- a GTS tunnel, for example because it is not connected to the
GNUnet
- network, the record set MUST be returned as retrieved from the
network.
- <!-- FIXME: idea: what if we prescribe this ONLY for the dns2gns
proxy,
- and not for a vanilla GNS resolver? That would allow us to
more
- clearly separate VPN/legacy IP logic from GNS proper! -->
+ When the resolver encounters a record of a supported
+ zone delegation record type (such as PKEY or EDKEY)
+ and the remainder of the name is not empty, resolution continues
+ recursively with the remainder of the name in the
+ GNS zone specified in the delegation record.
+ Implementations MUST NOT allow multiple different zone
+ delegations under a single label.
+ Implementations MAY support any subset of ztypes.
+ Handling of
+ Implementations MUST NOT process zone delegation for the empty
+ apex label "@". Upon encountering a zone delegation record under
+ this label, resolution fails and an error MUST be returned. The
+ implementation MAY choose not to return the reason for the
failure,
+ merely impacting troubleshooting information for the user.
+ </t>
+ <t>
+ If the remainder of the name to resolve is empty and we have
+ received a record set containing only a single delegation record,
the
+ recursion is continued with the record value as authoritative zone
+ and the empty apex label "@" as remaining name, except in the case
+ where the desired record type as specified by the client
+ is equal to the ztype, in which
+ case the delegation record is returned and the resolution is
concluded without
+ resolving the empty apex label.
</t>
</section>
<section anchor="nick_processing" numbered="true" toc="default">
@@ -2334,6 +2271,19 @@ NICK: john (Supplemental)
Implementations of "aggregated" storages are conceivable, but
are expected to be the exception.
</t>
+ <t>
+ FIXME integrate
+ 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 storage, but might be present when a
resolver looks up
+ private records of a zone hosted locally.
+ This is a private record of this peer and it should thus not be
+ published. Thus, this flag should never be encountered by
+ a resolver for records obtained from the storage.
+ Private records should still be considered just like
+ regular records when resolving labels in local zones.
+
+ </t>
</section>
<section anchor="security_dht" numbered="true" toc="default">
<name>Impact of DHTs as Underlying Storage</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: start flags update incl CRITICAL; remove GTS; Add redirect record(s),
gnunet <=