From: Matthijs Mekking Date: Wed, 11 May 2022 07:39:44 +0000 (+0200) Subject: Nit changes in introduction of DNSSEC chapter X-Git-Tag: v9.19.3~30^2~21 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=fb24454c5876af9445054d4fe82297b0df0d28d6;p=thirdparty%2Fbind9.git Nit changes in introduction of DNSSEC chapter DNSSEC-bis is an uncommon term. Other servers are typically resolvers and they usually are configured with the root key. --- diff --git a/doc/arm/dnssec.inc.rst b/doc/arm/dnssec.inc.rst index ac92aedd0e0..2dffeef121e 100644 --- a/doc/arm/dnssec.inc.rst +++ b/doc/arm/dnssec.inc.rst @@ -15,7 +15,7 @@ DNSSEC ------ Cryptographic authentication of DNS information is possible through the -DNS Security ("DNSSEC-bis") extensions, defined in :rfc:`4033`, :rfc:`4034`, +DNS Security Extensions (DNSSEC), defined in :rfc:`4033`, :rfc:`4034`, and :rfc:`4035`. This section describes the creation and use of DNSSEC signed zones. @@ -32,9 +32,10 @@ indicated by the parent zone for a DNSSEC-capable resolver to trust its data. This is done through the presence or absence of a ``DS`` record at the delegation point. -For other servers to trust data in this zone, they must be -statically configured with either this zone's zone key or the zone key of -another zone above this one in the DNS tree. +For resolvers to trust data in this zone, they must be configured with a trust +anchor. Typically this is the public key of the DNS root zone, although you +can also configure a trust anchor that is the public key of this zone or +another zone above this on in the DNS tree. .. _generating_dnssec_keys: