lsd0001

LSD0001: GNU Name System
Log | Files | Refs | README

commit 140861cbb9ce2b1ab7be6ab162715332dc652b59
parent 8e69ca0c24eac95f4122ae0dc8a35fbc7cbbb61a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Wed, 16 Feb 2022 19:20:34 +0100

various minor fixes

Diffstat:
Mdraft-schanzen-gns.xml | 29+++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -829,13 +829,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] future protocol versions. If an application or implementation encounters a flag which it does not recognize, it MUST be ignored. + Any combination of the flags specified below are valid. <xref target="figure_flag"/> illustrates the flag distribution in the 16-bit flag field of a resource record: </t> <figure anchor="figure_flag" title="The Resource Record Flag Wire Format."> <artwork name="" type="" align="left" alt=""><![CDATA[ -0 13 14 15 16 +0 13 14 15 +--------...+-------------+-------+---------+ | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | +--------...+-------------+-------+---------+ @@ -846,12 +847,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] <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 + 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) + If this flag is set, this record MUST 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 storage. @@ -863,8 +864,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] This is a supplemental record. It is provided in addition to the other records. This flag indicates that this record is not explicitly managed alongside the other records under the respective name but - may be useful for the application. This flag should only be encountered - by a resolver for records obtained from the storage. + may be useful for the application. </dd> </dl> <section anchor="gnsrecords_delegation" numbered="true" toc="default"> @@ -876,7 +876,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] the GNU Name System Record Types registry (see <xref target="gana"/>). Zone delegation records MUST have the CRTITICAL flag set. Not supporting some zone types MAY result in resolution failures. This - MAY BE a valid choice if some zone delegation record types have been + MAY be a valid choice if some zone delegation record types have been determined to be cryptographically insecure. Zone delegation records MUST NOT be stored and published under the apex label. @@ -1439,7 +1439,7 @@ S-Decrypt(zk,label,expiration,ciphertext): </dl> <t> NOTE: If an application uses DNS names obtained from GNS2DNS records - in a DNS request they must first be converted to an IDNA punycode + in a DNS request they MUST first be converted to an IDNA punycode representation <xref target="RFC5891" />. </t> </section> @@ -1454,6 +1454,9 @@ S-Decrypt(zk,label,expiration,ciphertext): <section anchor="gnsrecords_leho" numbered="true" toc="default"> <name>LEHO</name> <t> + This record is used to provide LEgacy HOstnames. + </t> + <t> Applications can use the GNS to lookup IPv4 or IPv6 addresses of internet services. However, sometimes connecting to such services does not only require @@ -1466,10 +1469,12 @@ S-Decrypt(zk,label,expiration,ciphertext): Using a GNS name for the "Host"-header may not work as it may not be globally unique. Furthermore, even if uniqueness is not an issue, the legacy service might not even be aware of GNS. - + </t> + <t> A LEHO resource record is expected to be found together in a single resource record with an IPv4 or IPv6 address. - A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>.</t> + A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>. + </t> <figure anchor="figure_lehorecord" title="The LEHO DATA Wire Format."> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 8 16 24 32 40 48 56 @@ -1496,8 +1501,8 @@ S-Decrypt(zk,label,expiration,ciphertext): <section anchor="gnsrecords_nick" numbered="true" toc="default"> <name>NICK</name> <t> - Nickname records can be used by zone administrators to publish an - the label that a zone prefers to have used when it is referred to. + Nickname records can be used by zone administrators to publish a + label that a zone prefers to have used when it is referred to. This is a suggestion to other zones what label to use when creating a delegation record (<xref target="gnsrecords_delegation" />) containing this zone key. @@ -1522,7 +1527,7 @@ S-Decrypt(zk,label,expiration,ciphertext): <dt>NICKNAME</dt> <dd> A UTF-8 string (which is not 0-terminated) representing the preferred - label of the zone. This string MUST NOT include a "." character. + label of the zone. This string MUST be a valid GNS label. </dd> </dl> </section>