commit 1717a4af900c0d1492143a063d406f6429f2fb66
parent 3604c53d5edb71a7f1585e623938cdf5ea5cc0e9
Author: Christian Grothoff <christian@grothoff.org>
Date: Wed, 2 Feb 2022 17:23:00 +0100
SHOULD allow turning of DNS
Diffstat:
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -2060,20 +2060,20 @@ example.com = zk2
GNS2DNS record, there is no "going back".
The (possibly recursive) resolution of the DNS name MUST NOT
delegate back into GNS and should only follow the DNS specifications.
- For example, names contained in CNAME records MUST NOT be
+ For example, names contained in DNS CNAME records MUST NOT be
interpreted as GNS names.
</t>
- <t>
- GNS resolvers MUST offer a configuration
- option to disable DNS processing to avoid information leakage
- and provide a consistent security profile for all name resolutions.
- Such resolvers would return an empty record set upon encountering
- a GNS2DNS record during the recursion. However, if GNS2DNS records
- are encountered in the record set for the apex and a GNS2DNS record
- is explicitly requested by the application, such records MUST
- still be returned, even if DNS support is disabled by the
- GNS resolver configuration.
- </t>
+ <t>
+ GNS resolvers SHOULD offer a configuration
+ option to disable DNS processing to avoid information leakage
+ and provide a consistent security profile for all name resolutions.
+ Such resolvers would return an empty record set upon encountering
+ a GNS2DNS record during the recursion. However, if GNS2DNS records
+ are encountered in the record set for the apex and a GNS2DNS record
+ is explicitly requested by the application, such records MUST
+ still be returned, even if DNS support is disabled by the
+ GNS resolver configuration.
+ </t>
</section>
<section anchor="cname_processing" numbered="true" toc="default">
<name>CNAME</name>