[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: clean up record processing, exising wri
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: clean up record processing, exising write-up failed on some corner cases and was not as well-ordered as it could have been |
Date: |
Wed, 02 Feb 2022 13:46:54 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 6e9cf09 clean up record processing, exising write-up failed on some
corner cases and was not as well-ordered as it could have been
6e9cf09 is described below
commit 6e9cf09617b0219d890f529ac8ba18824e5afc67
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 2 13:46:52 2022 +0100
clean up record processing, exising write-up failed on some corner cases
and was not as well-ordered as it could have been
---
draft-schanzen-gns.xml | 85 ++++++++++++++++++++++++++++++--------------------
1 file changed, 51 insertions(+), 34 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 485351a..1112353 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1913,50 +1913,67 @@ example.com = zk2
<t>
Upon receiving the RRBLOCK from the storage, as part of verifying
the
provided signature, the resolver MUST check that the SHA-512 hash
of the
- derived authoritative zone key zk' from the RRBLOCK matches the
query q.
- If not, the RRBLOCK MUST be ignored and, if applicable, the storage
- lookup GET(q) MUST continue to look for other RRBLOCKs.
+ derived authoritative zone key zk' from the RRBLOCK matches the
query q
+ and that the overall block is not yet expired.
+ If the signature does not match or the block is expired, the
RRBLOCK MUST
+ be ignored and, if applicable, the storage lookup GET(q) MUST
continue to
+ look for other RRBLOCKs.
</t>
</section>
<section anchor="record_processing" numbered="true" toc="default">
<name>Record Processing</name>
- <t>
- Record processing occurs at the end of a single recursion. We assume
- that the RRBLOCK has been cryptographically verified and decrypted.
- At this point, we must first determine if we have received a valid
- record set in the context of the name we are trying to resolve:
+ <t>
+ Record processing occurs once a well-formed block was decrypted.
+ In record processing, only the valid records thus
+ 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
+ on the context of the name we are trying to resolve:
</t>
- <ul>
+ <ul>
<li>
Case 1:
- If the remainder of the name to resolve is empty and the record set
- does not consist of a delegation, CNAME or DNS2GNS record,
- the record set is the result and the recursion is concluded.
+ If the filtered record set consists of a single CNAME,
+ the remainder of the name is prepended to the CNAME and the
+ recursion is started again from the resulting name.
+ Details are described in <xref target="cname_processing" />.
+ </li>
+ <li>
+ Case 2:
+ If the filtered record set consists exclusively of a one or more
DNS2GNS records
+ resolution continues with DNS.
+ Details are described in <xref target="gns2dns_processing" />.
</li>
- <li>
- Case 2:
- If the name to be resolved is of the format
- "_SERVICE._PROTO" and the record set contains one or more matching BOX
- records, the records in the BOX records are the result and the recursion
- is concluded (<xref target="box_processing" />).
- </li>
<li>
Case 3:
- If the remainder of the name to resolve is not empty and
- does not match the "_SERVICE._PROTO" syntax, then the current
record set
- MUST consist of a single delegation record (<xref
target="delegation_processing" />),
- a single CNAME record (<xref target="cname_processing" />),
- or one or more GNS2DNS records (<xref target="gns2dns_processing"
/>),
- which are processed as described in the respective sections below.
- The record set may include any number of supplemental records.
- Otherwise, resolution fails
- and the resolver MUST return an empty record set.
-
- Finally, after the recursion terminates, the client preferences
- for the record type MUST be considered and possible conversions such as
- defined in <xref target="vpn_processing" /> MUST be performed.
- </li>
- </ul>
+ If the remainder of the name to resolve is empty
+ the record set (including supplemental records)
+ is the final result and the recursion is concluded.
+ </li>
+ <li>
+ Case 4:
+ If the remainder of the name to be resolved is of the format
+ "_SERVICE._PROTO" and the record set contains one or more matching
BOX
+ records, the records in the BOX records are the final result and
the recursion
+ is concluded (<xref target="box_processing" />).
+ </li>
+ <li>
+ Case 5:
+ If the current record set
+ consist of a single delegation record (<xref
target="delegation_processing" />),
+ resolution of the remainder of the name is delegated to
+ the target zone as described in <xref
target="delegation_processing" />.
+ </li>
+ <li>
+ 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>
<section anchor="delegation_processing" numbered="true" toc="default">
<name>Zone Delegation Records</name>
<t>
--
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: clean up record processing, exising write-up failed on some corner cases and was not as well-ordered as it could have been,
gnunet <=