commit 1af28b3804e447ebcbcc76e9a8f615d894b7b878
parent 6e9cf09617b0219d890f529ac8ba18824e5afc67
Author: Christian Grothoff <christian@grothoff.org>
Date: Wed, 2 Feb 2022 16:44:21 +0100
another FIXME
Diffstat:
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -841,6 +841,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
+--------+--------+--------+--------+--------+----
|RESERVED|PRIVATE |SUPPL |EXPREL | SHADOW | ...
+--------+--------+--------+--------+--------+----
+<!-- 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>
@@ -1979,15 +1984,14 @@ example.com = zk2
<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
+ 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 type
+ Implementations MUST NOT allow multiple different zone
delegations under a single label.
- Implementations MAY support any subset of zone types. If
- an unsupported zone type is encountered, resolution fails and an
- error MUST be returned. The information that the zone type is
+ 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 impacting troubleshooting information for the user.
